Lec 5: Use Case

• Informally Use cases are:

– User stories, user scenarios or user needs of using a
system to meet goals.
– Formally, Use cases are the cases of use of the system.
• Use Case in UP
– The UP defines the Use-Case Model within the
Requirements discipline.
– This model is the set of all use cases;
– Use cases means user requirements
– model of the system's functionality and environment.
 Short History of Use Cases
• The idea of use cases to describe functional
requirements was introduced in 1986 by Ivar
Jacobson.
• He is a main contributor to the UML and UP.
• E.g. Rational Rose is a UML Based software
product
 NexGen POS Case Study
A POS system is a computerized application used (in part) to record sales and handle
payments; it is typically used in a retail store. It includes hardware components such
as a computer and bar code scanner, and software to run the system. It interfaces to
various service applications, such as a third-party tax calculator and inventory
control. These systems must be relatively fault-tolerant; that is, even if remote
services are temporarily unavailable (such as the inventory system), they must still be
capable of capturing sales and handling at least cash payments (so that the business is
not crippled). A POS system increasingly must support multiple and varied client-
side terminals and interfaces. These include a thin-client Web browser terminal, a
regular personal computer with something like a Java Swing graphical user interface,
touch screen input, wireless PDAs, and so forth. Furthermore, we are creating a
commercial POS system that we will sell to different clients with disparate needs in
terms of business rule processing. Each client will desire a unique set of logic to
execute at certain predictable points in scenarios of using the system, such as when a
new sale is initiated or when a new line item is added. Therefore, we will need a
mechanism to provide this flexibility and customization. Using an iterative
development strategy, we are going to proceed through requirements, object-oriented
analysis, design, and implementation.
 Some Informal Definitions:
• Actor: Something with behavior. E.g.
– Person, Computer System, Organization and Cashier,
other things: computer systems, such as "watchdog"
software processes etc.
• Scenario: A specific sequence of actions and
interactions between actors and the system
under discussion
• Also called use case instance (same as class and
object, use case is class and object is scenario)
Finding Primary Actors, Goals and Use Cases

• Use cases are defined to satisfy the user goals of the primary actors.
Hence, the basic procedure is:
1. Choose the system boundary: Is it just a software application, the
hardware and application as a unit, that plus a person using it, or
an entire organization?
2. Identify the primary actors: those that have user goals fulfilled
through using services of the system.
3. For each, identify their user goals: Raise them to the highest user
goal level that satisfies the EBP guideline.
4. Define use cases that satisfy user goals: name them according to
their goal. Usually, user goal-level use cases will be one-to-one with
user goals, but there is at least one exception, as will be examined.
 Reminder Questions to Find Actors and
Goals to find Missing use cases
• Who starts and stops the system?
• Who does user and security management?
• Is there a monitoring process that restarts the system if it fails?
• How are software updates handled? Push or pull update?
• Who does system administration?
• Is "time" an actor because the system does something in
response to a time event?
• Who evaluates system activity or performance?
• Who evaluates logs?
• Are they remotely retrieved?
 Class Activity
• Answer the following questions as per ATM Case study:
• Who starts and stops the system?
• Who does user and security management?
• Is there a monitoring process that restarts the system if it fails?
• How are software updates handled? Push or pull update?
• Who does system administration?
• Is "time" an actor because the system does something in
response to a time event?
• Who evaluates system activity or performance?
• Who evaluates logs?
• Are they remotely retrieved?
 Class Activity
• Find following actors and their goals from ATM
Case study:
• Primary Actors
• Secondary Actors
• Goals
• Use cases
• Use cases Instances (use case scenario)
 Another approach to aid in finding actors,
goals, and use cases
• To identify external events:
• What are they?
• where from?
• and why?
• Often, a group of events belong to the same
Elementary Business Processes (EBP)-level goal or
use case. For example:
 Difference b/w Primary and Supporting
Actors
• Primary actors have user goals fulfilled
through using services of the system. They call
upon the system to help them.
• Supporting actors provide services to the
system under design
 The Actor-Goal List

The Sales Activity System is a remote application that will frequently request sales
data from each POS node in the network.
 Class Activity
Draw The Actor-Goal List of ATM Case Study
Actor Goal Actor Goal
 So Informally What is use case?
