Use cases

1. Use cases Requirements Engineering

2. Use cases • Formal definition; a use case describes a sequence of actions a system performs that yields a result of value to a particular actor • Describes the interactions between a user and a system • Focus on what the system does for the user Requirements Engineering

3. Use case modeling steps • Find the system boundary • Find the actors • Find the use cases • Specify the use case • Create scenarios Requirements Engineering

4. Use case model components • Actors; roles played by people or things that use the system • Use cases; things that the actors do with the system • Relationships; meaningful relationships between actors and use cases • System boundary; a box drawn around the use cases to denote the edge or the boundary of the system being modeled Requirements Engineering

5. The system boundary • What is part of the system and what is external to the system • Positioning of boundary has big impact on functional and non-functional requirements • Defined by who or what used the system • Drawn as a box Requirements Engineering

6. Actors • Specifies a role that some external entity adopts when interacting with the system directly • Represents a user role or a role played by another system • Always external to the system • Outside our control Requirements Engineering

7. Finding actors • Who or what uses the system? • Who installs the system? • Who starts and shuts down the system? • Who maintains the system? • Who gets and provides information to the system? Requirements Engineering

8. Time as an actor • For modeling things that happen to your system at a specific point in time but which don’t seem to be triggered by an actor • Automatic system backup that runs every morning Requirements Engineering

9. Building the use case model • Consists of all the actors of the system • All the use cases by which the actors interact with the system • Describe totality of functional behavior of the system (not really!) Requirements Engineering

10. Use cases • Use cases are always started by an actor • Use cases are always written from the point of view of an actor PlaceOrder GetStatus OnOrder Requirements Engineering

11. Identifying use cases • Consider how each actor is going to use the system • Give the use case a short descriptive name that is a verb phrase • May also discover new actors • Iterative process of stepwise refinement • Start with a name, fill in details, refine to complete spec Requirements Engineering

12. Identifying use cases • What functions will a specific actor want from the system? • Are any actors notified when the system changes state? • Are there any external events that affect the system? What notifies the system about those events? • Does the system store and retrieve information? Which actors trigger this behavior? Requirements Engineering

13. Communication relationship actor System name Use case System boundary Use case diagram PlaceOrder Mail order system CancelOrder Shipping company Send Catalog customer CheckOrder Status Send Catalog dispatcher Requirements Engineering

14. Detail a use case • Each use case has a name and a specification • Preconditions; these are things that must be true before the use case execute – they are constraints on the state of the system • Flow of events; the steps in the use case • Postconditions; things that must be true at the end of the use case Requirements Engineering

15. Pre and post conditions • Preconditions; constrain the state of the system before the use case can start. Think of them as gatekeepers that prevent the actor from triggering the use case until all their conditions are met • Postconditions; constrain the state of the system after the use case has executed Requirements Engineering

16. Use case for PayVAT Requirements Engineering

17. Flow of events • The use case starts when an <actor> <function> • <number> the <something><some action> • Can also use prose but this can be too imprecise • Simple declarative statement of some thing performing some action Requirements Engineering

18. Ill formed use case • “Customer details are entered” • Three important deletions • Who is it that enters the customer details? Who triggers the use case? • Into what are the details entered? • What Requirements Engineering

19. When encountering vagueness • Who specifically…..? • What specifically…..? • When specifically…..? • Where specifically…..? Requirements Engineering

20. Branching within a flow • Alternative flows must be represented • Can be argued that a branch indicates a new use case • But also leads to more use cases • Keyword If Requirements Engineering

21. Use case for ManageBasket Requirements Engineering

22. Alternative flows • Sometimes its hard to express branching • Things that can happen at any point in time • Where in the main flow would the If go? • Express as one or more alternative flows Requirements Engineering

23. Alternative flows • 1. Specify the preconditions for the use case – these must be true for all possible paths through the use case • 2. Specify the normal flow of events • 3. Specify the postconditions of the normal flow of events • Append a new section to the end of the use case for each alternative flow Requirements Engineering

