Creating and maintaining a requirements traceability matrix (RTM) is not a simple task. It is time consuming and requires a considerable amount of effort and commitment from the project team. In my experience, the RTM is one of the artifacts that is frequently out of date and constant reminders are needed to ensure that it is updated by the team. The RTM has its uses, but I find that project teams rarely use it. The sheer effort that is required to maintain the document deters the team and if it is not a deliverable to the client, the traceability matrix is usually ignored.
For organizations that follow enterprise quality management systems such as CMMi, it is compulsory to have traceability procedures. As a result the RTM becomes a mandatory artifact for software projects. However, whether it is actually used by the project team for its purpose is uncertain. Stakeholders generally view the RTM as something to be implemented to comply with standards. Consequently project teams spend less effort on traceability leading to an artifact that is not useful.
What are the key components of a RTM? A comprehensive requirements traceability matrix should include the following.
- Business objective
- High-level Use case / Use case #
- Requirement ID / Description / Type of requirement / Source
- Risks
- Dependent requirements #
- Design reference #
- Implementation class / module
- Unit test cases
- Integration test cases
- Implemented release / release #
- System test cases
- User acceptance test cases
Most RTM templates will not include all of these components. Organizations can customize the template according to their needs and may choose to add or remove certain elements. However, for the RTM to be complete and useful, I believe that all of the above components are required.
Given the amount of information that has to be included, it’s easy to see how cumbersome it can be to maintain the document, especially in large, complex programs. Not surprisingly, there will be resistance from the project team to keep the RTM up to date.
Here are some of the advantages and disadvantages of the RTM.
Advantages:
- Maintain forward traceability to ensure the completeness of the implementation.
- Requirement changes can be traced forward to associated requirements and all the work products that are impacted by the change.
- Reduces the effort required to do a thorough impact analysis.
- Reduces risk that one of the affected work products is forgotten which may result in an incomplete implementation of a change.
- Maintains backwards traceability to ensure that the product remains on the correct track with regards to the requirements.
- Ensures that the scope of the project is not expanded by adding design elements, code or tests that are not specified in the requirements.
- Implementation changes / new technical solutions can be traced backwards to the requirements and the business objectives to ensure that it is within the scope of the product.
- Defects can be traced back to determine if it is a code, design or requirement defect and what other work products might be affected.
Disadvantages:
- Additional effort required to create and maintain the RTM and update it regularly.
- Capturing requirements traceability becomes complex and expensive as the product grows in size and complexity.
- Maintaining traceability through changes to the system can be challenging as all changes have to be updated in the RTM.
- Manual traceability methods can lead to incorrect requirements traceability data.
In my view, the benefits outweigh the drawbacks. Investing the additional effort and cost to maintain the RTM will help to prevent problems arising from lack of impact analysis, incomplete implementation, expanded scope etc. during project execution. If the benefits of the RTM are clearly understood by the project team and other stakeholders, there would be less resistance to implementing it. I believe this can be achieved through proper training regarding the importance and benefits of the RTM. As projects become larger and more complex, maintaining traceability becomes more vital.
Have you implemented a requirements traceability matrix in your projects? What are the pros and cons that you have experienced? Please share your thoughts in the comments.
References:
- Requirements Traceability Matrix - http://www.tutorialspoint.com/software_testing_dictionary/requirements_traceability_matrix.htm
- Why Software Requirements Traceability Remains a Challenge - http://static1.1.sqspcdn.com/static/f/702523/9188499/1288392919397/200907-Kannenberg.pdf?token=0cOV5UTB4kPtIijp6g16fgqSAlo%3D
- Why is it necessary to use a traceability matrix? - http://www.chiron-solutions.com/chiron-professional-journal/2011/01/27/why-is-it-necessary-to-use-a-traceability-matrix/
