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.
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).
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.
There are various parameters which can be included into RTM, but is not limited to, are as follows:
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:
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.
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 −
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.