ZEIT2301
Design of Information Systems
Functional Design:
Use Cases
School of Engineering and Information Technology
UNSW@ADFA
Dr Kathryn Merrick
Topic 04: Functional Design

Objectives




Appreciate the role of Use Cases in Systems Development
Be aware of the rules & style guidelines for Use Case diagrams.
Be able to create functional models using Use Case diagrams.
Design Use Case Descriptions
Reference: Dennis Ch 5
Use Cases


Model the systems interaction with the environment
Provide a high level view of the system from the user’s
perspective.


Use cases are a non-technical record of what the customer (or
user) expects the system to do.
Based on functional requirements.
Use Cases and Requirements

Use Cases assist the analyst to organize and model the functional
requirements identified for the system.


Requirements obtained via interviews, questionnaires, observation,
document analysis, JAD sessions or prototyping.
Use cases are not effective in capturing non-functional requirements


They describe what a system accomplishes, not how
Non-functional requirements (e.g. reliability, etc) are often documented
outside the use case.
A Use Case

Informally, a use case is a story of using a system to fulfill
a (business) goal.

A Use Case represents a behaviour, so name should start
with a verb

eg RentDVDs, Make Appointment, CheckPrice, ApproveLoan
Types of Use Cases
Amount of information
Essential
Detail
High-level overview of
issues essential to
understanding required
functionality
Detailed description of
issues essential to
understanding required
functionality
Real
Purpose
Overview
High-level overview of
a specific set of steps
performed on the real
system once
implemented
Detailed description of a
specific set of steps
performed on the real
system once implemented
Early analysis stage concentrates on Use Cases: Overview
and Essential
Guidelines for Good Use Cases





Identify major system functions
Choose a good name (start with a verb)
Illustrate a complete behaviour
Limit each use case to one behaviour
Represent the actor’s point of view
An Actor

An actor is an external entity that interacts with one or
more Use Cases of the system


An actor is outside the system boundary
An actor is a role, not a specific user

One actor may represent many users; a particular user may
perform more than one role.
An Actor

Most actors represent user roles


but occasionally actors can also be external systems.


e.g. StoreClerk, Customer, BankTeller
eg CreditAuthorizationSystem
An actor is connected to a Use Case

Depicts a usage relationship
Connection does not indicate data flow

NB. There are no arrow heads on the connection line

Use Case Diagrams

A Use Case Diagram provides a high-level graphical view
of all the Use Cases for the part of the system being
modelled.

Illustrates, in a very simple way, the main functions of the
system (or sub-system) and the users that will interact
with it.

Can be used as a tool to communicate with users in the early
phases of system development.
Use Case Diagram Syntax

Actor


Use Case


person or system that derives benefit from and is external to the
subject
Represents a major piece of system functionality
Association Relationship
(between an actor and a use case)

Include Relationship
<<include>>

Extend Relationship
<<extend>>

Generalization Relationship
A simple Use Case Diagram
Note the high level view of the system from the user’s perspective.
Diagram does not show the backend processes and databases that would connect these views.
store clerk
rent DVDs
add new DVDs
system manager
increase price
financial system
A simple Use Case Diagram

Actors: store clerk (perhaps there are several clerks), system manager,
financial system.
store clerk
rent DVDs
add new DVDs
system manager
increase price
financial system
An <<include>> Relationship

Two Use Cases may be connected by an <<include>>
relationship

Indicates a Use Case that is used (invoked) by another
Use Case


Useful if the Use Case includes common functions also used by
other Use cases.
The included Use Case is always performed as part of the
original Use Case

But can also stand on its own
A Sales
System with
<<include>>
relationships
<<include>> arrow points from the base use case to
the included use case.
An <<extend>> Relationship

Two Use Cases may be connected by an <<extend>>
relationship

Extends a Use Case by adding new behaviour or actions
that are not always part of the Use Case

An extend use case cannot stand on its own
A Retail
Sales
System with
<<extend>>
and
<<include>>
relationships
<<extend>> arrow points from the extending use
case to the extended use case.
Include vs. Extend

Use <<extend>> if you want to model an extension to, or
a variation of, a use case.

Use <<include>> if you want to factor the common
behaviour among two or more use cases into a single
generalized use case
Generalization Relationships
Optionally, it
may be useful
to portray a
generalization
(of an actor or
of a Use case).
New patient is a type of
patient.
Use Case Diagram with Extend, Include and Generalization
Make appointment is a
generalization of Make old
patient appt and Make new
patient appt.
Use Case Diagrams

In a Use case Diagram, the only connection between two Use Cases is via
<<extend>>, <<include>> or generalization
store clerk
increase price
rent DVDs
add new DVDs
X
system manager
print updated catalogue
financial system
Levels of Use Cases

A common challenge is identifying use
cases at a useful goal level.

For example, how do we know which of
these is at a useful level?




Negotiate a Supplier Contract
Rent DVDs
Log In
Start Up System
Material sourced from Craig
Larman and Alistair Cockburn
Levels of Use Cases

One answer is that they are all use cases.

Not helpful…
We can end up with too many fine-grained use cases

management and complexity problems.

Or “fat” use cases which span an entire organization.

Guidelines for Use Case Levels

Cockburn supports the Elementary Business Process
(EBP) guideline.

Focus on use cases at the level of EBPs.

“A task performed by one person in one place at one time, in
response to a business event, which adds measurable business
value and leaves the data in a consistent state.”
EBP for Use Case Levels