24. Alternative flows • 1. Specify the flow of events for the alternative flow • Must always begin with a boolean condition • Specify postconditions for the flow of events Requirements Engineering

25. Use case for DisplayBasket Requirements Engineering

26. Postconditions: • Alternative flow 1: • At any time the customer may leave • the shopping basket screen Postconditions: • Alternative flow 2: • At any time the customer may leave • the system Postconditions: Requirements Engineering

27. Repetition within a flow: For • May have to repeat an action several times within a flow of events • Iterates a positive whole number of iterations n. For (iteration expression) n.1 Do something n.2 Do something else n.3 …. n+1 Requirements Engineering

28. Use case for FindProduct Requirements Engineering

29. Postconditions: • Alternative flow 1: • At any time the customer may move • to a different page Postconditions: Requirements Engineering

30. Repetition within a flow: While • Use the keyword While to model a sequence of actions in the flow of events that is performed while some boolean condition is true n. While (Boolean condition) n.1 Do something n.2 Do something else n.3 …. n+1 Requirements Engineering

31. Use case for ShowCompnyDetails Requirements Engineering

32. Requirements tracing • Important to understand if anything in SRS is not in a use case • Many to many relationship between individual functional requirements in the SRS and use cases • CASE tools help • Manually create a requirements traceability matrix Requirements Engineering

33. Traceability matrix Requirements Engineering

34. Complex use cases • Use cases should be as simple as possible • May encounter irreducible complexity that will lead to complex use cases • In this cases model the main flows through through this branching network as separate scenarios Requirements Engineering

35. Scenarios • A scenario is one specific path through a use case • Scenarios do not branch • Each possible branch in a use case is a possible scenario • Each use case has one and only one primary scenario • “perfect world” path through complex flow Requirements Engineering

36. Scenarios • Each use case has many secondary scenarios • Alternative paths through the flow of events • Exception scenarios (capture errors) Requirements Engineering

37. Use case for CheckOut Requirements Engineering

38. Secondary scenarios: InvalidCustomerIdentifier InvalidCreditCardDetails CreditCardLimitExceeded CreditCardExpired Postconditions: Requirements Engineering

39. Specifying secondary scenarios • Specify in the same way as a primary use case • Secondary scenarios should be traceable back to its use case • Can also reference the primary scenario Requirements Engineering

40. Secondary use case Requirements Engineering

41. Finding secondary use cases • Identified by inspection to the primary use cases • For each step in the primary use case look for; • Possible alternative paths • Errors that might be raised • Interrupts that might occur to the flow – things that might happen at any time Requirements Engineering

42. How many scenarios? • Should limit the number of secondary use cases to the necessary minimum • Pick the most important ones and document those • Where there are groups of secondary scenarios that are similar, document one as an exemplar and add notes explaining how the others differ Requirements Engineering

43. How many scenarios? • Basic principle in use case modeling is to keep the amount of information captured to a necessary minimum • Used to understand the desired behavior of the system • Because of the iterative process, can always go back and add more Requirements Engineering

44. Top 10 Mistakes to Avoid When Writing Use Cases 10. Write functional requirements instead of usage scenario text. 9. Describe attributes and methods rather than usage. 8. Write use cases too tersely. 7. Divorce yourself completely from the user interface. 6. Avoid explicit names for your boundary objects. 5. Write using a perspective other than the user’s, in a passive voice. 4. Describe only user interactions; ignore system responses. 3. Omit text for alternative courses of action. 2. Focus on something other than what’s “inside” a user case, such as how you get there or what happens afterwards. 1. Spends a month deciding whether to use include or extends.[Rosenburg p. 60] Requirements Engineering

45. Summary • Use case modeling is part of the requirements flow • Find the system boundary, find the actors, find use cases • Time is often an actor • Find use cases by considering how each actor interacts with the system Requirements Engineering