Tracking Requirements

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.

Comments

• Anonymous
  February 25, 2005
  The comment has been removed
• Anonymous
  April 06, 2006
  We have approached this problem in TopTeam Analyst by providing four different traceability views and editors. So users can take their pick and choose the interface that they like best.
  
  For example, there is the traditional "Traceability Matrix" and there is also a new "Trace Network Diagram" which shows the trace relationships as a network.  What we have found is that most users tend to gravitate towards the newer "Trace Network" interface.