P12

Requirements Traceability Patricio Letelier

Departamento de Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia

www.dsic.upv.es/~letelier/pub

Summary

I. Introduction to Requirements Traceability

II. Related Work Non-UML Community UML Community Commercial Tools: RequisitePro


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


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

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



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



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]



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



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



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



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



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



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



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


[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

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

... 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_COMPONENTS 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 20. REQUIREMENTS DERIVE FROM REQUIREMENTS 21. SCENARIOS DESCRIBE ORGANIZATIONAL_NEEDS22. SCENARIOS DESCRIBE SYSTEM_OBJECTIVES23. SCENARIOS DESCRIBE REQUIREMENTS 24. COMPLIANCE_VERIFICATION_PROCEDURES DEVELOPED_FOR REQUIREMENTS 25. REQUIREMENTS DRIVE DESIGN



26. REQUIREMENTS ELABORATE REQUIREMENTS 27. DECISIONS EVALUATE ALTERNATIVES 28. OBJECT GENERATE ISSUE_OR_CONFLICTS 29. SYSTEM_OBJECTIVES GENERATEs CHANGE_PROPOSALS30. SYSTEM_OBJETIVES GENERATES REQUIREMENTS 31. COMPLIANCE_VERIFICATION_PROCEDURES GENERATE CHANGE_PROPOSALS 32. ORGANIZATIONAL_NEEDS IDENTIFY CRITICAL_SUCCESS_FACTORS 33. CRITICAL_SUCCESS_FACTORS INFLUENCE DECISIONS 34. ORGANIZATIONAL_NEEDS JUSTIFY SYSTEM_OBJECTIVES35. REQUIREMENTS MANAGED_BY CRITICAL_SUCCESS_FACTORS 36. CHANGE_PROPOSALS MODIFY REQUIRIMENTS37. CHANGE_PROPOSALS MODIFY DESIGN 38. ARGUMENTS OPPOSE ALTERNATIVES 39. REQUIREMENTS PART_ OF REQUIREMENTS40. SYSTEM_SUBSYSTEM_COMPONENTS PART_OF SYSTEM_SUBSYSTEM_COMPONENTS 41. SYSTEM_SUBSYSTEM_COMPONENTS PERFORM FUNCTIONS42. DECISIONS RESOLVE ISSUES_OR_CONFLICTS 43. SYSTEM_SUBSYSTEM_COMPONENTS SATISFY REQUERIMENTS VERIFIED_BY COMPLIANCE_VERIFIC._PROC. 44. SYSTEM_SUBSYSTEM_COMPONENTS SATISFY COMPLIANCE_VERIFICATION_PROCEDURES 45. SYSTEM_SUBSYSTEM_COMPONENTS SATISFY REQUERIMENTS VERIFIED_BY COMPLIANCE_VERIFIC._PROC. 46. DECISIONS SELECT ALTERNATIVES 47. ARGUMENTS SUPPORT ALTERNATIVES 48. OBJECT TRACEs_TO OBJECT49. RESOURCES USED_BY SYSTEM_SUBSYSTEM_COMPONENTS50. RESOURCES USED_BY COMPLIANCE_VERIFICATION_PROCEDURES



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

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

OMG Unified Modeling Language Specification (draft), version 1.4, February 2001.



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]

Related Work: UML Community


Usage PermissionAbstractionmapping : MappingExpression

Binding

Dependency

Relationship

Flow

ModelElementname : Name 1..n n

+supplier

1..n

+supplierDependency

n

1..n n

+client

1..n

+clientDependency

n

n

n

+target

n

+targetFlown

+sourceFlow

+source

n

n

n

n

Generalization

Association Include Extend

"become""copy"

"derive""realize""refine""trace"

"access""friend""import"

"call""create""instantiate""send"

... Related Work: UML Community

[OMG UML 1.4 Specification]


Use Case Use-Case Realization - Analysis

Use-Case Realization - Design

Test Case

X

«trace» «trace»

«trace»«trace»

Black-box test

White-box test

Unified Process => “Use-Case Driven Process”


[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]


Business Model

Analysis Model

Requirement Model

Design Model Deployment Model

Implementation Model

Test Model

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Black-Box TestSpecification

White-Box TestSpecification

<<depend on>>

<<depend on>>

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]


Use-Case Realization - Analysis

Use-Case Realization - Design

Analysis Class

InterfaceImplementation

Design Class Component

InterfaceDesign

«trace»

«trace»

«trace» «trace»

«trace»

Model/Subsystem/Package

Use Case/Use Case Realization

Actor/Class/ComponentInterface/Node/etc.

Use Case

«trace»«trace»

NodeComponent

«trace»

Bussines Use Case


Specification Granularity


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



Commercial Tools

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/

Requirements Management Products


Telelogic(DOORS)

30%Rational(RequisitePro)

26%

Integrated Chipware

(RTM) 20%

Startbase(Caliber-RM )

7%Others17%

Source: Standish Group 1999

... Commercial Tools


“Document management tool”. A project is a set of documents (of different types – templates) containing marked pieces of text corresponding to some “requirement type”

Commercial Tools: RequisitePro



Customization

• Document Type

• Requirement Type

• Requirement Attributes

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



• Visualizing the traceability information



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



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



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



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



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)



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

Comments
