![]() |
VOOZH | about |
Here we will discuss the Requirement Traceability Matrix (RTM). The following 8 topics will be discussed:
Table of Content
Let's start discussing each of these topics in detail.
RTM stands for Requirement Traceability matrix. RTM maps all the requirements with the test cases. By using this document one can verify test cases cover all functionality of the application as per the requirements of the customer.
The main purpose of the requirement traceability matrix is to verify that the all requirements of clients are covered in the test cases designed by the testers.
In simple words, one can say it is a pen and pencil approach i.e., to analyze the two data information but here we are using an Excel sheet to verify the data in a requirement traceability matrix.
When business analysis people get the requirements from clients, they prepare a document called SRS (System/Software Requirement Specification) and these requirements are stored in this document. If we are working in the Agile model, we call this document Sprint Backlog, and requirements are present in it in the form of user stories.
When QA gets the SRS/Sprint backlog document they first try to understand the requirements thoroughly and then start writing test cases and reviewing them with the entire project team. But sometimes it may happen that in these test cases, some functionality of requirements is missing, so to avoid it we required a requirement traceability matrix.
The below figure shows the basic template of RTM. Here the requirement IDs are row-wise and test case IDs are column-wise which means it is a forward traceability matrix.
From the figure below, it can be seen that: RTM
The following are the parameters to be included in RTM:
There are 3 types of traceability matrix:
In the forward traceability matrix, we mapped the requirements with the test cases. Here we can verify that all requirements are covered in test cases and no functionality is missing in test cases. It helps you to ensure that all the requirements available in the SRS/ Sprint backlog can be traced back to test cases designed by the testers. It is used to check whether the project progresses in the right direction.
In forwarding the traceability matrix:
Rows = Requirement ID
Column = Test case ID
In the backward traceability matrix, we mapped the test cases with the requirements. Here we can verify that no extra test case is added which is not required as per our requirements. It helps you to ensure that any test cases that you have designed can be traced back to the requirements or user stories, and you are not extending the scope of the work by just creating additional test cases that can not be mapped to the requirement. The backward traceability matrix is also known as the reverse traceability matrix.
In the Excelbackward traceability matrix:
Rows = Test cases ID
Column = Requirement ID
A bi-directional traceability matrix is a combination of a forward traceability matrix and a backward traceability matrix. Here we verify the requirements and test cases in both ways.
Bi-directional traceability matrix = Forward traceability matrix + Backward traceability matrix
When testers design the test cases they need to check whether test cases cover all functionality of the application as per the requirements of the customer given in the SRS/Sprint backlog.
Before creating RTM SRS/Sprint backlog documents and test cases documents are required. Below are the steps to create RTM:
Below are some benefits of using RTM:
The below figure shows the basic template of RTM. Here the requirement IDs are row-wise and test case IDs are column-wise which means it is a forward traceability matrix.
From the figure below, it can be seen that: