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 on-going problem that experience. And one of them said, “Oh, we need to create a Requirements Traceability Matrix.“
Then, I had another discussion with 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 for 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 from 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 Need. 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 sack 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.
And we have a limited budget .
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. Often times, 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 a blue button on a white background. Another one red button on a green background.
These stakeholders may never meet . They don’t know about the requirement 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 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 in a 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, Project Team can use these case cases as additional pieces of information to ensure that product meets requirements and passes the test cases.
You’ll get less defects in the process .
9. RTM Will Help You Validate Scope
Later, when you are done with 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.
Requirements Traceability Matrix Template
You can get my RTM template in the PM Basics Library.
Click here to check all the Downloads in the Library .
When to Use Requirements Traceability Matrix?
It goes without saying, that Requirements Traceability Matrix requires a lot of efforts.
So, I would recommend using it on medium and large projects mostly.
But also I would recommend to use it even if you have a small team but you plan to develop a product for a prolonged period of time.
I Recommend to Read Next
The post Requirements Traceability Matrix in Project Management (Example+Template) appeared first on Become a Project Manager .