Review of Scenarios and Use Cases Richard Hopkins UML for Use Cases

advertisement
Review of Scenarios and Use Cases
Richard Hopkins
rph@nesc.ac.uk
UML for Use Cases
NeSC, Edinburgh, Jan 5/6 2006
Content
Goals
To understand Scenarios and Uses Cases

Their Role

Their Structure
Content
What are Scenarios and Use Cases?
How do I Write a Use Case?
Why?
Practical
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
2
Requirements
Scenarios and Use Cases
Express behaviour of a system
Primarily a requirements tool
system exists to satisfy requirements of its stakeholders
the behaviour is an example of what the stakeholders want
the to do
Goal-oriented
the behaviour expressed is to achieve a goal
Role-oriented
Expressed in terms of “Actors”, some entity playing role

entity – human / a system
Primary actor – the one who requests the behaviour
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
3
The Structure
System
Scenario
Use case
case
Use
case
Use
Use Case
case
Use
narrative describing how an
actor achieves a goal
through a series of action steps
Scenario
Action
Action
Action
Action
Action
Action
step
step
step
step
step
step
Action Step
Single active-verb
phrase/sentence
Use Case
Collection of Scenarios
expressing all possible
behaviours as actor tries to
achieve goal
System
A full set of Use Case gives the
behavioural requirements
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
4
Example - Scenario
Alan, a maths lecturer, uses a learning object repository
to find a simulation of the behaviour of an equation. He
logs in using his Athens account, searches using suitable
keywords, finds the object and obtains a reference to
the object that he uses in the class web site. He
demonstrates the simulation in a lecture by using the
class web site.
Written for an imaginary person’s viewpoint – very
specific
Defines key stakeholder (primary actor) and his goal
Motives and emotional content
Describes usage, not requirements
Lists the action steps in a narrative text
Describes a single path – usually the main success path
Informal – plain English loosely structured
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
5
More Structured Scenario
Goal: Teacher locates a learning object in a repository and uses
it in another web site
Primary actor: Teacher
Other actors: repository, authentication system, web site
Action Steps
1. Teacher logs into repository with ATHENS authentication
2. Teacher searches for object by keywords
3. Teacher identifies suitable object
4. Teacher obtains reference to object
5. Teacher uses reference in web site
Explicitly identify- actors, goal, individual steps
Still just one path – Use Case can combine this with variants
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
6
Example - Use Case
Goal: Teacher locates a learning object in a repository and uses
it in another web site
Primary actor: Teacher
Other actors: repository, authentication system, web site
Main success scenario:
1. Teacher logs into repository with ATHENS authentication
2. Teacher searches for object by keywords
3. Teacher identifies suitable object
4. Teacher obtains reference to object
5. Teacher uses reference in web site
Other scenarios (extensions):
1a. Teacher’s authentication initially refused (s)
1b. Teacher authenticates using a local LDAP authentication (s)
3a. Teacher cannot find suitable object (f)
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
7
Example - Use Case
Goal: Teacher locates a learning object in a repository and uses
it in another web site
Primary actor: Teacher
Other actors: repository, authentication system, web site
Main success scenario:
1. Teacher logs into repository with ATHENS authentication
2. Teacher searches for object by keywords
…
Other scenarios (extensions):
1a. Teacher’s authentication initially refused
1a1. Teacher requests new password
1a2. Teacher receives new password
(return to step 1)
1b. Teacher authenticates using a local LDAP authentication
3a. Teacher cannot find suitable object
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
8
Use Case / Scenario Notes
A Use Case
Is a collection of Scenarios, expressing all possible
behaviours as actor tries to achieve goal –

Covers all success and failure variants

May combine similar Scenarios into one Use Case

Can have complex, nested, structure
Formal structure
Constitutes a contract for behaviour
But may start as an incomplete, single-scenario, use case
Scenarios
less formal structure
Easier to gather from non-technical groups
Useful for discussion, but incomplete – not a contract
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
9
How To Write A Use Case
Goals
To understand Scenarios and Uses Cases

Their Role

