The Ultimate Guide to Requirements Traceability Matrix (RTM)

Are you a QA tester who needs to create a Requirements Traceability Matrix? Not sure how to do it and are looking for examples? In this blog post, we'll show you ways to create one using our example template. It includes fields like requirement ID and more. In addition, you'll get some tips on what information is important when creating your matrix.

Are you a product manager? RTMs can provide insights into the quality of the requirements for your product.

Let's get into it...

What is the Requirements Traceability Matrix?

RTM is a document or a tool to map the test cases to business requirements and vice versa. The main purpose of RTM is to provide testing coverage insights. It ensures appropriate testing of requirements and aligns test cases with needs. RTM tracks the testing progress by looking at the status of test cases linked with specific requirements.

In theory, there are three types of RTM: Forward, Backward, and Bi-directional RTM. However, in the real world of software product development, Forward and Backward RTM are hardly used. They don't actually add value with traceability in one way. Therefore, this blog will mainly focus on the Bi-directional RTM that brings many benefits to different stakeholders.

Bi-directional RTM creates a one-to-many relationship: a requirement can link to multiple test cases, and one can link to only one requirement. A test case should be in unique size to be easily executed, maintained, or automated.

Why is RTM important?

As stated in the section above, it's all about testing coverage. To be more specific, it ensures that RTM will validate every piece of requirements through test cases. It also keeps the testing in the right direction that fulfills the users' needs through requirements.

Imagine if there is no RTM...

• We don't know if we write sufficient test cases to cover all requirements.
• In Agile, requirements often change. We don't know which test cases need to be updated. It will lead to a discrepancy between requirements and test cases. As a result, the test execution can't happen because the test cases are obsolete. Testers might report invalid defects from the outdated test cases.
• When transferring knowledge, test cases can create confusion when they're not up to date. Test cases need to be up to date with existing behaviors & requirements to confirm correct behaviors. This will save teams a lot of back-and-forth.

"Good RTM does not guarantee the software has good quality. It only means that all requirements have been tested and covered."

How to prepare RTM

Let's get into the general idea of creating an RTM first; then, we'll go to a specific example and template in the next session.

• First, create a Requirement table, add requirements and generate a unique Requirement ID, Title/Summary, Description, Status.
• Second, create a Test Case table with a unique Test Case ID for each test case. Then add related Requirement ID to test case (usually in the first column)
  

Hot tip: Use the Data Validation feature to populate the list of Requirement IDs from the Requirements sheet to avoid mistake.

• Add a Defects table to link defects to test cases if necessary. Link defects to related test cases to keep track of why tests failed.
• Create an RTM table once requirements, test cases, and defects are linked.
  ‍

Example and template

Many articles online include many types of requirements mentioned in RTM. It goes from Businesses Requirements, Technical Requirements, Use Case Documentation, and User Story. This makes RTM seem complicated or hard to understand.

To keep things simple, I'll be demonstrating RTM with a user story. This is the most common user requirement format used in Agile development.

A user story describes what the user needs to achieve their business goals. An essential part of a user story is the acceptance criteria which is used for deriving test cases.

Below is an example of a user story that describes the screen recording feature of Bird Eats Bug:

As a Bird user, I want to record screens so that I can report issue with all necessary information for developers with minimal amount of time.

Acceptance Criteria:

• User is able to record screen with video and camera on.
• User is able to record screen with video and camera off.
• After recording, the user is able to input the title and description to the recorded session.
• After recording, all technical data (console, network, system info) will be captured.
• User is able to upload recorded session to their workspace.
  ‍

Steps to create RTM

1. Create Requirement table with Requirement ID and description
2. Make Test Cases table contains Test Case ID and link it to Requirement ID
3. In the Defects table, each defect is linked to a Test Case ID
4. Create RTM once all requirement ID, Test case ID, and Defect ID are linked

And we'll walk you through how each step should look like below.‍

1. Create Requirement table with Requirement ID and description

2. Make Test Cases table contains Test Case ID and link it to Requirement ID

3. In the Defects table, each defect is linked to a Test Case ID

4. Create RTM once Requirement ID, Test case ID, and Defect ID are linked

Challenges and tips to avoid mistakes

RTM and test cases have to be updated more often whenever requirements change

In Agile development, requirements often change based on customers' feedback. It will take more effort to maintain RTM than the traditional method. This means that the tester should be creative in creating RTM to minimize time spent on maintaining it.

Criteria fulfillment does not equal to a bug-free product

When all the criteria of requirements are met, it does not mean that the product is bug-free. Many factors affect the quality of the product:

• Requirements are not well-defined, especially the interdependencies between features.
• Test environments sometimes are different from production environments of customers' environments where they actually use the product.

Good RTM does not guarantee the software has good quality

It only means that all requirements have been tested and covered. More often, some edge cases are not directly related to requirements but could lead to a defect. Therefore, exploratory testing needs to be conducted to improve the testing coverage.

QAs should not only rely on requirements defined by the product owner

Or ones defined by the product manager. Reason being that, yes, product managers can have excellent vision and a high-level understanding of the product. But they can also overlook some minor details and dependencies. As a consequence, it might need to be re-worked later.

On the other hand, QAs have a unique perspective of features. QAs can create a link between multiple features because they are detail-oriented and work with the product daily. Therefore, QAs should keep asking questions to clarify requirements to improve the test coverage as much as possible.

Communication and transparency within the team

Communication and transparency are essential to keep RTM up to date. RTM's owner should be informed when requirements change to update the test cases.

Wrapping up

The Requirements Traceability Matrix (RTM) is a document that can help you keep track of the project's requirements, as well as attributes and tests. It will also allow your team to identify any gaps in the system or missing features. When used effectively, RTM can save time by helping teams stay on top of what has been accomplished and what still needs work.

If you found this information helpful or know someone who could benefit from using an RTM, please share! We hope these pointers will be helpful when creating your templates down the road, too - happy testing!