FAST National University of Computer and Emerging Sciences

Islamabad, Pakistan

CASE STUDY

Object Oriented Analysis and Design, OOAD, Fall 2018

 Use Case Model

Revision History

Version Date Description Author

Inception Jan 10, First draft. To be Craig Larman
draft 2031 refined primarily
during elaboration
Introduction
This document is the repository of all Point of Sale (POS)
Terminal use cases.

Object Oriented Analysis and Design, OOAD, Fall 2018

High-Level Use Cases
UC01: Use case: Buy Items
Actors: Customer (initiator), Cashier
Type: primary
Description: 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.

UC02:Use case: Start Up

Actors: Manager
Type: primary
Description: A Manager powers on a POST in order to prepare
it for use by Cashiers. The Manager validates
that the date and time are correct, after which
the system is ready for Cashier use.

Object Oriented Analysis and Design, OOAD, Fall 2018

Expanded Essential Use Cases
Section: Main
Use case: Buy Items
Actors: Customer (initiator), 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, R1.9, R2.1,
R2.2, R2.3, R2.4.
*Use cases: Cashier must have completed the
“Log_In” use case.

Object Oriented Analysis and Design, OOAD, Fall 2018

Typical Course of Events
Actor Action System Response
1. This use case begins when Customer
arrives at the POST checkout with
items to purchase.

2. The Cashier records each item. 3. Determines the item price

If there is more than one item, and adds the item information
Cashier can enter the quantity as well. to the running sales transaction.
The description and price of the
the current item are presented.

4. On completion of item entry, the 5. Calculates and presents the

Cashier indicates to the POST that sale total.
item entry is complete.

6. The Cashier tells the Customer the total.

Object Oriented Analysis and Design, OOAD, Fall 2018

Continues……………
Actor Action System Response
7. Customer chooses payment type: 8. Logs the completed sale.
a. If cash payment, 9. Updates inventory levels.
see section Pay by Cash. 10. Generates a receipt.
b. If credit payment,
see section Pay by Credit.
c. If check payment,
see section Pay by Check

11.The Cashier gives the receipt

to the Customer.
12.The 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.

Object Oriented Analysis and Design, OOAD, Fall 2018

Section: Pay by Cash
Typical Course of Events
Actor Action System Response
1. The Customer gives a 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.
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 asks Customer for different payment
amount or method.

Object Oriented Analysis and Design, OOAD, Fall 2018

 Section: Pay by Credit

Actor Action System Response

1. The Customer communicates their credit 2.Generates a credit payment
information for the credit payment. Request and sends it to an external Credit
Authorization service.

3. Credit Authorization Service authorizes 4. Receives a credit approval

the payment. * Reply from the Credit Authorization Service
(CAS).

5. POST (records) the credit payment and

approval reply information to the Accounts
Receivable system.(The CAS owes money
to the Store, hence Acct/Recv must track it).
6. Display authorization success message.

Alternative Courses
* Line 3: Credit request denied by Credit Authorization Service.
Suggest different payment method.

Object Oriented Analysis and Design, OOAD, Fall 2018

Section: Pay by Check
Actor Action System Response
1. The Customer writes a check and
identifies him/her-self.
2. Cashier records the identification 3. Generate a check payment request
information and requests check and sends it to an external Check
payment authorization. Authorization Service.
4. Check Authorization Service
authorizes the payment. 5. Receives a check approval reply
from the Check Authorization
Service.

6. Indicates authorization success.

Alternative Courses
* Line 4: Check request denied by Check Authorization Service. Suggest
different payment method.

Object Oriented Analysis and Design, OOAD, Fall 2018

 FAST National University of Computer and Emerging Sciences
Islamabad, Pakistan

RANKING AND IMPORTANCE OF

USE CASES

10

Object Oriented Analysis and Design, OOAD, Fall 2018

 Ranking Use Cases
