Writing Effective Scenarios and Use Cases

							Writing Effective Scenarios and
Use Cases
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
Book

• “Writing Effective Use Cases”
• Alistair Cockburn

• Page references       124

• Short, true stories   39, 54, 63, 104,
                        169, 170, 175
Introductions
Strategies for gathering
requirements - Introduction
     Charles Duncan, Intrallect
     C.Duncan@intrallect.com
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
Glossary

• Important to share a common vocabulary
• See handout
• See book      253-256

• 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
Structure
  Project, System, Service
        case
    Usecase
       case
   Usecase
   Usecase
  Use
  Use
                Scenario
                Action   step
                Action   step
                Action   step
                Action   step
                Action   step
                Action   step
                                Use case
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
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
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 refused (fail)
1b. Teacher authenticates using a local LDAP authentication (s)
3a. Teacher cannot find suitable object (f)
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)
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”
Strategies for gathering
requirements - Experiences
Ed Barker        Digital Rights Management
Peter Douglas    Learning Activity Design
Charles Duncan   Agile Software Development
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
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
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
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
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
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
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
Agile Software Development

• NOT the waterfall method
  – User requirements, specification, development,
    testing, installation
• Small iterations, XP              187, 223-224
  – 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
Example story
Example tests
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)
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