Lecture 3
Use Cases
• Use cases are scenarios for understanding system
requirements
• A use case is an interaction between users and a system
• A use cases can be identified
by talking to typical users and
discussing the various things
they might want to do with the
application being prepared
Use Case Model
• The use-case model captures the goal of the user and
the responsibility of the system to its users
– The use case model describes the uses of the system and
shows the events that can be performed
– It shows a system in terms of its users and how it is being
used from a user point of view
Help Desk
Make a call
Take the call
Client
Operator
The role of Use Cases
• Use cases provide us with comprehensive documentation
of the system under study
• They represent the external view of the system
– Use cases represent the things that the user is doing with the
system, which can be different from the users goals
• Each use or scenario represents what the user wants to
do
– It defines what happens in the system
when the use case is performed
– It must have a name and short textual description,
no more than a few paragraphs
• Jacobson et al. (1995) describe a use case as
“a sequence of transactions in a system whose task is to
yield results of measurable value to an individual actor
of the system”
4
The role of the Use Case Model
• The use case model tries to systematically identify
uses of the system
– and therefore the systems responsibilities
• The use case model expresses what the application
will do and not how
– The use case model can also be known as a what model
• Users are shown in the roles they play
– they are named Actors
Use case diagrams
• Should capture those parts of the system
visible to the outside
• Actors are roles that people or systems play
• Each use case must have a name
Use Case Example
• A patient calls the clinic to make an
appointment for a yearly checkup.
• The receptionist finds the nearest empty time
slot in the appointment book and schedules
the appointment for that time slot.
7
Use Case Componentss
• The use case has three components.
• The use case task referred to as the use case that
represents a feature needed in a software system.
• The actor(s) who trigger the use case to activate.
• The communication line to show how the actors
communicate with the use case.
Use Cases
• The picture below is a Make Appointment use case for the medical clinic.
• The actor is a Patient. The connection between actor and use case is a
communication association (or communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use
cases.
Use-Case Diagram
A use case diagram is a collection of actors, use cases, and their communications.
The use case description
• How and when the use case begins and ends
• The interaction between
the use case and its actors,
including when the interaction occurs and
what is exchanged
• How and when the use case will store data in the
system
• Exceptions to the flow of events
Use Case Modeling
Fowler and Scott (1997)
1. Capture the simple and normal use case first
2. For every step in the use case, identify
– What could go wrong here?
– How might this work out differently?
3. Extract common sequences into a new, shared use case
with the includes associations
4. If you are adding more specialised or exceptional use
cases, take advantage of use cases you already have
with the extends association
12
Guidelines for Finding Use Cases
• Sequential steps
– For each actor, find the tasks and functions that the
actor should be able to perform or that the system
needs the actor to perform
• The use case should represent a course of events that leads
to a clear goal or goals
– Name the use cases
– Describe each use case briefly
• apply terms with which the user is familiar making the
description less ambiguous
• this is called the “use case description”
13
Guidelines for Finding Use Cases
• While finding use cases, you might have to make
changes to your set of actors
– All actor changes should be updated in the textual
description of actors and use cases
• Also watch for the possible use of extends and
includes relationships
• Naming a Use Case
– Should provide a general description of the use case
function (verb or verb and noun [e.g. Borrow Books])
14
4 use case symbols
• Actor
– and its name
Line manager
• System boundary
Budget Planning
– with system name
• Interaction Line
– and optional qualifier
Not an
information
flow!
(secondary)
• Use case
– and its name
Do something
Use-Case Diagrams (POST)
POST: Point of Sale Terminal
Use Case
System Boundary
POST
Buy Item
Log In
Cashier
Customer
Refund a Purchased Item
Adapted from Larman “Applying UML and Patterns”
Rules for Actors
• Actors to the outside of the System Boundary
• Actors should never communicate with each
other
• Actors should be named with singular,
business relevant nouns
• Actors should be roles not positions
Example
A client makes a call
that is taken by an
operator, who
determines the
nature of the
problem.
Some calls can be
answered
immediately;
other calls require
research and a return
call.
Help Desk
Make a call
Take the call
Client
Do research
Operator
Return a call
Support
representative
Includes and Extends
• Includes
– You have a piece of behavior that
is similar across many use cases
– Break this out as a separate usecase and let the other ones
“include” it
– Examples include
•
•
•
•
Valuation
Validate user interaction
Sanity check on sensor inputs
Check for proper authorization
• Extends
– A use-case is similar to another one
but does a little bit more
– Put the normal behavior in one usecase and the exceptional behavior
somewhere else
• Capture the normal behavior
• Try to figure out what can go wrong
in each step
• Capture the exceptional cases in
separate use-cases
– Makes it a lot easier to understand
Use Case Description
• Other than a short scenario, involving actors
associated with the use case, also record
– Preconditions
• A list of conditions that must be true before the Use
case begins
– Postconditions
• A list of conditions that must be true when a use case
ends
– Abnormal path(s)
– Non-functional requirements
20
{System Name}
Author (s):
_______________
USE CASE NAME:
USE CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR
PRIMARY SYSTEM
ACTOR
OTHER PARTICIPATING
ACTORS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
Date: ___________
Version: ___________
Step 1:
Step 2:
….
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:



21
Another Template
Use Case ID:
Use Case Name:
Created By:
Date Created:
[Repeat for multiple use cases]
Last Updated By:
Last Revision Date:
Actors:
Description:
Trigger:
Preconditions:
Postconditions:
Normal Flow:
Alternative Flows:
Exceptions:
Includes:
Frequency of Use:
Special Requirements:
Assumptions:
Notes and Issues:
22
Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1.2.1
Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g. Withdraw Cash
Created By:
Last Updated By:
Date Created:
Last Revision Date:
Actors: [An actor is a person or other entity external to the software system being specified who interacts
with the system and performs use cases to accomplish tasks.
Description: [Provide a brief description of the reason for and outcome of this use case.]
Trigger: [Identify the event that initiates the use case. This could be an external business event or system
event that causes the use case to begin, or it could be the first step in the normal flow.]
Preconditions: [List any activities that must take place, or any conditions that must be true, before the use case
can be started. Number each pre-condition. e.g.
1. Customer has active deposit account with ATM privileges
2. Customer has an activated ATM card.]
Postconditions: [Describe the state of the system at the conclusion of the use case execution. Should include both
minimal guarantees (what must happen even if the actor’s goal is not achieved) and the success
guarantees (what happens when the actor’s goal is achieved. Number each post-condition. e.g.
1. Customer receives cash
2. Customer account balance is reduced by the amount of the withdrawal and transaction
fees]
Normal Flow: [Provide a detailed description of the user actions and system responses that will take place
during execution of the use case under normal, expected conditions. This dialog sequence will
ultimately lead to accomplishing the goal stated in the use case name and description.
1. Customer inserts ATM card
2. Customer enters PIN
3. System prompts customer to enter language performance English or Spanish
4. System validates if customer is in the bank network
5. System prompts user to select transaction type
6. Customer selects Withdrawal From Checking
7. System prompts user to enter withdrawal amount
8. …
9. System ejects ATM card]
Alternative Flows:
[Alternative Flow 1 – Not in Network]
[Document legitimate branches from the main flow to handle special conditions (also known as extensions). For each alternative flow reference the
branching step number of the normal flow and the condition which must be true in order for this extension to be executed. e.g. Alternative flows in the
Withdraw Cash transaction:
4a. In step 4 of the normal flow, if the customer is not in the bank network
System will prompt customer to accept network fee
Customer accepts
Use Case resumes on step 5
4b. In step 4 of the normal flow, if the customer is not in the bank network
System will prompt customer to accept network fee
Customer declines
Transaction is terminated
Use Case resumes on step 9 of normal flow
Note: Insert a new row for each distinctive alternative flow. ]
Exceptions:
[Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those
conditions.
e.g. Exceptions to the Withdraw Case transaction
2a. In step 2 of the normal flow, if the customer enters and invalid PIN
Transaction is disapproved
Message to customer to re-enter PIN
Customer enters correct PIN
Use Case resumes on step 3 of normal flow]
Includes:
[List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a
separate use case that is included by the ones that need that common functionality. e.g. steps 1-4 in the normal flow would be required for all types of
ATM transactions- a Use Case could be written for these steps and “included” in all ATM Use Cases.]
Frequency of Use:
[How often will this Use Case be executed. This information is primarily useful for designers. e.g. enter values such as 50 per hour, 200 per day, once a
week, once a year, on demand etc.]
Special Requirements:
[Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or
implementation. These may include performance requirements or other quality attributes.]
Assumptions:
[List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description.
e.g. For the Withdraw Cash Use Case, an assumption could be:
The Bank Customer understands either English or Spanish language.]
Notes and Issues:
[List any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. e.g.
What is the maximum size of the PIN that a use can have?]
Drawing Use Cases
•
•
•
•
•
Think from an end user perspective
Create simple appropriate use case names
Actor is a role (not an individual person)
Model common use case with <<includes>>
Model exceptional behaviour with
<<extends>>
• Position actors and use cases in a meaningful
way
25
Partial POST
POST
Buy Item
Log In
Cashier
Customer
Refund a Purchased Item
Start Up
Manager
Manage Users
System Administrator
And a Lot More
MH
Adapted from Larman “Applying UML and Patterns”
POST Use-Case
Use case:
Actors:
Type:
Description:
Buy Item
Customer (initiator), Cashier
Primary
The Customer arrives at the
checkout with items to purchase.
The Cashier records the purchase
items and collects a payment.
On completion the Customer
leaves with the items
POST Expanded Use-Case
Use case: Buy Item
Actors:
Customer (initiator), Cashier
Type:
Primary and essential
Description:
The Customer arrives at the checkout with items
to purchase. The Cashier records the purchase
items and collects a payment. On completion the
Customer leaves with the items.
Cross Ref.:
Requirements XX, YY, and ZZ
Use-Cases:
Cashier must have completed the Log In use-case
When to use Use-Cases
• Requirements is the toughest part of software development
– A Use-Case is a powerful tool to understand
• Who your users are (including interacting systems)
• What functions the system shall provide
• How these functions work at a high level
• Spend adequate time on requirements and in the elaboration phase