Requirements Traceability Matrix (RTM)

A Requirements Traceability Matrix (RTM) is a tool used to identify and track requirements throughout a project lifecycle.

An RTM can be part of the Business Requirements Document (BRD) or its own separate document. It can be represented in the form of a table, diagram, or written text and is often used with high-level or detailed requirements for the purpose of matching the requirements with the work done in design documents, Use Cases, and test cases.

The RTM may be used to verify that the current requirements are being met and to aid in the creation of a Request for Proposal (RFP), various deliverable documents, and project activities.

Business Analysts can use the RTM to track the requirements in each phase of the project. For example, if a BA identifies 50 Requirements during the “Requirements” phase, the developers should base their design on supporting the 50 requirements in the “Design and Development” phase. Likewise, the QA/QC team should plan their testing activities based on the same 50 requirements. If at either phase a team is working with less than or greater than the originally identified 50 requirements a requirement may have been missed or added and an investigation should be done to resolve the issue.

A common reason for a QA team to have more requirements than what is in the RTM is that they have their own set of testing standards that have not been identified during the “Requirements” phase.  If this is the case, a BA should update the BRD to include all testing activity requirements.  Likewise,  if the development team is designing a product based on requirements not recorded in the RTM,  the BA should identify if the additional requirements were initially missed or if it is due to scope creep.  Missing requirements will also have to be reviewed to determine where and why they were dropped.

A simple RTM to hand to the Development or QA teams may consist of a Unique Identifier for each Requirement, a Description of the Requirement, Source of the Requirement, Priority, and a status column to indicate if the requirement has been approved, rejected, or out of scope. (See the matrix below).

Simple RTM based on the MoSCoW method

Identifier Description Source Priority Status
1 The System must display a welcome message CEO, August 19, 2010 High Approved
1.1 All messages must be in French and English Client, August 20, 2010 High Approved
1.2 A welcome message won’t be longer than 140 characters Brainstorming session, September 5, 2010 Medium Approved
2 The System must connect to the internet CTO, August 19, 2010 High Approved
2.1 The System must support a Wi-Fi connection John Smith, August 19, 2010 Low Out of Scope
3 The System should record audio CEO, August 19, 2010 Medium Approved
4 The System should record video Status Meeting, September 8th, 2010 Medium Approved
5 The System could record 3d images Client, August 20, 2010 Low Rejected
5.1 The System could support .jpg images Client, August 20, 2010 Medium Approved
5.2a The System could store images in a repository John Smith, August 19, 2010 Low Out of Scope
5.2b The System could store images online John Smith, August 19, 2010 Low Out of Scope

Another way to create an RTM is to take the BRD (or other deliverables) identifier for each of the requirements and place them in the left column of a matrix (see matrix below) The identifiers for the other document (i.e. Use Cases) are placed across the top row of the matrix. When an item in the left column is related to an item across the top, a check mark (or x) is placed in the intersecting cell.  If you are creating an RTM to map Use Cases then each requirement should be associated with at least one Use Case.

Use Case RTM

Unique Identifier Requirements Tested Use Case Use Case Use Case Use Case Use Case Use Case Use Case
    1.1 1.2 1.2.1 2.1 2.2 2.3.1 3.1
Test Cases 35 2 2 5 3 1 4 1
1 3 x            
1.1 2   x x        
1.2 2 x            
3 1     x   x    
4 5 x            
5 4   x          
5.1 3 x            
5.1a 12       x   x  
5.1b 5             x


By Morgan

CBAP and PMI-ACP with over 20 years of Project management and Business Analysis experience.