Requirements Traceability Matrix Template Guidelines

To aid in the completion of a Requirements Traceability template, please adhere to the following guidelines. For additional assistance
regarding templates or project deliverables please refer to the University Services Program Management Office.
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.
Purpose 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 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.

When 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.

Template This Requirements Traceability template includes data input fields that support internal controls and processes,
Flexibility 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 1. This Template Guidelines section is for reference purposes only. It should be printed and deleted prior to
Completion 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.
Technology Information Group, Home and Consumer Finance Group, Private Client 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.
Important Notice As
9. this
Oncetemplate may change,
the Requirements it is highly template
Traceability recommended that youand
is completed access
after athe
blank template
project for each
has been newthis
closed, project and not
document is
merely use onewith
to be retained from a previous project by editing the content.
other
project documentation in accordance with the PMO standards and the business line's records schedule, storage and
destruction requirements.
es. For additional assistance
Office.
ements from identification
verfies that every requirement

uild and test documents conform

all requirements are allocated to
ne the source of documented,

nts when there is a requirements

etermined, thereby facilitating

Business Analyst is responsible

necessary input.

uirements Stage of the Execution

updated and maintained

s Traceability template is
usiness line projects; however,
umentation created for the

al controls and processes,

anagement control standards and
omplete the requirements
n the template will depend on

nd relevance to the project at

an be added, but should not be
mark it as "N/A" (non-applicable)
ted and deleted prior to

wning Line of Business Name in

nt Services, etc.
document. Its purpose is to either

t.
cts as it traces Test

ub-headings under Design

iness Requirements Document

s document(s) as well as various

ocuments, etc. and the various

Detailed Technical Specifications

e table into additional tables to

umns as well. Note that these are

ude them within the Comments

atebeen
as for each newthis
closed, project and not
document is

records schedule, storage and

Requirements Traceability Matrix

Project Name Business Area

Project Manager Business Analyst Lead

QA Lead Target Implementation Date

BR# Category/Functional Requirement Description Use Case Design Code Module/ Test Case User Comments
Activity Reference Document Reference Reference Acceptance
Reference Validation

Page 5