1. 1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 10: Structure the Use-Case Model

2. 2 Objectives  Simplify the maintenance of the requirements without sacrificing clarity or comprehension for stakeholders.  Structure the use-case model.  Define and describe the relationships between use cases. Include, Extend, Generalization  Describe concrete and abstract use cases.  Define actor generalizations.  Describe concrete and abstract actors.

3. 3 Where Are We in the Requirements Discipline?

4. 4 Manage Change: Activities and Artifacts

5. 5 Structure the Use-Case Model  What is model structuring?  Factoring out parts of use cases to make new use cases.  Why structure the use-case model?  Simplify the original use cases. Make easier to understand. Make easier to maintain.  Reuse requirements. Share among many use cases.

6. 6 Relationships Between Use Cases  Include  Extend  Generalization «include» «extend» WP5: Structuring the Use-Case Model

7. 7 What Is an I nclude Relationship?  A relationship from a base use case to an inclusion use case.  The behavior defined in the inclusion use case is explicitly included into the base use case. «include» Base Inclusion

8. 8 Include Relationship: RU e-st Example Identify Customer Use Case 1. Log on 2. Validate logon 3. Enter password 4. Verify password A1: Not valid logon A2: Wrong password A3:... Get Quote Use Case 1. Include “Identify Customer” to verify customer’s identity 2. Display options. Customer selects “Get Quote” 3.... Execute Trade Get Quote Identify Customer Other Use Case «include» Trading Customer RUCS7: Structured Use- Case Reports

9. 9 Execution of an Include Relationship  Fully executed when the inclusion point is reached. Use-Case Instance Base Use Case Included Use Case

10. 10 Why Use an Include Relationship?  Factor out behavior common to two or more use cases. Avoid describing same behavior multiple times. Assure common behavior remains consistent.  Factor out and encapsulate behavior from a base use case. Simplify complex flow of events. Factor out behavior not part of primary purpose. «include» Base Inclusion Why?

11. 11 What Is an Extend Relationship?  Connects from an extension use case to a base use case.  Insert extension use case’s behavior into base use case.  Insert only if the extending condition is true.  Insert into base use case at named extension point. «extend» Extension Base

12. 12 Extend Relationship: RU e-st Example RUCS4: Structured Use- Case Reports Get Expert Predictions Get News Get Quote «extend» Trading CustomerExpert Quote System News System

13. 13 Extend Relationship: RU e-st Example (cont.) Get Quote Use Case Basic Flow: 1. Include “Identify Customer” to verify customer’s identity. 2. Display options. 3. Customer selects “Get Quote.” 4. Customer gets quote. 5. Customer gets other quotes. 6. Customer logs off. A1. Quote System unavailable … Extension Points: The “Optional Services” extension point occurs at Step 3 in the Basic Flow and Step A1.7 in Quote System Unavailable alternative flow. Get News Use Case This use case extends the Get Quote Use Case, at extension point “Optional Services.” Basic Flow: 1. If Customer selects “Get News,” the system asks customer for time period and number of news items. 2. Customer enters time period and number of items. The system sends stock trading symbol to News System, receives reply, and displays the news to the customer. 3. The Get Quote Use Case continues. A1: News System Unavailable A2: No News About This Stock …

14. 14 Execution of an Extend  Executed when the extension point is reached and the extending condition is true. Use-Case Instance Base Use Case Extension Use Case Extension Point

15. 15 Why Use an Extend Relationship?  Factor out optional or exceptional behavior.  Executed only under certain conditions.  Factoring out simplifies flow of events in base use case.  Example: Triggering an alarm.  Add extending behavior.  Behavior developed separately, possibly in later version. « extend » Extension Base

16. 16 Concrete Versus Abstract Use Cases Abstract use cases (A & D): Do not have to be complete. Exist only for other use cases. Are never instantiated on their own. A use case is either concrete or abstract. «extend» «include» Concrete use cases (B & C): Have to be complete and meaningful. Can be instantiated on their own. A D C B Hint: Cover up all abstract use cases and you should still be able to understand the main purpose of the system.

17. 17 Why Wouldn’t You Structure The Model?  The solution is harder to see when the use case gets fragmented. Functionally decompose the requirements. Decrease understandability. Increase complexity. Increases effort for reviewers, implementers and testers. Not all stakeholders are comfortable with the format.  The use-case model looks like a design. «include» Base Inclusion Why not? «extend» Extension Child

18. 18  Actors may have common characteristics.  Multiple actors may have common roles or purposes interacting with a use case. What Is Actor Generalization? Child 1 Child 2 Parent

19. 19  Parent: Medical Worker  Medical Worker can read charts  Children: Doctor, Nurse, Aide  Doctor, Nurse, and Aide can read charts Actor Generalization: Hospital Example Read Chart Nurse Aide Medical Worker Doctor Schedule Operation

20. 20 Why Use Actor Generalization?  Simplify associations between many actors and a use case.  Show that an instance of a child can perform all behavior described for the parent.  Represent different security levels. Child 1 Child 2 Parent

21. 21 Abstract Versus Concrete Actors  An abstract actor contains the common part of the roles.  It cannot be instantiated itself.  Example: No person is hired to be a Medical Worker.  A concrete actor can be instantiated.  Example: Lauren is a Doctor. Daniel is a nurse. DoctorNurse Medical Worker

22. 22 Use-Case-Modeling Guidelines  Notations to use and not use.  For example, whether to use generalization relationships.  Rules, recommendations, style issues, and how to describe each use case.  Recommendations for when to start structuring the use cases (not too early). RUCS11: Use- Case Modeling Guidelines

23. 23 Discussion: Structuring the Use-Case Model  How should we structure the use-case model for our class project?  Include relationships?  Extend relationships?  Actor generalizations?

24. 24 Review: Relationships in the Use-Case Model from to generalization «include» «extend» generalization communicates from to

25. 25 Checkpoints for Use Cases  For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided so that the included use case is not affected by changes to the including use cases.  Are there some optional requirements that are not part of the standard product requirements? If so, you model this with an extend-relationship to the other use case.

26. 26 Review: Structure the Use-Case Model 1.Why might you decide to structure your use-case model? 2.When is an extend-relationship used? 3.When is an include-relationship used? 4.What is an abstract actor? A concrete actor? An abstract use case? A concrete use case?

27. 27 Summary (1 of 2)  Build the right system right by using a process to define and manage requirements to meet the customer’s needs.  Effective problem analysis helps avoid the “Yes, but…”  Elicitation helps you understand your stakeholders’ needs.  Use features and a use-case model to gain agreement with the customer on the definition of the system.

28. 28 Summary (2 of 2)  Increase your chances to deliver on time and on budget by managing scope throughout the lifecycle of the project.  A use-case model of requirements helps refine the system definition to drive design, test, and user documentation.  Requirement attributes and traceability help you manage change and avoid “scope creep.”

29. 29 MRMUC Handouts WP 1: The Five Levels of Requirements Management Maturity WP 2: Features, Use Cases, and Requirements, Oh My! WP 3: Using the RUP to Evolve a Legacy System WP 4: Generating Test Cases from Use Cases WP 5: Structuring the Use-Case Model WP 6: ACRE: Selecting Methods For Requirements Acquisition

30. 30 Other Sources of Information  Rational Unified Process®  Other courses  Essentials of Rational Unified Process®  Essentials of Rational® RequisitePro® Web-based or Instructor-led training  Mastering Business Modeling with the UML  Web sites  Rational’s corporate site: www.rational.com  Rational Developer Network SM : www.rational.net  Books and articles about requirements management  See Reference list