Types of Requirement Traceability Matrix (Uses &  Examples)


Did you know that the lack of proper requirement validation is one of the most common causes of project failure? 

According to a ResearchGate study, improper documentation, validation, and management of requirements are among the leading causes of most project failures.

How can you avoid this, you wonder? By using the requirements traceability matrix or RTM.

In today’s guide, we’ll quickly go through the three types of RTM, showing you how they work. We’ll also share some requirement traceability matrix examples from which you can draw inspiration. But first, let’s look at the uses of RTM.

Gain visibility, from requirement to release.

View GitHub insights, identify blockers, and deliver with predictability.

What is a Requirement Traceability Matrix?

The requirement traceability matrix is a document that helps you connect your requirements to test cases. This is to ensure that you don’t miss out on any requirements in the testing phase. 

These requirements could be: 

  • Product requirements 
  • Functional requirements 
  • Technical requirements 
  • Business requirements
  • Compliance requirements 
  • User requirements 

Let’s assume you want to create a reservation module for your software. This requirement is quite comprehensive, though. So, with an RTM, you can break it down into measurable test scenarios like round-way tickets, one-way tickets, and multi-city ticket features, as shown below.

Source

You can then assign test cases to these scenarios to see if they are met individually. Once the test cases validate individual scenarios as “met/pass,” you’ve fully met the requirement. 

You’ll record this validation in an additional requirements traceability matrix status column, as shown below.

Source

With the requirements traceability matrix, you can be sure that your project meets every goal it set out to achieve. Moreover, RTM allows you to detect missing functionalities in your software product efficiently. 

It also becomes easier to find the root cause of bugs since every test scenario and case is clearly listed.

The requirement traceability matrix doubles as a form of software documentation that helps keep your project team in sync. Everyone has a clear picture of what is and what’s not to be done, making their workflow seamless.

Finally, with the RTM in place, you can confidently show your compliance with regulations related to the project. Thus, it becomes easier to avoid needless expenses or project delays related to an audit.

Types of RTM with Examples

Generally, there are three types of RTM; forward, reverse, and bidirectional traceability matrices. To help you understand each, we’ll explain these types with relevant requirement traceability matrix examples. So, let’s dig in. 

1. Forward Traceability Matrix

Forward traceability involves mapping the requirements to test scenarios and, eventually, the test cases. This type of matrix is developed at the beginning of the project cycle to ensure the project progresses in the right direction. 

In this type of RTM, you’re tracing the requirements down to the final design to ensure it meets the initial request. It confirms that every requirement is tested thoroughly.

With the forward traceability matrix, you’ll find the requirements in columns and the test case in rows. Here’s an example.

Source 

For example, let’s say one of the requirements is that the system must allow users to create an account using an email address and password. One of the test scenarios would be to check the login functionality. In this scenario, you might have test cases such as:

  • Check the result after invalid login data
  • Check results after valid login data
  • Check response for empty entries

The forward traceability matrix helps you trace everything from the initial requirements to the test scenario and test cases to ensure that you’ve fully met the requirements.

2. Reverse Traceability Matrix

This RTM type is just the opposite of the forward traceability matrix. The reverse or backward traceability matrix involves mapping the test cases back to the initial list of requirements. 

Essentially, this matrix allows you to track a request back to its source.

Some high-level RTM models represent the requirements in the row and the test case in the column for this type of traceability matrix. Here’s an example.

Source

For example, let’s assume your current project requirement involves logging into an email server. For the test cases, you’ll have steps like:

  • Launch email server
  • Input username
  • Input password
  • Click on the login button.

Now, in the backward traceability matrix, you pick each consideration in the test case and trace it to the original requirement. The project is still on track if the test case relates to the initial requirement.

The essence of this type of requirement traceability matrix is to prevent scope creep. Besides, it further ensures that you are not going beyond the previously laid down requirements for the project.

For example, let’s assume you add a test case like “enter bank account details” to the previous email server example. Obviously, this is going beyond the predefined project scope. And this is what the reverse traceability matrix helps prevent.

Further, if there is a defect in a particular test case, the backward traceability matrix helps you pinpoint the test scenario responsible and the requirement that could be affected. 

3. Bi-directional Traceability Matrix

The bi-directional traceability matrix is essentially the combination of reverse and forward traceability. With this RTM, you map your test case to the requirement and the requirement to the test case in one document.

We recommend using the bidirectional requirement traceability matrix. It combines both the benefits of forwarding and backward matrices. It ensures the entire source requirements are well addressed. Plus, the bidirectional form can help you trace back lower-level requirements to their original high-level source.

The bidirectional form makes it easier to assess the impact of a change. It gives you a clearer view of the deliverables potentially affected by an altered requirement. 

Moreover, it helps you understand how changes in deliverables can influence your requirements. These parameters are necessary to gauge the impact of change in your software project lifecycle.

The bidirectional traceability matrix may also help you discover missing application requirements and address them proactively. 

In Closing

The requirement traceability matrix is the key to tracking and meeting every one of your project requirements. It ensures you’re not missing out on any vital client and user expectations.

There are three ways to trace your project requirements; forward, backward, and bi-directional traceability matrices. This article took a deep dive into these types with relevant requirement traceability matric examples.

The bi-directional RTM is an excellent option in most cases. But, regardless of the type of RTM chosen, you can only expect the benefits promised if you implement them correctly. Therefore, create the matrices, share them with your testing team, and inform them why and how to use them.