1 / 45

Use cases

Use cases. 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. Use case modeling steps.

gwen
Télécharger la présentation

Use cases

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

More Related