I have just completed two years building a software team for embedded medical device development using agile/XP development techniques. We were very successful and I’ve learned a lot and I want to share some of those lessons here. But there were definitely some areas that didn’t go as smoothly as I would have liked. The biggest gap for me was requirements traceability and especially the disconnect between the requirements/specification work and the day-to-day activities of the team. I’d like to explore some new ideas on this blog to improve traceability and make it very visible in the team’s work.

Basic traceability usually stacks up like this:

Product Requirements →
System and/or Software Specification →
Design →
Code →
Unit Tests →
Verification Tests →
Validation Tests

But that’s too simplistic for me. Where does hazard analysis and associated mitigations fit; why don’t we have a place for the stories and tasks that a development team uses to manage an iteration; what criteria do we use to ensure that traces are complete; where does architecture fit; what aspects of design are relevant; and most important for me: how does traceability help us to accept and embrace change throughout the product development process?

Lots of questions…

This will take some time to explore.


Published by amaxo

This is the "wpengine" admin user that our staff uses to gain access to your admin area to provide support and troubleshooting. It can only be accessed by a button in our secure log that auto generates a password and dumps that password after the staff member has logged in. We have taken extreme measures to ensure that our own user is not going to be misused to harm any of our clients sites.