Writing Effective Scenarios and Use Cases

Timetable

10.00 Introductions10.10 Strategies for gathering requirements11.00 refreshments11.20 Creating a Scenario12.30 Creating a Use Case13.00 lunch14.00 Creating a Use Case (continued)15.00 Using a Use Case – gathering requirements

15.45 refreshments16.00 Review

Book

• “Writing Effective Use Cases”• Alistair Cockburn

• Page references

• Short, true stories

124

39, 54, 63, 104, 169, 170, 175

Introductions

Strategies for gathering requirements - Introduction

Charles Duncan, IntrallectC.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

• 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

Structure

Project, System, Service

Use case Use case Use case Use case

Use case

ScenarioAction stepAction stepAction stepAction stepAction stepAction 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 caseGoal: Teacher locates a learning object in a repository and uses it in another web site

Primary actor: TeacherOther actors: repository, authentication system, web site Main success scenario:1. Teacher logs into repository with ATHENS authentication2. Teacher searches for object by keywords 3. Teacher identifies suitable object4. Teacher obtains reference to object5. Teacher uses reference in web siteOther 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 - ExperiencesEd Barker Digital Rights ManagementPeter Douglas Learning Activity DesignCharles 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– 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

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