1 / 35

Support for Requirement Traceability: The Tropos Case

Support for Requirement Traceability: The Tropos Case. Rosa Pinto, Carla Silva, Jaelson Castro. {rccp, ctlls, jbc}@cin.ufpe.br. Outline. Motivation Requirements traceability Meta-model Tropos framework The Requirements Traceability Process Case Study Conclusions. Motivation.

keith-hall
Télécharger la présentation

Support for Requirement Traceability: The Tropos Case

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. Support for Requirement Traceability: The Tropos Case Rosa Pinto, Carla Silva, Jaelson Castro {rccp, ctlls, jbc}@cin.ufpe.br Universidade Federal de Pernambuco - Centro de Informatica

  2. Outline • Motivation • Requirements traceability Meta-model • Tropos framework • The Requirements Traceability Process • Case Study • Conclusions

  3. Motivation • In complex systems there are quite complex web of relationships • Methodologies supporting requirement traceability can develop higher quality software with fewer costs • Agent Oriented Development Software

  4. Requirements Traceability • Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases) [Pinheiro 2003]

  5. Tracing Agents Tropos Our Proposal

  6. Requirements Traceability Reference Model • [Toranzo 2002 e 2005] • Requirement Management sub-model • Design sub-model • Rational model

  7. Requirement Management sub-model

  8. Design sub-model

  9. Rational Model

  10. Requirements-driven Software development Detailed design Detailed design Architectural design Architectural design Early requirements Early requirements Late requirements Late requirements DEPENDER DEPENDUM DEPENDEE Tropos Framework • Concepts and Phases

  11. Estudo de Caso: Media Shop Universidade Federal de Pernambuco - Centro de Informatica

  12. Requirements Traceability Process • Stages of process • 1. Information Gathering (IG): • identify the information to be traced • 2. Information Structuring (ST) used to: • achieve the proper structuring of the information identified before • defined the set of valid values for association instances • 3. Definition of the Traceability Matrixes (TM): • guide the construction of the appropriate traceability matrixes

  13. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG1. Requirement Management sub-model classes from SD diagram of the actor representing the system • Rule 1. Actor which has some dependency relationship with • System actor  STAKEHOLDER class

  14. SD Diagram for Medi@ System STAKEHOLDERS Universidade Federal de Pernambuco - Centro de Informatica

  15. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG1. Requirement Management sub-model classes from SD diagram of the actor representing the system • Rule 2. System actor is dependee of softgoal, resource or task • the dependum  REQUIREMENT class

  16. DEPENDER DEPENDUM DEPENDEE SD Diagram for Medi@ System STAKEHOLDERS REQUIREMENTS Universidade Federal de Pernambuco - Centro de Informatica

  17. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG1. Requirement Management sub-model classes from SD diagram of the actor representing the system • Rule 3. System actor is dependee of a goal dependency of the actor representing the organization • The depedum  ORGANIZATIONAL OBJECTIVES class

  18. DEPENDER DEPENDUM DEPENDEE SD Diagrama for Medi@ System STAKEHOLDERS REQUIREMENTS ORGANIZATIONAL OBJECTIVE Universidade Federal de Pernambuco - Centro de Informatica

  19. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG1. Requirement Management sub-model classes from SD diagram of the actor representing the system • Rule 4. System actor is depender of a goal dependency of the actor does not represent the organization • The goal  SYSTEM OBJECTIVES class

  20. DEPENDER DEPENDUM DEPENDEE SD Diagrama for Medi@ System Organizational Map STAKEHOLDERS REQUIREMENTS ORGANIZATIONAL OBJECTIVE SYSTEM OBJECTIVE

  21. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG1. Requirement Management sub-model classes from SD diagram of the actor representing the system • Rule 5. System actor is depender of goal, softgoal, resource or task • The dependum  EXTERNAL class

  22. DEPENDER DEPENDUM DEPENDEE SD Diagrama for Medi@ System Organizational Map STAKEHOLDERS REQUIREMENTS ORGANIZATIONAL OBJECTIVE SYSTEM OBJECTIVE EXTERNAL

  23. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG2. Requirement Management sub-model classes from SR diagram of the actor representing the system • Rule 1. Goal  SYSTEM OBJECTIVES class • Rule 2. Task  REQUIREMENT class • Rule 3. Softgoal  REQUIREMENT class • Rule 4. Resource  REQUIREMENT class

  24. DEPENDER DEPENDUM DEPENDEE SR Diagrama for Medi@ System SYSTEM OBJECTIVE REQUIREMENTS

  25. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG3. Rational model classes from the process for selecting the proper architectural style • Rule 1. SUBJECT class  issue on which a decision must be taken • Rule 2. POSITION class  alternative solutions for the SUBJECT • Rule 3. ARGUMENT class  some criteria used for choosing the proper solution

  26. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG3. Rational model classes from the process for selecting the proper architectural style • Rule 4. ASSUMPTION class  facts that must be taken into account for choosing • Rule 5. CONSTRAINT class  limitations/restrictions that must be taken into account for deciding the proper solution • Rule 6. DOCUMENT class  some information used as reference for choosing the proper solution

  27. Requirements Traceability Process • Stage 1. Information Gathering (IG) • IG4. Design Sub-model classes from the architectural design model • Rule 1. Each architectural component  SUBSYSTEM class

  28. Requirements Traceability Process • Stage 2. Information Structuring (ST) • ST1. to remove classes unnecessary, and to delete instances with the same meaning • ST2. for each pair of associated classes in the reference model, the association should be instantiated • ST3. for each instance created in the ST2, define the set of values assigned to it.

  29. Requirements Traceability Process • Stage 3. Definition of the Traceability Matrixes (TM) • Guideline TM1 • For each pair of instantiated classes which are associated in a reference model, we can create a traceability matrix. • Guideline TM2 • For each created matrix, we have to analyze the system artifacts which are related to the matrix and fill the association which has been instantiated in a previous stage of the process.

  30. Requirements Traceability Process • Stage 3. Definition of the Traceability Matrixes (TM) • Applying TM1 and TM2: • create a traceability matrix to the instances of the <<resource>> association between REQUIREMENTS and ORGANIZATIONAL INFORMATION elements • <H> (High), <M> (Medium) or <L> (Low).

  31. Requirement Management sub-model C O N S T R A I N T EXTERNAL 0..n <<resource>> <<resource>> 0..n <<satisfy>> 1..n 0..n 1 1..n 0..n 0..n ORGANIZATIONAL INFORMATION I N F O R M A T I O N 0..n 0..n 0..n <<satisfy>> 0..n 0..n <<resource>> <<resource>> 1 0..n 1..n SYSTEM OBJECTIVES <<resource>> 0..n CHANGE PURPOSE <<resource>> 0..n 0..n 0..n <<resource>> 0..n 0..n 1 0..n T A S K 0..n <<resource>> 1..n <<resource>> 0..n 0..n 1 0..n R E Q U I R E M E N T 0..n 0..n <<responsability>> <<responsability>> S T A K E H O L D E R 0..n 0..n

  32. Case Study

  33. Case Study • Estimating the impact of a change • If some organizational information is changed, the impact in the system requirements can be analyzed.

  34. Conclusions • We outline a process that can be used to extend Tropos to address requirements traceability. • We intend to develop a complete and usable requirement traceability process for Tropos aiming to ensure the quality improvement of both the methodology and the software developed with it. • Further guidelines for instantiating all the classes of the three reference models (Requirement Management and Design sub-models and Rational model) for each phase of Tropos may be required.

  35. Questions/suggestions ?

More Related