Their Structure
Content
What are Scenarios and Use Cases?
How do I Write a Use Case?
Why?
Practical
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
10
Collect Scenario(s)
Peter is working on a project that is developing a
multimedia online resource based on a
performance of a Shakespeare play.
While gathering the materials that will go into
the resource Peter obtains some photographs.
He gets permission from the photos’ rights
holder for the photos to be used in an
educational context by other users.
Peter puts the photos into a digital repository,
complete with the rights associated with them.
The photos are now available for others to use.
Peter works for Linlithgow University and they
are very concerned that any rights are not
contravened.
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
Notecontext
as well
as
actions
11
Write Use Case Summary
Write a Use Case Summary
The primary actor and goal – 1 sentence
Context - other stakeholders
Use Case Summary
A research project wants to create a multimedia online resource
based on a Shakespearian performance.
All contributors must have digital rights acknowledged when
material is reused and reuse must be limited to educational
purposes.
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
12
Identify Actors / Stakeholders
Actors - participants
people, systems, organisations
always representing some role
Stakeholder
A no-participant actor with a vested interest
e.g. copyright holder
“An actor entitled to have its interests protected by the
system, and satisfying those interests requires the system
to take specific action [in this Use Case]”
For any action step - that behaviour must be there
to further the goal of a participating actor
and/or
to protect rights of a stakeholder
Otherwise –
the behaviour is redundant
an actual stakeholder has not been explicitly named
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
13
Identify Actors / Stakeholders
Primary Actor (and goal)
Research
Project
To produce a high quality learning resource that
can be used by others
Other Actors (and goals)
User
To access materials for educational use
Repository
To facilitate access within educational context
Stakeholders and Interests
Photographer
To protect rights for his/her work
(rights holder)
Funders of
Project
To ensure resource is disseminated to
eductational users
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
14
Write Main Success Scenario
Sentences should be in sequential order
each sentence should have an actor performing an action (pg 90)
Main Success Scenario
1 Research project obtains permission from rights holder for reuse of material under clearly stipulated conditions (i.e. for
educational use)
2 Research project digitises photograph and adds relevant
metadata including rights statement
3 Research project deposits collection and metadata within
digital repository
4 The repository automatically propagates metadata to other
catalogues with educational context
5 User identifies existence and location of resource and
conditions under which it may be used
6 The user sees and agrees to conditions of use
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
15
Writing Extensions
An extension is an alternative route within a scenario
Start with condition under which extension occurs; then
explain steps
Extension can result in success or failure
Extensions
1a
Rights holder demands more stringent restrictions
1a1
Use ATHENS authentication
1b
Rights holder stipulates end date after after which
agreement must be reviewed
1b1
Metadata element flags up termination of agreement date
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
16
Pre- / Post- Conditions
Preconditions - The system will ensure that this is true
before letting the Use Case start
Postcondition – The system will ensure that this is true
after the use case has completed
Minimal Guarantees – about failure to deliver the goal
Success Guarantees – in addition to the minimum
Preconditions
User is part of the community of subscribers to
the learning repository
Minimal
Guarantees
The system has logged how far it got
Success
Guarantees
The systems has a record of the user agreeing to
the conditions of use
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
17
Iteration
put in a repetition pseudo step
1 Research project obtains permission from rights holder for reuse of material under clearly stipulated conditions (i.e. for
educational use)
2 Research project digitises photograph and adds relevant
metadata including rights statement
Research project repeats steps 1-2 for all photographs
3 Research project deposits collection and metadata within
digital repository
…
pseudo step could go first – but after is usually easier to
understand
could also have pseudo step – “steps n-m can happen in any
order”
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
18
What Use Cases are for
Goals
To understand Scenarios and Uses Cases

Their Role

Their Structure
Content
What are Scenarios and Use Cases?
How do I Write a Use Case?
Why?
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
19
For Communicating Behavioural
Requirements
Scenario is something that user can write – how they
want the system to work
short
right level of detail
easy to understand
Use case is an elaboration of that covering all variations
Will give rise to questions – what happens if … ?
Can be used to feed-back to user
Ends up as a contract between the system supplier and
all the stakeholders – that’s the point
Can be used as basis for testing
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
20
Not For Other Requirements
Not for
Interface Design
“library-joiner enters name and contact details”
designing the interface is a separate activity
Business Rules
Performance
Prioritisation
….
These need to be separately documented
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
21
Needs Context
Purpose and Scope
The overall purpose of the system
Identifying the stakeholders
What is in scope and what is out of scope

e.g. are we talking about the whole system
including human roles, or just a computer system
Collecting the scenarios will help articulate purpose and
scope –
implicit assumptions
explicit questions
These then need to be separately documented as context
for the Use Cases
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
22
Questions?
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
23
Content
Goals
To understand Scenarios and Uses Cases

Their Role

Their Structure
Content
What are Scenarios and Use Cases?
How do I Write a Use Case?
Why?
Practical
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
24
Practical - Groups
TRAINING ROOM
Group A
Group B
Group C
Richard Green
Alan Tonge
James Reid
Tim Riley
Jackie Proven
Jenni Squire
David Dripps
Julie Allinson
Mahendra Mahey
Simon Lamb
Philip Turbitt
MEETING ROOM
Group D
Group E
Group F
John Casey
Philip Hunter
Rachel Heery
Sara Currier
Pete Johnston
Graham Pryor
Chris Higgins
Eddie Boyle
Jim Downing
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
25
Practical –
Working with Scenarios and Use Cases
Creating a Single-Scenario Use Case
40 Mins – Create it
Need a scenario with potential for variations /
extensions and multiple actors (systems) involved
For 4-person group – possibly split into two 2-person
groups
One approach would be to spend first 5 – 10 mins
individually thinking up a scenario, then group
discusses which to develop
15 Mins – Discuss the process
feed back
common issues
UML for Use Cases, Jan 5/6 2006
Review of Scenarios and Use Cases
26
Download