1. OOSE Use Case

2. Requirement Functional: –Features, capabilities, and security Non Functional: –Usability: Human factors, help, and documentation –Reliability: Frequency of failure, recoverability, and predictability –Performance: Response time, throughput, accuracy, availability, and resource usage –Supportability: Adaptability, maintainability, internationalization, and configurability

3. Use Case Example: Process Sale Name: Process Sale Summary: Customer arrives with items to purchase Actors: Cashier Basic sequence: 1. System presents a running total 2. Cashier enters payment information 3. System validates and records payment information 4. System updates inventory 5. System prints customer’s receipt 6. Customer leaves the store

4. Use Case: Process Sale Primary Actor: Cashier Preconditions: Cashier is identified and authenticated Postconditions: - sale is saved - tax is calculated - inventory is updated - commissions are recorded - receipt is generated - payment approval is recorded

5. Use Case Preconditions Preconditions: –State what should always be true –Take place before scenario begins –Not tested by the use-case –Assumed to be true –Imply another use case: “user logged into the system” “cashier is identified and authenticated”

6. Use Case Postconditions Postconditions: –State what is true upon successful completion of use case. –Main success scenario –Alternate path scenrio

7. Use Case: Process Sale Main “Success Scenario”, also known as Basic Flow 1. Customer arrives at checkout with goods 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. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays, System handles payment. 8. System logs sale, sends payment info to Accounting, makes Inventory update.

8. Use Case: Process Sale Main “Success Scenario”, continued: 9. System presents receipt. 10. Customer leaves with receipt and goods (if any).

9. Use Case Alternative Flows Customer tells Cashier to cancel sale. –1. Cashier cancels sale. System fails to communicate with external tax calculation service –1. System signals error. –2. Cashier manually calculates tax, or cancels sale.

10. Use Case: Two-Column Variation Primary Actor: Cashier Main Success Scenario: Actor Action (or intention)System responsibilty 1. Customer arrives at a checkout with goods 2. Cashier starts a new sale 3. Cashier enters item identifier Cashier repeats step 3-4 until done 6. Cashier tells Customer the total and asks for payment 7. Customer pays 4. Records each sale line item and presents item description and running total 5. System presents total with taxes calculated 8. Handles payment

11. Use Case Diagram of an Online Purchase System

12. Sequence Diagram Sequence Diagram of “Track a Package” Use Case