A traceability matrix is a document that aims to establish the relationship between two documents that usually comes in tabular form. It usually consists of many-to-many relationship comparisons, which means that multiple records in one document are related to various data points in another document. In other words, there is no exclusivity in the relationship between records in each document.
A traceability matrix is commonly used in software development and testing to ensure that client requirements are met. For this reason, the document is also referred to as the “Requirements Traceability Matrix (RTM).”
Other interesting terms…
Read More about a “Traceability Matrix”
A traceability matrix is based on the relationship between two baselined documents. In software testing, one of these documents contains the client’s specific requirements, while the other is for different test cases. The traceability matrix is then submitted to the client during product delivery.
Benefits of Using a Traceability Matrix
Project managers use a traceability matrix to ensure the completeness of software testing and confirm adherence to client requirements. It helps them and software developers ensure that the product is up to par and all necessary tests were performed. It also helps them identify any missing features or functionality the client requested easily.
On the client’s part, a traceability matrix lets them know what tests have been completed and check that the development team fulfilled all they asked for.
A traceability matrix makes software development and testing transparent, removing doubts about the existence of loopholes. And even when there are, the matrix can help development teams address them immediately.
How Do You Create a Traceability Matrix?
To illustrate how a traceability matrix is prepared, consider these two documents as a baseline:
- Document A contains the test cases.
- Document B contains the client requirements.
The identifiers on Document A are placed on the first column of the traceability matrix, while those on Document B become the labels on the first row. When a test case on the left column fulfills a requirement on the top row, the corresponding cell is marked.
The traceability matrix would look something like this but there could be dozens of more identifiers on the left column and the top row in the real world.
In Table 1 above, Test Case 1.1 completed the client’s first and second requirements. Test Case 1.2 was done to fulfill the second and fourth requirements, while Test Case 1.3 was for the first and third requirements. Lastly, Test Case 1.4 completed the client’s second to fourth requirements.
A traceability matrix could be as simple as the table above. Or it could also contain a lot more information, such as each requirement’s status (e.g., defective, submitted, accepted, or rejected by the client). The document could also be linked to the details of each use case.
A screenshot of such kind of traceability matrix from Think Thyme is shown below.
—
With a traceability matrix, software developers and project managers would easily see when a particular client requirement is not addressed by any test case. As a result, they would be able to take immediate action and remedy the problem before the product delivery date.
A traceability matrix can be as simple as Table 1 or as exhaustive as that in the screenshot above. The goal is to trace the fulfillment of client requirements and ensure that they are accounted for and performed accordingly.
