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.
