Requirements Gathering and Analysis: Requirements Traceability Matrix

A requirements traceability matrix (RTM) is a very important tool to have when gathering and analyzing requirements.  It gives you a vital resource that will help you even when the system has been implemented: bidirectional traceability.  What that means is that you can trace the requirement in the entire life of the system.  This is important because after a system is up and running, the requirements process doesn’t end.  There will be enhancements that the users will want done to the system, so you want to ensure that you are able to have your requirements well documented with bidirectional traceability.

So how do you create a traceability matrix?  Here you go.

  • Create a unique ID - This is how to track the requirement.
  • Have a requirement description - The requirement.  This usually begins with “The system shall…”

Here comes the bidirectional traceability begins:

  • Design Reference – Enter a reference to the design documentation that is addressing the requirement
  • Test Reference - Testing is very important to test out requirements.  Reference the test script
  • Release Reference - This is the release number that was pushed out to the users

This is usually done in a tabular form. I’ve seen many companies maintain the requirements on a spreadsheet. There are a couple of good requirements management tools out there, so definitely check those out before keeping them on a spreadsheet.

Develop your requirements traceability matrix today.  You will be able to track the requirements backwards and forward, so that you ensure that the development is on the right track.


3041233786 7b07b392bb Requirements Gathering and Analysis: Requirements Traceability Matrix

Tags: , , , , ,

  • Bala

    When do you write a RTM? Is it written before or after writing out test cases?

  • http://www.chicwriter.com dcfemella

    RTM should always be written before you start testing. However, I think you meant use cases.  If this is the case, then usually use cases are written first because you are working with the users to flesh out their every day tasks and how the envisioned system will simplify their processes.  One thing to note is that with more applications being built (some even open source), spreadsheets are being used less and less to capture all requirements.