1. Requirements Traceability Matrix
PLAN IT!
Hi! My name is Bev Dias, a member of the Program Management Center of Excellence Advisory Council. The purpose of this video is to provide you with an introduction of the Requirements Traceability Matrix (RTM). In project management, the RTM is a one-stop shop to store all of the requirements of your project in an organized, easy to use format. Developing it is critical to the success of your project, and is an important step in the project Plan IT! phase.
Requirements are so critical that they are often found in procurement documents, which must be individually addressed as part of the vendor proposal.
The RTM is a required deliverable for all projects.

2. Requirements Traceability Matrix
There are various types of Requirements:
Functional Requirements
Technical Requirements
Security Requirements
Vendor Requirements
The Requirement Type is recorded in Column 1
Requirements are usually grouped by Type
There are various types of Requirements:
Functional Requirements – Usually, requirements are identified and gathered through a stakeholder workshop after the current and future business processes have been mapped. The gap between current and future business process, and current processes being kept in the future process, become the functional requirements of your project.
Technical Requirements – are the requirements the technical team needs to ensure that the hardware, software, network, database, etc. can support the business operations, and functional requirements.
Security Requirements – are the technical and organizational requirements needed to nsure all security needs are in compliance.
Vendor Requirements – are the requirements an organization has for its vendors in order to meet procurement policies and procedures, and technical and security requirements.
There could also be project requirements, legal requirements, regulatory requirements, or others, as needed specific to your project.
The Requirement Type is recorded in Column 1; Requirements are usually grouped by Type

3. Requirements Traceability Matrix
Each requirement contains the following:
A unique requirement number
A brief, high level description of the requirement
The requirement priority (Must Have, Should Have, or Nice to Have)
The requirement source (the requestor)
The objective (from the Project Charter) to which the requirement relates
Where the requirement is located in the Work Breakdown Structure
Each requirement contains the following:
A unique requirement number
A brief, high level description of the requirement
The requirement priority (Must Have, Should Have, or Nice to Have)
The requirement source (the requestor)
The objective (from the Project Charter) to which the requirement relates
Where the requirement is located in the Work Breakdown Structure

4. Requirements Traceability Matrix
The second half of the RTM is completed as the project progresses:
Design Document Reference
Code Module/Reference
Verification
Verifier
Use Case Reference
Test Case Reference
User Acceptance Validation
Comments
The second half of the RTM is completed as the project progresses:
The Design Document Reference is assigned during the Design phase and used in subsequent phases of the project.
The Code Module/Reference is assigned during the Build/Development phase, and utilized through subsequent phases of the project.
The Verification is performed during the Design and Build/Development phases to ensure that the coding is operating as expected.
The verifier of each requirement is also tracked.
Use Case Reference and Test Case Reference are used to track the testing of the requirements.
User Acceptance Validation are part of the final sign-off and acceptance.
The Comments field may be used to record any information that you want to associate with the requirement.

5. Requirements Traceability Matrix
Used correctly, the RTM is a running history of the project requirements, including Change Requests, from identification through implementation, to ensure that every requirement has been allocated appropriately through design, build (development), testing, and final sign-off and acceptance.
Used correctly, the RTM is a running history of the project requirements, including Change Requests, from identification through implementation, to ensure that every requirement has been allocated appropriately through design, build (development), testing, and final sign-off and acceptance.
Good luck with your Requirements Traceability Matrix.
The next video is the Work Breakdown Structure.