COEPD – Center of Excellence for Professional Development Happy Learning
Requirement Traceability Matrix:
The requirements traceability matrix is a document that maps user requirements with test cases. The document captures all client requirements and traces those throughout the product development. This document is then delivered at the end of the software development life cycle. The main purpose is to ensure all requirements are accounted for and have been checked with test cases. No functionality should be left unchecked at the end of this process.
How to Create an RTM
Used in software testing and product development, a requirements traceability matrix is an important tool to make sure you fulfill every user requirement. No project should be without one, which is why we’ll take you through a step-by-step guide to making your own requirements traceability matrix.
1. Define Goals:
The goal of a requirements traceability matrix is to track the user requirements for the project, and it’s easiest to list them on a spreadsheet. But an RTM can be used for a variety of things. For example, you can make sure your requirements have been tested or are compliant. You can also determine which requirements are impacted if something changes. Regardless, the first step is to define the goal.
2. Collect Artifacts:
Based on your goal, you’ll start to collect relevant artifacts that include at least the requirements, tests, test results and issues. After you’ve collected the artifacts, you’ll want to get the most current requirements documents. Each requirement should have a unique ID number that doesn’t change, even if the requirement is reordered. Test cases also need to be defined and given a status. For example, they might be started, done or blocked. If the test fails, then whatever issues led to that failure should be detailed.
3. Create Requirements Traceability Matrix:
Now you’re ready to build the RTM. Use a spreadsheet and make four columns. Each column will be for an artifact. The first column outlines the requirements lists, the next has the tests and following that are the test results. You’ll also have a column for issues. This is the bare minimum and you can add more as needed for your project. For instance, a column that numbers each of the requirements would be useful.
4. Copy and Paste:
You’ve done the work and now you have to add it to the requirements traceability matrix. Simply add the requirements, test cases, test results (if you have them at this point) and issues to the spreadsheet.
5. Revive the RTM:
The requirements traceability matrix is a living document that’ll you’ll often reference for updates. As requirements change, so does the RTM. Some requirements might drop from the project or another test case may be added; all of these changes need to be reflected in the requirements traceability matrix. The requirements ID number, however, should stay the same even if the requirement is reordered or reused.
Types of Requirements Traceability Matrices
Now that we know what a requirements traceability matrix is and how to create one, let’s look deeper into the topic. There are three different types of requirements traceability matrix: forward traceability, backward traceability and bidirectional traceability. Let’s take a moment to define each.
- Forward Traceability
The forward traceability matrix is used to see the requirements of the test cases. This allows for each of the requirements to have a test and also allows one to know that the project’s trajectory is positive.
- Backward Traceability
Backward traceability maps the test cases with the requirements. This is done to avoid scope creep and going beyond the initial requirements without cause to do so.
- Bidirectional Traceability
As you might guess, a bidirectional traceability matrix is one that combines the forward and the backward traceability in one document. This ensures that every requirement has a related test case.
It’s clear how important a requirements traceability matrix is for project management. If you miss a requirement, you might not deliver what users want. Having a list of those requirements and being able to map them in whatever direction is best for your project ensures that all have been included. But you can also see that they involve a lot of work and manual labor to create, fill in and update.
