What is Requirement Traceability Matrix?

Introduction to Requirement Traceability Matrix

A traceability matrix is a table-style document that is used to track requirements in the development of software applications. It can be used to trace backwards (from Coding to requirement) as well as forwards (from Requirements to Design or Coding). Requirement Traceability Matrix (RTM) or Cross Reference Matrix are other names for it (CRM).

It is produced prior to the test execution process to ensure that all requirements are addressed in the form of a Test case, ensuring that no testing is missed. We connect all of the requirements to their associated test cases in the RTM document to guarantee that we have written all of the test cases for each condition.

RTM will be prepared by the test engineer for their assigned modules, and it will be forwarded to the Test Lead. The Test Lead will go to the repository to see if the Test Case is present, and then consolidate and prepare a single RTM document.

This document is intended to ensure that each requirement has a test case, and that the test case is prepared based on the client's business needs. If any requirement is absent, it will be performed using test cases, which means that the test case was not designed for that specific need, and that specific demand will not be tested because it may contain bugs. The traceability is written in such a way that it ensures that all of the requirements are met

This is similar to a worksheet document with a table, but the traceability matrix additionally has a number of user-defined templates. Each need in the traceability matrix is linked to its corresponding test case, allowing tests to be run in the order specified by the requirements.

Important −

• We go for RTM after approval and before execution to ensure that no Test Case for any requirement is missed.

• We don't write RTM while writing the testing since it may be unfinished, and we don't go here after writing the test case because it may be refused.

• The RTM document assures that each need has at least one test case, but it does not discuss all possible test cases for that particular requirement.

Example of RTM template

What is the significance of RTM?

Every tester's major goal should be to comprehend the client's requirements and ensure that the final product is defect-free. To accomplish this, each QA should properly understand the requirement and design both positive and negative test cases.

This means that the client's software requirements must be further divided into scenarios and test cases. Each of these cases must be handled separately.

Here's a question − how can you ensure that the requirement is tested in all potential scenarios/cases? How do you be sure that no requirements are missed throughout the testing process?

Tracing the requirement with its related test scenarios and test cases is a straightforward method. This is simply known as the 'Requirement Traceability Matrix.'

The traceability matrix is usually a worksheet that provides the requirements together with all conceivable test scenarios and cases, as well as their present status, such as whether they have been passed or failed. This would aid the testing team in determining the extent of the product's testing operations.

Traceability Matrix's Objectives

• It aids in the tracking of papers created during the SDLC's various stages.

• It ensures that the program fully satisfies the customer's needs.

• It aids in the detection of any bug's root cause.

Traceability Test Matrix Types

The following are the three different forms of traceability matrix −

• Forward traceability

• Backward or reverse traceability

• Bi-directional traceability

Forward Traceability

The forward traceability test matrix is used to guarantee that each business's needs or requirements are properly implemented and extensively tested in the application. The primary goal is to ensure that product development is progressing in the appropriate path. The requirements are then mapped to the test cases in a forward orientation.

Backward or Reverse Traceability

The reverse or backward traceability is utilized to ensure that we are not extending the product's space by improving design elements, code, or testing other items that are not included in the business requirements. And the major goal of this is to keep the current project moving in the right way. The requirements are mapped backwards to the test cases in this method.

Bi-directional traceability

It's a forwarding and backward traceability matrix combination that's used to ensure that all of the business requirements are fulfilled in the test cases. It also assesses any changes in the requirement that emerge as a result of defects in the program.

Parameter to be included in Requirement Traceability Matrix

In the Requirement Traceability Matrix, which parameters should be included?

• Requirement ID

• Type and Description of the Requirement ID

• Status of Test Cases

A sample requirement traceability matrix is shown above.

The traceability matrix in a typical software testing project, however, would have more than these criteria.

A requirement traceability matrix can have −

• Show the number of test cases needed to cover all of the requirements.

• For the individual test case, there is a design status as well as an execution status.

• If users are required to perform User Acceptance Testing, the UAT status can be recorded in the same matrix.

• In the same matrix, associated flaws and the current condition can be mentioned.

This type of matrix would serve as a one-stop shop for all testing needs.

Aside from keeping a separate excel file. A testing team can also use one of the various Test Management Tools to trace requirements.

What Can Requirement Traceability Do for You

Where is a Requirement Implemented

As an example,

Requirement − Implement ‘Compose mail' feature in an email application

Implementation − Where should the 'Compose mail' button be located and accessed on the main page?

Is it required to have a requirement?

As an example,

Requirement − Only allow specified users to use the ‘Compose mail' functionality in a mail application.

Implementation − If the email inbox is set to "Read-only" by the user, the "Compose mail" button will not be necessary.

What is the best way to understand a Requirement?

As an example,

Requirement − 'Compose mail' with Fonts and attachments functionality in a mail program.

Implementation − What functionalities should be available when the ‘Compose mail' button is pressed?

• Text Body to compose emails and edit them in many font styles, as well as bold, italics, and underlining.

• Attachments of many types (Images, documents, other emails, etc.)

• Dimensions of attachments (Maximum size allowed)

As a result, the requirements are divided into sub-requirements.

What design decisions have an impact on a Requirement's implementation

As an example,

Requirement − All features such as ‘Inbox,' ‘Sent mail,' ‘Drafts,' ‘Spam,' ‘Trash,' and so on should be plainly visible.

Implementation − The viewable items should be displayed in either a ‘Tree' or ‘Tab' format.

Have all of the requirements been assigned

As an example,

Requirement − There is a ‘Trash' mail option.

Implementation − If the ‘Trash' mail option is available, the ‘Delete' mails option (requirement) must be implemented first and tested to ensure that it is working correctly. If the ‘Delete' mail option is functioning successfully, then only the deleted emails will be collected in the ‘Trash,' and adopting the ‘Trash' mail option(requirement) will be justified (will be useful).

Vineet Nanda

Updated on: 30-Aug-2021

1K+ Views

Kickstart Your Career

Get certified by completing the course

Get Started