Transcript Requirements Traceability in a UML based Development

Requirements Traceability
Patricio Letelier
Departamento de Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Summary
I.
Introduction to Requirements Traceability
II.
Related Work
 Non-UML Community
 UML Community
 Commercial Tools: RequisitePro

www.dsic.upv.es/~letelier/pub
Introduction to
Requirements Traceability
Concepts
 A model captures a view of a physical system. It is an
abstraction of the physical system, with a certain purpose.
Thus the model completely describes those aspects of the
physical system that are relevant to the purpose of the
model, at the appropriate level of detail.
 Diagram: a graphical presentation of a collection of model
elements, most often rendered as a connected graph of arcs
and vertices
OMG UML 1.4 Specification

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
 A software development process must offer a set of
models to organize the product construction
according to specific characteristics of the project
 At least two models should always be present:
Requirements Model and Code
 Each model is complete from its point of view, but
relationships should exist among them

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Modeling with different levels of abstraction
 Not only you need to view a system from several
angles, different people might want the same view of
the system but at different levels of abstraction
 Basically, there are two ways to model a system at
different levels of abstraction:
 by presenting views with different levels of detail
against the same model
 by creating models at different levels of abstraction
with traces from one model to another
The Unified Modeling Language User Guide, Booch, Rumbaugh, Jacobson

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Requirements Engineering
 Feasibility Studies
 Requirements Elicitation and Analysis
 Requirements Validation
 Requirements Management
– Includes information capture, storage, dissemination
and management (organization, traceability, analysis
and visualization)
– Is a Key Process Area (KPA) needed to achieve the
level 2 (Repeatable Level) of the CMM
– Its success depends on how good the requirements
traceability is implemented

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Requirements Traceability
“The ability to describe and follow the life of a
requirement, in both a forward and a backward direction,
i.e., from its origins, through its development and
specification, to its subsequent deployment and use, and
through periods of ongoing refinement and iteration in any
of these phases”
[Gotel and Finkelstein, 1994]

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Requirements Traceability benefits
[adapted from Dömges, 98]
1. Traceability links between different kinds of specifications support:
 Validation that the system functionality meets the customer
requirements and that no superfluous functionality has been
implemented
 Impact analysis upon changing customer requirements. The links
allow to determine which other specifications might be affected

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
... Requirements Traceability benefits
2. Contribution structures (links between stakeholders and
specifications):
 Improve communication and cooperation among teams. In case of a
change request, the stakeholders who should be involved and/or informed
can be determined
 Assure the contribution of each individual is passed on and filed
3. Rationale associated to specifications (alternatives, decisions,
underlying assumptions, etc.):
 Improve the understanding of the system by the customer and thus the
system acceptance
 Improve the change management by reducing the changes of neglecting
considerations during change integration, since previously rejected
solutions and the reasons for their rejection are accessible

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Traceability information allows answering:
– What is the impact of changing a requirement?
– Where is a requirement implemented?
– Are all requirements allocated?
– What need is addressed by a requirement?
– Is this requirement necessary?
– What design decisions affect the implementation of a requirement?
– Why is the design implemented this way and what were the other
alternatives?
– Is the implementation compliant with the requirements?
– What acceptance test will be used to verify a requirement?
– Is this design element necessary?
– How do I interpret this requirement?
INCOSE, International Council On Systems Engineering, http://www.incose.org/tools/reqsmgmt.html

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Current Problems in Requirements Traceability
 Need for guidelines on what types of information must be
captured and used in what contexts. The interpretation of the
meanings of linkages between system components is left to the
user
 Need for abstraction mechanisms to allow variation of
granularity (aggregation) and sophistication (generalization) in
traceability tasks
 Need for inference services supporting the semantic of the
different traceability link types

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
... Current Problems in Requirements Traceability
 Need for mechanisms that allow project managers and
developers to define and enact a model driven trace process
accompanying the development process
 Most of the tool support is document-oriented (dealing only with
textual expressed requirements) working as modules not well
integrated with other development modules in a CASE tool
context

www.dsic.upv.es/~letelier/pub
... Introduction to
Requirements Traceability
Our Approach
 Define a Traceability Metamodel. Customizable
framework establishing the traceability information
and
extensible
 Establish integration with UML specifications. UML is used as a
