Introduction to Scenarios

Scenarios are a powerful antidote to the complexity of systems and analysis. Telling stories about systems helps to ensure that people – 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, for example 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.

Context

Scenarios are simple, human things. This book reveals that there are many possible variations on the theme, and the Scope section below introduces some of the concepts; but the basic idea is just a story: someone does this, someone else does that:

The driver walks towards the car and presses his key.
The car recognises the driver, unlocks the doors, and adjusts the driving seat, steering wheel, radio, and mirrors to the driver's preferred settings.

“Scenarios are arguably the starting point for all modelling and design” (Sutcliffe 2003). Since systems either do something that somebody wants, or are shelfware, and scenarios describe how to do things, it seems hard to disagree with the idea that scenarios are the way to begin a development – if not also to continue, as several authors in this book argue.

More and more modelling notations are being invented – I saw one in a new gadget being shown off at a trade fair, and it had no fewer than 26 symbols that somebody believed were necessary for requirements analysis – and no end to the madness is in sight. I have no idea how the developers of such things imagine that ordinary people are going to use anything so intricate, and so far removed from life. I do have a lively idea of the blank looks I'd get from practical engineers if I tried to pull any such trick on them.

The use of the narrative scenario in engineering seems in one way to be a kind of reaction against too much technology, too fast. There is no need to be a Luddite to wonder what is being missed in the race to construct ever more complex, formal and unfamiliar models for ever more risky projects.

Scenarios 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. And they do this at low cost, at least once people are trained in their use (Sommerville and Sawyer 1997).

The scenario perspective looks at what people do and how people use systems in their work, with concrete instead of abstract descriptions, focus on particular instances rather than generic types, being work- not technology-driven, open-ended and fragmentary rather than complete and exhaustive, informal, rough and colloquial instead of formal and rigorous, and with envisioned rather than specified outcomes (Carroll 1995).

Analysis means 'dissolving [into component particles]', which is fine and very necessary; but it also means looking at details, which as everyone knows is a way of not seeing the wood for the trees. Engineers love analysis and design: our profession's occupational hazard is diving into detail, ignoring the people involved, and what they may want.

Using scenarios in analysis is thus paradoxical. Analysis is about refinement, precision, and completeness with respect to the parts of a problem. But scenarios are basically holistic. Whether in terse and summary form, or written out at length in a carefully-studied sequence – or even in a complex analytical framework with multiple paths ingeniously fitted together – the scenario is in essence a single thing that conveys a human meaning. And that meaning is enhanced by the reader from her own experience; the story told in the written scenario slips effortlessly into the context of the network of meaning in the reader's mind.

"Let me out of this bottle" wailed the desperate Djinni, "and I'll make you richer than King Solomon".

"You are a tricky Djinni", answered the Fisherman. "You deserve the same fate as the King in the story of The King and the Doctor."

Stories are quite insistent on one point: a tale is not over until it's finished in every detail. The Djinni is not just playing for time by exploring side-issues: he's thinking out other options and tricks that might result in a better outcome – from his dark and devious point of view. It goes without saying that the exploration is by storytelling, and the Fisherman has to use all his cunning to outwit his immensely powerful opponent. Scenario-based techniques such as searching for Exceptions, Functional Hazard Analysis, and Misuse Cases (see Chapter 7) make use of the power of storytelling to explore likely weaknesses, and thus to make systems more reliable, safer, and more secure, in the face of active and intelligent opposition.

Sven Birkerts, in his richly reflective Gutenberg Elegies (Birkerts 1994), states that humanistic knowledge is unlike instrumental knowledge, since it aims to fashion a comprehensible narrative. His thesis is essentially that the Internet and electronic media detract from the ability to concentrate in the way that a printed book encourages; that the private world that a good book lets you into is a doorway into civilisation, as it fosters just that depth of thought that the instant availability of colourful hypertext banishes. He would argue that narrative is extremely important, and for quite different reasons than those I have set out above.

Well, we believe that at least one kind of instrumental knowledge, that needed to serve system designers, testers, safety engineers and others in their work by giving them a mental picture of how the system-to-be is going to be used, also needs to be fashioned into a ‘comprehensible narrative’. Our goal is not, indeed, anything as grand as enabling humanity to grow emotionally or spiritually, as Birkerts believes literature may do; but more humbly, we hope that scenarios may help engineers to make systems that serve humanity a little better.

Narrative can fulfil these diverse purposes because sequences of events in time are at the heart of our ability to construct meaning.

In David Attenborough's wonderful television series, The Life of Mammals, one story shows a group of monkeys of different species feeding on the ground (Attenborough 2003). Suddenly one spots a snake. At once all the members of the group shout out the 'Snake' call of their own species. Everyone looks about for the snake. The youngest realize the danger, learn the calls, and live to watch out for snakes another day.

could hardly carry a clearer survival message. And this tale of communication in the face of danger is part of our shared primate heritage. Actually there is a further twist: some monkeys give not only the basic call, but accompany it with a modifier which seems to mean something like 'serious', 'intense' – the monkeys have not only nouns but adjectives to convey their meaning.

