2008-06-30

Traceability

Even small requirements errors can produce

big problems !

Content
1. Traceability according to CMMI, IEEE and
INCOSE Handbook
2. Traceability
3. Procedure
4. Traceability Tools
5. Quality Function Deployment (QFD) Method
Sources: - IEC EN 50128 Software for Railway Control and Protection Systems
- Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003.
- IEEE Std 1059, Guide for Verification and Validation Plans
- Capability Maturity Model Integration, Software Engineering Institute, 2006
- Systems Engineering Handbook, A How To Guide for All Engineers, 2007.
6/30/2008

International Council On Systems Engineering (INCOSE).

2008-06-30

Participants in the Requirements Process

6/30/2008

Participants in the Requirements Process

What the customer

actually wanted !
6/30/2008

2008-06-30

Traceability - Definitions
Traceability
A discernable association among two or more logical entities
such as requirements, system elements, verifications, or tasks.
(See also bidirectional traceability and requirements
traceability.)

Requirements traceability
A discernable association between requirements and related
requirements, implementations, and verifications.

Bidirectional traceability
An association among two or more logical entities that is
discernable in either direction (i.e., to and from an entity).

6/30/2008

Traceability IEEE Std-1059

1. The ability to identify the relationships between
originating requirements and their resulting system
features.
2. It permits tracking forward or backward through the
network of interrelationships that are created as
requirements are decomposed and refined throughout a
systems life cycle.
Traceability provides the thread that links one element
to another. When an element is traced to another, and
that element is traced on to another, a chain of cause
and effect is formed.

6/30/2008

2008-06-30

Traceability IEEEStandard 1059

Traceability allows verification of the properties set forth in

the concept and that requirement specifications have been:
1.
2.
3.
4.

Carried forward to the design specifications

Implemented in the code
Included in the test plan and cases
Provided to the customer and user in the resulting system

Traceability Analysis

Each trace is analyzed for consistency, completeness, and correctness

to verify that all software requirements are implemented in the
software and are associated with the correct design, code, and test
information.
An analyst examines each trace path to ensure that the connected
pieces are the proper ones.
Analyst has to understand the intent of requirements, design and other
documents.

6/30/2008

Traceability IEEE Std-1059

6/30/2008

Traceability analysis is performed to assure that:

1. Every requirement in the specification is identified
correctly
2. All traces are continuous from the prior phase through
the current phase
3. Forward and backward traces between adjoining
phases are consistent
4. The combined forward traces originating from each
specification, fully support that specification
5. Each current specification or feature is fully supported
by traceable predecessor specifications

2008-06-30

Traceability

Aim

To ensure that all requirements can be shown to have been

properly met and that no untraceable material has been
introduced.

Description

Traceability to requirements shall be an important

consideration in the validation of a system and means shall
be provided to allow this to be demonstrated throughout all
phases of the lifecycle.

Source: IEC EN 50128 Software for Railway Control and Protection Systems
6/30/2008

Traceability-Attributes
1. The requirement identification number
2. The source of the requirement

Such as the customer's document paragraph number or the

engineering report documenting the analysis that derived the
requirement.

3. The full text of the requirement

4. For allocated or derived requirements, a pointer to the
requirement from which it was derived, or "parent" requirement.
5. A pointer to the next lower-level area that this requirement was
allocated to during the allocation process
6. Verification method (e.g. test, demonstration, analysis,
inspection/examination).
7. The Test Plan name & number controlling the verification
8. The Test Procedure name & number performing the verification
9. The date and results of the final verification
10. The name of the responsible engineer.
6/30/2008

Source: SYSTEMS ENGINEERING HANDBOOK, A HOW TO GUIDE For All Engineers, Version 2.0,
10
July 2000. International Council on Systems Engineering (INCOSE).

2008-06-30

Some key requirements traceability links.

Business
Requirement
Modifies

drives specification of
System Requirement,
Use Case, External
Interface Requirement,
Quality attributes

Modifies

Change
Request

is origin of

Modifies

Software
Functional
Requirement

Modifies
is satisfied by

is verified
by
Architecture, User
Interface, Functional
Design
is verified by

Integration
test
6/30/2008

System
Test

Business
Rules

is origin of
depends
on another
Leads to
creation of

Project
Plan Task

is implemented in

Code
is verified by

Unit
test

Wiegers K., Software Requirements, Microsoft Press, 2003

11

Requirements Traceability Matrix*

Also called Proof of Compliance Matrix or Verification Matrix

A column should be added to show that tests have been performed and successful
6/30/2008

Adapted from: Linda Westfall, Bidirectional Requirements Traceability, SQP, Dec 2007 12

2008-06-30

Traceability Matrix

Verification methods:
Test, demonstration, analysis, inspection/examination.
6/30/2008

13

Four types of requirements traceability.

Customer
Needs

forward to
requirements

backward from
requirements

Requirements

forward from
requirements

backward to
requirements
Product

Source: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003.
6/30/2008

14

2008-06-30

Traceability in Standard EN 50128

