What is Requirement Traceability Matrix (RTM)?

Posted in

What is Requirement Traceability Matrix (RTM)?

Sameeksha Medewar
Last updated on May 22, 2024

    The primary goal of the software development process is to deliver high-quality and error-free software products that meet quality standards and end-user requirements. To ensure that software products are error-free and satisfy end-user requirements, a team of professional testers performs various types of testing on them.

    Furthermore, every software product is associated with various types of requirements, including business requirements, UI requirements, technical requirements, functional and non-functional requirements, and user requirements. Each type of requirement plays a vital role in the development of software products.

    It is essential for the testing team to consider each requirement carefully during the testing process so that no functionality of the software product is left unchecked, and this is where the requirement traceability matrix comes into the picture.

    The requirement traceability matrix is a document that links the user requirements stated by the clients at the onset of the development process to the software product under development. In other words, the requirements traceability matrix is a document that links and traces the user requirements with test cases to ensure that every requirement undergoes an adequate level of testing.

    In this blog post, we shall make you familiar with what exactly the requirements traceability matrix is, along with its importance and the types of traceability matrix.

    What is the Requirement Traceability Matrix?

    The requirement traceability matrix, often abbreviated as RTM, is a detailed document that maps and traces all the requirements of a particular product with the test cases.

    Now, you may wonder what exactly the term test case means. Well, a test case is a set of actions that a team of professionals performs on a particular software product to verify that it functions correctly.

    The primary purpose of RTM is to make sure that the testers test every requirement through its corresponding test cases. It also ensures that the software product is in conformance with the specified requirements.

    Benefits of RTM

    The following are some significant advantages of RTM:

    • RTM helps you to easily determine the missing functionality of the software product.
    • It ensures 100% test coverage.
    • When there is a change in the requirements, RTM allows you to determine the test cases that you need to update.
    • It helps you understand the impact of the requirement changes on the software product.
    • It helps you track the overall defects and the test execution status.

    Why is the Requirement Traceability Matrix Important?

    In the testing process, it is essential for testers to have a clear understanding of all the requirements specified by the end-users. Based on these requirements, they create positive and negative test cases.

    Moreover, it is important to note that each requirement can have multiple test cases, where testers test each test case individually. They check each requirement by executing all the possible test cases.

    The requirement traceability matrix consists of multiple requirements, along with their corresponding positive and negative test cases and the state of each test case. Here, the state of a test case is either pass or fail.

    As a result, this document provides in-depth insights into the testing activities performed on the software product and which requirements have produced a large number of defects. Also, it ensures that the testers perform thorough testing on every requirement and do not leave any functionality of the software product unchecked.

    Types of Traceability Matrix

    In software engineering, there are three different types of traceability matrix, namely forward traceability, backward or reverse traceability, and bi-directional traceability.

    1. Forward Traceability

    The forward traceability matrix maps the requirements to the test cases. It checks that the product development moves in the right direction as expected and that each business need or requirement is tested accurately and thoroughly.

    2. Backward or Reverse Traceability

    The backward or reverse traceability matrix maps the test cases to requirements. This type of traceability matrix also ensures that the product under development moves on the right track. Moreover, it ensures that we are extending the scope of the software product by adding extra functionalities that are not specified in the requirements.

    3. Bidirectional Traceability

    As its name suggests, bidirectional traceability is an amalgamation of forward and backward traceability. It maps the requirements to the test cases and vice-versa. Furthermore, it ensures that we can trace test cases to requirements, and every requirement has accurate and valid test cases.

    How to Create the Requirement Traceability Matrix?

    Test engineers are responsible for creating RTM in the early stages of the software development life cycle. They ensure that RTM incorporates everything required to make the development of the software product successful. The following are the steps to creating RTM:

    • Gather all the business requirements or needs specified by the end-users.
    • Assign each requirement with a unique requirement ID.
    • Later, create test cases for each requirement, allocate an ID for each test case, and finally, link the test case IDs to the respective requirement ID.
    • If the testers find the defect while testing a specific requirement, they assign it a unique defect ID and map it to the corresponding test case IDs and the requirement ID.


    Now, consider that we have three business requirements, with requirement IDs BR1, BR2, and BR3, respectively. Each business requirement has the corresponding test scenario, i.e., BR1 has TS1, BR2 has TS2, and BR3 has TS3.

    Let us now say that BR1 has two test cases, namely TC1 and TC2. Similarly, say BR2 has three test cases, namely TC1, TC2, and TC3, and BR3 has two test cases TC1 and TC2. In addition, BR3 involves the first test case from BR1 and BR2.

    Moreover, consider there is a defect in BR1, and let us assign it as D01. There are two defects found in BR, namely D02 and D03. Finally, there is no defect in BR3.

    Our RTM will look like this:

    Business Requirements Test Scenario Test Cases Defects
    BR1 TS1 TS1.TC1 TS1.TC2 D01
    BR2 TS2 TS2.TC1 TS2.TC2 TS2.TC3 D02 D03
    BR3 TS3 TS3.TC1 TS3.TC2 TS1.TC1 TS2.TC1 NIL

    RTM varies from organization to organization. Besides the parameters in the above-mentioned RTM, other parameters include requirement description, test phase from STLC , test case result, document owner, etc. In addition, whenever there is a change in the requirements, you need to update RTM accordingly.


    The requirement traceability matrix (RTM) consists of all the requirements that the client specifies at the beginning of SDLC, along with their corresponding test cases and defects discovered.

    This document ensures that no requirement is left unchecked and the final software product meets all the client’s requirements without any defects. In addition, it highlights the missing requirements and the testing activities performed on the software product.

    We hope you found this article informative and helpful. Still, if you have any queries regarding this topic, feel free to post them in the comments section below.

    People are also reading:


    No, the test matrix and RTM are two different documents. The test matrix is a document that captures the quality, effort, plan, resources, and time required to finish all the phases of STLC. On the other hand, RTM is a document that maps the requirements of the software product with test cases.

    The following are the three types of traceability matrix: Forward traceability Backward or reverse traceability Bidirectional traceability

    Test coverage is a software testing metric that determines the amount of testing that a particular test suite covers. In other words, test coverage is a metric that determines how much of the total code is exercised when you run a specific suite of test cases.

    Leave a Comment on this Post