Use Case UC1: Process Sale

This use case is provided as an example of how a use case might be expressed in structured text.  If you're asked to describe any everyday use case in textual form in an examination context, then the detail your answer should provide would reflect the mark allocation for the question. 

Thus if there were ten marks allocated for a particular question then you'd flesh out a use case in roughly twice the detail than you would in a five marker question.  If you're in doubt as to the detail required, then use up any spare time at the end of the exam to provide more detail.

Primary Actor:  Cashier
Stakeholders and Interests:
-Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages 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 Authorisation 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.  May be multiple agencies such as the Revenue Commissioners, Customs and Excise etc.
Payment Authorisation Service (such as Visa, Laser etc): Wants to receive digital authorisation requests in the correct format and protocol.  Wants to accurately account for their payables to the shop.
Precondidtion:  Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved.  Tax is properly calculated.  Accounting and Inventory are updated.  Commission recorded.  Receipt is generated.  Payment authorisation 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 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.
        2a. System detects anomalies preventing recovery:
            1. System signals error to 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 veggie-burgers):
    1. Cashier can enter item category identifier and the quantity. 
3-6a: Customer asks Cashier to cancel sale:
    1. Cashier cancels sale on System.
    2. Cashier displays updated running total.
3-6b. Customer tells Cashier to cancel sale:
    1. Cashier cancels sale on system.
3-6c. Cashier suspends 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 (for example: Customer complained about something and is offered a lower price).
    1.  Cashier enters override price.
    2.  System present 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 Information.
     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. Customer enters Customer identification.
    3. Customer applies credit up to price=0, and reduced remaining credit.
6a. Customer says they intended to pay by cash but don't have enough cash.
    1a. Customer uses and alternative payment method.
    1b. Customer tells Cashier to cancel sale.  Cashier cancels sale on System. 
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 an returns balance in cash to Customer.
    4. System records the cash payment.
7b. Paying by credit:
    1. Customer entered their credit account information.
    2. System sends payment authorisation request to external Payment Authorisation 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 cheque...
7d. Paying by debit...
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 UI on a large flat panel monitor.  Text must be visible from 1m.
- Credit authorisation response within 30s 90% of time.
- Somehow, we want robust recovery when access to remote services such as the inventory system, is failing.
- Language internationalisation on the text displayed.
- Pluggable business rules to be insertable at steps 3 to 7
- ...

Technology and Data Variations List:
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may by by UPC, EAN, JAN or SKU coding schemes (different bar code/number standards)
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt.  But within two years, we predict customers will want digital signature capture. 

Frequency of Occurence:
Could be nearly continuous.

Open Issues:
-What are the tax law variations?
-Explore the remote service recovery issue.
-What customisation is needed for different businesses?
-Must a cashier take their cash drawer when they log out?
-Can the customer directly use the card reader, or does the cashier have to do it?