common place for specifications, including textual specifications
(requirements, rationale, test)
 Establish a traceability process to be included in a requirements
management process which would be part of a software development
process
 Provide tool support using current CASE tool extension mechanisms

www.dsic.upv.es/~letelier/pub
Related Work

“Non-UML Community”





NATURE, CREWS
O. Gotel, A. Finkelstein, J. Mylopoulos, R. Dömges,
K. Pohl, B. Ramesh, M. Jarke, ...
“UML Community”
 OMG UML Specification, Unified Process
 I. Jacobson, J. Rumbaugh, G. Booch, ...
Commercial Tools
www.dsic.upv.es/~letelier/pub
Related Work: Non-UML Community
[B. Ramesh and M. Jarke. Toward Reference Models for Requirements
Traceability. IEEE Transactions on Software Engineering, January 2001]
Traceability users classification:




Low-end users: typical complexity about 1000 requirements, zero
to two years of experience in traceability, traceability is
understood as “document transformation of requirement to
design”
High-end users: typical complexity about 10000 requirements,
five to ten years of experience in traceability, traceability is
defined as “increases the probability of producing a system that
meets all customer requirements and will be easy to maintain”
 Two Models: Low-end and High-end Traceability Models
www.dsic.upv.es/~letelier/pub
... Related Work: Non-UML Community
High-end Traceability Model

Objects and Links
• “Current practice shows that the efficiency and effectiveness of
traceability support is largely determined by the system of OBJECT
types and traceability LINKS types offered”
 31 entity types, 29 different link types (but 50 different link
types considering the connected entity types)
 Four submodels:
•
•
•
•

Requirements Management
Rationale
Design Allocation
Compliance Verification
www.dsic.upv.es/~letelier/pub
... Related Work: Non-UML Community
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.

FUNCTIONS ADDRESS REQUIREMENTS
ALTERNATIVES ADDRESS ISSUES_OR_CONFLICTS
DECISIONS AFFECT OBJECT
REQUIREMENTS ALLOCATED_TO SYSTEM_SUBSYSTEM_COMPONENTS
REQUIREMENTS BASED_ON MANDATES
COMPLIANCE_VERIFICATION_PROCEDURES BASED_ON MANDATES
DESIGN BASED_ON MANDATES
OBJECT BASED_ON RATIONALE
DECISIONS BASED_ON RATIONALE
DESIGN CREATE SYSTEM_SUBSYSTEM_COMPONENTS
DESIGN DEFINE SYSTEM_SUBSYSTEM_COMPONENTS
ASSUMPTIONS DEPEND_ON ASSUMPTIONS
REQUIREMENTS DEPEND_ON REQUIREMENTS
ARGUMENTS DEPEND_ON ASSUMPTIONS
DECISIONS DEPEND_ON ASSUMPTIONS
OBJECT DEPEND_ON ASSUMPTIONS
SYSTEM_SUBSYSTEM_COMPONENTS DEPEND_ON SYSTEM_SUBSYSTEM_COMPONENTS
SYSTEM_SUBSYSTEM_COMPONENTS DEPEND_ON EXTERNAL_SYSTEMS
RATIONALE DEPEND_ON ASSUMPTIONS
REQUIREMENTS DERIVE FROM REQUIREMENTS
SCENARIOS DESCRIBE ORGANIZATIONAL_NEEDS
SCENARIOS DESCRIBE SYSTEM_OBJECTIVES
SCENARIOS DESCRIBE REQUIREMENTS
COMPLIANCE_VERIFICATION_PROCEDURES DEVELOPED_FOR REQUIREMENTS
REQUIREMENTS DRIVE DESIGN
www.dsic.upv.es/~letelier/pub
... Related Work: Non-UML Community
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.

