Before starting the traceability activity, it is assumed that the documents being traced (e.g., requirements, design, code, test data, etc.) have been approved.
Using a matrix such as the one shown below (Bidirectional Requirements Traceability, Westfall, 2006), allows a single exercise to show traceability both forwards and backwards. The matrix is completed left to right early in the appropriate phase in the project life cycle. As each column is completed, the forward trace is extended to the next set of products. Simply starting with a column such as the LLD (low-level design) Section and looking at the data in the columns to the left shows the backward traceability from a LLD element to its parent HLD (high-level design) element and back to the parent requirements.
Missing requirements are an indication that the resulting software product may not fully meet the goals and objectives for which the software is being designed. Extra requirements mean the end product may include unnecessary features and functionality which add complexity and allow for additional areas where problems could occur with the software.
This requirement, SWE-052, is specific to tracing software requirements to higher-level requirements; however, traceability also extends to design, code, and test procedures (see SWE-059, SWE-064, and SWE-072). Per the NASA Software Safety Guidebook, the key benefits of tracing requirements include:
- Verification that all user needs are implemented and adequately tested. Full requirements test coverage is virtually impossible without some form of requirements traceability.
- Verification that there are no "extra" system behaviors that cannot be traced to a user requirement.
- Improved understanding of the impact of changing requirements.
When creating a bidirectional traceability matrix, consider the following actions:
- Create the matrix at the beginning of the project.
- Uniquely identify each requirement using a number system that helps convey information about the requirement hierarchy and lineage.
- Capture the source of the requirement, such as the document or standard identifier for the highest level requirements or the unique identifier for the higher-level (parent) requirement.
- List a requirement once and show all of its higher level requirement relationships using the appropriate identifiers; do not duplicate requirements in the traceability matrix.
- Consider including the requirement text in the matrix (rather than just the identifier).
- Keep the matrix maintained throughout the life of the project.
- Assign responsibility for creating and maintaining the matrix to a project team member, since managing the links/references can be a labor-intensive process that needs to be tracked and monitored.
- Maintain the matrix as an electronic document to make maintenance and reporting easier.
- Create the matrix such that it may be easily sorted to achieve/convey bi-directional traceability.
- Provide justification for requirements that are not directly traceable to higher-level requirements to show that they are included for a purpose.
- For example, a system architectural design that creates multiple CSCIs (Computer Software Configuration Items) may result in requirements about how the CSCIs will interface, even though these interfaces are not covered in system requirements. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation.* Have the matrix reviewed at major phases/key reviews of the project
Additional guidance related to bidirectional traceability may be found in the following related requirements in this Handbook:
Bidirectional Traceability Between Software Requirements and Software Design
Bidirectional Traceability Between Software Design and Software Code
Bidirectional Traceability Between Software Test Procedures and Software Requirements