Human language is a far richer medium for sharing meanings than even the most sophisticated calls of our primate relatives, but Stephen Pinker is surely right when he writes in The Language Instinct that it grew out of the need to share knowledge with similar survival value (Pinker 1994). He quotes a conversation imagined by the evolutionary biologist George Williams between a mother and a child along the lines of “don't play with that, dear, that's a Sabre-Toothed Tiger and it wants to eat you” (page 289). The rest of the scenario hardly needs to be told; the child that understood grew up safe and well, and the one that didn't, didn't.

Every parent of young children has made the same striking observation as I have: even very little ones instantly appreciate being shown different kinds of beast, and never tire of hearing about the noises they make, or of seeing how the crocodile snaps his jaws. These things are important to know if you're inexperienced, and want to live.

It's no exaggeration, then, to suggest that spoken language, and with it the human mind, evolved precisely because planning – constructing and evaluating scenarios – is a survival skill.

Planning becomes important when resources are short, when outcomes are uncertain, and especially when intelligent opponents are making their own plans which contradict our own. That's pretty much all the time. We are social animals; gangs and tribes and shifting alliances and treachery are a permanent feature of our existence. Our social brain – the one that enjoys watching the scheming complexities of Shakespearean tragedies and soap operas – is adapted precisely to understand stories. It is adept at filling in details from scant evidence; at guessing and reasoning about people's intentions; at predicting how people would respond if we chose a certain course of action.

The scenario exploits exactly these mental abilities. It uses narrative – a time-threaded sequence of actions. It focuses on agents and their (inter)actions. It is at root brief and abstract, but highly suggestive of context. It is helpful for predicting outcomes. It is all about courses of action.

In a nutshell, scenario approaches allow projects to benefit from the inherent strengths of narrative, and from the excellent match of the story form to the story-processing capabilities of the human brain – whether trained or not. We predict that scenarios will always be useful in engineering.

Scope - what does scenario mean, and what does it cover?

Like other important concept-terms in systems engineering, Scenario has multiple connotations, all subtly different. Fortunately these form quite a coherent set of meanings, which we'll explore below to set out the scope of the book.

One other concept intimately connected with scenarios is that of the Stakeholder. Scenarios are all about communicating with people. One of the main reasons why traditional development approaches failed was precisely that they excluded non-engineers – and quite often the kinds of models used were not too helpful for communicating with other engineers. So we’ll start by defining what we mean by Stakeholder, and then look at what Scenarios can offer.

Stakeholders

Scenarios are for people: a way to explain what they want, and to check that what is being asked for is correct. People with a legitimate interest in a System are its Stakeholders, and they are the people we have in mind throughout this book. Who are they? At the least, they represent diverse groups.

Incidentally, scenario techniques such as roleplay (see Suzanne Robertson’s account in Chapter 3) can be used to document stakeholders’ viewpoints: they can tell the story of how people behave and to paint a picture of their “motivations, expectations, and attitudes.” (Kuniavsky 2003). Such an ethnographic perspective – getting a user experience point of view – is valuable, as it gives engineers the chance of

“putting on the shoes of the people you’ve created, and looking at their problems and your solutions through their eyes.” (Kuniavsky 2003, page 149)

While this may seem a surprising application of scenarios, making a user profile is common practice in the worlds of user interface design, marketing, and product management: perhaps it should be more widely used in system design also.

Figure 1 shows an ‘onion’ model of a system’s stakeholders (Alexander 2003, Alexander and Robertson 2004). Since the concepts of both ‘system’ and ‘stakeholder’ are slippery, let us take a moment to define what we mean. The central circle, labelled ‘The Kit or Product’ denotes whatever it is that we are making – the hardware and software, the equipment, machinery and installations of any kind that we are specifying and designing. If we were making something for a market, we would call it our Product. That is often called a system, but we’ll choose to call ‘Our System’ the next circle out. ‘Our System’ consists not only of kit, but also of the people who are actually operating that kit. Consider an aircraft: it’s clearly a system, as it consists of a set of connected parts that together produce the behaviour of controlled flight. Those ‘parts’ include engines, airframe, controls, electronics – and the aircrew. From this point of view, therefore, any Stakeholder who is directly involved in operating the Kit or Product is part of Our System, the one that produces the results we are describing with our Scenarios.

The onion model provides generalized ‘slots’ such as ‘Normal Operator’ and ‘Maintenance Operator’, which need to be filled with specific stakeholder roles for a particular project. For instance, the Normal Operator slot in an aircraft contains roles such as the Pilot, the Navigator, and arguably the whole of the rest of the aircrew. The Maintenance Operator slot for an aircraft includes the first-line daily maintenance crew – the refuelling team, the cleaners, etc, as well as second- and third-line roles like radar fitter, engine fitter and so on. All such ‘direct’ (Kotonya and Sommerville 1997) Roles, those that belong in ‘Our System’ slots on the onion model, can play Operational Roles in Scenarios, and can serve as ‘Actors’ in Use Cases.

All other Stakeholder Roles, those outside the ‘Our System’ circle, are ‘indirect’ or non-operational; these terms have some value, but as Figure 4 shows, they cover many different kinds of role. For example, the Aviation Authorities who certify that an aircraft is safe to fly belong in the ‘Regulator’ slot in the ‘Wider Environment’ circle. Regulators don’t pilot planes; they don’t even work for airlines that operate those planes; but although they are outside those ‘system’ circles, they are among the most important stakeholders in an aircraft development project.