Naively, you can apply the “boss test” for an Elementary
Business Process

Boss: “What do you do all day?”

Me: “I logged in!”

Is Boss happy?
Guidelines: Size for Use Case
Levels

An EBP-level use case usually is composed of several
steps, not just one or two.

Think in terms of user-level goals.

Stakeholders usually relate to requirements presented in the
form of goals.
Use Case Levels: Applying the
Guidelines

Applying the EBP and size guidelines, which would you
choose as a use case?




Negotiate a Supplier Contract
Rent DVDs
Log In
Start Up System
Use Case Levels: Applying the
Guidelines

Applying the EBP and size guidelines:





Negotiate a Supplier Contract
Rent DVDs
Log In
Start Up System
The others can also be modelled as Use Cases.

But, prefer a focus on the user-goal level.
Definition: Essential & Concrete
(Real) Use Cases



“Keep the User Interface out”
Essential use cases defer the details of the UI, and
focus on the intentions of the actors.
Essential: Clerk enters Customer ID


Good
Concrete: Clerk takes Customer ID card and reads the
bar code with laser scanner.

Not recommended at this stage. Anticipates physical design
decisions about how the process will be done
Use Case Descriptions

Individual Use Cases are described in words: Use Case
Description.

Use Cases are text, not diagrams


Despite the emphasis often given to the diagrams.
A Use Case Diagram just helps in identifying Use Cases by name
and creating a context for the Use Case
Use-Case Descriptions

Describe basic functions of the Use Case
 What the user can do
 How the system responds

Describes one and only one function, but may have
multiple paths.

Content is developed in collaboration with users.

There is no formal specification for a Use Case
Description.
Use-Case Descriptions

Each Use Case has at least one sequence (or flow) that a
user follows when interacting with the system
 eg the “normal” process for withdrawing money from an
ATM

The Use Case may have alternative paths that illustrate
alternative actions
 Typically to cater for exceptions eg the user enters an
incorrect PIN; the user has insufficient funds.

Each path through the Use Case is known as a scenario
Sample Elements of a UseCase Description
Use Case Name:
ID:
Primary Actor:
Use Case Type:
Importance Level:
Stakeholders and Interests:
Brief Description:
Trigger:
Relationships: (Association, Include, Extend, Generalization)
Preconditions:
Normal Flow of Events:
Subflows:
Alternate/Exceptional Flows:
Elements of a Use Case
Description

Title


ID


usually a user role, the trigger for the use case
Stakeholders


Low, High
Primary actor


indentifying number
Importance level


descriptive name, matches name in use case diagram
any group or individual with an interest in the function of the use case
Brief description
Elements of a Use Case
Description

Type



Overview vs Detail
 Overview: a high level view of requirements as agreed between the
analyst and users
 Detail: documents as much relevant information as possible
Essential vs Real
 Essential: only the minimum needed to understand the required
functionality
 Real: describes specific steps in detail
In early analysis, the type is typically overview and essential
Elements of a Use Case Description

Precondition – conditions that must be satisfied in order to
execute the use case;



Where we are up to when the Use Case commences?
eg For a Use Case “Purchase Items” the precondition might be:
Customer has searched the web site and selected at least one
item to purchase
Note: preconditions not shown in textbook’s template (Fig 5-5) for Use case descriptions
Elements of a Use Case Description
Trigger

Each Use case usually has a trigger – an event or action
that initiates the use case


External trigger
 eg a customer placing an order
Temporal trigger
 eg library book overdue
Use Case Elements:
Relationships

Association


Extend


Any uses cases which are extensions of this use case
Include


Actors that are associated with this use case
Any use cases included with this one
Generalization

Whether this is in a hierarchy of use cases
Use Case Elements: Flows

Normal Flows


Sequence of steps that are normally executed in this particular use
case
 Simple, clear steps
 Identify who initiates the step
If flow “includes” other use cases, then specify that use case name
eg
 Step 2: …..
 Step 3: perform “Check Outstanding Fines”
Use Case Elements: Flows

Sub-Flows


The normal flow of events decomposed, if necessary, to keep the
normal flow of events as simple as possible
Alternate or Exceptional Flows


Flows that do happen but are not considered to be the norm
Some of these exceptional flow may cause the use case to end;
others may be recoverable
Larman example: Place an Order
UC 4: “Place an order”
1.
2.
3.
Clerk identifies the customer, each item and quantity
System checks credit
System accepts and queues the order
Extensions:
2a. Low credit: Customer is ‘Preferred’...
2b. Low credit & not Preferred customer: ...
3a. Low on stock: Customer accepts reduced...
Use Case Writing Guidelines
1.
2.
3.
4.
5.
6.
7.
Write in the form of subject-verb-direct object
Make sure it is clear who the initiator of the step is
Write from independent observer’s perspective
Write at about the same level of abstraction
Ensure the use case has a sensible set of steps
Apply the KISS principle liberally.
Write repeating instructions after the set of steps to be repeated
Summary

Examining the goals a system supports makes for good functional
requirements a user can understand

Use Case Diagrams present a graphical overview of the main
functionality of a system.

Use Case Diagrams present a graphical overview of the main
functionality of a system represented by the use cases shown.

A description is developed for each use case shown on the use case
diagram.

Use Case Descriptions detail the interactions of a user with the
system when undertaking a particular function.