You are on page 1of 6

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.

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

be determined. but should not be deleted. the Business Analyst is responsible for provides necessary input. benefit and However. complexity and type of pplicability and relevance to the project at hand. d in the Requirements Stage of the Execution Phase. implemented and em components when there is a requirements change. elds can be added. however. siness requirements from identification through that verfies that every requirement has been all design. te is updated and maintained accordingly. the sub-headings may n created for the project. build and test documents conform to the y that all requirements are allocated to system ermine the source of documented. thereby facilitating cost. upport internal controls and processes. Requirements Traceability template is provided for use ess line projects. If a mark it as "N/A" (non-applicable) and provide a BRIEF . corporate management control standards and proven best omplete the requirements traceability deliverable in te will depend on the size.Company PMO lowing guidelines.

the project has been closed. 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. etc. Its purpose is to either provide is to be input. storage and a blank template for each new project and not merely . the sub-headings under Design Solution would project. hnology projects as it traces Test Plans/Results back to ojects. from the Business Requirements Document (BRD) or Specifications document(s) as well as various cal Design documents. then include them within the Comments section.hould be printed and deleted prior to completing the he Project Owning Line of Business Name in the page n your final document. this document is to be siness line's records schedule.

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 .