Use Case

Use Case - Summary Slide

Use Cases Definition

The purpose of use cases

Why use use cases?

UML - Use case diagram

UML use cases Actors
Example of use case diagram
Use case definition + description - the process

Draw use case packages

Grouping of business functionality Use case packages

Draw use case diagrams

Identify actors
Complete verbal description
Use cases Verbal description
Identify variants and exceptions
Audit business process and term model
2

Use Cases Definition

A Use Case is a way of using a system
o

A scenario that describes limited interaction

between a system and actors in the field

In a Use Case, you describe the use of a

system for a given work task
o

You consider a complete work task, initiated by an

actor
You utilise company language in describing the
work task
The aggregate Use Cases display the aggregate
actor use of the system
3

The purpose of use cases

The purpose for using use cases is to
o

Uncover and describe all tasks that need doing in a system (of
both human and system actors)

To analyse what functionality that need developing for the system

The use of use cases must mean that the right functional
requirements are made of the IT system (the requirements of the
business!)

Why use use cases?

Use case strengths are
o

That they work well as an analytical tool

That the notation is simple and easy to pick up

That they are easy to understand, both for the business and from the
technological aspect

It is a widely recognised market standard

That customer and supplier or operators and technicians can

jointly work out and understand the operational functionality

They bring structure, and ensure complete analysis

The challenge, then, is to find and describe all use cases!

Use cases are documented in two ways

Use Case diagrams
o

o
o

Give an overview of visible use scenarios in the

system
Describes what actors that interact with the system
Describes any linkages between use cases

Verbal description
o
o

Describes the content of each use case

Typically uses a pre-defined template

UML - Use case diagram

Construction elements:

Definition:
o

diagram which provides an

overview of system functionality
Shows which use cases the
individual actor uses

Purpose:
o

To analyse the functionality the

system must include
To give an overview of the
functionality and how it is linked
To analyse how the actors should
use the system

Challenges:
o

To simplify the complex

Package
Package name

Use case
No. and use
case name

Communication arrow

extends

Extends a use case

<<include>>

Includes a use case

UML use cases Actors

Actor:
o

Person (or system), which

uses the system (think in
terms of roles)

Purpose:
o

Construction
elements:

Aktr

Actor

To analyse which actors will

use the system
To analyse how the use of
the actors is linked

Challenges:
o

It is NOT an organisational
chart (no organisational
linkages required)

Specialisation /
Generalisation

Example of use case diagram

Web store

Actor
(person)

Free search
Find an
item
Customer

Structured
search

<<include>>

Order an
item

<<extend>>

Order fast
delivery

Actor
(system)

SADAD

Registered
customer

Check
order
use case

Use case definition + description - the process

Initial state:
- A stakeholder analysis has been performed
- Processes have been modeled

Final state:
- All use cases identified and documented

Draw
use case
packages

Audit business
process
and term model

Agency

Draw
use case
diagrams

Link to:
-Business Process
-Term modeling
Identify
actors
Complete
verbal
descriptions

Identify variants,
exceptions,
and start &
end conditions
no

10

All
Use Cases
Finished ?

yes

Prerequisites
Always begin by making a stakeholder analysis! (In case it
has not been done during process modelling)
o
o
o

A good way of discovering new use cases

A high degree of confidence that all relevant use cases are included
The use case actors are often only part of the overall pool of
stakeholders

11

Draw use case packages

1. Draw use case packages - for each business process
o
o
o

Base it on the processes

Has a thorough stakeholder analysis been done?
Put all actors for each business process on the packages

12

Grouping of business functionality Use case packages

Use case packages divide use cases into packages that make
business sense

Typically, cases that belong to a given process

But it could also be use cases in a given topic / with particular
actors / other

The packages help to provide overview

If a documentation tool is used,

use cases may be organised as illustrated

13

Draw use case diagrams

2. Draw use case diagrams - for each package
o

Which of the process diagram activities are relevant to the

solution?
An activity in a process corresponds to a use case (using this
method)

14

Use Case Example

Use case diagram:
Work Permit

Work Permit

Request Work Permit

Employee
View decision

MoL new solution

Process request

SADAD
Company HR officer
Payment

MoI system

15

Identify actors
3. Identify actors - for each use case
o
o
o
o

Who or what initiates the use case?

Split the actors into roles (not e.g. according to organisational dependence)
Any specialisations of an actor?
Split the actors into those that initiates (triggers) a use case, and those that
are passive actors (e.g. received data)

16

Complete verbal description

4. Complete verbal description - for each use case
o
o
o

What is the purpose of the use case?

What needs to be done for the use case to begin? (start conditions)
Describe the steps in the use case
o What does the actor do? How does the system react?
What is the result of the use case? (end conditions)

17

Use cases Verbal description

18

Use Case - verbal description

There is no standardised notation for how a
use case is described, verbally
The description typically includes:

The Use Case name

Purpose
Actors
Start conditions (premises)
Description of the use case steps
Any exceptions
Any variants
End conditions (result)
19

Use cases Verbal description

Use case descriptions always include a highway

And may contain both variants and exceptions

The highway describes:

The way the use case is typically run through

Variants describe:

Alternative ways the use case may be run through

The highway and variants can be equally important
Start and end conditions will be common with the highways

Exceptions describe:

Events that cause failure to perform use case as described

I.e. end conditions are not met

- Start and end conditions are often under estimated!

Make sure they are precise and well-defined

20

Identify variants and exceptions

5. Identify all variants and exceptions and firm up the start and
end conditions
o
o
o

What alternative routes would complete the use case?

Any exceptions that would make the use case stop?
Review the start and end conditions once again
- Are they precise and well-defined?
- Have all variants been considered?

21

Audit business process and term model

After completion of use cases (or during) a need will often
rise to adjust the process diagrams
o

You gain knowledge as you dig deeper into the material

o The activities (and their order) may need adjustment
o You typically discover new actors/roles and new interfaces with other
systems / stakeholders

Need to add new terms to the term model

o

And maybe correct the use case descriptions to ensure strict use of
the terms in the term model

22

Use cases best practice

The grain of use cases what is the right size for a use
case?
o

o
o

A UC must contain a complete task that needs solving not just a

step in a task
Well-defined start and end conditions
Feel your way forward it takes experience!

The aggregate use cases do not need to reflect a workflow!

o

If you do that, the use cases may well be too fine-grained

Naming a UC use imperative verbs!

o
o

E.g. Acquire car Search for car Get FDM test etc.
A good idea to attach numbers to the use cases (not meaningful
IDs!)
23

Definition of use cases - tips

Know your business!
o
o

Be business oriented
The professional experts must participate in the completion of use cases

Keep matters abstract

o
o

Describe functionality not solution designs

Keep use case descriptions free from computer monitor-thinking

Requirement specification with creativity and visions

o

It is important that project participants are visionary and do not re-create

existing solutions

You may want a resource able to coordinate business and technical

aspects
o
o

Has an idea of how a use case can be technically realised

Can discuss issues with the technical staff
24