Keeping Track Of What You're Delivering To Your Customers
Ensuring what the customers need and what is being delivered is a constant battle.
Where I live, there was an upgrade to a sports website used by clubs around the state to register players, volunteers and officials but it’s causing problems with the whole process of registering and log-ins.
When I registered my son and tried to log in, it would send me in an endless loop of registering, trying to log in and fail and being sent back to register.
Somewhere along the way, what was built was not what the users required the system to do.
This, in turn, caused a lot of angst for people trying to register, make payments, complete online training and registrars not able to process the admin with the season starting next month.
Projects face many challenges. Some are outside the control of the project team, whilst others are within their control. One challenge is requirements management, how the project identifies, documents, tracks changes and manages changes to requirements.
Requirements traceability is part of requirements management and it’s a critical factor in project success. It provides a line of sight of the business outcomes to the requirements (functional and non-functional), to the solution design and the test cases and what is delivered to customers.
It ensures that the solution, code and testing meet the requirements. And when requirements change (as they do), you and your team will be able to assess the impact of the changes using traceability.
The Requirement Traceability Matrix (RTM) is a tool that tracks the requirement from the start through to the design, coding and test cases.
RTM begins during the requirements planning. This is during the kick-off for the Discovery phase where the project team is planning how to identify stakeholders, eliciting and documenting the requirements, analysing them, and getting them validated.
As part of the planning process, the team will identify how to trace the requirements and what elements need to be documented.
Most organisations have standards and templates for how RTMs are used and managed. At its most basic RTM would capture the following:
ID - an identifier
Requirement description - not a full description with details but a summary. The full details will sit somewhere else.
A category to group the requirements - for example, whether it’s from stakeholders, regulation or system.
System requirement ID - if the project has a system requirements artefact, sections of it that refer to the requirement can be referred to here. Most Agile projects don’t have the Systems Requirement documentation, more complex and older systems do.
Design ID - this can be the architectural solution design document or a detailed design document. Refer to the sections of design reference that satisfy the requirement.
Build ID or component - this can be the build number or some other reference number that links the code to the requirement. This will also link the code to the design
Test case ID - these are the test cases that will test the code and make sure it is working as expected and satisfy the requirement.
As you can see, the RTM can be used to in either direction, forward tracing, where from the requirement you can trace to the system specification, which part of the design document covers it, the build component and the test cases.
If there is a change in the requirement or a new requirement, this can be used to do the impact analysis. And if there is a bug for a particular test case, then you could use this backwards to identify the requirement that it impacts.
Numerous tools in the market can be used to help with requirements traceability. Most tools are mandated by the organisation. However, having an understanding of how to use and manage an RTM makes it easier to use a tool. It provides an understanding of the principles of the RTM which makes the tool easier to use.
To develop the RTM requires a whole team approach. Using the RACI framework:
Responsible - Business Analysts, Designers and Testers are responsible for completing the traceability of the requirements ensuring that the business requirement is documented and logged.
The solution designer needs to ensure and link the components of the design to each requirement.
The tester needs to ensure that the test cases are linked to the requirement to ensure full coverage of the test cases.
Accountable - The project manager is accountable for making sure that the RTM is created and updated regularly. The project manager needs to provide the framework and processes to ensure that the RTM is reviewed and updated and any changes to requirements are managed in a controlled fashion.
Consulted - Other project team members can be consulted on the RTM and other project stakeholders.
Informed - other project team members and stakeholders like the PMO can be kept informed on the RTM.
A key success criterion for the RTM is to have the team discipline to review and update the artefact regularly. Discipline is also required to ensure that changes to requirements go through the change process and that impact assessment is done on the new or changed requirements. The RTM can assist in this impact assessment as you can go downstream from the requirement to the design and test cases to assess the impact.
Example of Process to Review, Maintain and Update the RTM
Put the RTM template in a shared folder that everyone can access and that there is version control.
If you’re using an Excel spreadsheet, a Sharepoint folder is a good way to share it without having multiple copies and you need to put in a process where there are no multiple versions of the document stored in the folder.
An example of a tool to manage requirements traceability, you can use the Atlassian suite to create traceability.
JIRA - is where the requirements and tasks sit. The relevant tasks are linked to the requirement. The issues can be linked to a section in Confluence with the design ID
Confluence - is where the design document can sit and each section of the design document can be backlinked to the JIRA issue with the requirement.
Bitbucket - where the code is implemented. The link with the JIRA issue and design ID in Confluence. This ensures traceability to the solution and requirement
X-Ray - stores the test cases and can be linked to the JIRA issue with the requirement, bitbucket commit reference and design ID.
Where the requirement is not a software development but an activity, for example, a marketing campaign, then the RTM can reference the document that has the marketing campaign plan.
Common Pitfalls
There are three common pitfalls for project teams when they are managing RTM.
Lack of Discipline
The project team is not regularly reviewing and updating the RTM and as a result, the RTM is outdated and doesn’t assist the project in delivering business outcomes.
To overcome the lack of discipline, the project manager should develop a process for the team to review and update the RTM regularly.
For example, the project manager and business analyst can develop a checklist of things to do when a new requirement comes in and how it goes through the change process. One of the steps would be to update the RTM. For the development team, the definition of done for a code commit is to update the RTM with the reference.
Setting aside time for updating the RTM is also a good idea. During the weekly project team meeting one of the agenda items could be a review of the RTM.
Incorrect Tool or Misuse of a Tool
An example of this would be using a Word document for a RTM instead of an Excel spreadsheet as it’s more versatile.
Another is making the process manual when the team uses a tool to capture the RTM or has too many mandatory fields to complete.
Tool selection, keeping the process simple, automating as much as possible and only capturing essential information makes the whole RTM process achievable.
Poor Communication
Poor communication between team members makes it challenging to keep the RTM updated. This can result in missing and outdated information in the RTM.
An agreed process, and time set aside to review the RTM as a team can help to overcome this issue.
Make sure team members and stakeholders are engaged to review and update the RTM.
Not Just Another Documentation
The Requirements Traceability Matrix is not just another document. It is a key tool to ensure that the project captures all the requirements and delivers the outcome that the customers and business are looking for.
It is not one person who is responsible. It’s an all-team effort to keep it up-to-date and relevant.
Free Template
I’ve created a template of a Requirements Traceability Matrix that you can download and use.
Click here to get a copy.
Practice
If you’re starting a new project, start using the RTM to track the requirements of the project.
If you have an existing project, see how you can improve the traceability of the requirements. It doesn’t have to be the full RTM as it is difficult and time-consuming to retrofit documentation into a project.
For example, you may be just about to start the testing cycle, can the test team and business analyst team trace the test cases back to the requirements?
If you have an RTM in your current project, is there any improvements that you and the team can make on it?
Quote
“Simple rules guide innovative, intelligent responses. Comprehensive rules guide rote, routine responses.”
— Jim Highsmith
Is there an instance in your project environment where there are comprehensive rules? Can they be simplified?
Resource
A solid book on gathering requirements for software development. It takes the beginner from the start right to the end on the what, why, who and how of software requirements. For the seasoned professional, it is a great reference guide to brush up on techniques and processes.
My Resources
Below are some of my free resources if you’re new to project management.
Paid Resources
Simple and Effective Project Risk Management is for those new to project management, the accidental project manager and experienced PMs wanting to learn something new. It will teach you what you need to know and get you started quickly. I’m running a promotion where the first 10 people who buy this get a discount, pay only $19, and can book a 30-minute coaching call with me.