usecase presentation
TRANSCRIPT
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
Copyright e-Government Program (Yesser)
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 tasko You consider a complete work task, initiated by
an actoro You utilise ”company language” in describing the
work tasko The aggregate Use Cases display the aggregate
actor use of the system
Copyright e-Government Program (Yesser)
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)
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!)
Copyright e-Government Program (Yesser)
Why use use cases? Use case strengths are
o That they work well as an analytical toolo That the notation is simple and easy to pick upo That they are easy to understand, both for the business and from
the technological aspecto It is a widely recognised market standardo 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!
Copyright e-Government Program (Yesser)
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
Copyright e-Government Program (Yesser)
UML - Use case diagram
Copyright e-Government Program (Yesser)
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
Copyright e-Government Program (Yesser)
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
Copyright e-Government Program (Yesser)
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 process
Copyright e-Government Program (Yesser)
Age
ncy
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
Copyright e-Government Program (Yesser)
Draw use case packages1. 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
Copyright e-Government Program (Yesser)
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
Copyright e-Government Program (Yesser)
Draw use case diagrams2. 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)
Copyright e-Government Program (Yesser)
Use Case Example
Copyright e-Government Program (Yesser)
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 actors3. Identify actors - for each use case
o 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)
Copyright e-Government Program (Yesser)
Complete verbal description4. 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)
Copyright e-Government Program (Yesser)
Use cases – Verbal description
Copyright e-Government Program (Yesser)
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) Copyright e-Government Program (Yesser)
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-definedCopyright e-Government Program (Yesser)
Identify variants and exceptions5. Identify all variants and exceptions and
firm up the start and end conditionso 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?
Copyright e-Government Program (Yesser)
Audit business process and term model After completion of use cases (or during) a
need will often rise to adjust the process diagramso You gain knowledge as you dig deeper into the
materialo The activities (and their order) may need
adjustmento 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 modelCopyright e-Government Program (Yesser)
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 tasko 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!)
Copyright e-Government Program (Yesser)
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 aspectso Has an idea of how a use case can be technically realisedo Can discuss issues with the technical staff
Copyright e-Government Program (Yesser)