What is Requirement Traceability Matrix RTM? – Learning Guide
What is requirement traceability matrix RTM in Project Management

What is Requirement Traceability Matrix RTM? – Learning Guide

Last updated on 15th Jul 2020, Blog, General

About author

Yuvan (Sr Project Manager )

He is a Proficient Technical Expert for Respective Industry & Serving 11+ Years. Also, Dedicated to Imparts the Informative Knowledge to Freshers. He Share's this Blogs for us.

(5.0) | 17953 Ratings 3680

What is the Traceability Matrix? (TM)

  • A Traceability Matrix is a document that co-relates any two-baseline documents that require a many-to-many relationship to check the completeness of the relationship.
  • It is used to track the requirements and to check the current project requirements are met.

What is Requirement Traceability Matrix?

Requirement Traceability Matrix (RTM) is a document that maps and traces user requirements with test cases. It captures all requirements proposed by the client and requirement traceability in a single document, delivered at the conclusion of the Software devlopement life cycle. The main purpose of Requirement Traceability Matrix is to validate that all requirements are checked via test cases such that no functionality is unchecked during Software testing.

    Subscribe For Free Demo

    [custom_views_post_title]

    Requirements Traceability Matrix

    The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols. The traceability matrix is a tool both for the validation team, to ensure that requirements are not lost during the validation project, and for auditors, to review the validation documentation.

    The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Requirements Specification). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested.

    Requirements Traceability Matrix Example

    The traceability matrix can either reference the requirement identifiers (unique numbers for each requirement)  or the actual requirement itself.  In the example shown below, requirements are traced between a Functional Requirements Specification, Design Specification, and Operational Qualification.

    Functional RequirementsDesign SpecificationsTest Cases
    The program will have a functional audit trail.Each form will use fxn_Audit_Trail in the OnUpdate event procedure.OQ, Test Case 3, Step 52: Audit Trail Verification
    • For more examples, see our FastVal Traceability Matrix template.
    • In more complicated systems, the traceability matrix may include references to additional documentation, including user requirements, risk assessments, etc.
    • The traceability matrix can be created and maintained in an automated tool, in an Excel spreadsheet, or MS Word table.

    RTM – WorkFlow:

    • The Matrix is created at the very beginning of a project as it forms the basis of the project’s scope and deliverables that will be produced.
    • The Matrix is bi-directional, as it tracks the requirement forward by examining the output of the deliverables and backward by looking at the business requirement that was specified for a particular feature of the product.
    requirements_traceability_matrix

    Requirement traceability Matrix – Parameters:

    • Requirement ID
    • Risks
    • Requirement Type
    • Requirement Description
    • Trace to Design Specification
    • Unit Test Cases
    • Integration Test Cases
    • System Test Cases
    • User Acceptance Test Cases
    • Trace to Test Script

    RTM in testing

    To use Requirements Traceability Matrix (RTM) in testing, you need to be aware about which test cases are linked to requirements and which bug reports are related to which test cases and eventually to which requirements.

    Course Curriculum

    Enroll in PMP Certification Training Course to Build Your Skill Sets

    Weekday / Weekend BatchesSee Batch Details

    In ReQtest you will find two columns Linked Test Cases, and Linked Bug Reports in the Requirements module for traceability. You can trace the test cases and bugs that are linked to each requirement.

    In the Test Cases tab, the Linked Bug Reports, Linked Requirements column will help you in tracing the linked items. The Bugs tab will help you trace any linked Requirements, linked Test Runs, and linked Test Cases. With ReQtest, you can easily get Forward, Backward, and Bi-directional traceability.

    What are the components of an RTM?

    • Requirement ID 
    • Requirement descriptions
    • Module name
    • Test specification
    • Test case ID
    • Verification status 

    Depending on the nature of your industry or project goals, a traceability matrix can have more than these components or parameters. An RTM can show the required coverage in the number of test cases, design status, as well as execution status for the particular test case. 

    With systems implementations, various types of test phases will be required, including User Acceptance Testing (UAT), Systems Integration Testing (SIT), and Application-Under-testing (AUT); the status of all types of tests should be included in the same traceability matrix. The current state and related defects would be displayed in the same traceability matrix.

    Figure AThis is what an RTM might look like (Figure A).

    requirements-traceaplity-matrix-figure-A

    What are the types of traceability matrices?

    There are three key types of requirement traceability matrices used in requirements tracing. 

    1. Forward RTM: Forward matrix is used to check if a project is progressing in the right direction and relating to the right product. It maps the requirements to test cases, ensures that each requirement is applied to the product, and is tested thoroughly.
    2. Backward RTM: Backward traceability matrix focuses on ensuring that the current product is on the right track. The goal is to confirm that project scope is not changing or growing through the addition of codes, design elements, tests, or other work that has not been specified in the requirements. It also maps the requirements to test cases.
    3. Bi-directional RTM (Forward/Backward): Bi-directional RTM ensures that all requirements have been covered by test cases. It also analyzes the impact of changes in requirements in relation to defects in a product and vice versa. 

    What are the benefits of a Requirements Traceability Matrix?

    The Requirements Traceability Matrix benefits teams by helping them to stay focused on tasks, goals, and accurate execution, and helps to:

    • Highlight any missing requirements or document inconsistencies; 
    • ensure test coverage is complete; 
    • highlight all defects and execution status, focusing on the business requirements; and
    • analyze the impact of the QA expert’s work in the context of revisiting or re-working on the test cases.

    Leveraging the power of a Requirements Traceability Matrix can help your project team to effectively meet a client’s business needs by reducing the risk of defects and missed objectives.

    Workstation Processes and Metrics

    • The RTM is, essentially, a control tool, but to be effective it should be implemented in parallel with a clear definition of the processes to follow in each of the project workstations. Every piece of the RTM is thought to tell you where to find the evidences to check all the items needed to fulfill each requirement. But the checking process should control different things depending on the item you want to check, and the standards to follow in each workstation process is not part of the traceability matrix. Those standard are part of your quality plan.
    • Requirements. Let’s take the requirement workstation as an example to analyze the situation in a better way. The requirement workstation has as main objectives: collecting, organizing and documenting the requirements. As part of your project planning effort, an approach for the work in this workstation should be defined, as well as who does what and when. Also, the characteristics of the main workstation result should be specified in the requirement document to be accepted by the customer. To ensure customer acceptance you should define some basic quality aspects for the document, allowing you to answer questions like: are all the collected requirements included in the document? Do they have a unique and concise identification? Are they organized in a reasonable manner? Are they concise and unambiguously written?
    • Now, you can see that the RTM will not help you to start defining the work, document format, standards, etc., you need to create for this workstation. But after creating the RTM you will have a framework allowing you to trace the effectiveness of your project processes in resolving each of the customer’s accepted requirements. Building the RTM before asking for the customer’s acceptance of the requirement document will help you to judge the document quality. The RTM will point to the items that need to be checked to have your answer to each question in the previous paragraph.
    • You should develop a set of metrics to measure the effectiveness of your processes and your team. The number of negative answers to the questions above is a good metric. You should express it as a percentage over the total number of requirements, and it would be excellent if you calculated this number by project team member.
    • After the customer accepts the requirements, it is time for the design. At the design workstation, the project should “invent” the solution for every requirement. This is commonly a disruptive, almost chaotic process, very difficult to normalize in all the aspects related to creativity. Nevertheless, you should define an approach for the work in this workstation, and you should specify the characteristics of the main workstation result, which is the design document. In most cases, the customer is only interested in reviewing the aspects of the design related to the project constraints, like platform size and performance, but will refuse to be responsible for the design quality. If the project cannot resolve some of the requirements due to a design defect, we would not argue with the customer based on his approval of the design.
    • For the reasons explained above, you need to consider that the real design approval authority should be someone inside your project team. Nevertheless, you should get the customer acceptance for several definitions emerging at the design stage about the way to manage some of the requirements. Examples of these definitions are: consolidated validation rules for data entry, conventions on the graphical interfaces to the users, volume limits for transaction processing and data filing, and proposed implementation for accessibility and security requirements.
    • Depending on the development tools and methods you use, you should create similar lists of questions to the ones stated for the previous workstation. Again, the RTM will point to the elements you should check to evaluate how every requirement is resolved in the design. But the sort of checking you should do is not stated in the RTM. It depends on the definition of your processes and standards of the design. The questions should be related to logical structures, naming conventions, data structure, and procedural definitions as some examples.
    • The relevant aspects to consider in the preparation of the design column of the RTM are: uniqueness of the references to design document components, inclusion of references for all the design components needed to resolve a single requirement, replication of the references in the cases where a design component resolves multiple requirements. The RTM will help you to ensure that there is a resolution for every requirement. And checking the content of the individual design documents, you will be able to evaluate the quality of those resolutions.
    • The metrics to measure the effectiveness of your design processes team should relate to the number of negative answers to the questions you should have formulated based on the design tools and methods you have in your specific project. Remember to express it as a percentage over the total number of requirements, and try to calculate this number by project team member.
    • Once you have confidence on your design and the customer has approved its document, the project team needs to start building the solution. Great quantities of entities will be created, belonging to very different entity types, like source files, object files, parameters, data tables, scripts, and their associated documentation. Your team will need an approach to the work in this workstation, and a set of standards to respect. The main objective of this workstation is to create the final entities required to implement the design. Then, it should be a relationship among the items that have emerged from the design and those emerging from the building.
    • The RTM is the tool to show that relationship. To do so, the identification of the items emerging from building should be written on the right of the items on the design column that they are implementing. Consequently, you will have a chain for every requirement, stating the design elements created to resolve it and the final entities created to implement every item in the design. The information on the RTM will help you to identify absences of implementation (holes in the matrix), and drives you to the items you should check to assure the quality of the solution for a given requirement. Processes and standards to assure quality at building workstation should be treated in a similar way to the ones described for previous workstations.
    • The main objective of this workstation is to ensure that the solution for the requirements has reached the state where it can be implemented for production. Customer’s approval is essential to attain this objective, and the customer will feel more confident if the test is related to every one of the requirements. This is a strong idea behind the RTM: it is a tool to help attain the final customer’s acceptance without surprises. All the work we do to update the RTM during previous workstation, plus all the quality control we perform to ensure appropriate resolution for every requirement has its payback at the end of the project, facilitating the final customer’s acceptance thus having a satisfied customer.
    • Testing plans should be developed considering how to prove the solution features and functions, taking into consideration the way that the customer can perceive the test, and the way the test will be documented. The RTM will be of help in the testing plan development. The main objective of the test is to show the customer how the solution resolves each of all the requirements on the left RTM column. Information on the design and building RTM columns will help identify what features and functions should be tested, and you should use this information to define specific testing data and procedures.
    • At this workstation, the solution should be prepared to start out production, and should end with the final project acceptance from the customer, after the performance test. There are always activities to perform before going into production, like data conversion, final security information entry and user profiles validation. The rightmost column in the RTM has the objective of stating the entities to use to perform this sort of activities for every requirement. Your project team should use the process of incorporating this last information as double-checking, realizing cases where the solution is not yet ready to start out production. As an example, security implemented for development and testing is normally different from the one required for production, then, some procedure should be performed to create the required security environment.

    Examples Of RTM

    #1) Business Requirement

    BR1: Writing emails option should be available.

    Test Scenario(technical specification) for BR1

    TS1: Compose mail option is provided.

    Test Cases:

    Test Case 1 (TS1.TC1): Compose mail option is enabled and works successfully.

    Test Case 2 (TS1.TC2): Compose mail option is disabled.

    #2) Defects

    After executing the test cases if any defects are found that too can be listed and mapped with the business requirements, test scenarios and test cases.

    For Example, If TS1.TC1 fails i.e. Compose mail option though enabled does not work properly then a defect can be logged. Suppose the defect ID auto-generated or manually assigned number is D01, then this can be mapped with BR1, TS1, and TS1.TC1 numbers.

    Thus all Requirements can be represented in a table format.

    Course Curriculum

    Best Advanced PMP Training from MNC Experts

    • Instructor-led Sessions
    • Real-life Case Studies
    • Assignments
    Explore Curriculum
    Business Requirement #Test Scenario #Test Case #Defects #
    BR1TS1TS1.TC1TS1.TC2D01
    BR2TS2TS2.TC1TS2,TC2TS2.TC3D02D03
    BR3TS3TS1.TC1TS2.TC1TS3.TC1TS3.TC2NIL

    RTM Opportunities and Risks

    • As you could see up to here, RTM is hardly focused on the customer, demanding that everything in the solution development must be tied to customer requirements. You have seen that the RTM will help attain the customer final acceptance at testing workstation, and you have also seen that testing is not the only place where it is suggested confirming that the solution has evolved properly. In fact, the correctness of the evolution should be confirmed during the work done in each workstation. The RTM will point to what should be analyzed to ensure a proper solution for any given customer requirement. It should be your responsibility to dedicate enough time and effort to this analysis.
    • The tool you should use is inspection. Inspection allows us to make corrections along the way, before we move from one workstation to the next one. It is a way to avoid the frustration of arriving to test with lots of predictable, sometimes naive mistakes. Inspections will allow you to catch defects early in the development process. And if you exercise inspections frequently, you will become better and better in doing them. You will realize ways to improve your processes and standards, and you will early identify root cause of failure, like poor platform performance or capacity, lack of project team member skills, low adherence to standards, etc.
    • The core idea is this: every step in the process should have its way to be tested. It should be a test method for every workstation. And everything you test should be related to some requirement, because that is the customer perspective, and your goal must be getting the customer final acceptance and satisfy your customer.
    • There are also risks inherent to every project workstation, and the RTM can help you manage them, pointing to the partial results you should evaluate. At the requirement workstation, your team could be defining solutions rather than understanding and documenting the requirements (problems to resolve plus characteristics that will be demanded for a valid solution). The requirements document could be poorly written and incomplete. At the design workstation the project team could quit too soon or stay too late. Carelessness is the typical risk at the building workstation. People try to implement the design using their own style, feeling really tempted to leave the procedures and standards aside. During testing, people become impatient, and lots of features and functions remain untested.
    • One of the biggest benefits of RTM is the help it provides to move from the traditional to a modern approach for testing life cycle. Traditionally, you design, code, test and debug. A modern test approach should consider testing aspects in each of the project workstations. At the requirements phase, you should develop master test plans, acquire test tools, design the acceptance tests and start identifying testing data. At the design phase, you should consider integration tests, review the initial test plan and design structural and functional test data. At the building phase, you should design unit test plans, organize code reviews and inspections, create structural and functional test data and perform unit testing. At the testing phase, you should perform integration and system tests. At the implementation phase, you should execute the performance acceptance test and get the final acceptance from the customer. You may be thinking on the investment in time and effort required to implement this modern approach, but consider this: doing testing several times along the project life cycle will shorten the overall cycle. The RTM will help you organize all the testing activities around the requirement definitions, driving your team to focus on customer satisfaction.
    PMP Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download
    • Additionally, the RTM will help you evaluate the impact of suggested changes. Evaluating the impact of a change in some of the project requirements is not easy, even for small changes. The difficulty is to realize which project results are involved in the change, without forgetting any of them. Only after identifying them we will be able to analyze and estimate the impact of the change. And the RTM will facilitate the identification of all the project results involved in every change solicited for any given requirement.

    Are you looking training with Right Jobs?

    Contact Us
    Get Training Quote for Free