Requirements Traceability

1
Requirements Traceability
Patricio Letelier Departamento de Sistemas
Informáticos y Computación Universidad
Politécnica de Valencia
2
Summary

• Introduction to Requirements Traceability
• Related Work
• Non-UML Community
• UML Community
• Commercial Tools RequisitePro

3
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

4
... 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

5
... 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

6
... 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
• Software Engineering, Ian Sommerville, Sixth
  Edition 2001

7
... 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

8
... Introduction to Requirements Traceability

• Requirements Traceability benefits
• adapted from Dömges, 98
• 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

9
... Introduction to Requirements Traceability

• ... Requirements Traceability benefits
• 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
• 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

10
... 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

11
... 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

12
... 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

13
... Introduction to Requirements Traceability

• Our Approach
• Define a Traceability Metamodel. Customizable and
  extensible framework establishing the
  traceability information
• 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

14
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

15
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

16
... 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

17
... Related Work Non-UML Community

1. FUNCTIONS ADDRESS REQUIREMENTS
2. ALTERNATIVES ADDRESS ISSUES_OR_CONFLICTS
3. DECISIONS AFFECT OBJECT
4. REQUIREMENTS ALLOCATED_TO SYSTEM_SUBSYSTEM_COMPONE
   NTS
5. REQUIREMENTS BASED_ON MANDATES
6. COMPLIANCE_VERIFICATION_PROCEDURES BASED_ON
   MANDATES
7. DESIGN BASED_ON MANDATES
8. OBJECT BASED_ON RATIONALE
9. DECISIONS BASED_ON RATIONALE
10. DESIGN CREATE SYSTEM_SUBSYSTEM_COMPONENTS
11. DESIGN DEFINE SYSTEM_SUBSYSTEM_COMPONENTS
12. ASSUMPTIONS DEPEND_ON ASSUMPTIONS
13. REQUIREMENTS DEPEND_ON REQUIREMENTS
14. ARGUMENTS DEPEND_ON ASSUMPTIONS
15. DECISIONS DEPEND_ON ASSUMPTIONS
16. OBJECT DEPEND_ON ASSUMPTIONS
17. SYSTEM_SUBSYSTEM_COMPONENTS DEPEND_ON
    SYSTEM_SUBSYSTEM_COMPONENTS
18. SYSTEM_SUBSYSTEM_COMPONENTS DEPEND_ON
    EXTERNAL_SYSTEMS
19. RATIONALE DEPEND_ON ASSUMPTIONS

18
... Related Work Non-UML Community

1. REQUIREMENTS ELABORATE REQUIREMENTS
2. DECISIONS EVALUATE ALTERNATIVES
3. OBJECT GENERATE ISSUE_OR_CONFLICTS
4. SYSTEM_OBJECTIVES GENERATEs CHANGE_PROPOSALS
5. SYSTEM_OBJETIVES GENERATES REQUIREMENTS
6. COMPLIANCE_VERIFICATION_PROCEDURES GENERATE
   CHANGE_PROPOSALS
7. ORGANIZATIONAL_NEEDS IDENTIFY CRITICAL_SUCCESS_FAC
   TORS
8. CRITICAL_SUCCESS_FACTORS INFLUENCE DECISIONS
9. ORGANIZATIONAL_NEEDS JUSTIFY SYSTEM_OBJECTIVES
10. REQUIREMENTS MANAGED_BY CRITICAL_SUCCESS_FACTORS
11. CHANGE_PROPOSALS MODIFY REQUIRIMENTS
12. CHANGE_PROPOSALS MODIFY DESIGN
13. ARGUMENTS OPPOSE ALTERNATIVES
14. REQUIREMENTS PART_ OF REQUIREMENTS
15. SYSTEM_SUBSYSTEM_COMPONENTS PART_OF
    SYSTEM_SUBSYSTEM_COMPONENTS
16. SYSTEM_SUBSYSTEM_COMPONENTS PERFORM FUNCTIONS
17. DECISIONS RESOLVE ISSUES_OR_CONFLICTS
18. SYSTEM_SUBSYSTEM_COMPONENTS SATISFY REQUERIMENTS
    VERIFIED_BY COMPLIANCE_VERIFIC._PROC.
19. SYSTEM_SUBSYSTEM_COMPONENTS SATISFY
    COMPLIANCE_VERIFICATION_PROCEDURES

19
... Related Work Non-UML Community
OMG Unified Modeling Language Specification
(draft), version 1.4, February 2001.

• 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

20
... Related Work Non-UML Community
OMG Unified Modeling Language Specification
(draft), version 1.4, February 2001.

• 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

21
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

22
... Related Work UML Community
OMG UML 1.4 Specification
23
... Related Work UML Community
Unified Process gt Use-Case Driven Process
The Unified Software Development Process. I.
Jacobson, G. Booch and J. Rumbaugh.
Addison-Wesley, 1999
24
... Related Work UML Community
Traceability in a RUP-like Process
- The Unified Software Development Process. I.
Jacobson, G. Booch and J. Rumbaugh - Rational
Unified Process (RUP) - OMG UML 1.4
Specification
25
... Related Work UML Community
Specification Granularity
Model/Subsystem/Package
trace
trace
trace
Use Case/Use Case Realization
trace
trace
Analysis Class
Actor/Class/Component Interface/Node/etc.
trace
trace
26
... 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

27
Commercial Tools
Requirements Management Products
28
... Commercial Tools
Startbase (Caliber-RM ) 7
Others 17
Integrated Chipware (RTM) 20
Telelogic (DOORS) 30
Rational (RequisitePro) 26
Source Standish Group 1999
29
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

30
(No Transcript)
31
... Commercial Tools RequisitePro

• Customization
• Document Type
• Requirement Type
• Requirement Attributes

32
... 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

33
... Commercial Tools RequisitePro

• Visualizing the traceability information

34
... Commercial Tools RequisitePro

• Traceability Matrix, trace-to, trace-from,
  suspect links, indirect links between to types of
  requirements (text)

35
... Commercial Tools RequisitePro

• Traceability Tree (Traced out of ...), showing
  trace-to relationships from other requirements
  (including all requirements types)

36
... Commercial Tools RequisitePro

• Traceability Tree (Traced into ...), showing
  trace-to relationships from other requirements
  (including all requirements types)

37
... Commercial Tools RequisitePro

• Attribute Matrix, showing the attributes of
  requirements of certain types

38
... 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)

39
... 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