REQUIREMENTS ELABORATE REQUIREMENTS
DECISIONS EVALUATE ALTERNATIVES
OBJECT GENERATE ISSUE_OR_CONFLICTS
SYSTEM_OBJECTIVES GENERATEs CHANGE_PROPOSALS
SYSTEM_OBJETIVES GENERATES REQUIREMENTS
COMPLIANCE_VERIFICATION_PROCEDURES GENERATE CHANGE_PROPOSALS
ORGANIZATIONAL_NEEDS IDENTIFY CRITICAL_SUCCESS_FACTORS
CRITICAL_SUCCESS_FACTORS INFLUENCE DECISIONS
ORGANIZATIONAL_NEEDS JUSTIFY SYSTEM_OBJECTIVES
REQUIREMENTS MANAGED_BY CRITICAL_SUCCESS_FACTORS
CHANGE_PROPOSALS MODIFY REQUIRIMENTS
CHANGE_PROPOSALS MODIFY DESIGN
ARGUMENTS OPPOSE ALTERNATIVES
REQUIREMENTS PART_ OF REQUIREMENTS
SYSTEM_SUBSYSTEM_COMPONENTS PART_OF SYSTEM_SUBSYSTEM_COMPONENTS
SYSTEM_SUBSYSTEM_COMPONENTS PERFORM FUNCTIONS
DECISIONS RESOLVE ISSUES_OR_CONFLICTS
SYSTEM_SUBSYSTEM_COMPONENTS SATISFY REQUERIMENTS VERIFIED_BY COMPLIANCE_VERIFIC._PROC.
SYSTEM_SUBSYSTEM_COMPONENTS SATISFY COMPLIANCE_VERIFICATION_PROCEDURES
SYSTEM_SUBSYSTEM_COMPONENTS SATISFY REQUERIMENTS VERIFIED_BY COMPLIANCE_VERIFIC._PROC.
DECISIONS SELECT ALTERNATIVES
ARGUMENTS SUPPORT ALTERNATIVES
OBJECT TRACEs_TO OBJECT
RESOURCES USED_BY SYSTEM_SUBSYSTEM_COMPONENTS
RESOURCES USED_BY COMPLIANCE_VERIFICATION_PROCEDURES
www.dsic.upv.es/~letelier/pub
OMG Unified Modeling Language Specification (draft), version 1.4, February 2001.
... Related Work: Non-UML Community
Summary of links

Product related
• SATISFIES. To ensure that the requirements are satisfied by the
system. Relationships between one or more design, implementation
objects and requirements
• DEPEND-ON. Help manage dependencies among objects (typically
at the same stage of development)

Process related
• RATIONALE. Represent the rationale behind objects or document
the reasons for evolutionary steps
• EVOLVE-TO. Document the input-output relationships of actions
leading from existing objects to new or modified objects

www.dsic.upv.es/~letelier/pub
OMG Unified Modeling Language Specification (draft), version 1.4, February 2001.
... Related Work: Non-UML Community
Comments





There is neither definition for OBJECTS nor a precise semantics
for LINKS
Links to/from STAKEHOLDERS and SOURCES are not studied in
detail. This is an important issue when dealing with cooperative
(and distributed) software development
The proposal is independent of a particular notation or
development process, but most of the artifacts are behind the
OBJECT SYSTEM_SUBSYSTEM_COMPONENTS (and only
supporting the links “PART-OF” and “DEPEND-ON”)
There are neither references to a specific notation nor software
process
www.dsic.upv.es/~letelier/pub
Related Work: UML Community
Dependency
A relationship between two modeling elements, in which a
change to one modeling element (the independent element)
will affect the other modeling element (the dependent
element)
Trace
A dependency that indicates a historical or process
relationship between two elements that represent the same
concept without specific rules for deriving one from the other
[OMG UML 1.4 Specification, Glossary]

www.dsic.upv.es/~letelier/pub
... Related Work: UML Community
"become"
"copy"
+sourceFlow Flow
n
Association
Generalizatio
n
Include
n
+targetFlow
Relationship
+target
n
n
ModelElement
name : Name
+source
+supplierDependency
+supplier
1..n
n
Dependency
1..n
n
+client +clientDependency
Binding
[OMG UML 1.4 Specification]

www.dsic.upv.es/~letelier/pub
Abstraction
mapping : MappingExpression
"derive"
"realize"
"refine"
"trace"
Usage
"access"
"friend"
"import"
Permission
"call"
"create"
"instantiate"
"send"
Extend
... Related Work: UML Community
Unified Process => “Use-Case Driven Process”
«trace»
Use Case
«trace»
Use-Case Realization
- Design
Use-Case Realization
- Analysis
«trace»
«trace»
White-box test
Black-box test
X
Test Case
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

