Use

Case UC1: Process Sale

Primary Actor: Cashier
Stakeholders and Interests:
Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short
ages are deducted from his/her salary.
Salesperson: Wants sales commissions updated.
Customer: Wants purchase and fast service with minimal effort. Wants proof of
purchase to support returns.
Company: Wants to accurately record transactions and satisfy customer interests.
Wants to ensure that Payment Authorization Service payment receivables are
recorded. Wants some fault tolerance to allow sales capture even if server
components (e.g., remote credit validation) are unavailable. Wants automatic and
fast update of accounting and inventory.
Government Tax Agencies: Want to collect tax from every sale.
Payment Authorization Service: Wants to receive digital authorization requests in
the correct format and protocol. Wants to accurately account for their payables to
the store.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting
and Inventory are updated. Commissions recorded. Receipt is generated. Payment
authorization approvals are recorded.

Main Success Scenario (or Basic Flow):
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.
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 (for accounting and commissions) and Inventory system (to
update inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows):

*a. At any time, System fails:

To support recovery and correct accounting, ensure all transaction sensitive state and
events can be recovered from any step of the scenario.
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. System reconstructs prior state.

Page 1 of 5

2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records the error, and enters a clean
state.
2. Cashier starts a new sale.

3a. Invalid identifier: 1. System signals error and rejects entry.

3b. There are multiple of same item category and tracking unique item identity not
important (e.g., 5 packages of burgers): 1. Cashier can enter item category identifier and the
quantity.

3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters item identifier for removal from sale.
2. System displays updated running total.
3-6b. Customer tells Cashier to cancel sale:
1. Cashier cancels sale on System.
3-6c. Cashier suspends the sale:
1. System records sale so that it is available for retrieval on any POS terminal.

4a. The system generated item price is not wanted (e.g., Customer complained about
something and is offered a lower price):
1. Cashier enters override price.
2. System presents new price.

5a. System detects failure to communicate with external tax calculation system service:
1. System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Cashier may manually calculate and enter the tax, or cancel the sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred customer):
1. Cashier signals discount request.
2. Cashier enters Customer identification.
3. System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1. Cashier signals credit request.
2. Cashier enters Customer identification.
3. Systems applies credit up to price=0, and reduces remaining credit.
6a. Customer says they intended to pay by cash but don't have enough cash:
1a. Customer uses an alternate payment method.
1b. Customer tells Cashier to cancel sale. Cashier cancels sale on System.



Page 2 of 5
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:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment
Authorization Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. System receives payment approval and signals approval to Cashier.
3a. System receives payment denial:
1. System signals denial to Cashier.
2. Cashier asks Customer for alternate payment.
4. System records the credit payment, which includes the payment
approval.
5. System presents credit payment signature input mechanism.
6. Cashier asks Customer for a credit payment signature. Customer enters
signature.
7c. Paying by check...
7d. Paying by debit card...
7e. Customer presents coupons:
1. Before handling payment, Cashier records each coupon and System reduces price
as appropriate. System records the used coupons for accounting reasons.
1a. Coupon entered is not for any purchased item:
1. System signals error to Cashier.
9a. There are product rebates: 1. System presents the rebate forms and rebate receipts for
each item with a rebate.
9b. Customer requests gift receipt (no prices visible): 1. Cashier requests gift receipt and
System presents it.
Special Requirements:
- Touch screen Ul on a large flat panel monitor. Text must be visible from 1 meter.
- Credit authorization response within 30 seconds 90% of the time.
- Somehow, we want robust recovery when access to remote services such
the inventory system is failing.
- Language internationalization on the text displayed.
- Pluggable business rules to be insertable at steps 3 and 7.
Technology and Data Variations List:
3a. Item identifier entered by bar code laser scanner (if bar code is present) or key- board.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict
many customers will want digital signature capture.

Page 3 of 5
Use case: Buy Items
Actors: Cashier

Purpose: Capture a sale and its payment.

Overview: A Customer arrives at a checkout with items
to purchase. The Cashier records the purchase
items and collects a payment. On completion,
the Customer leaves with the items.

Type: Primary and Essential

Cross References: *Functions: R1.1, R1.2, R1.3, R1.7
*Use cases: Cashier must have completed the
Log_In use case.

Typical Course of Events
Actor Action System Response
1. The use case begins when Customer
arrives at the POST checkout with items to
purchase.
2. Cashier records each item. If there is more 3. Determines the item price and adds the
than one item, Cashier can enter the quantity item information to the running sales
as well. transaction. The description and price of
the current item are presented.
4. On completion of item entry, the Cashier 5. Calculates and presents the sale total.
indicates to the POST that item entry is
complete.
6. The Cashier tells the Customer the total.
7. Customer chooses payment type:
a. If cash payment, section: Pay by Cash
b. If credit payment, section: Pay by Credit.
8. Logs the completed sale.
9. Updates inventory levels.
10. Generates a receipt.
11. Cashier gives the receipt to the Customer.
12. Customer leaves with the items
purchased.
Alternative Courses
Line 2: Invalid item identifier entered.
Indicate error.

Line 7: Customer could not pay. Cancel sale
transaction.







Page 4 of 5
Section: Pay by Cash
Typical Course of Events
Actor Action System Response
1. The Customer gives cash payment-the
cash tendered - possibly greater then the
sale total.
2. The Cashier records the cash tendered. 3. Shows the balance due back to the
Customer.
4. The Cashier deposits the cash received
and extracts the balance owing.
5. The Cashier gives the balance owing to
the Customer.
Alternative Courses
Line 1: Customer does not have sufficient
cash. May cancel sale or initiate another
payment method.
Line 4: Cash drawer does not contain
sufficient cash. Cashier requests additional
cash from supervisor or ask Customer for
different payment amount or method.



Section: Pay by Credit
Typical Course of Events
Actor Action System Response
1. The Customer communicates their credit 2. Generates a credit payment request and
information for the credit payment. sends it to an external Credit Authorization
Service (CAS).
3. Credit Authorization Service authorizes the 4. Receives a credit approval reply from the
payment. Credit Authorization Service (CAS).
5. Records the credit payment and approval
reply information to the Accounts
Receivable system.

6. Display authorization success message.
Alternative Courses
Line 3: Credit request denied by Credit
Authorization Service.
Cashier suggests different payment method.

Page 5 of 5