Scenarios enable software developers to verify that we understand how the users expect to use system that we are about to build.

Here are two classic definitions of the term scenario:

a) An outline or synopsis of the plot of a drama, opera, etc., indicating scenes, characters, etc.

b) The outline of a motion picture, indicating the action in the order of its development, the scenes, the cast of characters and their appearances, etc

A scenario serves the same purpose as a map. We know that it isn’t possible to experience San Francisco by looking at a map of the city, but we can get an idea of the different business and residential neighborhoods in the city, and how to move across the city via highways or public transportation. As we all know, the map isn’t the territory, however, the map provides a means to evaluate some aspects of the territory.

Let’s say we have a friend who is a playwright. She has a concept in her head for a play, which is derived from a book. There’s lots of description in the book about the thinking of the characters, who they are, how they came to be they way they are, and why they behave they way they do. In a play, this description must be represented to the audience without written words. The thoughts of the characters, while clear in the book, will be conveyed to the play audience explicitly through body language and implicitly through dialogue.

Our playwright needs to find financial backing and someone to produce the play. Although she perceives the performance in her head, she must distill it down to the essence so that the producer can quickly understand the concept and become emotionally involved. Asking the producer to sit through a play reading isn’t appropriate at this early stage of development; the producer wants just enough information to determine whether go with the concept.

The book is a popular title; the producer most likely has read it. However, the playwright can’t assume that the producer’s understanding will be the same as hers. People can read the same book, or see the same movie, and each person will take away their own impressions.

She builds a scenario to convey the big picture of a play. The scenario will expose the major themes and characters that enable those themes to develop. A critical selling point is suggesting who might play the major characters. Imagine if Shirley Temple had been Dorothy in the Wizard of Oz.

In the context of software development projects, we have refined the common definition to apply to software designed for business purposes. Nevertheless, the fundamental definition of a scenario is still applicable: it’s the example that everybody always gives when they want to make the point clear.

The scenario isn’t perfect solution, but it’s better than many (most) of the popular methods of gathering requirements. Scenarios enable us to identify process and metrics at the time as we create the usage model. The process of formulating the scenario gets us to visualization (shared hallucination). Once we have the visualization, we still have to tease out the rest of the requirements.

Let's modify our definition of a scenario to be:

a) An unambiguous view of what the consumer wants
b) An unambiguous view of what the consumer is doing

What do we mean by an unambiguous view? An unambiguous view leaves no room for interpretation, i.e., the consumer either wants to accomplish something or not, the consumer either does things a certain way or doesn’t. Earlier, we talked about how two people can read the same book, or see the same movie, and walk away with completely different impressions. An objective of the scenario is to minimize the ambiguity.

What do we mean by consumer? In the context of a software development technology project, a consumer is a person who has a specific business task to complete, and, using a software application facilitates completing that task. We write a scenario from the consumer’s point of view so that the consumer can read the description and instantly relate to the events and activities as if she or he was physically involved with the task at this very moment.

When we tell a story, whether it be the background for a play or a movie, we describe a sequence of events. When we tell a story about accomplishing a business task, we specify the attributes and behaviors of the people involved as well as the task being accomplished. Sometime the task is a compilation of related tasks. When we talk with the consumer, we ask, What is it that you want to do? In a scenario, we articulate what it is, what it is not, and what its behaviors are.

A scenarist’s modus operandi is objectivity and clarity in describing these attributes and behaviors. The more objective and clear the scenario, the easier it will be for the consumer to understand, relate to, and evaluate.

We talked about how a scenario captures the essence of the big picture. For software development project purposes, a scenario is a means to bridge the gap between the business consumer’s worldview and the software system designers’ worldview.

In a scenario we describe a business task so that the consumer can recognize the task, yes, that is what I do, or yes, that is what I wish would happen. Our description is constructed as a sequence of deliberately chosen events so that we can measure the complexity, usefulness, and desirability of an application that would bring the scenario to life.

We often build scenarios in pairs or in multiples. Again, our objective is to obtain a basis for metrics. We often need to ascertain how big a change the consumer is asking for. A pair of scenarios, one describing the current sequence of events, the other describing the accomplishment of the same task via the new or proposed sequence of events, gives us the ability to measure, and to quantify the delta between the current situation and the proposed new world.

