Use a Traceability Matrix to:

· verify and validate system specifications,

· ensure that all final deliverable documents are

included in the system specification, such as process models
and data models,

· improve the quality of a system by identifying

requirements that are not addressed by configuration items
during design and code reviews and by identifying extra
configuration items that are not required. Examples of
configuration items are software modules and hardware
devices,

· provide input to change requests and future project

plans when missing requirements are identified,

· provide a guide for system and acceptance test plans

of what needs to be tested.

Need for Relating Requirements to a Deliverable

Taking the time to cross-reference each requirement to a

deliverable ensures that a deliverable is consistent with the
system requirements. A requirement that cannot be
mapped to a deliverable is an indication that something is
missing from the deliverable. Likewise, a deliverable that
cannot be traced back to a requirement may mean the
system is delivering more than required.

Use a Traceability Matrix to Match Requirements to a

Deliverable

There are many ways to relate requirements to the

deliverables for each stage of the system life cycle.

One method is to:

· create a two-dimensional table,

· allow one row for each requirements specification

paragraph (identified by paragraph number from the
requirements document),

· allow one column per identified configuration item

(such as software module or hardware device),

· put a check mark at the intersection of row and

column if the configuration item satisfies the stated
requirement.

USEFUL TRACEABILITY MATRICES

Various traceability matrices may be utilized throughout the

system life cycle. Useful ones include:

· Functional specification to requirements document:

It shows that each requirement (obtained from a preliminary
requirements statement provided by the customer or
produced in the Concept Definition stage) has been covered
in an appropriate section of the functional specification.

· Top level configuration item to functional

specification: For example, a top level configuration item,
Workstation, may be one of the configuration items that
satisfies the function Input Order Information. On the
matrix, each configuration item would be written down the
left hand column and each function would be written across
the top.

· Low level configuration item to top level

configuration item: For example, the top level configuration
item, Workstation, may contain the low level configuration
items Monitor, CPU, keyboard, and network interface card.
· Design specification to functional specification
verifies that each function has been covered in the design.

· System test plan to functional specification ensures

you have identified a test case or test scenario for each
process and each requirement in the functional specification.

Although the construction and maintenance of traceability

matrices may be time-consuming, they are a quick reference
during verification and validation tasks.
Project Name
Requirements Traceability Matrix

Uniq Requirement Source of Software Design Program Test Test Successful Modification Remarks
ue Requirement Reqs. Spec Spec. Module Spec. Case(s) Test of
No. / Verification Requirement
Functional
Req. Doc.

Objective 1:

Description of Matrix Fields

Develop a matrix to trace the requirements back to the project objectives identified
in the Project Plan and forward through the remainder of the project life cycle
stages. Place a copy of the matrix in the Project File. Expand the matrix in each
stage to show traceability of work products to the requirements and vice versa. The
requirements traceability matrix should contain the following fields:

• A unique identification number containing the general category of the

requirement (e.g., SYSADM) and a number assigned in ascending order (e.g.,
1.0; 1.1; 1.2).
• The requirement statement.
• Requirement source (Conference; Configuration Control Board; Task
Assignment, etc.).
• Software Requirements Specification/Functional Requirements Document
paragraph number containing the requirement.
• Design Specification paragraph number containing the requirement.
• Program Module containing the requirement.
• Test Specification containing the requirement test.
• Test Case number(s) where requirement is to be tested (optional).
 • Verification of successful testing of requirements.
• Modification field. If requirement was changed, eliminated, or replaced,
indicate disposition and authority for modification.
• Remarks.

Traceablity matrix is nothing but a mapping between the specifications

and Test cases.

how many test cases written for perticular specification and all the test
cases for specified specification.

Template for traceablity matrix .

Specification document name Specification no test case document name

Test case No.

Traceability Matrix – A document

showing the relationship between Test Requirements and Test Cases. From
Traceability Matrix, we can check that which requirements are covered in which
test cases and "particular test case covers which requirements".

In this matrix, we can also cover that a particular requirement is covered in

which section of code etc.

In this matrix, the rows will have the requirements. For every document {HLD,
LLD etc}, there will be a separate column. So, in every cell, we need to state,
what section in HLD addresses a particular requirement. Ideally, if every
requirement is addressed in every single document, all the individual cells must
have valid section ids or names filled in. Then we know that every requirement
is addressed. In case of any missing of requirement, we need to go back to the
document and correct it, so that it addressed the requirement.

In a nutshell, requirements traceability is the process of ensuring that one or

more test cases address each requirement.
Example of a Traceability Matrix document:
Req ID Req Description TC001 TC002 TC003
R1.1 ……… Yes Yes
R1.2 ………. Yes
R2.1 ……. Yes

Example of a Traceability Matrix document:

Req ID Req Description TC001 TC002 TC003
R1.1 ……… Yes Yes
R1.2 ………. Yes
R2.1 ……. Yes

Above table shows –

Requirement R1.1 is covered in TC001 and TC003.
R1.2 is covered in TC001.
R2.1 is covered in TC002

Above table also provides the test coverage. Fron Traceability Matrix document,
we can ensure that all the requirements are addressed in the test cases. More
science behind traceability matrix can be found at Software Testing Times

Bidirectional is Forward and Backward traceability.

Forward traceability is from requirements to design to code to testcases.

Backward traceability is on the reverse direction that the end product has met
the requirements or not. It is very difficult to do this traceability without tool

This is what cmmi demands. It demands for bi-directional which is mandatory.