Requirements Traceability Matrix

Project ID
Requiremen
t ID

Project Name

Last Update

Requirement Description

Requirements
Category

Design ID

Build ID

Technical /
System Test
Case

User /
Acceptance
Test Case

Guidelines
At the most basic level traceability is concerned with two things:

Ensuring that every requirement is built into the completed product/solution

Ensuring that every feature ties back to a requirement

This template is a very simple guide for organizations just starting to trace requirements. As organizations become more comfortable with traceability they will likely
want to add additional columns, but this will serve to help ensure that all requirements are built, and that all features match requirements. The descriptions of the
columns below provide some basic guidelines on how to use this template as well as suggestions for how the template can be expanded. The headings of this
template suggest a software build, but the concepts of traceability can be applied to any kind of solution.

Requirement ID This is the key reference back to the requirements documentation and should follow a logical numbering convention. This numbering
convention should be determined when the requirements are written with each requirement being given a unique identifier. A common ID format is 1.1, 1.2,
2.1, etc., where the first number references the section in the requirements document and the second references the specific requirement. This approach
is better than a straight numeric format because it allows for grouping of requirements. A similar approach uses a description of abbreviation of the
Copyright ProjectManagement.com

category UI1, UI2, Profile1, Profile2, etc. Regardless of the format you use, it is important to ensure that the convention is consistent with the
requirements documentation to make traceability easier perhaps even making the ID a hyperlink to the requirement in a requirements management tool
(if used). The requirement ID should be unique within the project and not reused in the event of a requirement being removed from scope, and if you have
multiple versions of requirements consider adding a version number field to the template. Each row in the traceability template should relate to one
Requirement ID.
Requirement Description This is simply a convenience field for the description of the requirement. It is not strictly necessary as the ID field is included,
but by pasting the description from the requirements document it makes it easier to work with the traceability matrix as the need to keep switching between
documents is avoided.
Requirements Category This field is used to assist with the grouping of requirements or to otherwise identify characteristics of the requirements. While
the Requirements ID field can help to categorize items by requirements category, this is used for other elements. In some cases, you may need to create
additional columns for multiple characteristics of a requirement. Examples of categories that may be captured here are product area, requirements priority
or requirements type (product enhancement, bug fix, client request, etc.). This field should not be included unnecessarily; any captured data should assist
with the management of the requirements traceability.
Design ID This field follows the same concept as the Requirements ID, but this time it refers to the design documentation. While requirements are
generally captured as sentences and paragraphs, the design may be more of a diagram format, especially for technical solutions, but it is still possible to
assign IDs to each box/feature/function. Unlike Requirements ID, this field may contain multiple IDs (a requirement is completed by multiple design
elements) and a single Design ID may appear in multiple rows in the table (a design element fully or partially addresses multiple requirements).
Build ID This field builds on the Design ID and takes the design element to actual implementation, each Build ID represents the implementation of a
specific feature. The concept is identical to Design ID in that there may be multiple Build IDs for each Requirements ID and that a Build ID may appear in
multiple rows (i.e. for multiple Requirements ID). However, there are some restrictions that should be imposed on this field:
o Build IDs should always reference Design IDs in other words, if a feature in the build does not relate to a feature in the design for that
requirement then there is a problem. The easiest way to do this is to use the same ID convention for Design ID and Build ID (for example, if the
Design ID is UI1 then the Build IDs that support that should be UI1.1, UI1.2, UI1.3 etc.).
o Design IDs should always have at least one related Build ID in the same row in other words, if a design element doesnt have any related build
elements then there is a problem.
Technical/System Test Case This field captures the test case(s) that will validate that the built features perform as required by the requirements. This
field will capture a test case ID, a test script reference or similar. There may be multiple test cases for each feature, and each test case may impact
multiple features, but this is the way that we validate the successful implementation of the requirement from a system and technical standpoint. You may
wish to introduce the concept of color coding once tests have passed to visually show that the requirement has been validated, although be careful to only
reflect that technical testing is complete at this point.
User/Acceptance Test Case This is exactly the same concept as above but for business validation rather than technical validation. Once this testing
has passed applying color coding to the entire row will visually demonstrate that the requirement has been successfully delivered.

General Rules
Clearly this document has to evolve throughout the project and it is important to maintain and update the content regularly. The ground rules for the project should
stipulate the frequency of updates and/or the allowable time between an approved change and the updating of the traceability matrix. However, the main rules
relate to the traceability of requirements and are very simple:

Every requirement must map to at least one build element

Copyright ProjectManagement.com

Every build element must map to at least one requirement

The first of these is very evident in this template. The second may require comparison with the actual build documentation to ensure that there are no rogue
features that do not map to any requirements. While the matrix could show this more clearly in a traditional rows and columns matrix that would lose some of the
detail and may not provide as clear a picture.

Copyright ProjectManagement.com