• Collection of related success and failure scenarios that describe
actors using a system to support a goal. E.g.
• Handle Returns of POS:
• Main Success Scenario: A customer arrives at a checkout with
items to return. The cashier uses the POS system to record each
returned item ...
• Alternate Scenarios: If the credit authorization is reject, inform
the customer and ask for an alternate payment method. If the
item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is
corrupted). If the system detects failure to communicate with the
external tax calculator system, ...
 Formally, What are Use Cases?
• Use cases are text documents, not diagrams,
• Use-case Modeling: Primarily an act of writing text,
not drawing.
• However, the UML defines a use case diagram to
illustrate the names of use cases and actors, and their
relationships.
• Some think use cases are "the system shall do...“ is not
only feasible, also known as “shall” statements
• Its basic use is to model features of existing old system.
Example of Brief Format Use Case:
• Process Sale: A customer arrives at a checkout
with items to purchase. The cashier uses the
POS system to record each purchased item.
The system presents a running total and line-
item details. The customer enters payment
information, which the system validates and
records. The system updates inventory. The
customer receives a receipt from the system
and then leaves with the items
Essence (Heart) of Use Case is:
• Discovering and Recording
functional requirements by
writing stories of using a
system to help fulfill various
stakeholder goals/dream
(vision)
 Black-Box Use Cases and System
Responsibilities
Black-box style Not
The system records the sale. The system writes the sale to a
database. ...or (even worse): The system
generates a SQL INSERT statement for the
sale...
 Types of Use Case Formats
• Brief: concise one-paragraph summary, usually of the
main success scenario. The prior Process Sale
example was brief.
• Casual: informal paragraph format. Multiple
paragraphs that cover various scenarios. The prior
Handle Returns example was casual.
• Fully Dressed: the most elaborate. All steps and
variations are written in detail, and there are
supporting sections, such as preconditions and
success guarantees and post conditions.
 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. May be multiple
agencies, such as national, state, and county. –
• 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.
• 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 veggie-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.
• 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...
• 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.
 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
 Class Activity
• Use Case UC2: Withdraw Cash from ATM

• Note : follow steps as per Use Case UC1:

Process Sale.
 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 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.
 Remember!
• Goals are usually composite or complex, from the level of an
enterprise ("be profitable"), to many supporting intermediate
goals while using applications ("sales are captured"), to
supporting subfunction goals within applications ("input is
valid").
• Similarly, use cases can be written at different levels to satisfy
these goals, and can be composed of lower level use cases.
• Note: In case of confusion of identifying appropriate level of
use cases then follow the EBP (Elementary Business Process)
guideline provides guidance to filter out excessive low-level use
cases, read 6.8 section of applying UML and Patterns book.
 Types of Actors in addition to the actors of
the System under Discussion (SuD):
• Primary actor: has user goals fulfilled through using services of the
SuD. For example, the cashier. ) Why identify? To find user goals,
which drive the use cases.
• Supporting actors: provides a service (for example, information) to
the SuD. The automated payment authorization service is an
example. Often a computer system, but could be an organization or
person. ) Why identify? To clarify external interfaces and protocols.
• Offstage actors: has an interest in the behavior of the use case, but
is not primary or supporting; for example, a government tax agency.
Why identify? To ensure that all necessary interests are identified
and satisfied. Offstage actor interests are sometimes subtle or easy
to miss unless these actors are explicitly named.
Partial Use Case Context Diagram
 Class Activity
• Draw the Use Case Diagram to Withdraw cash
from ATM Machine:
 Use Cases Within the UP
• Use cases are vital and central to the UP, which encourages use-case
driven development. This implies:
• Requirements are primarily recorded in use cases (the Use-Case
Model); other requirements techniques (such as functions lists) are
secondary, if used at all.
• Use cases are an important part of iterative planning. The work of an
iteration is in-part defined by choosing some use case scenarios, or
entire use cases. And use cases are a key input to estimation.
• Use-case realizations drive the design. That is, the team designs
collaborating objects and subsystems in order to perform or realize the
use cases.
• Use cases often influence the organization of user manuals.
 Use Cases and Requirements Specification
Across the Iterations
• Table on next slide presents a sample (not a
recipe) which communicates the UP strategy
of how requirements are developed.
• This is the key difference in iterative
development to a waterfall process:
Production-quality development of the core of
a system starts quickly, long before all the
requirements are known.
Timing of UP Artifact Creation

Where: s - start; r - refine

 Class Activity
• Reference to ATM Case Study, perform the
following tasks:
• Identify primary and secondary actors
• Identify number of functional requirements
• Classify the functional requirements as per
actor
• Draw use case diagram.