Ranking Use Cases: what for ?
In most projects, the most important use cases are developed first.
Use-case ranking and priority matrix – a tool used to evaluate use cases and
determine their priority.
Evaluates use cases on 1-5 scale against six criteria:
Some qualities and characteristics to rank use cases:
(a) Significant impact on the architectural design
(b) Significant info (reports)- Easy to implement but contains significant functionality
(c) Risky, time critical, or complex functions
(d) New, research oriented
(e) Basic/primary processes (f) Support increased
Score Bases revenue/decreased costs
Use Case a b c d e f Sum
Buy Items 5 3 2 0 5 3 20
and so on
11

Object Oriented Analysis and Design, OOAD, Fall 2018

 Ranking/Classification Scheme

Fuzzy Classification High, medium, Low

Rank Use Case Justification

High - Buy Items Scores on most increased ranking criteria.

Medium - Add New Users Affects security subdomain.

- Log In Affects security subdomain.
- Refund Items Important process; affects accounting.
Low - Cash Out Minimal effect on architecture.
- Start Up Definition is dependent on other use cases.
- Shut Down Minimal effect on architecture.

Both can be applied independently or jointly con

12

Object Oriented Analysis and Design, OOAD, Fall 2018

 Sample Use-Case Ranking
and Priority Matrix Example

13

Object Oriented Analysis and Design, OOAD, Fall 2018 7-13

 FAST National University of Computer and Emerging Sciences
Islamabad, Pakistan

MISCELLANEOUS
INFORMATIOTION ON USE
CASES

14

Object Oriented Analysis and Design, OOAD, Fall 2018

 Creating multiple versions of complex use cases

• Buy items--version 1 (cash payments, no inventory

updates…….)
• Buy items--version 2 (allow all payment types)
• Buy items--version 3 (complete version
including inventory update,..)

15

Object Oriented Analysis and Design, OOAD, Fall 2018

 Buy items--version 1
• Simplifications, Goals, and Assumptions
a) Cash payments only.
b) No inventory maintenance.
c) It is a stand-alone store, not part of a larger organization.
d) Manual entry of UPCs; no bar code reader.
e) No tax calculation.
f) No coupons.
g) Cashier does not have to log in; no access control.
h) There is no record maintained of the individual customers and their buying
habits.
i) There is no control of the cash drawer.
j) Name and address of store, and date and time of sale, are shown on the receipt
k) Cashier ID and POST ID are not shown on receipt
l) Completed sales are recorded in an historical log.

16

Object Oriented Analysis and Design, OOAD, Fall 2018

 Use Cases: Requirements in Context

 Use Cases capture requirements in the context of the goals

and scenarios of using a system.

 Its not sufficient just writing use case; other kind of

requirements (FURPS+) need to be identified.

 Some non-functional requirements, domain rules and context,

and other hard-to-place elements are better captured in the
Supplementary Specification.

17
 Use Cases: Requirements in Context (2)

• One idea behind use cases is to replace detailed, low-level

feature lists (which were common in traditional requirements
methods) with use cases (with some exceptions).

• Low level feature list like the one below is never required:

ID Feature
FEAT1 .9 The system shall accept entry of item identifiers.
FEAT2.4 The system shall log credit payments to the accounts
receivable system.

Suggestion: Try to replace detailed, low level feature list with use cases.

18

Object Oriented Analysis and Design, OOAD, Fall 2018

 Use Cases: Requirements in Context (3)

High-Level System Feature Lists Are Acceptable

Summary of System Features

 Sales capture
 Payment authorization (credit, debit, check)
 Automatic offline sales processing when external components fall
 Real-time transactions, based on industry standards, with third-party system,
including inventory, accounting, human resources, tax calculators, and
payment authorization services
 Definition and execution of customized “pluggable” business rules at fixed,
common points in the processing scenarios
 …

19

Object Oriented Analysis and Design, OOAD, Fall 2018