Requirement traceability matrix – a simple and a powerful tool

One of my colleagues quotes in his signature – “Help me understand your requirements clearly.. so I can help you better through our deliverables.” I too think understanding the requirements of your customer is the most important factor in delivering the project successfully in IT business. A requirement traceability matrix (RTM) is a simple and useful tool which facilitates this understanding throughout the lifecycle of the project. A RTM is useful in many ways.

1. It controls the scope creep. This is the main job of a RTM.
2. It gives very clear picture of project in a simple consolidation
3. It is very Helpful in scope verification
4. It helps in building the customer/stakeholders confidence
5. It simplifies the complex requirements
6. It facilitates in dealing with issues and risks

A RTM can be build in a simple excel sheet, in a SharePoint listing or as a part of an enterprise PM tool. Whatever the way one builds a RTM, it will have the references to all the deliverables of all the stages of the project with some meaningful descriptions.

How to develop a RTM -

The business requirements are built in planning phase of the project. They are decomposed into functional requirement/system requirement specification/WBS in planning phase itself as a part of the scope planning. There will be one -many mapping between business requirement and functional requirement usually. The first version of requirement traceability matrix should be built at this point by writing the requirements clearly along with unique requirement traceability numbers in a tabular form. It is also advisable to get the RTM approved by the customer or the responsible stakeholders after completing a project phase. Technical requirements are built during planning/define or design phase of the project depending on the complexity and business need of the project. Functional requirements and technical requirements can have one-many or many-one mapping. Technical requirements can be referred in RTM as a short description with reference to technical or system requirement specification document. HLD and LLD can be referred in RTM with reference numbers and reference pointers. It’s as simple to do as updating an excel cell. HLD and LLD will have one-one mapping with functional/technical requirement usually. Code references should be made with component name and address of the component and unit testing references should be made with testing case number and location of unit testing document. There will be one-one or one-many mapping between technical/functional requirement and code. Requirement to unit testing mapping will be one-many mostly. Finally, functional testing and system/integration testing should be referred with test case numbers and testing document location address or testing references of the testing tool if a testing tool is being used in the project. Some testing tools also provide in-built RTM. There will be one-many mapping between functional and system testing and the requirements.