Finally, notice that the owners of Interfacing Systems are also Stakeholders in our system: they are part of the ‘Containing System’ that includes our system. In the case of an aircraft, that Containing System consists of the airports and air traffic control that the aircraft operates with. For example, the towbar that connects a tractor to an aircraft’s nose-wheel is an interface: both tractor and aircraft have to comply with a standardized design so that they can be sure to be compatible. Interfacing Systems (like tractors) can appear in scenarios and can serve as Actors in Use Cases, even though they are not human. But while the company managing the towing of an aircraft is potentially a Stakeholder, tractors and towbars are not.

Story

The story form is, as has been argued above, 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 more usually of actions taken by a small number of interacting protagonists:

A poor woodcutter had two children. There was little to eat, so to keep them safe he decided to send them to his brother, who lived deep in the forest…

The pilot has no stick or rudder pedals. Instead, a small joystick mounted in the armrest allows the pilot to control the craft with one hand. With the joystick in the neutral, vertical, position, the craft remains stationary. When the pilot tilts the joystick to the left, the craft turns, banking according to the joystick's left-right angle to the vertical. When the pilot pushes the joystick forward, the craft accelerates smoothly…

Even the simplest story has the power to create in our minds an image of a world – maybe magical, maybe technical – so that we almost feel we are there. Questions and guesses arise unbidden. Will the children meet a witch, or an ogre? Can the craft fly or hover? If it does, can it climb or descend vertically, and if so how would you control that with a little joystick?

The most basic form of story is a spoken or written narrative, but stories can also be told more visually. Indeed, story underlies nearly every kind of scenario. For example, an organisation 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. More simply, a story can be told by acting out a scene, live in a workshop or recorded on video. For instance, a subgroup of workshop participants can pretend to interact with a future device, to illustrate a desired capability or to bring to life a possible problem that ought to be handled.

Stories bring with them a wealth of context, mostly unwritten, from our shared culture. As long as this is what the story's author intended, it is useful, as it provides a frame of reference in which the reader can evaluate the story as a whole, and make sense of its individual statements – which can therefore individually be short.

Stories provide an internal logic – of a sequence of events in time; of causality – which is valuable to engineering as it permits, indeed encourages validation. Questions like

spring naturally to mind, and stakeholders – people with a legitimate interest in a system – in practice correct stories rapidly and deftly, in marked contrast to their behaviour when asked to review a list of requirements.

Stories are coming into favour in various branches of engineering, notably in human-computer interaction and in ‘agile’ (or ‘extreme’) methods of software development.

Kent Beck and David West propose in Chapter 13 that some kinds of software should be written on the basis of brief ‘User Stories’ and tests devised from them (Beck 2000).

Thomas Zink and Frank Houdek write about Story Use & Reuse in Automotive Systems in Chapter 16. Here the stories are seen not as system specifications, but as ways of carrying the gist or essence of the system's purpose from one project to another – for after all, despite all the differences, one car remains much like another. But recycling and reuse of requirements are harder than they look.

Roger Schank, a pioneer of artificial intelligence and much else, has almost cornered the market in arguing the value of stories in engineering. He and his colleagues invented the script in the 1970s, basically a simple sequential scenario describing a stereotypical interaction – famously, when a hungry customer walks into a restaurant, is shown to a table by a waitress, hangs up his coat, and so on. In his Tell Me A Story (Schank 1990) he goes further, and argues that knowledge is stories, and that everything we know is embodied in stories. It seems clear that he would include scripts and sequence scenarios (see below) as stories.

A story, like any scenario, is inherently episodic, “an illustrative instance of a set of behaviours, not a definition of the set”[1]. The more structured kinds of scenario and use case (see below) go some way to mitigating this ‘for instance’-ness, but arguably they never throw it off altogether.

Development on the basis of stories alone is possible only if you are not too concerned with perfection (at least at the start). If you want a system to be as safe as possible, you will specify and analyse its every behaviour, and use formal logic to prove that its code is logically equivalent to its specification. If, frankly, you don't care, but you have a few situations in mind that describe what you'd broadly like the system to do, then telling a few stories may well be quite adequate – the team can make the system converge with stakeholders’ intentions by iteration (rapid prototyping, agile methods, and so on). These mindsets are poles apart, and it is easy for engineers with such different backgrounds to talk past each other. However, there are more structured forms of scenario that many engineers may find more comfortable.

Situation, Alternative World

To the businessman or politician, a scenario means a projected future situation or snapshot. Typically, either a team brainstorms a few possible scenarios, or more scientifically, a simulation is run say 15 years into the future to project a set of variables.

For instance, in an approach pioneered by Shell, an oil company might look at a moment in the future where the oil price is $100 per barrel, alternative sources of electricity are cheap at just 10¢ per Kilowatt hour, and fuel cells are available for 50% of all cars. These values of these variables suggest a pattern of energy use very different from what would happen if electricity cost $1 per Kilowatt hour, and so on; and that pattern can be convincingly modelled using suitable mathematical models and simulation tools.

This usage of ‘scenario’, as an instantaneous snapshot that illustrates the outcome of a set of trends, is plainly helpful in long-term business planning. In a world where politicians had any foresight, it would undoubtedly be useful in long-term government planning also. But on the whole it seems to be rare in systems engineering. When engineers need to refer to a specific outcome they tend to use other words, such as system state or failure mode.

