1. Managing Changing Requirements: Structure the Use Case Model PowerPoint Presentation derived from IBM/Rational course Mastering Requirements Management Most slides copyright IBM/Rational. Slide 1

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. Where Are We in the Requirements Discipline?

4. Manage Change: Activities and Artifacts

5. Workflow of use case modeling Seek Actors: Name and describe Seek Use Cases: – For each (active) actor ask “What would you like to use the system for?” Name and briefly describe each Use Case Iterate based on previous findings Iterate Seek Actors Describe the Use Cases Seek Use Cases Analysis Phase

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

7. Relationships Between Use Cases Include Extend Generalization «include» «extend»

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

9. Dependency – Include A relationship from a base use case to an inclusion use case Implies that a use case “calls” another use case Primarily for reuse behavior common to several use cases The “calling” Use Case references the “called”. All conditions for the usage are stated in the “calling” Use Case, e.g: – ”… The system then prints the report according to …” – ”… The system collects the coins according to, the system is now ready to …” Analysis Phase OrderCoffee

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

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

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

13. Why not? Do not overuse this concept – generates too many Use Cases – makes the Use Case Model more difficult to understand and maintain Analysis Phase OrderCoffee

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

15. Dependency - Extend From an extension use case to a base use case Implies behavior in one use case is an extension of the behavior in an other use case. Is used to model optional behavior. Conditions for how and when the extension is done is stated in the extending Use Case: – ”… if the user pushes the “add sugar” button, sugar is added according to …” Analysis Phase OrderCoffee

16. Extend Relationship: RU e-st Example Get Expert Predictions Get News Get Quote «extend» Trading CustomerExpert Quote System News System

17. Extend Relationship: (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 …

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

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

20. Why not? Do not overuse this concept – generates to many Use Cases – makes the Use Case Model hard to understand and maintain – should still add value to the Actor Analysis Phase OrderCoffee

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

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

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

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

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

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

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

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

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

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

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