This isn’t technically a testing topic, but it is a topic close to tester’s hearts.  Software requirements are one of my passions (boy is that an embarrassing statement).  While I am definitely not one of “those testers” who say testing can’t be done without requirements, I am a firm believer that well written requirements are a key component of a successful software project.

Once you have requirements (I’ll save my opinions of what well written requirements are for another post), how important is it to track these requirements throughout the rest of the engineering process?  I would expect to see a design document explain design and implementation details for each requirement.  I’d also expect a test design specification (or test plan) describe how each requirement would be tested.  Somewhere along the line, I also convinced myself that each test case should link back to the requirement it was testing.  The implementation of this could be very complex, but it could potentially help a tester target a lot of rework if (and when) requirements changed.

The problem of course, is that there aren’t a lot of tools to aid in this level of requirements tracing.  Enterprise requirements tracking tools are available, but they are expensive, and overkill for many smaller projects.  On the other hand, some level of requirements tracing can be done with word and excel, but the complexity can quickly get out of hand with any non-trivial project.

The question I end up asking myself is not whether I should trace requirements, but when and where and how I should trace requirements.  There’s also the issue of educating the rest of the team on the value of requirements tracing, as well as any implementation details that a solution would involve.

I’ll follow up with more of my thinking in this area in a future post.  While this discussion isn’t as exciting as curly brace placement, I’d still appreciate any comments.