What are the factors for deciding when to implement traceability in a requirements management tool?
Traceability establishes relationships (or connections) among requirements or between artifacts that pertain to the business and those that pertain to software development. For example, you can use your requirements management tool to trace between a requirement and the business objectives, goals or strategies that it enables. Or you can trace between a requirement and the architectural component, design or code that automates it or the tests that verify your code.
Traceability offers several benefits. First, it helps you check your requirements for completeness by helping you identify, for example, a requirement that’s not linked to a business goal, or a goal that’s not supported by a requirement. Traceability also helps you propagate wording changes in multiple documents or artifacts. For example, if your organization primarily uses documents as the authoritative record of requirements within your tool, you may refer to a term or a capability in many documents and in many places in one document. If you decide to change the term or phrase, you need to make that change everywhere the old term appears. Tracing helps you find where the changes need to be made.
Other organizations mainly use models or individual requirements housed directly in their tools as the authoritative record. With some tools, when you make a wording change in one tracked requirement it automatically gets changed everywhere, a process sometimes referred to as “automatic change propagation.” But some tools do not support this feature or make it partial or optional. For those tools, you still need tracing to find where the changes need to be made. If you change wording in docs stored in different tools, cross-tool tracing can help you propagate those changes.
To identify additional business, technical, or testing changes that need to be made because of a proposed requirements change, you need to conduct change impact analysis. Traceability supports this task by identifying where to look to determine whether additional changes are needed. In support of change impact analysis, many tools flag direct as well as transitive linkages. In a transitive linkage, requirements are linked indirectly; for example, if A traces to B and B traces to C, we can see that A traces to C. The link between A and C is transitive.
The good thing -- and the challenging thing -- about traceability is that the tool can trace anything to anything. As part of developing a requirements management plan, you need to establish standards for what types of requirements to keep and which ones to trace (and to what). Keep in mind that tracing requires human overhead, which only increases as you add requirements, create new artifacts and establish new traces. On the bright side, once you’ve established tracing, using a tool’s traceability features speeds checking for completeness, change propagation and change impact analysis.
To create an optimal traceability protocol as part of your requirements management plan, keep the following tips in mind:
- Highly regulated organizations and those whose initiatives focus on health or safety usually need to trace rigorously.
- If you don’t need up-to-date traceability all the time, it may be sufficient to use a matrix or spreadsheet instead of a requirements management tool. This gives you a way to spot- check traceability between any two requirement types or other artifacts.
- If few people use traceability, do some serious thinking. Should you try to expand the usage? Or is it even worthwhile to start a formal traceability effort (even if it is the “right” thing to do)?
- If your industry is not highly regulated or safety focused, or if you are managing a small number of requirements, try to limit your automated tracing to a small set of artifacts. Use coarse tracing, and rely on humans to complete the analysis manually, using the traces as a starting point.
- Some organizations trace each use case to all the tests that cover it. If there is a change in a use case, the analyst or developer can then assess the detailed impact of the change by inspecting the linked tests. In contrast, highly regulated organizations need a more granular approach and should trace, for example, use case steps to specific tests that verify them. When one step changes, the tool identifies which tests are impacted.
This was first published in February 2011