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 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.
While traceability matrices are not the only method for capturing bidirectional traceability, they are the most common. Traceability matrices can be included in the documents to which they apply, such as a test plan, or they can be combined into a single matrix covering higher level requirements, software requirements, design, code, and verification. General guidance for creating a bidirectional traceability matrix includes the following suggested actions:
- Create the matrix at the beginning of the project.
- Uniquely identify the elements in the matrix (requirements identifiers, design document identifiers and paragraph numbers, function identifiers, test identifiers, etc.).
- 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/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.
- Ensure a review of the matrix at major phases/key reviews of the project.
A bidirectional traceability matrix can be manually created and maintained, or may be a by-product of a requirements management tool. The tracing system needs to be chosen based on project complexity and the number of requirements. Check with project management to see if a requirements management tool exists for the local project that is capable of producing a bidirectional traceability matrix.
Keep in mind that a single requirement could trace to multiple test procedures. The reverse is also true, test procedures could trace back to multiple requirements, so the relationships identified in the matrix are not required to be one-to-one. The matrix needs to contain no missing relationships, i.e., empty cells in the matrix, as those indicate a problem with the set of test procedures which need to be designed such that every requirement is verified.
It is possible that new requirements may be generated during design and implementation. When that happens and the requirements are confirmed as being within the scope of the project (not expanding the scope or "gold plating" the system by including unnecessary functionality), the traceability matrix needs to be revised to include the new requirements and the mapped design elements, implementation (source code), and test procedures.
If the software verification team is not the same as the requirements development team, collaboration may be needed to ensure proper bidirectional traceability between test procedures and requirements.
To ensure full traceability between requirements and tests, it is important to trace test cases, test scripts, test data, and other supporting test information not already found in the test procedures to the relevant test procedures. This level of trace information may or may not appear in a traceability matrix. The test procedures, test cases, test scripts, and test data can include the proper links and references to ensure full traceability among all the elements of the tests.
Key aspects of tracing test procedures include:
- Ensure that tests for safety-critical functions are clearly identified either through the traceability matrix or through test procedure documentation.
- Trace each requirement and functional specification to one or more test cases (Manager's Handbook for Software Development).
- If not already done, trace unit tests to source code and to design specifications.
- Trace integration tests to high-level design specifications.
- Trace system tests to software requirement specifications (SRS).
Additional guidance related to bidirectional traceability may be found in the following related requirements in this handbook:
Bidirectional Traceability Between Higher Level Requirements and Software Requirements
Bidirectional Traceability Between Software Requirements and Software Design
Bidirectional Traceability Between Software Design and Software Code