Rally / Contour Integration for Requirements Traceability

I’ve been a Rally user for close to five years now and I’ve recommended the product to many of my clients developing products in highly regulated industries. Rally’s support for traceability is pretty standard among agile project management tools. It supports trace relationships between epics, stories, tasks, defects, test cases, and test results. Craig Lagenfeld discussed one way to handle traceability in Using Rally to Map High Traceability User Stories: PRD to SRS and High Assurance Agile Software Development: Traceability Matrix Examples.

Tracing in Rally still leaves a lot to be desired. Rally’s audit trail, especially for trace relationships, can’t be queried or sorted and it’s hard to use in reports. There is no notion of impact analysis when a requirement changes and typically no annotation on the change. It falls far short of my expectation for a complete trace solution.

That’s improved somewhat now with the recently announced new product integration with Jama’s Contour to tie requirements in Contour together with stories in Rally. I haven’t yet test-driven Contour or the Rally/Contour integration, but it’s something to keep in mind as I search for an integrated solution for agile traceability.

 

Traceability

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.