Two Laptop Bag
The moose likes Agile and Other Processes and the fly likes [Ship It!] Requirements traceability Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "[Ship It!] Requirements traceability" Watch "[Ship It!] Requirements traceability" New topic

[Ship It!] Requirements traceability

Jason Menard

Joined: Nov 09, 2000
Posts: 6450
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?
Jared Richardson
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
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="" target="_blank" rel="nofollow"></a>
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
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
Jared Richardson
Ranch Hand

Joined: Jun 22, 2005
Posts: 113
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...

Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

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.

[Jess in Action][AskingGoodQuestions]
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33130

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.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
I agree. Here's the link:
subject: [Ship It!] Requirements traceability
It's not a secret anymore!