www.dsic.upv.es/~letelier/pub
... Related Work: UML Community
Traceability in a RUP-like Process
Business Model
<<trace>>
Requirement Model
Black-Box Test
Specification
<<trace>>
White-Box Test
Specification
Analysis Model
<<trace>>
<<trace>>
<<trace>>
Test Model
Design Model
<<trace>>
<<depend on>>
Implementation Model
[- The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh
- Rational Unified Process (RUP)
OMG UML 1.4 Specification]
 -www.dsic.upv.es/~letelier/pub
<<depend on>> Deployment Model
... Related Work: UML Community
Specification Granularity
«trace»
Model/Subsystem/Package
«trace»
Use Case/Use Case Realization
Bussines Use Case
«trace»
Use Case
«trace»
«trace»
Actor/Class/Component
Interface/Node/etc.
Component
«trace»
Component
www.dsic.upv.es/~letelier/pub
«trace»
Design Class
Analysis Class
«trace»

Use-Case Realization
- Design
Use-Case Realization
- Analysis
Interface
Design
Node
Interface
Implementation
... Related Work: UML Community
Comments





«trace» specifies a trace relationship between model elements
or sets of model elements that represent the same concept in
different models
“Traces are mainly used for tracking requirements and changes
across models. Since model changes can occur in both
directions, the directionality of the dependency can often be
ignored”
Apart from Use-Case model element, UML does not include
other kinds of requirements (those that are textual)
Not much difference respect to «realize» and «refine»
stereotypes
www.dsic.upv.es/~letelier/pub
Commercial Tools
Requirements Management Products
Tool Name

Vendor
Vendor URL
DOORS
Telelogic
http://www.telelogic.com/
RequisitePro
Rational Software
http://www.rational.com/
RTM
Integrated Chipware
http://www.chipware.com
Caliber-RM
Starbase Corporation
http://www.starbase.com/
CRADLE
3SL
http://www.3sl.co.uk/
CORE
Vitech Corporation
http://www.vtcorp.com/
RDD
Ascent Logic Corporation
http://www.alc.com/
RDT
Igatech
http://www.igatech.com/
XTie-RT
Teledyne Brown Engineering
http://www.tbe.com/
SLATE
EDS
http://www.tdtech.com/
TOFS
Tool for Systems
http://www.toolforsystems.com
Vital Link
Compliance Automation Inc.
http://www.complianceautomation.com/
www.dsic.upv.es/~letelier/pub
... Commercial Tools
Startbase
(Caliber-RM )
7%
Integrated
Chipware
(RTM)
20%
Rational
(RequisitePro)
Others
17%
Telelogic
(DOORS)
30%
26%
Source: Standish Group 1999

www.dsic.upv.es/~letelier/pub
Commercial Tools: RequisitePro


“Document management tool”. A project is a set of
documents (of different types – templates) containing
marked pieces of text corresponding to some
“requirement type”
www.dsic.upv.es/~letelier/pub

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro

Customization
• Document Type
• Requirement Type
• Requirement Attributes

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro

Traceability
• A tab page in the Requirement Properties (for each
requirement)
• The established link is “trace” (“from” or “to”). Changes in
the linked requirements (text) makes the link be marked as
“suspect”

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
• Visualizing the traceability information

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
• Traceability Matrix, trace-to, trace-from, suspect links,
indirect links between to types of requirements (text)

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
• Traceability Tree (Traced out of ...), showing trace-to
relationships from other requirements (including all
requirements types)

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
• Traceability Tree (Traced into ...), showing trace-to
relationships from other requirements (including all
requirements types)

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
• Attribute Matrix, showing the attributes of requirements of
certain types

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
Rational Rose + RequisitePro
 RequisitePro is installed as an Add-in in Rational Rose
 The rose model is associated to a RequisitePro
project
 Use cases can be specified using a RequisitePro type
of document and types of “requirements” (marked
text)

www.dsic.upv.es/~letelier/pub
... Commercial Tools: RequisitePro
Comments
 A requirement in RequisitePro is a piece of text. The name
of the requirement is the text itself




The only supported link is “trace”. Establishing a traceability
matrix for pairs of requirements could simulate different
specific links
There are interesting security capabilities in order to control
the access to documents for different stakeholders
The only UML artifact integrated from rose models is the
Use Case
www.dsic.upv.es/~letelier/pub