View
216
Download
2
Tags:
Embed Size (px)
Citation preview
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
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
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
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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]
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
... 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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
... 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
... Introduction to Requirements Traceability
www.dsic.upv.es/~letelier/pub
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
... Introduction to Requirements Traceability
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
[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
www.dsic.upv.es/~letelier/pub
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
www.dsic.upv.es/~letelier/pub
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
... Related Work: Non-UML Community
www.dsic.upv.es/~letelier/pub
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
... Related Work: Non-UML Community
www.dsic.upv.es/~letelier/pub
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.
... Related Work: Non-UML Community
www.dsic.upv.es/~letelier/pub
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.
... Related Work: Non-UML Community
www.dsic.upv.es/~letelier/pub
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
www.dsic.upv.es/~letelier/pub
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]
www.dsic.upv.es/~letelier/pub
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”
... Related Work: UML Community
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
www.dsic.upv.es/~letelier/pub
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
... Related Work: UML Community
[- 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
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
... Related Work: UML Community
Specification Granularity
www.dsic.upv.es/~letelier/pub
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
... Related Work: UML Community
www.dsic.upv.es/~letelier/pub
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
www.dsic.upv.es/~letelier/pub
Telelogic(DOORS)
30%Rational(RequisitePro)
26%
Integrated Chipware
(RTM) 20%
Startbase(Caliber-RM )
7%Others17%
Source: Standish Group 1999
... Commercial Tools
www.dsic.upv.es/~letelier/pub
“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
www.dsic.upv.es/~letelier/pub
www.dsic.upv.es/~letelier/pub
Customization
• Document Type
• Requirement Type
• Requirement Attributes
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
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”
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
• Visualizing the traceability information
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
• Traceability Matrix, trace-to, trace-from, suspect links, indirect links between to types of requirements (text)
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
• Traceability Tree (Traced out of ...), showing trace-to relationships from other requirements (including all requirements types)
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
• Traceability Tree (Traced into ...), showing trace-to relationships from other requirements (including all requirements types)
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
• Attribute Matrix, showing the attributes of requirements of certain types
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
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)
... Commercial Tools: RequisitePro
www.dsic.upv.es/~letelier/pub
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
... Commercial Tools: RequisitePro