Understanding the Requirements Traceability Matrix

One of the important documents that stand out during project planning is the requirements traceability matrix (RTM). It is the heart of requirements collection phase and is a very effective document for maintaining, tracing and implementing the requirements as the project progresses.

While working in an SDLC project, there tend to be numerous resources involved for different phases. We can’t expect all of them to speak a common language in terms of referring to an item or a task or even the process itself due to different background on their skill set and type of job roles.

One term I often see people getting confused is the requirements traceability matrix and Mapping matrix. The key distinction is that the former is furnished by the Analyst throughout the requirements collection phase and the latter is produced during the BRD or mapping of physical requirements to their technical components (example – an item tracked through different schemas and databases and associated business rules).

The requirements captured and finalized in the requirements traceability matrix will help shape the WBS tasks and Activities list, which in turn will be used for developing, project schedule. That was a very high level description of the process but when you put all that into action there are many steps and many documentations resulting in the end.  That’s a topic of discussion for another day!

Going back to the Requirements Traceability Matrix, the project team manager and the analyst will work closely with the SMEs and stakeholders to capture their vision and goals of the project objectives more accurately and also capture supplemental information like who requested the requirement, business justification, affected components, business rules, related WBS entry, source etc. that comes in handy during the entire project. We’ll see some of the elements used in the matrix more closely in the attached sample.

So how are these different elements captured and what are the steps involved?

The requirements collection process starts with the project manager meeting with the SMEs and Stakeholders by setting up one or more of the following activities.

  • Interviews
  • Focus groups
  • Cross-functional team meetings
  • Brainstorming sessions
  • Facilitated workshops
  • Prototype (my favorite and most common)
  • Surveys and Questionnaire

In my experience, acquiring the prototype and following it up with additional questions around the components requested is one of the most effective ways of gathering requirements. Without examples or prototypes, the analyst will be left scrambling to understand the business requirements and translate them into technical deliverables. This is because at times the business users/stakeholders tend to be vague in what they want in terms of intrinsic needs while defining a deliverable. I shouldn’t say this but many of the users/stakeholders are of wavering mind and will change their requirements as the project timeline advances. Which in my opinion is fine because during project progression the corporate goals and direction of the organization might change with their changing consumer market and those changes in goals would need to be aligned and incorporated in an on-going project. This is where RTM comes in handy and is the master sheet for “tracing” the requirements and the details around each of them. One thing to remember is that there should be unique identifier for each requirement and they should never be deleted or re-ordered.  This is so each of the requirements that are referenced throughout the communications and also included in the BRDs or other documents like RAID would mess up the association and cause confusion. I always use a flag on all the entries that states if the requirement is current or outdated & whether it is needed or not.


Here is an example of a Requirements Traceability Matrix document.

Requirements Traceability matrix example