I worked across many projects with many stakeholders and have always found one tool which is not properly used and that is a Requirements Traceability Matrix (RTM).
People will either create a very complex RTM or a very simple RTM Many project professionals don’t consider this as an effective artifact and thereby resulting in a document which covers very few details and renders no use. On the contrary, some professionals expect a RTM to pin-point everything and thereby end up in creating a document which is not only complex to create but brain freezing when it comes to reviewing and updating it.
“If used correctly, a RTM can be your Google map for your requirements journey from its origin to destination”.
An effective Requirements Traceability Matrix
If you have a decent RTM in your project which is reviewed and updated regularly, trust me, you can save yourself from plenty of nightmares. On the other hand, no RTM means you can go wrong at many places.
RTM can help you by ensuring that the agreed upon requirements are met.
RTM’s main job is to track the relationship between business needs, requirements, test cases, release plans, etc. If used smartly, it can be used to prioritize team’s time towards the most important tasks.
Forming traceability can help project professionals:
- Track a requirement from origin through to delivery,
- Effectively Plan and manage testing and tracks defect better,
- Prevent requirements from escaping through the leakages, also prevents from resources doing out of scope work,
- Document sufficiently and effectively, and
- Allow collaboration and integration.
Requirement Traceability Matrix – Fields to capture
- Requirement ID
- Requirement Type and Description
- Trace to design specification
- Unit test cases
- Integration test cases
- System test cases
- User acceptance test cases
- Trace to test script
You can create different types of traceability matrix:
Forward traceability confirms direction of the developing product and specifies the completeness of the subsequent execution. For example, a business rule has to be traced forward to one or more business processes (use cases), if not, then the product requirements specification is not complete and the resulting product may not meet the business needs. Similarly, the use case has to be traced forward to its connected architectural design components, if not, and then the architectural design is incomplete.
Backwards traceability confirms that the developing product remains on the correct path in respect to the original and/or evolving requirements. To the main purpose is to ensure that people are not expanding the scope of the project by adding design components, code, tests or other work products that are out of scope. If solution change is required or recommended, the change should be tracked backwards to the requirements and the business needs it falls under, to ensure that it is not out of scope. For example, there may be a possibility is that some requirement has been added to the functionality that should not be part of the scope. This document prevents it.
Bi-directional traceability (Forward + Backward): A hybrid of both.
Steps to prepare a Requirement Traceability Matrix (RTM):
- Gather all the requirement documents. For e.g. Business Requirement Document(BRD), Functional Specification Document(FSD), Technical Requirement Document(TSD)
- Jot down all the requirements from the BRD first along with the requirement ID#
- Now next step is to do the same from FSD – list all respective functional requirements for each Business Requirements
- Link available Test Case IDs to respective Functional Requirements
So if we follow the steps above the RTM will look like the one below:
Add if you feel necessary, the following:
- Execution Status
- Defects column
This will help you to view overall status of all requirements along with Test Cases.