Imagine the following situation:
You are in a meeting with the client ready to present your work.
Your team has spent months building the product – some piece of software, a website, some equipment – all done with the greatest care and shying no effort, because:
You want to make the client happy.
Not only because a happy client is easier to deal with.
Only a happy client will pay your invoice (without complaining).
And transfer over the money that keeps your business afloat.
So you are walking the client through the final product —-
— Then, suddenly a tense moment:
Your client, taking a tour of the product: “I can’t see the …. [points at the screen] …. you know the feature that lets us do X. Remember the thing we talked about that at the beginning and Joanne gave you some input …. we need that”
You: “Oh, you mean the ____?”
Client: “No, that’s a different thing. I am talking about the ______”
You can feel cold sweat on your body.
Still, you try to exude confidence.
“Oh, I’m sure it’s in there somewhere. Maybe we are just looking at the wrong place. Let me speak to Tom, he has done most of the development. Then I’ll get back to you. I absolutely understand this is a key feature”
30 minutes later
You call up Tom, your developer.
After 5 minutes of discussion, the painful truth becomes apparent: The feature that the client was talking about in the morning, the one that he considers essential for his work …. it had fallen through the cracks!
Nobody took care of it!
How could that happen?
Why did the requirement fall off your radar?
After going through your meeting notes and email, you realize that the client was actually right. You did discuss that requirement with him during one of the discovery workshops. It’s all in your notes! Damn it!
The problem was that from a surface-level view, the request sounded very similar to one of the other requirements already in your database. So your developer saw that the topic was already being taken care of, and did not pursue it further.
Too bad!
Had the customer’s requirements been handled in a more systematic way, you would have been sipping champagne with the client and the meeting would have been nothing but a joy.
But unfortunately, it didn’t go that way, and even one small requirement missed can ruin the “endgame” — where you proudly hand over the finished product.
Because I don’t want you to run into those kinds of disappointing moments with your clients, I would like to give you a tool that enables you to manage your requirements in a systematic way.
The “tool” is called a Requirements Traceability Matrix — or short “RTM”.
But let’s first take a step back:
Why you can’t be careful enough about tracking requirements
The purpose of projects is to turn ideas into reality. To build “some thing” that solves a specific problem and thereby provides a meaningful benefit to the customer.
Those who carry out the work to build the product need to understand the idea (the concept) in full detail.
To facilitate the communication between “idea people” and “builders” we define “requirements”.
<Requirement example>
The larger and more complex a project, the more requirements will have to be dealt with.
There may be hundreds or even thousands of requirements!
Now here’s the problem:
As it is common for projects, a lot of people will be involved, each contributor working on their part and taking responsibility for their piece in the puzzle – turning requirements into inspectable, testable, verifiable objects — and helping the project deliver the expected end result and benefit.
What is a Requirements Traceability Matrix?
A Requirements Traceability Matrix is a tracking document for requirements. It helps you ensure that any requirement you received from the customer is actually considered in the concept design, is implemented, successfully tested and finally shipped.
You want to trace the life of a requirement through the entire cycle, hence “traceability”.
On a deeper level, a Requirements Traceability Matrix is a communication tool!
It facilitates any communication around customer requirements because we can always point to the requirements list when discussing a particular requirement. The RTM is your single source of truth.
“I’m talking about THAT requirement in the Requirements Traceability Matrix ….”
“ …. requirement number eighty-two!”
That’s the key point:
Every requirement is assigned an ID, and you refer to a requirement by its ID and not (just) the (usually vague) verbal description.
Example:
Imagine you are setting up a Warehouse Management System for a client, and you want to know from your developer Brad whether he has finished the custom shopping label for his client.
You would say: “What about requirement 82, custom shipping label for Scania, do we have it ready for testing?”
Numbering of requirements: What system should you use?
In my 10+ years in IT and project management, I have seen all kinds of numbering systems.
You can use any format as long as you use it consistently.
You could simply use running numbers:
1.
2.
3.
4.
5.
…
In my projects, we added a basic prefix to clearly designate items as customer requirements:
CustReq 1
CustReq 2
CustReq 3
CustReq 4
CustReq 5
…
Alternatively, you could use a more complex numbering system, with different blocks revealing details about each requirement. For example, you could designate all user interface-related requirements as UI-100, UI-101, UI-102, and database-related requirements as DB-100, DB-101, DB-102, and so on. You get the idea. Just make sure it’s easy to use and you don’t quickly run out of numbers.
My Requirements Matrix Excel-Template supports any format.
Here’s the template:
My Requirements Traceability Matrix Template [for Excel]
This is the spreadsheet I use for tracking requirements:
full view showing all columns:
The template uses the following, simple structure:
- Column Unique ID: Assign a requirement a unique identifier (ID). The template allows you to define the range and format of allowed IDs.
- Column Requirement Title: Enter a short text that describes the requirement on a high level. An example of a good title would be “Invoice split based on material group”. Even though it’s short, it already gives a good picture of the requested feature.
- Column Requirement Description: Describe the requirement in more detail. For my example, I have entered the following text: “Invoice split based on material group. We need to guarantee that invoices are created separately for each material group.” Note that this description is not the only specification of a requirement. You still need to specify all requirements in detail in a requirement document/specification (if you need a good Requirement Doc Template, check out my Project Template Pack which includes an advanced Word template for documenting requirements)
- Columns Org/Department and Process: These columns allow you to categorize requirements in a suitable way. You can categorize business requirements by department, by process, by country by component … whatever makes the most sense for your particular project
- Column Business Justification: Why does the business side or the client need the particular feature? It’s good to have the justification documented somewhere in case you need to prioritize or drop requests due to a lack of time or resources.
- Column Requested By: The person who brought up the requirement. This will also be the person who will review your results and approve the implemented feature or solution.
- Column WBS element: Enter the WBS element the requirement relates to or any other reference code.
- Column Test Case ID: Enter the number of the test case the requirement is tested in. Create a test plan with suitable test cases.
- Column Product Requirement: This is more an IT thing: For any business requirement, you typically define a technical requirement. Basically, this is where you describe how the desired feature is technically implemented. Normally, business requirements and product requirements use the same numbers, but in case you use a different numbering for technical / product requirements, you can enter the corresponding Product Requirement ID here.
- Columns Comment and Document Link: Here you can add comments or link to your requirement documentation (very convenient if all are linked here)
One cool feature of my template
My Excel template not only allows you to assign IDs easily based on your desired format.
It automatically ensures you are not assigning the same ID more than once!
How?
The template uses a picklist where you can choose a new ID when entering a new requirement. It only shows available values, and IDs which have already been assigned are not available for selection. Super simple.
If you still somehow manage to ‘hack’ the spreadsheet and enter a duplicate ID, my template will automatically highlight the duplicate:
Get my Requirements Matrix template
You can buy the template with a few clicks via FastSpring:
Get the Requirements Traceability Matrix Template
- Stay on top of customer requirements using this proven template
- Supports custom numbering of requirements
- Detects duplicate entries
- Fully customizable
- Excel file via instant download
- 30-day money-back guarantee if you are not happy
- Secure payment via FastSpring, a US payment services provider
- You will get an email with a download link
- Contact form for support and questions
