Trace Your Requirements with A Traceability Matrix (RTM)

The backbone of any project lies with requirements. The requirements identified, collected and documented at the initial stages, are generally designed, coded, tested, and takes the shapes of a product or an application to be used by the customers later. Those requirements are referred at any point of time by the team and other stakeholders to check whether the current project requirements are being met. And tracking back those bulk of requirements at the later stage of the project by manually examining the relationship between them is a cumbersome affair.

Business Scenario – Case Studies

Let’s discuss a scenario, Mr. A is working as a project manager in a renowned Mobile Network Service company. The company got a new project and assigned Mr. A, the experienced manager of the company to take the responsibility of the project as a Project Manager. It is a big project with huge requirements covering network data samples for a major part of North America. Mr. A formed his team and started the project works. In the initiation phase, he and his team collected and documented all the requirements. All the documented requirements like Business requirements document, Design Specification, Diagrams etc. are kept in the project repository. And, then the project works started and sailed smoothly through phase by phase and reaches the testing phase.

Before executing the test cases, Mr. A wants to check the test coverage. He wants the test coverage should be 100%. The test cases should be covered all the requirements, any missing requirements can jeopardize his project and his reputation at a later stage. So he called his team for an urgent round table meeting to discuss on it.

They started checking the test coverage by going through the test cases. But the major problem they faced is to find out the requirement documents for each of the test cases written by them. They have to manually download the requirement documents from the repository and search for the particular content from which the test cases are derived from. Thus, the process takes more time than the expected time. Mr. A is now in a big problem, he has to complete this exercise as soon as possible, so that the team can start the next phase, execution of test cases. He cannot afford to invest more time in this exercise. This becomes a major blow to his well maintained schedules. So, How can he manage now? What is his fault? Is this situation can be avoided? Yes, this situation can be avoided, if Mr. A and his team would have created a Requirement Traceability Matrix (RTM).

Requirement Traceability Matrix (RTM)

A Requirement Traceability Matrix (RTM) is a very useful document which maps test cases to requirements. The purpose of the matrix is to ensure that all the requirements are covered in the test cases. The RTM matrix used to map or link the requirements helps to trace them back when required. In the case of large volume project, the requirement documents and the test cases derived from them are huge in number, so it becomes a very difficult task to trace them back when required.

Parameters of Requirement Traceability Matrix

There are various parameters which can be included into RTM, but is not limited to, are as follows:

  • Requirement Identifier (ID)
  • Requirement Type
  • Requirement Description
  • Risk
  • Trace to design specification
  • Unit test cases
  • Integration test cases
  • System test cases
  • User acceptance test cases
  • Trace to test script

A sample Template of Requirement Traceability Matrix is as follows −

Another sample is as follows:

The Requirement Traceability Matrix can have different parameters depending upon the organizational and project needs. The basic purpose is that, the requirements are mapped to the Business Requirements, Work breakdown Structure (WBS), Design Specification, Code, test plans, Test Strategy, Test Scenarios, Test cases and other artifacts, which can be traced back and forward to check the complete coverage.

Typical parameters of Requirement Traceability Matrix are, a unique identifier, a brief description of that requirement, Version, Owner, Source, Priority, current status and date.

The unique identifier helps to search the related documents and artifacts in linked documents and repository. A brief description is provided along the identifier to understand that particular requirement. Version of the requirement should be mentioned there, as well as the name of the person who owns that piece of requirement. Another important thing is the source of the requirement, we need to mention whether those requirements are derived from Project Charter or Statement of account or any other source of information such emails, requirement documents etc. Priority of that requirements also need to be provided there. The status and date should be mentioned. The current statuses can be:

  • Active
  • Deferred
  • Cancelled
  • Approved
  • Assigned
  • Completed

The Requirement Traceability Matrix provides the team and the stakeholders to track requirements throughout the project life-cycle, and helps to ensure that all the requirements are delivered at the end of the project.

Tracing of Requirement Traceability Matrix

As we discussed, the main purpose of the Requirement Traceability Matrix (RTM) is to trace the requirements. The tracing can be forward, backward or bidirectional depending upon users requirement. Based on the need 0f the hour, the Project Manager and his team can perform forward, backward or bi-directional tracking. Let’s see when and how the project managers and other stakeholders trace the requirements by using these three directions Forward, Backward and Bi-directional −

  • Forward Tracing − When the Project Manager or any of the Stakeholders wants to check the project progress they can use the Requirement Traceability Matrix to ensure whether the progress is in the right directions. It ensures them, that the requirements are applied correctly and the product is shaping as per the required requirements. This helps in future prediction of the project health by measuring the accomplished works and remaining works, and whether the requirements are understood and covered correctly.
  • Backward Tracing − For example, You are in the last stage of testing phase and one of your important stakeholder questions you on one of the functionality of the product. He is doubting that you are expanding the requirement and added some additional feature which were not stated in the requirements initially. So, at that point of time how can you ensure that you are going on right direction? Here, the requirement Traceability Matrix will help you, where you can see the test cases and their respective requirements, Business requirements and design specification etc. to prove whether you are on the right path or not. This happens mostly in most of the projects, and at that point of crisis, the backward tracing really helps to trace back the actual requirements and clarifies whether anything is missed on the way or you are heading in right direction.
  • Bi-directional Tracing − So, this Matrix can be used in both the directions, forward as well as backward as per your needs. We can use it to check the progress in forward directions, and also can use it to trace back the requirements in backward directions.

So, today we discussed the usage, template and various parameters of Requirement Traceability Matrix. This is a very useful matrix for the Project Managers, as well as for the Stakeholders, as it helps them to keep an eye on the project statuses, it ensures them that the project is progressing in the right direction, and also helps them to trace back the requirements when needed. This is an important weapon for the Project Managers to run the project successfully without any hiccups.

Updated on: 17-Jan-2020


Kickstart Your Career

Get certified by completing the course

Get Started