Description
2. Traceability shall be considered applicable to both
functional and non-functional requirements and shall
particularly address:
1. Traceability of requirements to the design or other objects
which fulfill them,
2. Traceability of design objects to the implementation objects
which instantiate them,
3. Traceability of requirements and design objects to the
operational and maintenance objects required to be applied
in the safe and proper use of the system,
4. Traceability of requirements, design, implementation,
operation and maintenance objects, to the verification and
test plans and specifications which will determine their
acceptability,
5. Traceability of verification and test plans and specifications
to the test or other reports which record the results of their
application.

6/30/2008

Source: IEC EN 50128 Software for Railway Control and Protection Systems

15

Traceability
Design

Requirements

Implementation
objects

Operational and
maintenance
objects

Verification, test
plans,
specifications

Test or other
reports
6/30/2008

16

2008-06-30

Benefits of Implementing Traceability

1.

Certification -Verification

2.

Change Impact Analysis

3.

Traceability links help find all of the system elements that might have
to be modified if you change a particular requirement.
Without traceability information, chances are high youll overlook
some of the side effects of adding, deleting, or modifying a
requirement.

Project Tracking

6/30/2008

The traceability information can be used for certification in safetycritical applications ( e.g. avionics)
To verify and demonstrate that all requirements were implemented.

If you complete the requirements traceability matrix as development

takes place, you will have accurate insight into the implementation
status of planned functionality.
Empty space in the matrix indicates project deliverables that have
not yet been created.

Adapted from: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003.

17

Benefits of Implementing Traceability

4. Testing

5.

Reuse

6.

Traceability information can facilitate the reuse of product

components
By identifying packages of related requirements, designs, code,
tests, and other artefacts.

Risk Management and Reduction

6/30/2008

Links between tests, requirements, and code point toward likely parts
of the code to examine for a bug when a test fails to yield the
intended result

Documenting the information about system component

interconnections reduces the risk associated with a key team member
leaving the company with essential information residing only in that
persons brain (Ambler 1999).

Adapted from: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003.

18

2008-06-30

Benefits of Implementing Traceability

7.

Reengineering
If you dont have complete requirements for the existing
system.

8.

Provide a way to capture some of what you learn through

reverse engineering.

Identification of process improvements

6/30/2008

You can list the functions in a legacy system youre replacing

and record where they were addressed in the requirements and
software components for the new system.

e.g. Information about Requirements instability may be used to

improve the development process/change management process

Adapted from: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003. 19

Benefits of Implementing Traceability

9.

Allows developer, customer, supplier to follow the

development of components

If traceability is implemented on web site

10. Help to reduce cost and delay and improve quality

6/30/2008

By not developing the wrong components

By not forgetting components during development
By testing all components before delivery
By ensuring that all documents have been modified/updated
after a change

Adapted from: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003. 20

10

2008-06-30

Requirements Traceability Matrix*

Functional
Requirement

Parent
Use
Case

Design
Element

Code

Test Case

catalog.query.sort

UC-28

class catalog

catalog.sort()

search.7,
search.8

catalog.query.import

UC-29

class catalog

catalog.import()

search.8,
search.13,
search.14

* Also called Proof of Compliance Matrix or Verification Matrix

6/30/2008

Source: Wiegers, K., Software Requirements, Second Edition, Microsoft Press, 2003.

21

Likely Sources of Traceability Link Information

6/30/2008

Link Source Object

Type

Link Target Object Type

Likely Information Source

system requirement

software requirement

system engineer

use case

functional requirement

requirements analyst

functional requirement

functional requirement

requirements analyst

functional requirement

software architecture element

system architect

functional requirement

other design elements

developer

design element

source code

developer

use case or functional

requirement

test case

test engineer

22

11

2008-06-30

Procedure: Requirements Traceability

1. Verify that all formalized requirements are
traceable to a higher-level requirement
2. Verify that all higher-level requirements are
traceable to a formalized requirement(s)
3. Verify that all formalized requirements are
traceable to test requirement.
4. Verify that all test requirements are traceable to
test case(s).
5. Identify any requirement without a parent

6/30/2008

23

Traceability Tool

Should generate the following information from

a database:
1. Requirements Statements with Project Unique
Identifiers (PUID)
2. Requirements Traceability Matrices (RTM)
3. Verification Cross Reference Matrices (VCRM)
4. Lists of TBD (Determined), TBR (Reviewed), and TBS
(Specified)
5. Specifications
6. Requirements measures (e.g., requirements stability)

Source: SYSTEMS ENGINEERING HANDBOOK, A HOW TO GUIDE For All Engineers, Version 2.0,
July 2000. International Council on Systems Engineering (INCOSE).
6/30/2008

24

12

2008-06-30

Quality Function Deployment (QFD)

8
HOWs

WHATs

WHYs

Steps of the Method

1. Customer Requirements
2. Customer Priorities
3. Customer Assessment

4.
5.

Technical Requirements
Relationship Matrix

Importance Ratings

7.

Engineering Assessment

8.

7
6/30/2008

Between Whats and Hows

6.

Compare to competitors

Priorities X Relationships
Compare design options

Correlation Matrix

Relationships between Hows

Source: Haag, S, Quality Function Deployment, Communications of the ACM, Jan 1996.

25

Summary
1. Verification
2. Traceability according to IEEE Std et INCOSE
Handbook
3. Traceability
4. Procedure
5. Traceability Tools
6. Quality Function Deployment (QFD) Method

6/30/2008

26

13