1. 1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use cases

2. 2 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

3. 3 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case modeling steps Find the system boundary Find the actors Find the use cases –Specify the use case –Create scenarios

4. 4 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

5. 5 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

6. 6 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

7. 7 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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?

8. 8 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

9. 9 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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!)

10. 10 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

11. 11 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

12. 12 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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?

13. 13 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case diagram customer PlaceOrder CancelOrder CheckOrder Status Send Catalog Send Catalog Shipping company dispatcher Mail order system actor Communication relationship Use case System name System boundary

14. 14 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

15. 15 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

16. 16 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for PayVAT

17. 17 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Flow of events The use case starts when an the Can also use prose but this can be too imprecise Simple declarative statement of some thing performing some action

18. 18 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

19. 19 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering When encountering vagueness Who specifically…..? What specifically…..? When specifically…..? Where specifically…..?

20. 20 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

21. 21 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for ManageBasket

22. 22 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

23. 23 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

24. 24 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

25. 25 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for DisplayBasket

26. 26 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Postconditions: Alternative flow 1: 1.At any time the customer may leave the shopping basket screen Postconditions: Alternative flow 2: 1.At any time the customer may leave the system Postconditions:

27. 27 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

28. 28 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for FindProduct

29. 29 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Postconditions: Alternative flow 1: 1.At any time the customer may move to a different page Postconditions:

30. 30 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

31. 31 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for ShowCompnyDetails

32. 32 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

33. 33 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Traceability matrix Use case UC1UC2UC3 R1X R2XX R3X R4X R5X

34. 34 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

35. 35 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

36. 36 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Scenarios Each use case has many secondary scenarios –Alternative paths through the flow of events –Exception scenarios (capture errors)

37. 37 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use case for CheckOut

38. 38 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Secondary scenarios: InvalidCustomerIdentifier InvalidCreditCardDetails CreditCardLimitExceeded CreditCardExpired Postconditions:

39. 39 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

40. 40 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Secondary use case

41. 41 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

42. 42 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

43. 43 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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

44. 44 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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]

45. 45 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering 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