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.

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.

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 (2)

  1. Actually this is one of my daily chores — one of my roles is administering a Requirements Tracability tool — in addition to being a software developer — except the requirements in this case relate to the requirements associated with systems engineering, rather than software.

    As for a requirements management tool, other than the well-known Rational tools there are quite a few tools out there competing for the whole "requirements traceability" market.

    In Systems Engineering, there is some importance in tracking the requirements throughout the engineering process — requirements tracability — being able to trace why you’re designing a certain component of a system and its purpose by being able to trace it all the way back to its requirement.

    Tools (though some are geared somewhat to the Systems Engineering process) to support this are: Doors by Telelogic, Core by Vitech Corporation, Cradle by 3sl, Teamcenter Requirements by UGS, Artisan Real-Time Studio by Artisan Software…

    Important to note is that there’s a fine line between requirements management — managing changing requirements over time, maintaining an approved, baseline version, etc — and requirements tracability — managing the "things" associated with a particular requirement — functional analysis, physical, responsibility.. the goals of each are not necessarily condusive to one another.

    We’re using Core to support our requirements tracability efforts — additionally Core includes some diagramming functionality — physical and functional hierarchies for instance, and also allows us to develop functional flow block diagrams, IDEF0, and N2 diagrams with full tracability from the diagram elements (Function blocks for example) back to the requirement.

    IMHO, Core has (many) rough edges, (and happens to be one of the few commercial programs out there that are still being developed in Smalltalk) but it functions farily well for what we need.

  2. Jim Miles says:

    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.

Skip to main content