Happily, David Bush (Chapter 6) gives a concrete example of its usefulness in assessing requirement stability by looking ahead to whether goals are relevant in various imagined alternative worlds.

Simulation

Simulations can, as we've just explained, be used to model more-or-less static Situations, but they are also ideally suited for exploring dynamic, story-like aspects of scenarios.

Any story that has a direct concrete interpretation can be modelled, animated and simulated. If stakeholders say they want to run trains with more passengers on board, and that the trains must stop for half the time at each station to improve speed and punctuality, then engineers can model how long it would take to get so many passengers onto and off the trains given different door sizes and carriage layouts. Consider the scenario:

A train crush-loaded with 2000 passengers pulls into Central Station in rush hour. There are 1000 people waiting on the platform. 700 passengers leave the train and 700 join it. The driver closes the doors and the train moves off 30 seconds after it halted.

Simulation can give precise answers about whether such a scenario could be realized with any plausible design, given the existing constraints on train length, platform width and so on. Simulation can also be used to evaluate the implications of alternative possible worlds or situations (see above). Used for that purpose, simulation is interesting not so much for its ability to step through a story as for the results that it generates (e.g. did the passengers manage to leave the train within 30 seconds?).

A simulator with visual output enables scenarios to be replayed directly to stakeholders, in much the same way as a prototype system can allow users to see the effect of their requirements. David Harel and Rami Marelly’s recent book, Come, Let's Play (Harel 2003) presents Live Sequence Charts – extended Message Sequence Charts – with supplied “non-commercial”software, to enable readers to try capturing and executing user-interface scenarios for themselves; underneath are formally-defined model semantics. You could justifiably say that such a simulator is a prototype system; the fact that it is executable and behaves like the real thing effectively overcomes the difficulty of presenting formal specifications to stakeholders. An effective commercial implementation would continue the trend seen in “fourth-generation” programming languages and visual program design environments like those for Visual Basic and Visual C++, moving specification away from code towards the user interface. This is not simply a matter of Graphical User Interface (GUI) design, nor even of the use of an editing tool’s GUI, but of specifying system behaviour by means of the system-under-design’s own GUI. Since that is something that system operators need to understand, it is – at least from a system point of view! – the logical place to define what behaviour the system operators want. However, not all stakeholders are operators, and not all requirements are conveniently stated in terms of an operator’s interface.

The sorts of comments and suggestions that stakeholders typically make when they first see a running system or animated simulation are 'But what if …' or 'And then I'd like to be able to…'. These illustrate why scenarios are so valuable: once the implications of a set of choices are displayed, everyone can see if the result is right or needs improving.

In Chapter 21, Evaluating Scenarios by Simulation, Pericles Loucopoulos shows how the negotiations over the requirements for Olympic stadiums were informed by simulation. A simulation model can show stakeholders the likely effects of their requirements when implemented as design parameters. We may be interested in the dynamic results, as when people queue for admission to a stadium and its facilities at peak times, or in a more static conclusion that option A is more cost-effective than option B. Either way, appropriate use of simulation – possibly involving many runs – can explore scenarios that might be too slow, too costly, or too dangerous to try out for real. Simulation also answers questions (as the Olympic stadium example demonstrates) too difficult to visualize and to make decisions on without the kind of quantitative evidence that simulation can provide.

