Requirements Traceability Matrix (RTM)

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

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