Requirements Traceability Matrix – Demystified

Business Analysts often have to use the Requirements Traceability Matrix within their organisations but don’t necessarily use it in the most effective way. In this article we outline the purpose of the Requirements Traceability Matrix within a project environment and the basics of how to create and use this matrix effectively.

What is the purpose of the Requirements Traceability Matrix?

The Requirements Traceability Matrix (RTM) is a mechanism for managing the life cycle of a requirement throughout the project. It tracks what happens to each individual requirement from baseline (after initial approval) to final ‘go live’ or implementation. The Requirements Traceability Matrix records what happens to each and every requirement by way of status changes and phase artifacts. This matrix is also referred to as a Coverage Matrix by the BABOK Guide.

The reason for tracing requirements is simple: It enables everyone involved with a project in any way to know what has been implemented successfully and what have not been implemented successfully. It tells the story of each requirement’s life throughout the project. From a Business Analyst’s perspective, it helps the Business Analyst keep track of requirements and communicate to stakeholders about the status of each requirement as the project progresses.

So although the Requirements Traceability Matrix can be a fairly labor intensive document to manage, it is a very valuable and essential Business Analysis tool for each Business Analyst to utilise.

When in the Business Analysis Project Life Cycle do you need to create the Requirements Traceability Matrix?

You must only start your Requirements Traceability Matrix once your Business Requirements have been base-lined and approved. In a typical traditional waterfall methodology this means that you must get your Business Requirements Document or Stakeholder Requirements Document signed off and approved prior to creating the Requirements Traceability Matrix.

The reason for this is that the signed off Requirements are what you should use as your “base line” requirements to start with in the Requirements Traceability Matrix. Any changes to those requirements after they have been agreed and signed off must be managed via the Requirements Traceability Matrix. Once you started the Requirements Traceability Matrix you must not make any further changes to the requirements within the signed off Business Requirements document or Stakeholder Requirements document. From this point you only use the Requirements Traceability Matrix to manage your requirements.

Refer to the image below to see visually what this means.

How to create a basic Requirements Traceability Matrix?

Now we will outline the essential parts of a Requirements Traceability Matrix. You can simply use a MS Excel Spreadsheet to create your Requirements Traceability Matrix and contrary to popular belief, this matrix doesn’t have to be complex at all! However, you should also keep your own individual project structure, methodology and life cycle phases in mind when assessing and deciding which columns to include in your Requirements Traceability Matrix. This outline here is a starting point for you and serves as an explanation of the key parts of the RTM and the rest is up to you to interpret for your individual Business Analysis environment.

The Requirements Traceability Matrix consists of the following main categories or phases. These can simply be high level headings across the spreadsheet columns from left to right. Each of these headings will have sub headings – i.e. column headings as shown below.

Analysis Phase

• Column Heading: Scope ID – Each requirement must be traced back to a project scope item. As you would know each scope statement in your Business Requirements document must have a unique Scope ID.
• Column Heading: Scope Description – You should include the high level scope item description here to help the reader see which scope item your requirement refers to.

Please note: Although the Scope ID and Scope Description columns are the first two columns of your Requirements Traceability Matrix, you will only complete the Scope ID and Scope Description columns once you finished transferring all the signed off business requirements from the Business Requirements document.

• Column Heading: Requirement Category (optional column) – this column is only used if you logical categories which each of your requirements falls into. Often these categories will be defined in Business Requirements document.
• Column Heading: Requirement ID
• Column Heading: Requirement Description
• Column Heading: Requirement Status (Baseline, Changed, Deleted)
• Column Heading: Status – this column is typically a drop down list of statuses. See our proposed statuses and how you should manage each below:
• Status: Baseline – this status is assigned to each requirement which is transferred to the Requirements Traceability Matrix from the signed off Business Requirements document. It is the initial status for all the original requirements.
• Status: Changed – as you progress through the project, the original requirements sometimes change. If a requirement is changed for whatever reason, you should not change the Requirement Description of the original requirement but rather just change the Status of the original requirement to say: “Changed”. You then add a new requirement to the list which contains the description of the changed requirement. In the comments next to the original requirement you refer to the Requirement ID of the Changed Requirement Description which you just added. The idea here is that you will be able to keep track of the original requirement and when, why and to which requirement it changed.
• Status: Deleted – during a project life cycle, requirements are sometimes deemed inappropriate or not relevant anymore due to things that may have changed for the project. Again, you will never delete the original requirement as such, you will simply change the status of the original requirement to say “Deleted” and add your comments about why it is no longer required.
• Other Statuses: You can include other statuses that you might feel is relevant in your project environment but make sure they are distinct from the other statuses already included and that they will add value to describing the life cycle of your requirements.
• Column Heading: Comments – as described in the Status of “Changed” above, the comments column is used to capture the new Requirement ID where applicable, the reason for the change / deletion. In the reason provide dates and people as well to keep your information rich for future reference.

Design Phase

Depending on how you plan to implement the design phase of your project you may vary the columns used. The basic columns to include here are as follows:

• Column Heading: Design Specification ID
• Column Heading: Design Specification Description / filename – you should include here the details of the document that is describing the functional design of the requirement you are looking at. This entry may be the same for a set of your requirements but should nevertheless be as specific as possible. If you can refer to a specific prototype or design user story, please do so in this column by referencing the document sections as well as the document file name and location.

Build Phase

Again, depending on how you plan to implement the build phase of your project you may vary the columns used. The basic columns to include here are as follows:

• Column Heading: Build Specification ID
• Column Heading: Build Specification Description – you should try and be specific in terms of which Build Release the specific requirement would be included in.

Test Phase

Again, depending on how you plan to implement the test phase of your project you may vary the columns used. The basic columns to include here are as follows:

• Column Heading: Unit Test ID
• Column Heading: Unit Test Description
• Column Heading: System Test ID
• Column Heading: System Test Description
• Column Heading: Integration Test ID
• Column Heading: Integration Test Description
• Column Heading: User Acceptance Test ID

Column Heading: User Acceptance Test Description – this column is a very important column to include because this is where the business stakeholders get interested to see that their individual requirements have been implemented successfully. Make sure to refer to the specific test scripts here.

Implementation Phase

Finally, the Implementation phase of a project is the time when you should be able to get agreement from the business sponsor that your Business Requirements have been successfully implemented as per the original requirements of the project. This is essentially why the Requirements Traceability Matrix is very important for you to use to demonstrate to the Business Stakeholders the life cycle and the journey of each of their stated business requirements from beginning to the end of the project.

• Column Heading: Implementation Plan ID
• Column Heading: Implementation Plan Description