There is a close connection between scenario, simulation, and prototyping: all explore ways a system would work when in service, and all imply the need for an iterative and participative development life-cycle (see the section below, ‘Through the Life-Cycle’, and Andrew Farncombe's discussion of life-cycles in Chapter 15).

Storyboard

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. Anyone who has tried to understand a play by reading its script knows the problem: the words as they lie there on the page just fail to conjure up a visual impression of the action. The scripted dialogue is a kind of scenario, but while it is essential for telling the actors what to say, it is not sufficient for organizing shoots. If the heroine walks out of one shot in a blue skirt and a red top, and into the next in a red skirt and a blue top, the continuity of the story is badly damaged. The team producing the shot need quite detailed information to set everything up correctly, to ensure continuity among other things. Each frame of the storyboard gives just the right amount of detail for that shot (Figure 2); the storyboard as a whole tells the story of the film.

Unsurprisingly, storyboards find their main engineering use in human-computer interaction (e.g. Eberts 1994). HCI designers may sketch all or some of the desired screens in the user interface. These screen concepts can serve as prototypes: they are effectively software-free implementations of the system in various states. A user interface prototype acts as a window into the (future) system, allowing stakeholders to reason about its behaviour. David Benyon & Catriona Macaulay discusses Scenario-Based Design of HCI in Chapter 11. Joy Van Helvert & Chris Fowler explain their approach to Scenario-Based User Needs Analysis in Chapter 4.

On one project, when the user interface requirements were extremely uncertain, I made a set of storyboard sketches in ink and watercolour, before going on to use a sophisticated Graphical User Interface design tool. Colleagues later joked about my Early Watercolour Phase, but at least a dialogue on the required functionality and design had been started. The design tool, incidentally, did a beautiful job of setting up a possible graphical design, but it was a dangerous journey down a ‘rabbit hole’, as it focused my attention too sharply on the implementation of the interface – when what the interface ought to have been showing was anything but decided.

Sequence

A straight-line sequence of (possibly numbered, typically interactive) steps taken by independently-acting (presumably intelligent) agents playing (system) roles is roughly what most people mean by Scenario in engineering today – but note all the caveats. Synonyms or partial synonyms for this include Operational Scenario – itself part of a Concept of Operations, (Test) Case or Script, Path, and Course (of actions or events). It is evident that the terminology is slippery. We'll try to define Scenario a little better below.

Given that systems are by definition complex structures made up of interacting components, there are usually many possible interaction sequences for any system. For instance, if a tool offers only 10 menu options that may be chosen in any order, then a sequence of just 3 commands can be constructed in 1000 ways, or 720 if repeat commands are not allowed. When a tool has over a hundred menu options, as does Microsoft Word, and many of those allow numerous choices, and sequences are typically many commands long, the number of scenarios that could be generated quickly runs into the billions.

This is at the heart of the twin problems of specification and verification: it is impossible to test everything, as Edsger Dijkstra long ago argued so eloquently (Dijkstra 1972). There are simply too many possible test scenarios (see Chapter 14 by Ian Alexander). But by the same token, it is impossible to specify everything either, if we attempt to do it with scenarios alone. Surely it would be better to rely on analytic, program-like structures that can in the twirl of a while loop or a case statement take care of many possible scenarios?

Well, it would be much better, save for one crucial fact: humans are not at all good at expressing themselves in precise, systematic, logically complete and consistent form – or in understanding such things either. Even professional programmers make frequent mistakes when encoding system behaviour in software. It is said that carefully-debugged code still contains 1 error per 1000 lines. We should expect specifications written like code to be just as error-prone – otherwise, we could solve all the problems of software just by compiling code from our specification languages.

Since requirements come ultimately from people, we have a problem: we need precision in requirements, but we need people to express and understand and agree the same requirements. Precision means analysis and formalisation by engineers. But requirements elicitation and validation must be from and by stakeholders – people whose expertise is not in stating requirements. Therefore an altogether softer approach is mandatory.

Scenarios offer some hope of bridging this particular gap, as they are good raw material for analysis, but are close enough to ordinary stories for people to understand without effort. There are many possible ways in which straight-line time-sequence scenarios might be applied in engineering. Notably, they could be either inputs received from stakeholders, or ‘people-friendly’ outputs generated by a specification engine (presumably one that contains a database). Neil Maiden explains how to use Systematic Scenario Walkthroughs to validate complex requirements in Chapter 9.

Any bridge between the ordinary world and the domain of systems analysis is subject to enormous tension. Research engineers of different kinds constantly come up with ways of ‘improving’ the languages and notations used to express requirements and specify systems. The naivety of a simple scenario is a red rag to a bull to people thinking about how to make better specifications. Obviously you can just add a branch here and an exception mechanism there and a looping construct down here, and in no time at all you'll have a fully-capable specification language! Ah yes, but you'll also have left your stakeholders stranded on the far side.

Numerous researchers of undoubted intelligence claim that they have successfully demonstrated that a group of normal ‘users’ readily understood some (usually graphical) notation or other. Well, maybe they did; but the users were buoyed up by the excitement of being pioneers; they were probably self-selected as being the most adventurous people in their company – since they'd agreed to work with a researcher! – and not least, they had the pioneering researcher playing the role of the humble systems analyst. It isn't surprising that these approaches often don't work in less rarefied atmospheres.

The plain old list-of-steps scenario is not a perfect medium for specification. But it is a workable medium for the purpose of getting started on the task of writing requirements, and providing grist for the analyst’s mill. Suzanne Robertson explains in a simple and practical way in Chapter 3 how you can use Scenarios in Requirements Discovery. If you follow some of the authors in this book, you may find that the scenario is capable of much more than that; for example, Karen Holtzblatt explains in Chapter 10 how they use scenarios in system design. What is incontrovertible is that scenarios can be understood by ordinary people and engineers alike.

Structure

The further you go into analysis and specification, the greater is the pressure to impose structure on scenarios. Several ways to structure scenarios are described in this book. Ian Alexander takes a sideways look at use cases by examining Negative Scenarios and Misuse Cases in Chapter 7. Camille Salinesi describes how to author Use Cases in Chapter 8.

There are some longstanding techniques for defining the order of steps in a business process or program.

· The flowchart, despised by analysts but beloved of businessmen, is alive and well even in the UML as the Activity Diagram (Fowler 1999). 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 is quite a serious weakness, given how central stakeholders are to requirements. Happily, UML has also adopted the swimlanes diagram, which has been in use since the 1920s. Each role (or ‘actor’, to use Jacobson's term[2], adopted for UML) has a lane. Roles carry out actions by swimming down the page. Combining an Activity Diagram with a background of swimlanes allows the humble flowchart to show clearly who does what.

· Another notation that can be used to analyse scenarios is the (message) Sequence Chart, which is found in the UML and the ITU frameworks. This provides a timeline for each object or role down the page, with messages between roles shown as labelled horizontal arrows. Various different symbols can be used to annotate the sequence to define more elaborate behaviours, e.g. an hourglass to denote a timer for time-triggered events. It seems clear that such notations are suitable for analysts rather than for scenario-like communication with other stakeholders. A yet more sophisticated notation, the Live Sequence Chart invented by David Harel and Werner Damm (Harel 2003) takes sequence charts even further into the analyst’s world, but see the discussion of Simulation above.

Activity Diagrams and Sequence Charts may be fine as representations, but they do not solve the problem of identifying all the if..then..else.. branches – all the exceptional business events that have to be handled. There are usually far more of these than anyone thinks of initially. Programmers are all too familiar with filling in all the missing elses by experience and guesswork.

UML's answer to this problem is the Use Case[3], which has evolved far beyond what Jacobson originally proposed (Jacobson 1992). The Use Case began life as not much more than a Story or Sequence: it had a name, an actor, and some text.

“A use case is just what it sounds like: it is a way to use the system. Users interact with a system by interacting with its use cases.” (Jacobson 1995, page 310.)

Unfortunately, several tool vendors eagerly jumped on to the bandwagon and created tools that concentrate on drawing Use Case diagrams (Figure 3), leaving aside the much duller work of dealing with what the Use Cases contain – scenarios. This would be funny if it had not misled so many people. It is a necessary step to identify the various ways that people and systems may interact, but the scenarios give much more information.

Erring the other way from such a diagrammatic over-simplification, several authors have suggested ways of adding more structure to the contents of each use case, and to the relationships between them; and this trend is continuing.

Alistair Cockburn has been one of the most successful, as his Writing Effective Use Cases is based on practical experience, and he emphasises simplicity (Cockburn 2001). A Cockburn Use Case has a Goal – its title: a very sensible minimalist choice; a Main Success Scenario composed of about 3-9 steps; and usually several Extension Scenarios to describe other things (such as failures) that can happen, and must be handled. In addition, Cockburn provides slots for a range of other requirement-like things including Preconditions, Stakeholders and Interests (i.e. Viewpoints); Minimal (i.e. failure) and Success Guarantees; Scope and Level. To fill in all of this is a substantial piece of work, but in return you communicate much more of the stakeholders' intentions with far less ambiguity than you would with just a single scenario.

A closer look at Cockburn's approach will help us towards an understanding of what scenario means. Notice that the term ‘scenario’ in Cockburn's usage has subtly shifted its meaning. Consider what happens if you start executing a Use Case and a failure occurs. You execute part of the main success ‘scenario’ and then the appropriate failure ‘scenario’ – but the entire sequence of activities you've just executed is what we'd call a scenario: a particular complete path in time through the options available when interacting with a system. The Main Success Scenario, which at first sight matches our initial idea of a scenario, turns out to be just a tree-trunk, with several branches documented elsewhere. A Use Case changes from being pretty much ‘a named scenario’, to an analytic description of what happens when one or several actors try to achieve a goal with the system.

Now analysis is necessary for system specification, but a key question is whether it should take place in a scenario / Use Case framework, or somewhere else, with reference to scenarios which themselves can remain simple and comprehensible. I'll call these the Modernist and Traditionalist positions, respectively (Figure 4).

The Modernist view is broadly that if you know what your stakeholders want as a set of Use Cases, you can build your software straight from that: Scenarios are Specifications; the Pattern of the Problem corresponds to the Process of Design (to paraphrase Christopher Alexander, 1964).

For example, to develop an order processing system, you identify Use Cases such as Place Order, Make Payment, Deliver Goods and so on. You then detail what is meant to happen in each case, identify what can go wrong and work out what should happen in each of those extension cases. You add any other details such as guaranteed performance and availability, and you are ready to start designing the software.

The Traditionalist view is roughly that scenarios are fine for describing how your system may be pressed into service, and that they may well suggest a range of functions and quality requirements, but that they in no way express all the requirements, let alone specify the system.

For instance, if your tanks are going to have to drive across the desert, they must not sink into soft sand, and the engine and other parts must not get damaged by ingesting sand. These needs may translate into qualities such as low ground pressure (below so many KiloPascals) and functions such as the ability to filter sand-laden air. But whatever the ultimate analysis of requirements, these are entirely separate from the scenarios. It would be quite inappropriate to expect the soldier who describes what he wants to do with the vehicle in the desert to know about KiloPascals – indeed, if he is only describing desired actions, he knows neither the area of the tracks nor the weight of the vehicle, and sand mechanics isn't his forte either. The scenarios are insufficient as system specifications. But the scenarios remain valuable for discovering requirements, for acceptance testing, and as something to validate the requirements against – so traceability becomes essential.

It isn't an accident that these examples imagine very different environments: one may suspect that much of the confusion about scenarios stems from people with different viewpoints talking past each other, using disjoint languages. The rather small number of books on scenario-based development (as opposed to books on specific tools and techniques, such as UML and Use Cases) illustrates this quite neatly: see the ‘Recommended Reading’ section at the end of this chapter.

This book represents a wide range of viewpoints, but our chapter authors have been specifically invited to comment on each others' work. The result may not be consensus, but we hope it is a step towards greater mutual understanding, an appreciation that many different traditions of scenario use exist, and the realization that there is already a great deal of practical knowledge of scenarios in system development.

Through the Life-Cycle

If people give different meanings to scenario, we also think that scenarios help with quite different tasks in the system life-cycle. We have used an intentionally simple ‘Waterfall’ list of system development activities to indicate how widely each technique described in this book applies during development. This appears to assert that each activity is necessary, happens in the order shown, and happens only once. In this simplistic view of development, the obvious place for scenarios is up front in Requirements Elicitation. Ellen Gottesdiener describes how to run a successful use case workshop to elicit and structure requirements at the start of a project in Chapter 5. There is plainly something in common between this modern logic and the Traditionalist view of scenarios. However, scenarios are also very useful at the end of the Waterfall life-cycle for testing. A Test Case is in essence a sequence of activities, just like the steps of a scenario. Ian Alexander explains the relationship of use cases and test cases in Chapter 14.

Andrew Farncombe explicitly critiques the naïve ‘Waterfall’ life-cycle model. He unpacks the telling of development project stories in his reflective Chapter 15, Stories and Life-Cycle Process Models, based on his experience both as a developer and as a consultant. He shows that successful projects must not only tell the stories of the products they set out to create; they must also select the right story to describe their own development process – and follow it.

A key point that Andrew Farncombe makes is that the development life-cycle is often evolutionary or iterative. Kent Beck & David West describe their pioneering and highly iterative approach employing User Stories in Agile Software Development in Chapter 13. Contextual Design, the method underlying Karen Holtzblatt's account of Scenario-Based System Design in Chapter 10, is an excellent example of a participative, evolutionary approach. Peter Haumer explains how Software Development can be based on Use Cases in Chapter 12.

Types of System

It is practically a hopeless task to describe the types of system where scenarios may be used. There are no obvious limits to the applicability of scenarios. This is not to say that every development will find scenarios useful, but simply that there is no a priori reason to believe that scenarios are inappropriate to whole classes of development project. Our position is therefore that projects should consider writing scenarios as a matter of course. Once they have decided on that, the question of how arises, and that is the subject matter of this book.

Thomas Zink & Frank Houdek describe Story Use & Reuse in Automotive System Engineering in chapter 16. Ian Alexander & Andrew Farncombe describe some applications of use cases in railway systems in Chapter 17. Perminder Sahota of Praxis describes the use of scenarios in Air Traffic Control in Chapter 18. Juha Savolainen of Nokia illustrates scenarios in Telecommunications in Chapter 19. Alistair Mavin describes a use of scenarios for rail rolling stock with the safety-related REVEAL method in Chapter 20. Pericles Loucopoulos describes the power of working out precise scenarios with simulations of Olympic stadiums in Chapter 21.

Development projects are those that are doing something new, and therefore something risky and uncertain. This is the natural home of the scenario, as discussed earlier in this chapter. It matters little whether the project concerns hardware or software, structures in concrete or structures in silicon, complex business interactions or home entertainment, deep space exploration or easier-to-use video recording.

Projects that are essentially routine – doing yet another inspection of a civil engineering structure like a bridge, installing yet another virtually identical computer network – are not developments in this sense. Scenarios will only be useful to such projects individually when there are local conditions that have not been encountered before; then, there may be value in examining threats to the project, and planning suitable mitigations. On the other hand, there may be a powerful case for preparing a set of generic scenarios to be applied to all bridge inspections or all network installations.

This book is about the use of scenarios in engineering of all kinds, not only software. Obviously software is today extremely pervasive. It is finding its way into many structures and devices that were formerly completely passive – bridges have inbuilt monitoring systems; binoculars have image stabilisation; keys and credit cards authenticate themselves using strong encryption.

Much of the complexity of systems now goes into control software – in aircraft and luxury cars, software is already the single most costly constituent. DaimlerChrysler predicts that by 2010, 45% of the cost of a Mercedes will be in electronics – what in aerospace is called avionics, combining both hardware and software (Weber 2003). This has profound effects, some beneficial, some not. The complexity, size, and weight of hardware components is falling, and the chance of hardware failure is therefore falling with it, so we can build systems that are smaller, more efficient, and more reliable than ever before. But taking onboard software into account, we are also building systems that are growing rapidly in complexity, and we are in danger of introducing a multitude of unwanted interactions and failure modes. Overall reliability and safety are not guaranteed to improve in this situation. They will only do so if we keep control of system behaviour. Scenarios are valuable tools in this struggle, because they contribute in several ways to our understanding of wanted behaviour, and to our ability to prevent unwanted effects. This is the reason why DaimlerChrysler (for instance) is looking at stories and use cases, as Thomas Zink & Frank Houdek explain in Chapter 16. Obviously, many other tools are needed to maintain control throughout the system development life-cycle, as requirements are passed to subcontractors, and design choices introduce additional interfaces and risks.

Scenarios for Systems – Not Necessarily Software

Both because software is almost ubiquitous in systems, and because it carries an increasing share of system complexity, it is right that scenarios should often be intended for software. But what we absolutely deny is that there is anything inherently software-oriented about the idea of using scenarios. Indeed, the most accessible examples of scenario use are Hollywood storyboards and military planning (see below), which both existed long before computers became available. Businesses also constitute systems that are governed by carefully thought out scenarios – business processes. Let us take a brief look at all three of these examples.

Military Operations

Military plans take the form of orders that necessarily share the same hierarchical structure as the units (of infantry, armour, and so on) to which they apply. At each level in the hierarchy, a Schedule of Manoeuvre tells the story of what is to be done, not only by the forces on the friendly or ‘blue’ side, but also what actions or counter-measures might be taken by the enemy or ‘red’ side (see also Ian Alexander’s account of Misuse Cases in Chapter 7). A military operation is of course conducted by people and machines playing many roles. The actions of those roles have to be co-ordinated. This is achieved by breaking down the story into the military equivalent of a UML swimlanes chart, a Synchronisation Matrix. This is a table that shows at each time stage (column) what each unit (row) within the blue forces is to do. A map is drawn for each time-step showing the position and movements of each unit at that time. The commander of the blue forces uses this to derive the orders for each such unit – which in turn consist of a (lower-level) Schedule of Manoeuvre and (if applicable) a Synchronisation Matrix showing the further breakdown of tasks to lower-level roles. In other words, orders have a similar structure at every level in the hierarchy, and they always tell a story, using a combination of text, tables, and graphics.

Film-Making

The system that makes a film is another instructive example, because through most of the history of film, hardly any of the process was automated. The credits that roll at the end of a movie reveal job titles whose function most of us can barely guess at – best boy? key grip? gaffer? – yet they form precise and necessary parts of an intricate and highly-polished system for rolling out enormously complex products (measured in data terms, a 90-minute film is some Terabytes of uncompressed images and sound). That system contained for decades very little hardware – hand-controlled cameras, hand-controlled editing tools, and hand-controlled lamps were about the sum of it, if you don't count the trucks and catering equipment. Nowadays, animations and computer-generated imagery find their way into many films, but these are to be understood as particular implementation mechanisms among a wide choice of techniques. However a film is made, the chosen techniques have to be applied to create the desired effects. Those effects themselves tell a story to viewers, so it is not surprising that a storyboard (see above) is needed to define them. The storyboard scenario gives the right amount of information (in graphics and text) to support the planning and preparation of each shot independently – for it is a rare film that is shot in real time, or in the order in which it will be shown – and also of the subsequent editing and assembly of all the shots into a viewable sequence.

Business ‘Systems’ and Processes

A system is a set of interconnected components that work together to produce an effect that none of them could produce alone. Business systems generally contain people, procedures, and supporting equipment (telephones, fax machines, computers, etc), organised into departments that play different business roles (marketing, sales, design, production, and so on).

Therefore, from a purely logical point of view, it ought to be easy to justify the consideration of business scenarios or use cases – scenarios are good for exploring how systems do or ought to work; businesses are systems; ergo, scenarios are good for business analysis (Alexander 2000). But in practice there are sizable cultural obstacles in the way – business analysts are wary of software and technology. Given the history of how businesses have jumped to conclusions (and expensively inappropriate software and solutions) they have cause to be. Scenarios and especially use cases are seen as coming from software engineering. Even systems thinking (e.g. Simon 1996) has been opposed, sometimes quite rightly, on the grounds that ‘hard’ engineering thinking is not appropriate in a ‘soft systems’ world – where ‘soft’ means dealing sensitively with the social and political dimensions of work, and ‘hard’ means focussing excessively narrowly on the technical and hence computerisable aspects (e.g. Checkland 1999).

So, analysts should not imagine business systems as some distorted form of software without code, and business use cases as a bizarre mutant form of software specifications! It is quite sufficient to examine what a business wants to achieve, who is involved in it, what these people – the stakeholders – do, and what their viewpoints are (Alexander & Robertson 2004); and then to construct scenarios in one of the ways described in this volume. Thoughts of automation can come later. Indeed, a key strength of the scenario approach is the way that it encourages us to look at the whole problem before diving into possible solutions.

Systems, then, are not necessarily software, nor even hardware: people and procedures are and will remain important. Scenarios are ideal for exploring and defining the behaviour of systems involving people (socio-technical systems) in complex business procedures – indeed, every written procedure is scenario-like, however poorly expressed it may be.

The Way Ahead

The last part of the book looks at the way ahead for systems development with scenarios. Ian Alexander & Ramin Tavakoli look at how to put scenarios into practice in Chapter 22. Mary Beth Rosson, John Carroll & Con Rodi present their method of teaching computer scientists enough scenario-based design to make software ‘with use in mind’ in Chapter 23 – involving teaching students both human-computer interaction and usability engineering. We reflect on what scenarios are not good for in Chapter 24, and finally we assess the future of scenarios in Chapter 25.

References

Alexander, Christopher, Notes on the Synthesis of Form, Harvard University Press, 1964

Alexander, Ian, Introduction to Scenarios, a range of techniques for engineering better systems, Proceedings IEE Informatics Division Seminar 'Scenarios through the Life Cycle', December 7th 2000, London.

Jacobson, Ivar, The Use-Case Construct in Object-Oriented Software Engineering, in (Carroll 1995), pages 309-336

Sutcliffe, Alistair, Scenario-Based Requirements Engineering, mini-tutorial, 11^th IEEE International Requirements Engineering Conference, 8-12 September 2003, Monterey Bay, California, pages 320-329

Weber, Matthias, and Joachim Weisbrod, Requirements Engineering in Automotive Development: Experiences and Challenges, IEEE Software, January/February 2003, pages 16-24.

Summary