Requirements Traceability: Why Bother

Requirements have a habit of breeding. A little of this gets added here, a little of that gets slid in over there. Typically it all happens because every member of the project team and the business subject matter experts wants to get as much out of the project as possible. But unchecked scope creep inevitably causes downstream issues in project cost, time or quality. Scope creep is just one area where requirements traceability can help.

The good news is that your development team’s process for finding out what users really want has been effective, and you have developed sound practices for eliciting software requirements.  The bad news is that there are so many requirements! Everyone has an opinion and a desire. In many organizations, an active project is an open call to fill whatever gap people have.

Good project management and good requirements prioritization are a good start in curbing prospective users’ never-ending appetites. But every requirement that wiggles its way into the project increases design, development and testing time, and cost. Every added requirement threatens to move a project from straight-forward to complex or from already complex to fear-inducing ridiculous. This is just one area where a requirements traceability practice can help.

Requirements traceability is defined in the International Institute of Business Analysis Body of Knowledge V2.0 as, “The ability to identify and document the lineage of each requirement, including its derivation (backward traceability), its allocation (forward traceability), and its relationship to other requirements.” In short, you can trace a requirement back to the defined and agreed-to business goals for the project, and you can trace the requirement down to the design and code that implements it and the test case that tests it.  See the sample picture below.

Traceability in software requirements

Why Bother With Traceability

There are three key reasons to add a requirements traceability practice:

1. Improve scope management.

I’ve never met anyone who wants to add a requirement in order to be malicious. Any user who adds “just one more thing…” believes he or the organization has a gap the project can accommodate. It is not easy to say no. Even employing a priority scale to the requirement does not ensure the requirement should be part of this project. Whoever is eliciting and managing the project requirements has to be able to trace a functional requirement back to a feature or need that is part of the defined  project scope. The same is true for any type of requirement.

On the flip side, requirements can be missed. By using traceability, the person managing requirements can look at each need and feature to make sure that there is a lower level set of requirements that fulfill the scope. It’s far better to catch this miss during a requirements phase than to have to add to the project at a later date where it typically costs more and can damage your reputation with your client.

2. Improve test coverage and test cost.

Full coverage testing is both impractical and costly. Traceability can help here as well. A high-priority requirement must have an associated test case or condition. If a requirement cannot be traced to any test cases, the team can ask if that is appropriate based on risk of a problem and impact of a problem to the business. Good traceability aids in defining appropriate and necessary test coverage.

As above, there is a flip side. Finding that a low priority requirement is traced to a large number of test cases or conditions can indicate that the solution is being over-tested, resulting in more time and dollars spent than required.

3. Improve change impact assessment.

Changes to scope or business needs happens even in the most agile of projects with highly skilled analysts and scrum masters. We need a mechanism to fully understand the impact of a change and to provide a full accounting of what needs to happen to accommodate the change. With good traceability in place, a change to a requirement can be mapped to lower level requirements, to code components, and to test artefacts. The team is better positioned to understand exactly where the impact is, what needs to be touched, and what needs to be retested. And, of course, the team will understand what does not need to be touched or retested!

Beware the Pitfalls

While the reasons for requirements traceability are compelling and the potential benefits appealing, there are some pitfalls.

Traceability can be hard to do without proper tools. Simple traceability, between groupings of requirements to test cases for example, can be reasonably managed with spreadsheets. This approach is best left to small, simple projects. But when a project has hundreds of use cases or needs a finer breakdown of trace relationships, a spreadsheet quickly becomes cumbersome. It is hard to keep it up to date and reports need to be custom created. The cost of managing this way can outweigh the benefits.

The old saying is true: When you have a hammer, everything looks like a nail. When a requirements management or development or testing tool is in place that supports traceability, there is a tendency for people to try to trace everything, sometimes at an excruciating level of detail. You can have too much of a good thing! Along with the automated support, plan on building a practice for determining the project characteristics and the appropriate traceability approach. For example:

    • For most mid-sized projects, it is usually sufficient to trace at the level of use case paths (normal flow, alternative flows and error flows) up to features and needs, and down to test cases/conditions.

 

    • A project dealing with very complex functions or functions related to safety may well have to trace at a lower level of granularity and maintain more traceability relationships.

Start small, and focus the effort on the areas likely to be of highest benefit. Typically, this is requirement- to-requirement relationships with some level of tracing to test artifacts. Avoid a one-approach-solves-all to projects. Your traceability approach should be a conscious decision for each project.

Requirements have a habit of breeding. A little of this gets added here, a little of that gets slid in over there. Unchecked scope creep inevitably causes downstream issues in project cost, time, or quality. Missed requirements and flawed test coverage can add significant costs to projects. Traceability improves scope management, helps keep testing focused and cost-effective, and improves your ability to assess the impact of project change requests.











RedditFacebookTwitterGoogle+Hacker NewsLinkedInEmailPinterestShare

Comments

  1. And how do you ensure all requirements are captured?

Speak Your Mind

*