Tracing Requirements
1
The Role of Traceability in
Systems Development
 Experience has shown that the ability to
trace requirements artifacts through the
stages of specification, architecture,
design, implementation, and testing is a
significant factor in assuring a quality
product.
 Software developed in many areas for
certain customers may have mandated
traceability requirements (e.g. the FDA).
2
Definition of Traceability
 According to IEEE [1994] traceability is:
 “The degree to which a relationship can be
established between two or more products of the
development process, especially products having a
predecessor-successor or master-subordinate
relationship to one another; for example the degree
to which the requirements and design of a given
software component match.”
 “The degree to which each element in a software
development product establishes its reason for
existing; for example, the degree to which each
element in a bubble chart references the
requirement it satisfies.”
3
The Traceability Relationship
 A traceability relationship is a
dependency relationship between two
project elements.
Element B is in some way
Dependent on element A
A
traces
B
4
The Traceability Relationship
(Cont’d)
 A dependency relationship states that a
change in one element (e.g., a use case)
may affect another element (e.g., a test
case), but the reverse is not necessarily true.
 Additional meanings associated with the
traces (or traced by) relationship can be
inferred from the context. E.g., in the
previous example, the relationship infers that
the use case is “tested by” the test case.
5
A Generalized Traceability
Model
System
Definition
Stakeholder Need
traces
Implementation
Product Feature
traces
Supplementary
Requirements
traces
Test Cases
traces
Use Case
System Test
traces
Use-Case
Realization
traces
Test Cases
6
Tracing Requirements in the
System Definition Domain
 This is called requirement-to-
requirement traceability.
 It includes:



Tracing user needs to features
Tracing features to use cases
Tracing features to supplementary
requirements
7
Tracing User Needs to
Features
Traceability Matrix: User Needs versus Features
Feature 1
Need 1
Feature 2
Feature n
X
Need 2
X
…
X
Need m
...
X
X
X
8
Examining the Traceability
Matrix for Possible Errors
 If inspection of a row fails to detect any Xs, a
possibility exists that no feature is yet defined to
respond to a user need. This might be
acceptable, but it raises a red flag.
 If inspection of a column fails to detect any Xs,
possibility exists that a feature has been
included for which there is no defined product
need.
 The traceability matrix can be helpful when
changes in user needs occur.
9
Tracing Features to Use
Cases
 It is important to ensure that the features
can be related to the use cases
proposed for the system.
 A matrix similar to the Needs versus
Features matrix can be used.
10
Tracing User Needs to
Features
Traceability Matrix: Features versus Use Cases
Use Case 1 Use Case 2 . . .
Feature 1
Feature 2
X
X
X
…
Feature n
Use Case k
X
X
X
X
11
Examining the Traceability
Matrix for Errors
 If inspection of a row fails to detect any
Xs, a possibility exists that no use case
is yet defined to respond to a feature.
This is a red flag.
 If inspection of a column fails to detect
any Xs, a possibility exists that a use
case has been included for which there
is no known feature that requires it. That
is, this use case may not be required.
12
Tracing Features to
Supplementary Requirements
Traceability Matrix: Features versus Supplementary Requirements
Supplementary Supplementary . . .
Requirement 1 Requirement 2
Feature or
Sys Req 1
X
X
Feature or
Sys Req 2
X
…
X
Feature or
Sys Req j
Supplementary
Requirement p
X
X
X
13
Tracing Requirements to
Implementation
 First we trace use cases to use case
realizations as we did before.
 We then follow the traceability relationship to
the component parts of the use case
realization, the classes (code).
 We must do something similar for
supplementary requirements. In this case we
trace the requirements to a collaboration (which
we need to name since it doesn’t come from a
use case). See next slide.
14
Tracing Supplementary
Requirements to Implementation
Requirements
- The clocks shall . . .
Design Model
<<trace>>
Sync Clock
- Every 24 hours . . .
- Synchronization occurs . . .
Collaboration
Participating classes
15
Tracing from Requirements to
Testing
 A comprehensive approach to testing is to
assure that every use case is tested by one or
more test cases.
 In fact, each possible scenario for a use case
needs to be tested by one or more test cases.
 We can create a traceability matrix that maps
use cases to test cases.
 Requirements that are not expressed as use
cases are either traced individually to scenarios
and test cases or grouped into “requirements
packages” that operate in the same logical
fashion as use cases.
16
Traceability Matrix for Use
Cases to Test Cases
Use Case
Control Light
Run Vacation Profile
Scenario Number
Test Case ID
1
1.1
2
2.1
3
3.1
4
4.1
4
4.2
4
4.3
5
5.1
6
6.1
7
7.1
7
7.2
8
8.1
1
1.1
17
Mechanisms for Managing
Traceability Matrices
 For a large project creating and managing
the traceability matrices can be an
overwhelming task due to the problems of
correctly updating the information when
changes (e.g., to requirements) occur.
Mechanisms to help include:



Spreadsheets
Relational Data Bases
Specialized Traceability Management Tools
18