Use Case. 2 Copyright e-Government Program (Yesser) Use Case - Summary Slide Use Cases – Definition The purpose of use cases Why use use cases?

Use Case

Copyright e-Government Program (Yesser) 2

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


Use Cases – Definition

A Use Case is a way of using a systemo 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

o You utilise ”company language” in describing the work task

o The aggregate Use Cases display the aggregate actor use of the system


The purpose of use cases

The purpose for using use cases is too Uncover and describe all tasks that need doing in a system (of

both human and system actors)

o To analyse what functionality that need developing for the system

o 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 areo That they work well as an analytical tool

o That the notation is simple and easy to pick up

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

technological aspect

o It is a widely recognised market standard

o That customer and supplier – or operators and technicians – can

jointly work out and understand the operational functionality

o 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 diagramso Give an overview of visible use scenarios in the

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

Verbal descriptiono Describes the content of each use case o Typically uses a pre-defined template


UML - Use case diagram

Definition:o diagram which provides an

overview of system functionalityo Shows which use cases the

individual actor uses

Purpose:o To analyse the functionality the

system must includeo To give an overview of the

functionality and how it is linkedo To analyse how the actors

should use the system

Challenges:o To simplify the complex

Construction elements:

Package

Use case

Communication arrow

Extends a use case

Includes a use case

No. and use case name

Package name

«extends»

<<include>>


UML use cases – Actors

Actor:o Person (or system), which

uses the system (think in terms of roles)

Purpose:o To analyse which actors will

use the systemo To analyse how the use of

the actors is linked

Challenges:o It is NOT an organisational

chart (no organisational linkages required)

Construction elements:

Actor

Specialisation /Generalisation

Aktør


Example of use case diagram

Web store

Find an item

Order an item

Check order

Customer

Registered customer

SADAD

Order fast delivery

Free search

Structured search

<<include>>

<<extend>>

Actor (person)

Actor (system)

use case


Use case definition + description - the processA

gen

cy

Drawuse casediagrams

Complete verbaldescriptions

Identifyactors

Draw use casepackages

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

Final state:- All use cases identified and documented

AllUse CasesFinished ?

yesno

Audit businessprocessand term model

Link to:-Business Process-Term modeling

Identify variants,exceptions, and start &end conditions


Prerequisites

Always begin by making a stakeholder analysis! (In case it has not been done during process modelling)o A good way of discovering new use caseso A high degree of confidence that all relevant use cases are includedo The use case actors are often only part of the overall pool of

stakeholders


Draw use case packages

1. Draw use case packages - for each business processo Base it on the processeso Has a thorough stakeholder analysis been done?o Put all actors for each business process on the packages


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


Draw use case diagrams

2. Draw use case diagrams - for each packageo Which of the process diagram activities are relevant to the

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

method)


Use Case Example

Use case diagram: ”Work Permit”

Work Permit

View decision

Process request

Company HR officer

Payment

MoL new solution

MoI system

SADAD

Request Work Permit

Employee


Identify actors

3. Identify actors - for each use caseo Who or what initiates the use case?o Split the actors into roles (not e.g. according to organisational dependence)o Any specialisations of an actor?o Split the actors into those that initiates (triggers) a use case, and those that

are passive actors (e.g. received data)


Complete verbal description

4. Complete verbal description - for each use caseo What is the purpose of the use case?o What needs to be done for the use case to begin? (start conditions)o Describe the steps in the use case

o What does the actor do? How does the system react?o What is the result of the use case? (end conditions)


Use cases – Verbal description


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)


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


Identify variants and exceptions

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

o What alternative routes would complete the use case?o Any exceptions that would make the use case stop?o Review the start and end conditions once again

- Are they precise and well-defined?

- Have all variants been considered?


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 materialo 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 modelo And maybe correct the use case descriptions to ensure strict use of

the terms in the term model


Use cases – best practice

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

o A UC must contain a complete task that needs solving – not just a step in a task

o Well-defined start and end conditionso 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 E.g. ”Acquire car” – ”Search for car” – ”Get FDM test” – etc.o A good idea to attach numbers to the use cases (not meaningful

IDs!)


Definition of use cases - tips

Know your business!o Be business orientedo The professional experts must participate in the completion of use cases

Keep matters abstracto Describe functionality – not solution designso Keep use case descriptions free from ”computer monitor-thinking”

Requirement specification with creativity and visionso 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 Has an idea of how a use case can be technically realisedo Can discuss issues with the technical staff

Documents

Use Case. 2 Copyright e-Government Program (Yesser) Use Case - Summary Slide Use Cases – Definition The purpose of use cases Why use use cases?