Jan Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability, performance, supportability, interface, … A use case represents a goal an actor wants to accomplish. An actor is anything with behaviour – roles played by people, organizations, other systems

Jan Ron McFadyen2 Process Sale Use Case – fully dressed Primary Actor: the actor that executes the use case Preconditions: describes a state the system must be in prior to the execution of the use case Postconditions: describes a state the system must be in after execution of the use case Main Success Scenario: Step by step description of the interaction between the actor and the executing use case Extensions or Alternate Flows Alternate ways steps could terminate At this point in time (Inception), processing a sale is described in one use case that contains a main success scenario and all possible alternative scenarios. Some components of the written use case:

Jan Ron McFadyen3 Process Sale Use Case – fully dressed Use Case UC1: Process Sale Primary Actor: Cashier … Preconditions: Cashier is identified and authenticated Postconditions: Sale is saved…Commissions recorded…Payment authorization approvals recorded Main Success Scenario: 1.Customer arrives at POS checkout with goods and/or services to purchase 2.Cashier starts a new sale 3.Cashier enters item identifier 4.System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. 5.System presents total with taxes calculated …

Jan Ron McFadyen4 Process Sale Use Case – fully dressed Cashier repeats steps 3-4 until indicates done. 5.System presents total with taxes calculated 6.Cashier tells customer the total, and asks for payment. 7.Customer pays and System handles payment 8.System logs completed sale and sends sale and payment information to the external Accounting System and Inventory System. 9.System presents receipt 10.Customer leaves with receipt and goods Extensions or Alternate Flows *a. At any time, the System fails: 1.Cashier restarts System, logs in, and requests recovery of prior sale 2.System reconstructs prior state. … …

Jan Ron McFadyen5 Process Sale Use Case – fully dressed Extensions or Alternate Flows *a. At any time, the System fails: 1.Cashier restarts System, logs in, and requests recovery of prior sale 2.System reconstructs prior state. … … 3b. There are multiple of same item category and tracking unique item identity not important (e.g. 5 packages of veggie burgers) 1. Cashier can enter item category identifier and the quantity … 4a. The system supplied item price is not wanted … 1. Cashier enters override price. 2. System presents new price. … Identifies the step where this condition may arise. “*” means any step; “4” means at step 4; a letter following identifies a different exception

Jan Ron McFadyen6 Use Case Formats Text discusses two variations Single-column Double-column Essential-style use cases User interface details are left out Functionality is documented Focus is on actor goals and system responsibilities, not on the details of user/system interaction

Jan Ron McFadyen7 Use Case Guidelines See handout from Writing effective use cases by Cockburn 1.Use simple grammar Process sale has simple sentences 2.Show who has the “ball” In process sale it is always obvious who has the “ball”. Each step begins with customer or system 3.Write from a bird’s eye view Process sale always refers to customer or system 4.Show the process moving forward Each step in process sale accomplishes something

Jan Ron McFadyen8 Use Case Diagrams/Models Actors stick person or class symbol Use cases ovals Associations Between actors and use cases Between actors (generalizes) Between use cases (includes, extends, generalizes) notes