© 2000 Ian Alexander - Introduction to Scenarios Introduction to Scenarios A range of techniques for engineering better systems Ian Alexander version September 2000

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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 Chequebook customer

© 2000 Ian Alexander - Introduction to Scenarios 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...

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 2. Agent Model useful before collecting scenarios identify stakeholders & their conversations helps to focus attention on what is in scope

© 2000 Ian Alexander - Introduction to Scenarios 3. Sequence Diagram simple notation clear, easy to read actors get full weight single or multiple threads

© 2000 Ian Alexander - Introduction to Scenarios 4. Goal or Task Model encourages thinking about alternative ways of satisfying a goal may help to find exceptions before they cause problems

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios Understanding Business Processes for instance, a scenarios workshop can represent a sequence of tasks directly by roleplay

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios 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

© 2000 Ian Alexander - Introduction to Scenarios '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

© 2000 Ian Alexander - Introduction to Scenarios 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,...

© 2000 Ian Alexander - Introduction to Scenarios 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 Scenario Test Attributes Test Case +=

© 2000 Ian Alexander - Introduction to Scenarios Scenarios vs Test Cases Scenario 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

© 2000 Ian Alexander - Introduction to Scenarios Example: Scenario,Test Step Scenario 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

© 2000 Ian Alexander - Introduction to Scenarios 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?