Ian Alexander

This is a short summary
based on my (10,000 word) Introduction to the book
'Scenarios, Stories, Use Cases
Through the Systems Development Life-Cycle'
edited by Ian Alexander & Neil Maiden, John Wiley 2004

Full Version

Scenarios are a powerful antidote to the complexity of system development. Telling stories about systems helps to ensure that project stakeholders share a sufficiently wide view to avoid missing vital aspects of problems. Scenarios vary from brief stories to richly-structured analyses, but are almost always based on the idea of a sequence of actions carried out by intelligent agents. People are very good at reasoning from even quite terse stories, detecting inconsistencies, omissions, and threats with little effort. These innate human capabilities give scenarios their power. Scenarios are applicable to systems of all types, and may be used at any stage of the development life-cycle for different purposes.

"Scenarios are arguably the starting point for all modelling and design" (Alistair Sutcliffe). They allow us to take a backward glance. They use a simple, traditional activity – storytelling – to provide a vital missing element, namely a view of the whole of a situation, at low cost.

Story

The story form is as old as language. It seems simple, but is hard to describe. A story is essentially a narrated description of a causally connected sequence of events in some domain, or especially of actions taken by a small number of interacting protagonists. Stories can also be told visually: you could make a film of people actually using a legacy system, set in context by shots of customers phoning up, asking for a service, etc. Stories help engineers to ask key questions like

A variation on the story is the storyboard, invented in Hollywood in the 1920s and still in wide use on film shoots of all types today. Each frame of the storyboard gives the right amount of detail for a shot; the storyboard as a whole tells the story of the film.

Storyboards find their main engineering use in human-computer interaction. HCI designers may sketch all or some of the desired screens in the user interface. Such screen concepts can serve as prototypes: they are effectively software-free implementations of the system in various states.

Simulation

Simulations are ideally suited for exploring dynamic, story-like aspects of scenarios. Any story that has a direct concrete interpretation can be modelled, animated and simulated.

Simulation can give precise answers about whether scenarios could be realized with any plausible design. Simulation can also be used to evaluate the implications of alternative possible worlds.

Sequence

'A straight-line sequence of steps taken by independent agents playing system roles' is roughly what most engineers mean by Scenario. Synonyms include Operational Scenario – itself part of a Concept of Operations, (Test) Case or Script, Path, and Course (of actions or events). The terminology is clearly rather slippery.

A sequence of numbered steps in the form '<role> does <action>' is a simple and effective way to describe how a result is to be obtained. If you are describing interactions with a machine, it may be convenient to list the steps in two columns: one for what a human operator is to do, and the other for what the machine is to do in response.

Structure

The further you go into analysis and specification, the greater is the pressure to impose structure on scenarios.

Ways to structure scenarios include the flowchart (known in UML as the Activity Diagram). Flowcharts give a good impression of what has to be done when, including places where decisions are required and the outcomes of those decisions. What flowcharts on their own don't do is to show who is responsible for each action; this weakness is corrected in UML by adding swimlanes (one per role) to show clearly who does what. Message Sequence Charts can also be used, but are best for non-branching scenarios.

When there are many if..then..else.. branches, the resulting mass of options can be organised into a Use Case. This is a structure of text, associated with a functional goal and usually a primary role or 'Actor'. The goal is named in a bubble. The structured text has to be documented separately, and may run to several pages. Essentially the normal or main scenario is described, along with a separate account of each variation or exception scenario, the preconditions, and the expected results. Performance and other requirements associated specifically with the Use Case can also be described.

A Use Case Diagram is only a Summary

Scenarios on their own are often insufficient as system specifications – in particular, they tend to be descriptive rather than analytic, and they are not ideal for capturing design constraints (such as legacy interfaces) or for required qualities such as security, reliability, performance and so on. They are valuable for discovering requirements, for guiding design, and for acceptance testing.

© Ian Alexander 2004

A set of resources for scenario-based system development is available from http://www.scenarioplus.org.uk