1. Fall 2009ACS-3913 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

2. Fall 2009ACS-3913 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:

3. Fall 2009ACS-3913 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 …

4. Fall 2009ACS-3913 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. … …

5. Fall 2009ACS-3913 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

6. Fall 2009ACS-3913 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

7. Fall 2009ACS-3913 Ron McFadyen7 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