© 2000 Ian Alexander - Introduction to Scenarios Introduction to Scenarios A range of techniques...

© 2000 Ian Alexander - Introduction to Scenarios

Introduction to Scenarios

A range of techniques for engineering better systems

Ian [email protected]

version 0.0 30 September 2000


What is a Scenario?

• A concrete scenario involves specific actors, places, and times:

John sets the alarm and locks the door at 8 a.m. The alarm … • An abstract scenario describes what happens in

generic (class) terms: The Householder sets the alarm, locks the door, …

• Simplest kind of (abstract) Scenario is a straight path from start to finish, one step after another

• More complicated kinds are possible


How to Represent Scenarios?

• Absolutely no agreement• Text, Diagrams, Video, Animations, Cartoons,

Storyboards, Acted Scenes, Collaborative Workshops (passing a ball or a talking stick), etc

• Different representations may well be useful in specific situations

• Some 'methods' are quite ideological about notations, others not at all


1. UML Use Cases• supposes that the world

of business is divided into neatly addressable cases where a user interacts with a system

• the vertical list does not imply sequence (oh yes it does)

• no defined way of organizing cases

Read Balance

Withdraw £50

Order Chequebookcustomer


The Claim: Step-by-Step Development with Use Cases

• Driving force behind concept was crisis in Software• Jacobson's idea was to use scenarios as candidate

chunks for separate implementation• Not ideal for 10,000 overlapping use cases ...

time time

customersatisfaction

waterfallproject

use caseproject

deliveries

delivery


Scenario = Use Case?

• Depends whose definition of Use Case you use• Some Use Cases are Concrete• Some insist on exactly one Actor• Some talk about use of a specific System• UML notation can be helpful,

but only goes part of the way


2. Agent Model

• useful before collecting scenarios

• identify stakeholders & their conversations

• helps to focus attention on what is in scope


3. Sequence Diagram

• simple notation

• clear, easy to read

• actors get full weight

• single or multiple threads


4. Goal or Task Model

• encourages thinking about alternative ways of satisfying a goal

• may help to find exceptions before they cause problems


5. Traditional Flowchart

Specify

Design

Make

Build

Test

Analyse

? n

y

Design Rig

Make Rig

• old notation• still useful• remains popular in

business process modelling

• UML flowcharts have different symbols, same effect

• can be combined with swimlanes background


6. Many other Representations

• for instance, storyboards can describe situations, roles, & task sequences quickly and compactly

• may have advantages, e.g. for multi-national products• have long been used in planning film shoots• animations, video, acted scenes can all be helpful


How Can Scenarios Help?

• describe business processes• clarify system scope• identify stakeholders, situations, needs• organise requirements• guide design and coding• provide scripts for testing• improve project communications


Understanding Business Processes

• for instance, a scenarios workshop can represent a sequence of tasks directly by roleplay

1

token

user states role & activity,identifies next user(s),throws token(s)

next user statesrole, activity…


Organising Specifications

• scenario steps are ideal placeholders for requirements (functions and constraints)

• they set requirements in context of what came before, what comes next

• and allow for hierarchical document structure


Verifying Requirements• scenarios can be

animated e.g. from goal models

• users can see what systems would do, if built, and correct any mistakes or omissions

• allows systems to be 'tested' before they are designed


Guiding Design

• numerous 'Scenario-Based Design' approaches• developers are often unable to speak directly to

system users• scenarios offer a valuable echo of 'the voice of the

customers'• scenarios show what each small part of a system

actually needs to do … to deliver the results that system users want


'Extreme Programming'

• uses scenarios in the form of 'user stories'• acceptance tests are written straight from the

scenarios – and used as specifications!• programs written and tested directly from the user

stories• accompanied by pair programming and other

practices• but even anarchists may have good ideas


Generating Test Cases• Any scenario path through the requirements is a

possible test case ('000s of them)• Need to cover

– all requirements at least once

– all major paths (familiar problem to testers!)

• Need to select "interesting" cases• Need to add test attributes (for each Step)

– Criteria, Result, Tester, Date, ...


Test Cases from Scenarios

• Scenarios and Test Cases both describe the results users want to see

• Acceptance Test Cases provide a format for recording desired and actual results

• Test Case generation can be partly automated but usually needs judgement to select efficient tests

ScenarioTest

AttributesTest Case+ =


Scenarios vs Test CasesScenario

• says what result is wanted

• may branch, have alternatives, allow parallel steps, ...

• defines preconditions, actors, systems, ...

Test Case

• says what result is wanted

• must consist of definite and repeatable steps

• defines criteria for accepting/rejecting

• provides slots for pass/fail, tester, date


Example: Scenario,Test StepScenario Step

• Detect flying insect (without sounding alarm)

Test Step

• Action: – Release flying bee (length 1 cm)

into sensor test room

• Desired Response:– Detect flying insect

• Acceptance Criteria: – bee is detected within 15 seconds– alarm does not sound

• Result Pass• Tester IFA• Date 18 Aug 2000


Summary: Scenarios ...

• have many uses in systems engineering, e.g.– process description

– requirements elicitation and verification

– system specification

– guidance for system design and software coding

– basis of test scripts

• can be represented in varied and useful ways• provide neutral languages in which stakeholders

can describe their needs to developers• could with benefit be applied much more often?

© 2000 Ian Alexander - Introduction to Scenarios Introduction to Scenarios A range of techniques...

Documents

Transcript of © 2000 Ian Alexander - Introduction to Scenarios Introduction to Scenarios A range of techniques...