This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Where do you guys stand on requirements traceability? This is another one of those big CMM things. It's also something that can cause a lot of pain for the individual developer, as quite often what is being looked for is a way to tie project artifacta (design diagrams, code, etc...) back to a requirement, keeping in mind of course that some artifacts are architectural and do not address specific requirements. That said, I haven't seen any painless way to really implement this that a developer can latch onto without wanting to pull his hair out.
I've been thinking that it might be fairly painless to annotate the requirements addressed by a class or method in comments, and then use a tool like XDoclet or even simple text processing to run against the code base to produce a report detailing what code is affected by a change in a given requirement, for example.
What have you guys seen as far as handling requirements traceability?
If you order your work via The List and The List is populated via your bug tracking or feature tracking software, you can link your specific List items back to an entry in the bug or feature software. The bug or feature tracking software allows for lots of detail on who requested an item, who's edited the request over time, etc.
You can also reference a bug number or feature request number in your source code checkin comments. The number can used to look up the issue in the tracking software. You can even past in a link for some systems.
Given how many different requirements might drive a given class or routine over time, I'd be inclined to keep that information out of the code and in the source code management system.
Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
If you just want to know what requirements a certain line of code is needed for, you could just delete that line (temporarily) and observe what acceptance tests fail...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jun 22, 2005
Originally posted by Ilja Preuss: If you just want to know what requirements a certain line of code is needed for, you could just delete that line (temporarily) and observe what acceptance tests fail...
As someone who does agile development, but is familiar with how a number of shops do rigorous requirements traceability, the thing that's always astonished me is that 99% of the time, what they actually do is trace requirements to design/architecture artifacts. They do not trace requirements to real code, or least of all to executable tests.
We do semi-formal traceability to tests on one project I'm on: if you point to a story on our "done" list, I can tell you which tests prove that story is done and works, and I can tell you which "bullet" in a requirements document inspired that story. This is something that most XP shops would be able to do with a minimum of effort. We have never found it useful in any way, but we wanted to see if it could be done.
Jason, What do you do for requirements traceablility now? We're getting started with CMM. For now, we're just documenting that the requirement is in a certain release though. For major requirements we estimate and track time per really high level requirement, but it's not tied to the code in any way.