Definition of the Requirements Traceability Matrix is confusing.
So, simply put:
Requirements Traceability Matrix is a document that maps requirements with other aspects of a project.
It’s important to notice:
RTM is a powerful project integration tool.
It’s a connection link between project objectives, requirements, and scope of work.
So, don’t treat it as a simple tool to organize requirements or test cases.
Confusion about the Traceability Matrix
Recently, I had two interesting conversations.
One with my quality assurance team. We were looking for a solution for an ongoing problem that we experienced. And one of them said, “Oh, we need to create a Requirements Traceability Matrix.“
Then, I had another discussion with the Business Analyst. Almost the same day. Again, the Requirements traceability matrix came up.
But from my experience, from the project management perspective, in nether cases, the RTM was the best tool to use. So, I got curious and researched a bit.
I quickly found out that trainings for both Quality Assurance Engineers and Business Analysts teach about the Requirements Traceability Matrix. But only partially and from their point of view.
The RTM that we, project managers, use is a different tool that combines the best of two worlds.
Requirements Traceability Matrix Content
Usually, the RTM is a spreadsheet.
For sure, you can add or omit some of the columns, but right now, we’ll review all of them, and I’ll explain how you can use it.
Use Unique ID for a Requirement
First of all, we have a unique ID number for a requirement.
Optionally, we can decompose requirements into smaller pieces. Therefore, you may add the Associated ID column.
In agile terms, think of it as Epics and Features. Or Features and User Stories. Or simply as main and sub-requirements.
Write a Short Description
Next, we have a short description of a requirement.
Don’t put the whole specification here. Use a title that explains it. But do keep these descriptions consistent with the verbiage in the specification.
Fill Up the Business Need and Project Objective
Next, we have Business Needs. Again, it should be a short description that justifies the requirement.
And don’t confuse it with the next column – Project Objectives.
They look the same. But you’ll have just a few project objectives (one, two, maybe three) and you can have a multitude of business needs and justifications.
Capture the Name of Requestor of a Requirement
I didn’t find the next column on the RTM examples I saw on the Internet. But I do recommend putting the source or the requester of the requirement.
Also, for bigger projects, you may want to have not only the name of a person but also a department.
Link Requirements to WBS Elements
Then, we have a column for the WBS Deliverable.
It’s just the WBS element number in which the project team will implement the requirement.
Usually, you fill it in here a bit later in the planning process. Next, we can have links to specifications and visual designs.
Connect Requirements with Test Cases
And last but not least, even in a project management Requirement Traceability Matrix we need to list related Test Cases.
But I recommend listing UAT Test Cases or business validation ones. I don’t think you need to list all functional Test Cases.
Also, I see in many examples people put just IDs here. But be a modern PM and to put links to the test cases or test suites in your test management tool or even a spreadsheet.
Extend Your RTM with Additional Columns
This is a minimal viable RTM.
However, you can extend it to your needs. You can map these requirements to any other aspects of the project.
I often see the Status of a requirement and the Date of Status Change. You can add the Priority of a requirement.
You can list the Non-Functional Requirements here as well.
You can do the Release Planning here and map Releases or Sprints. Be creative.
How to Use Requirements Traceability Matrix
So, how do we use all of this information?
We don’t put it all here just for the sake of having a fancy document. We can analyze it and discover lots of opportunities, risks, and conflicts.
1. Prioritizing Requirements on a Higher Level
First of all, let’s imagine a project that has lots of requirements that we collected from different sources.
So, we’ll use the RTM to select the most critical requirements that we need to implement. This way, we can get the most from the resources we have and produce a product that clients need.
Or alternatively, we have a product that we continuously develop through several projects. We update the list of requirements all the time.
This matrix will help us to form the Scope for the next project.
That’s on the higher level. But we can also get very granular.
2. Avoid Gold Plating
We need to fill in the Business Need and justification for each requirement. Oftentimes, it appears that some requirements don’t have justifications.
We defer or remove these requirements because it doesn’t bring any value to the product or the users. It helps us prevent gold plating.
3. Triage Project Scope
Also, we have to connect a Requirement with a specific Project Objective.
This is pure integration on an objective level.
If something doesn’t support a project objective, it shouldn’t be a part of that project. With these two columns, we can easily triage the project scope.
You can learn more about Project Scope Management from this video:
4. Analyze the Requestor
Next, let’s review the connection between a requirement and its requestor or source.
First of all, you can get conflicting requirements:
One stakeholder will ask for a blue button on a white background. Another one is a red button on a green background.
These stakeholders may never meet. They don’t know about the requirements of each other.
So, you need to reach out to them to resolve the conflict. Or you can see who has more authority.
But, again, we might have a short deadline or a small budget. And different stakeholders will put the top priority on different requirements. But we can do only one of them.
So, we can check whether a client or sponsor provided a requirement or it was a technical stakeholder.
At the very least, we can initiate negotiations to select one of the requirements.
5. Keep Stakeholders on the Same Page
Also, it’s integration on the stakeholder level.
Different stakeholders have different areas of expertise. Sometimes, clients may not know some technical needs for the project. They don’t understand they need to allocate time and budget for it.
So, RTM provides transparency for all major stakeholders and their areas of responsibility.
6. Avoid Scope Creep
We have a connection between a requirement and a WBS Element.
From one side, by connecting these dots, you’ll ensure that you don’t forget to implement some requirements. You know the saying:
“What is not in the Work Breakdown Structure is not a part of the project.”
On the other hand, there won’t be scope creep. How?
Project Team will see that a work package or a deliverable includes a specific set of requirements. So, they’ll need to ensure that the tangible results they provide correspond to these requirements.
In addition to that, all stakeholders will know when and what deliverable to wait for to see a certain piece of functionality.
7. Control the Requirements Definition Process
Having reference to specifications and designs is convenient, first of all.
But it also shows you the progress on the requirements definition process.
Are you in good shape to start the project? Do you have all the requirements?
8. Ensure Test Cases Coverage
Now, think about having Test Cases on the same document.
First, it shows the coverage. Second, the Project Team can use these case cases as additional pieces of information to ensure that the product meets requirements and passes the test cases.
9. RTM Will Help You Validate Scope
Later, when you are done with the requirements definition, RTM becomes your tool for tracking the progress on the Scope Baseline.
You’ll provide deliverables and get acceptance from the client on each and every requirement. Performed Test Cases might be a pre-requisite for getting a sign-off.
As you know, it’s better to get acceptance during the project rather than at the end of it.
When to Use Requirements Traceability Matrix?
It goes without saying that Requirements Traceability Matrix requires a lot of effort.
So, I would recommend using it on medium and large projects mostly.
But I would also recommend using it even if you have a small team, but plan to develop a product for a prolonged period of time.
Get Requirements Traceability Matrix
Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.
If one part doesn’t work, the whole system breaks.
My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management.
Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.
All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.