Writing Effective Scenarios and Use Cases

1
Writing Effective Scenarios and Use Cases
2
Timetable

• 10.00 Introductions
• 10.10 Strategies for gathering requirements
• 11.00 refreshments
• 11.20 Creating a Scenario
• 12.30 Creating a Use Case
• 13.00 lunch
• 14.00 Creating a Use Case (continued)
• 15.00 Using a Use Case gathering requirements
• 15.45 refreshments
• 16.00 Review

3
Book

• Writing Effective Use Cases
• Alistair Cockburn
• Page references
• Short, true stories

124
39, 54, 63, 104, 169, 170, 175
4
Introductions
5
Strategies for gathering requirements -
Introduction

• Charles Duncan, Intrallect
• C.Duncan_at_intrallect.com

6
Why use scenarios and use cases?

• Scenarios and Use Cases are not an end in
  themselves, they are for
• Eliciting requirements (e.g. of software systems)
• Modelling business processes
• Drafting or sizing system requirements
• Writing functional requirements
• For a small (short-timescale) project
• For an iteration in a larger project
• In all cases they are a basis for communication
  and discussion

132
7
Glossary

• Important to share a common vocabulary
• See handout
• See book
• Important terms
• Action step Single active-verb phrase/sentence
• Actor Someone playing a role (e.g. teacher,
  student)
• Scenario Narrative describing how an actor
  achieves a goal through a series of action steps
• Use Case Collection of scenarios, expressing all
  possible behaviours as actor tries to achieve goal

253-256
8
Structure
Project, System, Service
Use case
Use case
9
Example action step

• Alan (teacher) logs into repository using ATHENS
  authentication
• Other actions may achieve the same result
• This action may result in success or failure
• This high-level action step could be defined in
  much more detail in a use case of its own

10
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.
• Describes usage, not requirements
• Defines key stakeholder (primary actor) and his
  goal
• Lists the action steps in a narrative text
• Scenarios are often written to reflect success

11
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. Teachers
authentication refused (fail) 1b. Teacher
authenticates using a local LDAP authentication
(s) 3a. Teacher cannot find suitable object (f)
12
Use Case points to note

• Expresses behaviour of the system in response to
  the primary actor trying to achieve the goal
• Takes account of different success and failure
  scenarios
• Identifies all actors systems, as well as
  people
• Use cases can be
• User-goal
• summary (involving many user goals over a
  prolonged period)
• sub-function (low-level detail, e.g. how
  authentication is implemented)

13
Use Cases versus Scenarios

• Use cases and scenarios are not alternative
  approaches they are different stages of the
  same approach
• Scenarios are easier to gather from non-technical
  groups, but they often only describe success
• Use cases gather common scenarios (those that use
  largely the same action steps) but also handle
  all the success and failure extensions
• Scenarios without use cases are useful for
  discussion but are incomplete for expressing
  behaviour. Use Cases are contracts for behaviour

14
Strategies for gathering requirements -
Experiences

• Ed Barker Digital Rights Management
• Peter Douglas Learning Activity Design
• Charles Duncan Agile Software Development

15
Digital Rights Management

• Project Details
• funded by JISC and completed in November 2004
• The aim was to determine the best approaches for
  JISC and the UK education and research
  communities to adopt in relation to DRM
• http//www.intrallect.com/drm-study/
• Use cases were produced from five workshops
  Produced 32 detailed use cases and 125 use case
  summaries.
• Key Points
• Objective was very wide
• There was uncertainty about processes and
  stakeholders

16
Methodology

• Explain aims of project and how they relate to
  the aims of the workshop (45 minutes)
• Explain the methodology for producing use cases
  (45 minutes)
• Attendees worked in pairs to create a full use
  case
• Attendees given time at end of workshop to ask
  questions and make further points

17
Results and Analysis

• Use Cases were anonomised and included in final
  report.
• Statistics about primary actors and objectives
  were collected.
• A set of requirements were extracted from the use
  cases

18
Strengths and Weaknesses

• Strengths
• Allowed us to identify the main concerns of the
  community
• Captured user requirements in a technology
  independent way
• Allowed each person at workshop to have input to
  the study
• Weaknesses
• Requirements gathering is open to interpretation.
• Some use cases were a bit vague or away from the
  point.
• Time Consuming

19
LADiE

• Project Details
• Learning Activity Design in Education
• funded by JISC and to be completed in March 2004
• The aim is to develop a Reference Model for
  Learning Activities based on the principals of
  the eFramework
• http//www.elframework.org/refmodels/ladie/
• Key Points
• Scope of domain is very wide
• Wanting to encourage imaginative/innovative
  learning activities

20
Methodology

• Same as DRM project!
• Held one workshop which was not a success
• Confusion between delivering learning activity
  with creating a learning activity
• Use Case generation proved difficult - where is
  the student?
• Tried to achieve too much in one day
• Conclusion?
• Tutors not the ones to write the use cases, but
  they do have useful information to provide

21
What we are doing now

• Holding workshops with tutors, but focusing on
  capturing the structure of the learning activity.
• Project team uses this information to generate
  more formal Use Cases
• Some use cases coming in directly from
  groups/projects

22
Agile Software Development

• NOT the waterfall method
• User requirements, specification, development,
  testing, installation
• Small iterations, XP
• Define usage (scenarios/stories), create tests
  for usage unit, develop only necessary code, run
  unit tests, integrate unit into system, run all
  tests, working system exists
• Scenarios/stories are written throughout the
  project lifecycle, not just at the start

187, 223-224
23
Example story
24
Example tests
25
Pros and Cons

• Pros
• Fast, well-tested, always a working system
• Only essential code is produced
• Flexible can change priorities each iteration
• Rapidly builds huge test bank
• Dynamic balance of resources, time, requirements
• Stories can be used for effort estimation and
  prioritisation
• Cons
• Not so suitable for database and user-interface
  design
• Periodic refactoring (revision) is needed to
  improve structure (but tests are invaluable at
  this stage)

26
Use cases?

• Scenarios are short, light narratives, enough for
  the customer and the developer to agree on what
  is needed
• Tests are where the behaviour is handled, again
  defined in a way that allow the customer and
  developer to agree what needs to be satisfied to
  recognise that the scenario behaves as expected