A Requirements Traceability Matrix (RTM) is a test document for illustrating test coverage for business requirements. By providing data like test cases or testing status, the record acts as a visual aid for the testing team and other stakeholders so they can easily track the progress of each requirement concerning testing.
Types of Requirements Traceability Matrix
There are three types of RTMs; bidirectional, forward, and backward traceability. The main ways they differ are in the relationship between business requirements and test cases.
- Bidirectional traceability – This type of matrix is most often used because it traces the requirement to the test case and the test case to the requirement. This facility benefits large and small projects.
- Forward traceability – This matrix type displays the relationship between requirements and test cases. It confirms test coverage for each requirement and is helpful for noting their progress. It also benefits stakeholders who may only want to see minimal data on the coverage of each requirement.
- Backward traceability – In contrast, backwards-facing traceability takes the test cases and displays the relationship in reverse to the requirement. This view is more beneficial for test leads, enabling them to track testing momentum or compare any progress to the testing schedule.
Steps for Creating a Requirements Traceability Matrix
Step 1 – Gather Requirements
Before you can create the requirements traceability matrix, you will need to collect business requirements. These should include the product’s purpose, functional and non-functional requirements, and any other information that describes the product’s objectives. Ideally, a product manager or other stakeholder will provide these as a formal document.
The requirements list forms the basis of the matrix, so it’s important to clarify any questions as soon as possible to prevent having to redo work. To keep track of all requirements, each one needs an individual identifier. From this list, you will begin to write test cases that can be saved in your existing test case management system.
Step 2 – Draft
How you format your requirements traceability matrix depends on which type of matrix you create. For this example, we will design a matrix with bidirectional traceability. A convenient way to do this is by using a spreadsheet. Have the requirements listed in the first column and the associated test case in the next. If there is more than one test case, you can add it in the same cell. Check the business requirements list and ensure each entry has at least one test case.
Step 3 – Customize
The previous step describes the minimum required data in the matrix. However, it’s often helpful to have additional columns to provide important information. Depending on the needs of the project, you may want to customize your matrix by adding columns for:
- Tester
- Status (Pass/Fail/Not Run)
- Defects
- Test Run
- Date
Step 4 – Maintain
The matrix will require continuous updating as requirements increase and test cases are added. Depending on the data within the RTM, this can mean a lot of work, but maintaining documentation is critical before it becomes too large and overwhelming.
Benefits
- Coverage – The most significant benefit of using an RTM is ensuring test coverage. Since the RTM is a visual document, it is a quick way to check that each requirement has test coverage.
- Communication – Part of a tester’s job is to share information with stakeholders in a manner they can understand. Since an RTM is easy to interpret, it can be created as a cloud document and shared with anyone who needs to see the status of testing progress.
- Compliance – Since compliance testing can be tedious and specific requirements are non-negotiable, RTMs are a quick way to keep track of testing before the auditing process.
Challenges
Stakeholders sometimes want or expect an RTM, but providing one may not always be practical. For example, it’s usually easier to keep track of requirements and testing progress within a test run using your typical test case management system if the option is available. However, best practice requires testers to keep track of testing progress in two different places. Other challenges come when requirements are changed or added with little notice. When this occurs, it’s essential to document the changes. It is also important to mark this event as a risk if it is likely to put the testing behind schedule.
Tools
As a project grows, requirements can become more complex and intertwined. This is when using tools can be beneficial because they can automatically create RTMs. By entering the requirements and then connecting the associated test cases, these tools will arrange the matrix into a configurable design that is easy to read. If a business requirement is updated, the RTM updates automatically. You can configure test runs to update the results in the matrix automatically.
Conclusion
A Requirements Traceability Matrix can help track test coverage for business requirements. They can be customized and shared so anyone can follow the testing progress, and viewers can obtain data as needed. An RTM can range from being very simple to quite complex. Fortunately, there are resources available to assist in the creation.