Sometimes a business task is a complex combination of related tasks. In order to describe completely the global task, the scenarist often finds it necessary to write multiple scenarios. One scenario provides the context for the rest; however, each scenario can stand on it’s own for the purposes of validation by the consumer.

Remember word problems? Unlike the nice clean problem with just numbers and function symbols, the problem is articulated in text. Here are two examples:

Example 1

Andy has three times as many sweets as Bernice. If he gives Bernice six sweets, he will then have twice as many as Bernice has. How many sweets did they each have to start with?

Example 2

The Haynes Parkway is a 20-mile road along a river that has no stoplights. The speed limit is 40 mph; but cars typically travel at 45-50 mph or perhaps faster. However, a sheriff regularly patrols the parkway, so speeds in excess of 50 mph are rare. During traffic, it is hard to pass, and traffic backs up behind any car that is going slower than the average speed. What is the average speed of cars on Haynes Parkway given the following information? A car enters one end of Haynes Parkway and drives at 40 mph. Other cars begin to arrive behind him, and because they are traveling faster than 40 mph, a line of cars traveling 40 mph begins to form. If after seven miles there is a line of 14 cars, what is the average speed of cars before they must slow behind the line of cars? There were only two cars that entered Haynes Park at the same time.

In the first example, you were given just the information you needed to solve the problem and nothing more. The fourth example includes information that is interesting, but does not appear relevant to solving the problem. How can you be sure? It is much harder to solve a “noisy” word problem. Using the same reasoning, a scenario should clearly separate what is and is not information relevant to the business task at hand. A good scenario is structured.

Here is the solution to the first problem:

Example 1

	Andy has three times as many sweets as Bernice. If he gives Bernice six sweets, he will then have twice as many as Bernice has. How many sweets did they each have to start with? A has three times as many sweets as B. If he gives B six sweets, he will then have twice as many as B then has. How many sweets did they each have to start with? Let x = number of sweets that Bernice has initially; then 3x is the number that Andy has. If now Andy gives 6 sweets to Bernice then Andy has 3x-6 sweets and Bernice has x+6 sweets. Now we are told that after this transfer, Andy has twice as many sweets as Bernice, so we can write down an equation to represent this fact, i.e.
	3x-6 = 2(x+6) 3x-6 = 2x + 12 3x-2x = 12 + 6 x = 18
	So initially Bernice had 18 sweets and Andy had 3*18 = 54 sweets. After transfer Bernice has 18+6 = 24, Andy has 54-6 = 48, and 48 is twice 24.

Example 2

Part of why the second problem is hard to solve is the noise; the noise makes the problem unstructured. Here is the thought process that ensues when we try to filter out the noise: Well, is there really enough information to solve this problem? See, the number of cars that pile up behind Driver A isn't just a function of how fast they are going, it's also a function of how they're spaced along the parkway. Therefore, if seven cars arrive shortly after Car A, and they all travel at 41 mph, they might all pile up behind Car A. But if they arrive twenty minutes after Car A and they all travel at 41 mph, it's likely that none of them will pile up behind Car A. Therefore, it's heavily dependent on how those cars are spaced. The information needed in order to make any conclusions is the time that the cars in the pile-up entered the road. Then we'd be able to look at the last car in the pile, and get a lower bound on how fast its driver was going (it would have to be going at least a certain speed if it wanted to make up the given distance in the given time). Given this information, all we could conclude is that seven cars had gone faster than 40 mph.

- Manager, Traffic Planning Department

There are two formats for a scenario, simple English and highly structured. For an example of the simple English scenario, see the (example in progress).

• A scenario is the example that everybody always gives when they want to make the point clear.

• A scenario is a means to bridge the gap between the business consumer’s worldview and the software system designers’ worldview.

• A scenario shows how a user interacts with a system to accomplish a specific business activity.

• The information in a scenario should be relevant to the business task that the scenario is illuminating. Extraneous information can be confusing, and can lead to unhappy results.

• There are two formats for a scenario, simple English and highly structured. The highly structured format often spawns a set of use cases. Scenarios can also be used by software developers to write Use Cases (see Erickson, Jacobsen, and Booch for further information on Use Cases). Use cases are a good tool for the software object modeling, but that is not the focus of our discussion here.

• A set of carefully selected and crafted scenarios is provides the critical validation of the business requirements.

Final conclusions for this tutorial.

Mountain View, California 94043-2715 
+ 1 650.965.9690  
+ 1 650.938.0858 fax