Company PMO

Requirements Traceability Matrix Template Guidelines

To aid in the completion of a Requirements Traceability template, please adhere to the following guidelines. Definition Traceability is an activity that establishes a thread that traces or maps business requirements from identification through implementation. There is a forward and backward element to this activity that verfies that every requirement has been allocated appropriately through design, build (development) and testing. The purpose of the Requirements Traceability template is to ensure that all design, build and test documents conform to the components of the business requirements. The template is used to verify that all requirements are allocated to system components and other deliverables (forward trace). It is also used to determine the source of documented, implemented and tested system changes (backward trace). It ensures that all requirements are met and helps to locate affected system components when there is a requirements change. This ability allows the impact of requirements changes on the system to be determined, thereby facilitating cost, benefit and schedule changes. Ownership When Tracing requirements through testing is owned by the Project Manager. However, the Business Analyst is responsible for insuring that the template is created and maintained. The Project Team provides necessary input. It is created once the business requirements are completed and approved in the Requirements Stage of the Execution Phase. As the product(s) of the project are designed, built and tested, the template is updated and maintained accordingly. Requirements Traceability is a required deliverable for all projects. This Requirements Traceability template is provided for use with technology projects. It can also be utilized for non-technology/business line projects; however, the sub-headings may need to be changed to accommodate the type(s) of design documentation created for the project.

Purpose

Template Flexibility

This Requirements Traceability template includes data input fields that support internal controls and processes, corporate policies and risk mitigation principles, governance drivers, and/or project management control standards and proven best practices. It provides the minimum basic fields required to successfully complete the requirements traceability deliverable in meeting PMO requirements. The amount of detail included in the template will depend on the size, complexity and type of project. Each data input field provided in this template should be considered for applicability and relevance to the project at hand. Depending on the needs of the project and business owner, data input fields can be added, but should not be deleted. If a provided field in the template does not apply do NOT delete it, but rather mark it as "N/A" (non-applicable) and provide a BRIEF explanation as to why it doesn't apply to the project.

Template Completion

Important Notice

1. This Template Guidelines section is for reference purposes only. It should be printed and deleted prior to completing the final document. 2. Enter the project # (if applicable) and name in the page header and the Project Owning Line of Business Name in the page footer; e.g. SaaS Division, Networking Division, Consulting Services, etc. 3. Note that the included blue < > bracketed text is NOT to be included in your final document. Its purpose is to either provide guidance for completing requested information or to show where text is to be input. 4. This Requirements Traceability template is designed for use with technology projects as it traces Test Plans/Results back to systems and architecture designs to the original business requirements. For non-technology projects, the sub-headings under Design Solution would need to be changed to accommodate the type(s) of design documentation created for the project. 5. The Req ID# corresponds to the Requirements Identification number from the Business Requirements Document (BRD) or Use Cases if iterative development is the chosen design approach. 6. Design Solutions for mapping include the Detailed Technical System Specifications document(s) as well as various Systems Architecture Specifications (SAS), Application Architecture Specifications (AAS), Logical Design documents, etc. and the various created for the project. There may not be a unique ID# and description for each requirement analyzed in the Detailed Technical Specifications document(s). Expand the number of columns (increase page size to Legal) as needed and/or separate the single table into additional tables to accomodate all FSDs. 7. If there are multiple Test Plans for the same Requirement, then expand these columns as well. Note that these are the more detailed test plans that are created from the Master Test Plan. 8. If you have addtional notations for the information included on the Matrix, then include them within the Comments section. 9. Once the Requirements Traceability template is completed and after the project has been closed, this document is to be retained with other project documentation in accordance with the PMO standards and the business line's records schedule, storage and As this template may change, it is highly recommended that you access a blank template for each new project and not merely destruction requirements. use one from a previous project by editing the content.

Company PMO

lowing guidelines.

siness requirements from identification through that verfies that every requirement has been

all design, build and test documents conform to the y that all requirements are allocated to system ermine the source of documented, implemented and

em components when there is a requirements change. be determined, thereby facilitating cost, benefit and

However, the Business Analyst is responsible for provides necessary input.

d in the Requirements Stage of the Execution Phase. te is updated and maintained accordingly.

Requirements Traceability template is provided for use ess line projects; however, the sub-headings may n created for the project.

upport internal controls and processes, corporate management control standards and proven best omplete the requirements traceability deliverable in te will depend on the size, complexity and type of

pplicability and relevance to the project at hand. elds can be added, but should not be deleted. If a mark it as "N/A" (non-applicable) and provide a BRIEF

hould be printed and deleted prior to completing the

he Project Owning Line of Business Name in the page

n your final document. Its purpose is to either provide is to be input. hnology projects as it traces Test Plans/Results back to

ojects, the sub-headings under Design Solution would

project. from the Business Requirements Document (BRD) or

Specifications document(s) as well as various

cal Design documents, etc. and the various created

lyzed in the Detailed Technical Specifications

rate the single table into additional tables to

nd these columns as well. Note that these are the

trix, then include them within the Comments section. the project has been closed, this document is to be

siness line's records schedule, storage and a blank template for each new project and not merely

Requirements Traceability Matrix

Project Name Project Manager QA Lead Business Area Business Analyst Lead Target Implementation Date

BR#

Category/Functional Requirement Description Activity

Use Case Design Reference Document Reference

Code Module/ Reference

Company PMO

Test Case Reference

User Acceptance Validation

Comments