Software development and testing use a straightforward concept called Requirements Traceability Matrix. Once you understand it and see the examples in this article, you will understand that the Requirements Traceability Matrix is an easy concept and you will use it effectively in your project.
The implementation of requirement traceability or the more it gets implemented in your project depends on your project lifecycle.
People will try to come out with more and more features or requirements to a project when the project starts. The goal of the Requirements Traceability Matrix is to ensure, all new features meet the projects higher-level business requirement which in turn meet the business objectives.
WHAT IS REQUIREMENTS TRACEABILITY MATRIX :
RTM’s shown as a table or a spreadsheet that maps the test cases against each requirement. It is one of the important and necessary documents in test artifacts. Just like every other test artifacts in software testing RTM also varies between project to project and company to company. Most of the organizations use just the requirement ID and the test case ID’s in the RTM. It is necessary to update the RTM whenever there is a change in requirement
WHAT IS THE USE OF REQUIREMENTS TRACEABILITY MATRIX?
When you look at the table we will come to know whether all the requirements have been covered by your test cases or not:
- Determines whether all the requirements are being covered 100% or not.
- Easy to determine the impacted test cases for regression.
- Prevents us from missing any functional requirement.
- Helps us to identify the importance of a particular requirement based on the mapping table.
- Can be used as a tracker in case of requirement changes.
- Makes our life easy when we are going over the test case review.
TYPES OF REQUIREMENTS TRACEABILITY MATRIX
Requirement ID and the test case ID is used by most of the organizations in the RTM. It is essential to update the RTM whenever there is a change in the requirement.
1. FORWARD TRACEABILITY:
Forward traceability is mapping requirements to test cases. It ensures that the project progresses in the decided direction. It makes sure that each requirement is testing thoroughly.
Backward or Reverse Traceability Matrix is mapping test cases to requirements. It ensures whether the current product remains on the right track. It also makes sure that we are not expanding the scope of the project by adding other functionality that is not specified in the requirements.
3. BI-DIRECTIONAL TRACEABILITY:
Bi-directional Traceability Matrix is mapping requirements to test cases and test cases to requirements. It ensures that all the specified requirements have appropriate test cases and vice verse. It is the combination of both the forward and backward traceability.
In the below table, Req1, Req2, etc., are the requirements of a project. But many organisation gives other names according to your software requirement specification like 1.1 or 1.0.1. You can have anything as a requirement ID. Every requirement will have a unique ID. Similarly, for test cases also. Each test case has a different ID. It can be TC001, TC002, etc.
Here, the test case has several requirements to be tested.
The above example requirement REQ1 has two test cases – TC001, TC004
REQ2 has two test cases – TC001, TC003
REQ3 has four test cases – TC001, TC003, TC004, TC005
REQ4 has only one test case – TC004
REQ5 has three test cases – TC002, TC003, TC004., and so on.
RTM indicates the relationship between each requirement and each test case. It is a many to many relationships. Which means one requirement may not be covered by a single test case. It may take one or more test cases to test that requirement.
PRO TIP: RTM implementation should be a priority in every project. If not, then you will end up with the chaos, having multiple requirements and numerous test cases if not then, you have to go through every test case and requirements to figure out the relationship, which consumes a lot of time. So, it is necessary to create RTM as early as possible in a project.
Requirements Traceability Matrix is just a summary of the relationship between requirements and test cases. RTM cannot have any texts. It should be in the ID.