1 / 39

Requirements Traceability

Requirements Traceability. Patricio Letelier Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia. Summary. Introduction to Requirements Traceability Related Work Non-UML Community UML Community Commercial Tools: RequisitePro.

brenna-camacho
Download Presentation

Requirements Traceability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 bepart 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 • 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

  18. ... Related Work:Non-UML Community • 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

  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. "become" "copy" Association Generalization Include Extend Flow +sourceFlow n n n n +targetFlow Relationship +source +target +supplierDependency n n n n +supplier ModelElement Dependency 1..n 1..n n n name : Name 1..n 1..n n n +client +clientDependency Abstraction Usage Permission Binding mapping : MappingExpression "derive" "call" "realize" "access" "create" "refine" "friend" "instantiate" "trace" "import" "send" ... Related Work:UML Community [OMG UML 1.4 Specification]

  23. X Test Case Use-Case Realization - Design «trace» «trace» Use Case «trace» «trace» White-box test Use-Case Realization - Analysis Black-box test ... Related Work:UML Community Unified Process => “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. «trace» Use-Case Realization - Design Use Case Bussines Use Case Component Component Interface Implementation Interface Design Use-Case Realization - Analysis Design Class Node ... Related Work:UML Community Specification Granularity Model/Subsystem/Package «trace» «trace» «trace» Use Case/Use Case Realization «trace» «trace» Actor/Class/Component Interface/Node/etc. Analysis Class «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. 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/ 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. ... Commercial Tools: RequisitePro • Customization • Document Type • Requirement Type • Requirement Attributes

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

  32. ... Commercial Tools: RequisitePro • Visualizing the traceability information

  33. ... Commercial Tools: RequisitePro • Traceability Matrix, trace-to, trace-from, suspect links, indirect links between to types of requirements (text)

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

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

  36. ... Commercial Tools: RequisitePro • Attribute Matrix, showing the attributes of requirements of certain types

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

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

More Related