What is a Traceability Matrix?
A traceability matrix is a type of document that creates a relation between two-baseline documents which will have many-to-many relation to check the completeness.
Main use of traceability matrix is requirement tracking and current project requirements are meeting or not.
What is the Requirement Traceability Matrix?
RTM captures all requirements proposed by the client or software development team and their traceability in a single document delivered at the conclusion of the life-cycle.
The main purpose of Requirement Traceability Matrix is to ensure that all test cases are covered so that no functionality should be missed while doing testing.
In Agile methodology we don’t prefer to have a requirement traceability matrix as it is having a fast paced work model and the turnaround time is shorter.
Some specific parameters in RTM to make it more efficient as follows :
Parameters of requirement traceability matrix:
- Requirement ID
- Risks
- Requirement Type and Description
- Trace to design specification
- Unit test cases
- Integration test cases
- System test cases
- User acceptance test cases
- Trace to test script
RTM flow:
RTM is used to track or trace the requirement in all perspectives as per the terminologies Forward and Backward.
Forward traceability:
This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.
Backward or reverse traceability:
It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test cases to requirements.
Types of Traceability Matrix:
Bi-directional traceability (Forward+Backward):This traceability matrix ensures that all requirements are covered by the test cases. It analyzes the impact of a change in requirements affected by a defect in a work product and vice versa.
Let’s Go Ahead and create RTM:
Step 1: Our Test Case is”Verify Login, when correct ID and Password is entered, it should login successfully”
Step 2: Identify the Technical Requirement that this test case is verifying. For our test case, the technical requirement is T94 is being verified.
Step 3: Note this Technical Requirement (T94) in the Test Case.
Step 4: Identify the Business Requirement for which this TR (Technical Requirement-T94) is defined.
Step 5: Note the BR (Business Requirement) in Test Case.
Step 6: Do above for all Test Cases. Later Extract the First 3 Columns from your Test Suite. RTM is Ready!
Before we discuss the details, it’s important to understand the difference between BRD and FRS.
FRS documents detail out the BRD and split each business requirement into multiple functional requirements. Hence in an RTM, you can opt to highlight both the BRD Number and FRS Number to ensure all BR’s are mapped to FR’s. So the table below showcases the same wherein the BR and FR ID’s are mapped.
Below is a sample of the test scenario document:
| S. No | Test Scenario ID | Test Scenarios |
| 1 | TS_Sign-up_001 | Verify whether the user is able to sign-up via sign-up form, facebook, gmail. |
| 2 | TS_Login_002 | Verify whether the user is able to login via login form, gmail, facebook. |
| 3 | TS_User Profile_003 | Verify whether the user is able to fill all required details and save them. |
Test Scenario Document
In the above table, the test scenario document highlights the test scenario ID used in the RTM document. The document will ensure that all the test scenarios should cover all the requirements mentioned in the requirements document. Likewise, a test case document which shows the mapping between the test scenario ID and test cases.
Advantage of Requirement Traceability Matrix
- It confirms 100% test coverage.
- It highlights any requirements missing or document inconsistencies.
- It shows the overall defects or execution status with a focus on business requirements.
- It helps in analyzing or estimating the impact on the QA team’s work with respect to revisiting or re-working on the test cases.
