Lecture Notes on ATM Use Cases: 9/25/2006
(use case worked at the board)

Actors - ATM Machine and Customer
Actions - Withdraw, Transfer, Deposit, Balance Check
Assumptions - only 1 bank account per Customer
 

Use Case - Withdrawal Happy Path:
1. customer signs in and is authenticated

2. customer indicates withdrawal from account X

3. customer chooses amount to withdraw (constraints on amount and
output type - for example,  rounded to $5 amount)

4. ATM validates withdrawal
(Note: steps 4+5 should be atomic so that joint account holders
can't both withdraw at the same time -- a non-functional constraint)

5. ATM debits the account

6. ATM delivers $$

7. ATM delivers receipt

8. Customer logs off

Other Requirements:

1. Performance - can't take too long to produce cash or respond to
input from Customer; may refuse transactions when System is down

2. Legal - possible warning of bank fees for use

3. Language requirements - support multiple languages/locales

4. Security - prevent retries

5. Usability requirements - be able to backout on any step 

Alternative Paths:
1-1. Authentication fails & ATM suggests retry
      1. Allow Customer to cancel
4-1. Specified amount exceeds limit
        1. exceeds amount of cash in ATM
             choose one --> restart with lower $$ -or- cancel transaction
             (choice of fixup is a business decision)
        2. exceeds "business logic" limit (e.g., max withdrawal per day)
           ATM suggests new withdrawal action (with restart) to user

        3. exceeds amount in customer account
           ATM suggests new withdrawal action (with restart) to user

6-1. ATM fails - can't deliver exact $$ amount (e.g., mechanical failure)

7-1. ATM fails to generate receipt because is out of paper (e.g.,
hardware failure)

(note: there are no software fixups for 6-1 and 7-1 so these are failure
scenarios.)