The Following Use Cases Give A Couple Examples Of

the following use cases give a couple examples of how use cases actually look. the problem domain is the classic problem of building a point-

The following use cases give a couple examples of how use cases
actually look. The problem domain is the classic problem of building a
point-of-sale (POS) terminal. Note that these use cases describe what
happens when a cashier initiates actions with the system. These use
cases are adapted from Applying UML and Patterns by Craig Larman. They
are by no means a full tutorial on use cases, but rather highlight a
simple form of use cases that can be easily applied.
UC1: Process Sale
=================
Basic Flow
----------
1.
Customer arrives at checkout with items to purchase
2.
Cashier starts a new sale
3.
Cashier enters item identifier
4.
System records item as being purchased and presents item
description, price and running total.
Cashier repeats step 3-4 until indicates done
5.
System presents total
6.
Cashier tells the 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 (if any)
Alternate Flows
---------------
3a. Invalid identifier.
1.
If the system cannot find the item presented, it rejects the
entry
3-6a. Customer asks Cashier to remove an item from the purchase.
1.
Casher enters item identifier to be removed
2.
System displays updated running total
7a. Paying by cash
1.
Cashier enters the cash amount tendered
2.
System presents the balance due, and releases the cash drawer
3.
Cashier deposits cash tendered and returns balance in cash to
customer
4.
System records the cash payment
7b. Paying by credit... (you get the picture)
Notes on 1st use case:
*
I used a unique identifier for the use case (UC1). This isn't
necessary, but can be helpful later on when you are trying to tie
things back to a use case.
*
Note that the details in the basic flow are very high level
*
In the alternate flows section, use the number of the step in the
basic flows section as the starting point for the alternate flows
section
*
Another approach to including the different payment methods in the
alternate flows section would be to define a Make Payment use case
that details how a customer can make a payment. You could then say
“Include Make Payment use case” in step 7 in the basic flow.
UC2: Balance Drawer
===================
Basic Flow
----------
1.
Cashier finishes shift at POS.
2.
Cashier starts close of drawer process
3.
System presents a summary of the transactions since last close,
broken down by payment type.
4.
Cashier counts cash left in the drawer
5.
Cashier enters amount into system
6.
System calculates difference from expected amount to actual amount
(as entered by cashier)
1.
Expected amount is calculated as the amount in drawer at last
close minus sum of cash transactions since last close.
7.
System prints closing report
8.
Cashier attaches all credit card slips, checks, and coupons to
closing report and presents it to the shift supervisor
Alternate Flows
---------------
2a. Transactions still pending
1.
System cancels close of drawer process
2.
System presents list of pending transactions
6a. Drawer out of balance
1.
System presents user with amount the drawer is out of balance
2.
System records close as an out of balance close