The official definition of the Requirements Traceability Matrix from the Project Management Institute is confusing.
So, I’ll put it based on my practical experience:
Requirements Traceability Matrix is a tool in project management that maps requirements to other aspects of a project. Usually, it’s a spreadsheet. It helps to track what project requirements were implemented in what deliverables.
It’s important to stress out right away:
RTM is a powerful integration tool in project management.
Why?
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.
What is the Requirements Traceability Matrix (RTM)?
Usually, the traceability matrix is a spreadsheet.
It’s a flexible tool. So you can adjust columns based on the needs of your project management approach.
You can get my requirements traceability matrix template as a part of the project scope management plan template.
Confusion about the Requirements Traceability Matrix
Recently, I had two interesting conversations.
One with my testing team. We were discussing a problem with compliance regulations and how to track test results.
And one of them said, “Oh, we need to create a Requirements Traceability Matrix! “
The same day, I had another discussion with the business analyst. Again, the requirements traceability matrix came up.
But from my experience, from the project management perspective, the RTM wasn’t the best tool to use in either case. So, I got curious and researched a bit.
I quickly learned that trainings for Quality Assurance Engineers and Business Analysts teach about the Requirements Traceability Matrix. But they focus on different aspects.
Quality assurance engineers use forward traceability and bidirectional traceability matrixes to facilitate software testing. They also use it for mapping test cases to requirements (e.g., user stories).
Obviously, business analysts collect initial requirements in the traceability matrix. Then, they transform them into project requirements. As a result, they generate a business requirement document that spans the whole project life cycle.
Requirements Traceability Matrix For Project Managers
The RTM that we, project managers, use is a different tool that combines the best of two worlds.
IT Project Managers use it to track project progress. The requirements traceability matrix helps to connect aspects of project management that don’t have a direct link.
I’m talking about the Project Objective -> Business Need -> Project Requirements -> Project Scope (deliverable) connection.
But there’s a bigger question you must answer.
What Do You Put In the Requirement Traceability Matrix?
Should you track business requirements in the requirements traceability matrix?
The short answer is no. And here’s why!
There’s a hierarchy of requirements in project management:
Business requirements.
Stakeholder requirements.
Solution requirements.
Functional requirements.
Non-functional requirements.
The idea is that you collect solution requirements in the traceability matrix.
That’s why a requirement traceability matrix is suitable for any development process. You can track requirements as user stories or as high-level project requirements.
Contents of the RTM for Managing Projects
As I said, we focus on a traceability matrix for project management.
At the same time, we can still connect project management aspects with software testing and track test cases and test results in the same document.
But most of all, we are interested in controlling project progress.
In other words, it means…
We want to ensure that each piece of project requirements gets into one of the project deliverables.
We spend money and effort only on requirements that help us reach project objectives.
We validate each requirement with test cases we envisioned in advance. Moreover, test cases cover the primary use cases for our product.
That’s why we need the following information in a traceability matrix.
1. Use a Unique ID for Project Requirements
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.
Unique ID helps to track requirements outside of the requirements traceability matrix.
2. Write a Short Description
A requirement needs a short description.
Don’t put the whole specification here. Use a title that explains it. But do keep these descriptions consistent with the vocabulary in the specification.
Likewise, you can have a link to a technical requirement document and user interface (UI) designs.
A link to such a document may also serve as an execution status for collecting requirements activities.
3. 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 following column – Project Objectives.
They look the same. But you’ll have just a few project objectives (one, two, maybe three), and you can have many business needs and justifications.
This information should come from a project charter.
4. Capture the Name of the Requestor of a Requirement
I didn’t find the next column on the RTM examples I saw online.
But I recommend putting the source or the requester of the project requirement.
Also, for bigger projects, you may want to have the name of a person and a department.
We’ll discuss how to use this information later in this article.
5. Link Requirements to a Work Breakdown Structure Elements
Then, we have a column for the work breakdown structure deliverable.
It’s just the WBS element number in which the project team will implement the requirement.
Usually, you fill it in here later in the planning process.
6. Connect Requirements with Test Cases
Last but not least, we need to list related Test Cases even in a project management requirement traceability matrix.
But I recommend listing user acceptance testing (UAT) test cases or business validation ones. These are high-level test cases that normal users perform.
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 put links to the test cases or test suites in your test management tool or even a spreadsheet.
7. 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 In Project Management
So, how do we use all of this information?
We don’t put it all here to have a fancy document. We can analyze it and discover lots of opportunities, risks, and conflicts.
#1. Prioritizing Requirements on a Higher Level
First, imagine a project with many requirements that we collected from different sources.
So, we’ll use the RTM to select the most critical requirements we need to implement. This way, we can get the most from our resources and produce a product that clients need.
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, it appears that some requirements don’t have justifications.
We defer or remove these requirements because they don’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 quickly triage the project scope.
#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 each other’s requirements.
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. Different stakeholders will put the top Priority on various 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 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?
The project team will see that a work package or a deliverable includes specific 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 specific 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 information to ensure that the product meets requirements and passes the test cases.
You’ll get fewer defects in the process.
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 the client’s acceptance of each requirement. Performed Test Cases might be a pre-requisite for obtaining 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?
Requirements Traceability Matrix requires a lot of effort.
So, I would recommend using it mainly on medium and large projects.
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 Template
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.