Requirements Tracebality Matrix

A matrix is a table that maps one variable to another.

A requirements traceability matrix or RTM maps requirements to test cases.

Example - Requirements Traceability Matrix (RTM)

Background

For any project, the business analyst builds requirements based on business needs. The BA prioritizes the requirements as critical (Level 1), major (Level 2) and good to have (Level 3).

Based on these requirements, the QA does his test design. For each requirement, the QA plans and scripts his test cases. At the end of this design, the QA builds a RTM and verifies that each requirement built by the BA will be tested by at least one test case.

That is the purpose of Requirements Traceability Matrix. The table what is RTM, clearly lays out what is called Test Coverage.

For different types of testing, there could be different requirements.

• System testing has module level technical requirements based on the solution for the business requirements.
• System Integrated Testing has business scenario requirements.
• User Acceptance Testing has user prioritized business scenario requirements.
• Performance testing has non functional requirements (NFR).

Sign Off decision based on RTM and test coverage

However in each case, a sign off authority would sign off the test design only by checking the test coverage based on the Requirements Traceability Matrix.

Go/No Go Decision

Another use of RTM is to take a Go/No Go decision. 

It is possible that in the planned amount of time, QA could not execute all scheduled tests. In this case, the QA lead and the BA can check the RTM and see which requirements were not tested 100%. Now based on the priority of the partially tested requirements, the leads can easily decide if the software is fit to move to production.