Project Management

Why implement a requirements traceability matrix?

From the The Project Management Corner Blog
by
A space for sharing project management concepts, tips for improvement, best practices and lessons learnt.

About this Blog

RSS

Recent Posts

Certifications: PMP vs ITIL

10 Tips to Improve Communication

Becoming a better PM: Lessons from 'How to get better at the things you care about'

5 Essential Skills of a Business Analyst

6 things to consider if you are thinking of becoming a Certified Scrum Master



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:

  1. Requirements Traceability Matrix - http://www.tutorialspoint.com/software_testing_dictionary/requirements_traceability_matrix.htm
  2. Why Software Requirements Traceability Remains a Challenge - http://static1.1.sqspcdn.com/static/f/702523/9188499/1288392919397/200907-Kannenberg.pdf?token=0cOV5UTB4kPtIijp6g16fgqSAlo%3D
  3. 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/

 

Posted on: April 06, 2016 12:31 PM | Permalink

Comments (11)

Please login or join to subscribe to this item
Hi Ranmali,
thanks for that good summary of a RTM.

I add some ideas from my experience:
In the SW industry, larger companies use RTM to track user/customer requirement for a product, which will transform into design features, components and to determine and track in which release they will be delivered. It then is often integrated into Configuration Mgmt System, integrated with a change control system.
I have seen automotive companies tracking their requirements through design, build, test and delivery, an integrative tool suite is IBM's Rational. If they use RTM alone, they suffer from the need to migrate data between tools for each development phase.

For individual SW project, mainly other means might be pursued in my experience, e.g. in agile with backlog item tracking, which is supported by tools like JIRA. But the do not strictly distinguish between requirements and features.



As Thomas mentioned, the industry is a factor in RTM adoption as well as the maturity of the organization has a major impact on the acceptance of RTM.

Hi Ranmali,
Thanks for the post and touching this subject.

I being part of Engagement Management and Business Development have faced challenges and problems when we come across Change Management scenario. As you have listed many advantages with possible additional investment in terms of Efforts and Resources but to make any project successful, I am FOR this. RTM need to be in place and tracked/referred time to time to ensure there is no conflict and issue. This would to be KEY when vendors work on Fixed Bid projects.
I have seen many vendors rushing to WIN the order and start the project without established approved/accepted RTM. Many projects move into dispute because of this and which cause more delay, conflict and failure of projects.

Having RTM would benefit all parties involved.





Thomas, David and Parag, than you for your insights. I agree that the maturity of the organization also plays a big part in the acceptance of the RTM. And I have experienced the issues faced in fixed bid projects where there is lack of traceability.

I'm working at home applicance field. We use RTM & Project change mangement together. And only record vital requirements which should impact project cost, quality and scope. Not every requirement was involved in RTM during new product introduction.

Thank you for the feedback Shibiao Meng! It's good to have views from other industries.

Hi Ranmali,

Thank you for taking us through the advantages & disadvantages of using this TOOL in projects.May be it is time consuming ,but it will help to bring more clarity into scope.One stitch saves nine.

Thanks for the comments Justin. It definitely brings more clarity to scope and the objectives.

Hello Ranmali,

Can you please share some sample RTM as we don't have any specific tool to manage this. we try to incorporate this on an excel sheet but with multiple fields as mentioned by you, it will be even more complex. Thus, is there a sample format that we can look at for the guidance.

Thanks,
Manish

Hi Manish, we use an excel spreadsheet for the RTM as well. I agree that the multiple fields make it complex so it needs to be managed within a version control system. Here's a link to a sample RTM. It has less fields but you can expand on it based on your need. I hope this helps.
https://www.projectmanagement.com/deliverables/279762/Requirements-Traceability-Matrix

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

Please Login/Register to leave a comment.

ADVERTISEMENTS

The second day of a diet is always easier than the first. By the second day you're off it.

- Jackie Gleason