Scenarios

Simply put, a scenario is a story, albeit one told in a particular format. The term "scenario" is generally used to mean a sketch of the plot of a movie or play, or an outline of a situation. In requirements work, we use this term to mean the plot of a section of the work we are studying. The use of "plot" is intended to imply that we break the work into a series of steps or scenes. By explaining these steps, we explain the work.

The scenario tells the story of a business use case.

For information on many other ways to use scenarios, see Alexander, Ian, and Neil Maiden. Scenarios, Stories, Use Cases Through the Systems Development Life,Cycle. John Wiley & Sons, 2004.

We have devoted an entire chapter to business events and business use cases (Chapter 4), so naturally we will make more use of them. From here on, we are talking about using scenarios to tell the story of a business use case.

This makes a certain amount of sense: The business use case is a discrete amount of functionality, it happens in its own continuous time frame, and it can be considered separately from other parts of the work's functionality. For these reasons the business use case is an ideal container for a story.

Business analysts use scenarios to describe a business use case to the interested stakeholders. The scenario is a neutral medium, understandable to all, and the business analyst uses it to elicit agreement on what the work has to do. Once consensus is achieved, the stakeholders can decide how much of that work will be done by the product. An additional scenario describing the user's or actor's interaction with the product might then be produced.

"A formal language for talking about work organizes concepts that help people learn to see work."

Beyer and Holtzblatt, Contextual Design

Suppose you have identified a business use case you wish to explore. Good practice indicates that you now identify the interested stakeholdersthose with knowledge or expertise in this part of the work. You use the scenario to portray the functionality of the business use case by breaking it down to a series of steps. We suggest that you aim for between three and ten steps.

Write your scenarios using between three and ten steps.

There is nothing fixed about the range of three to ten steps, and nothing untoward will happen to you if you use more steps than ten. However, if you end up with 126 steps, either you have a gigantic business use case (impossible for normal commercial work) or you are writing your scenario with an unnecessarily meticulous level of granularity. The aim is to keep the scenario simple enough to be readily understandable, and three to ten steps is a guide-line for achieving this goal.

Although a formalized template for a scenario exists, your first draft can be simple and informal. As an example, let's leave our IceBreaker case study for the moment and look at something that you are most likely familiar with: a business use case for checking a passenger in for an international flight (see Figure 6.1). Here's Sherri, one of the check-in agents:

Figure 6.1.

An airline check-in for an international flight. As we go through the scenario for this case, see if it matches your experience of checking in for a flight.

"I call the next customer in line. When he gets to my desk, I ask for a ticket. If the passenger is using an e-ticket, I need the booking record locator. Most of the passengers are not organized enough to have it written down, so I ask them their name and the flight they are on. Most people don't know the flight number, so I usually ask for their destination. They must know that!

"I make sure I have the right passenger and the right flight. It would be pretty embarrassing to give away someone else's seat or to send a passenger to the wrong destination. Anyway, somehow I locate the passenger's flight record in the computer. If he has not already given it to me, I ask for the passenger's passport. I check that the picture looks like the passenger and that the passport is still valid.

"If there is no frequent-flyer number showing against the booking, I ask the passenger if he belongs to our mileage scheme. Either he hands me the plastic card with the FF number, or I ask him and if he wishes to join I give him the sign-up form. We can put temporary FF numbers against the flight record so the passenger is credited for that trip.

"If the computer has not already assigned a seat, I find one. This usually means I ask if the passenger prefers a window or an aisle seat, or, if the plane is already almost full, I tell him what I have available. Of course, if the computer has assigned one, I always ask if it is okay. Somehow we settle on a seat and I confirm it with the computer system. I can print the boarding pass at this stage, but I usually do the bags first.

"I ask how many bags the passenger is checking and, at the same time, verify that he is not exceeding the carry-on limit. Some people are unbelievable with what they want to carry into a fairly space-restricted aircraft cabin. I ask the security questions about the bags and get the passenger's responses. I print out the bag tags and securely attach them to the bags, and then I send the bags on their way down the conveyor belt.

"Next I print the boarding pass. This means that I have everything done as far as the computer is concerned. But there is one more thing to do: I have to make sure that everything agrees with the passenger's understanding. I read out from the boarding pass where he is going, what time the flight is, and what time it will board. I also read out how many bags have been checked and confirm that their destination matches the passenger's destination. I hand over the documents, and wish the passenger a good flight."

Now sketch out the scenario. Break the story down to the steps that you consider to be the best ones to capture the normal path through the story. There are no hard and fast rules about how you accomplish thisjust write whatever seems logical to you. After all, you are going to use the scenario; it might as well fit with your view of the work. It will be adjusted by subsequent activities. Suppose that this is your first draft:

1. Get the passenger's ticket or record locator.

2. Is this the right passenger, flight, and destination?

3. Check the passport is valid and belongs to the passenger.

4. Record the frequent-flyer number.

5. Find a seat.

6. Ask security questions.

7. Check the baggage onto the flight.

8. Print and hand over the boarding pass and bag tags.

9. "Have a nice flight."

Confirm this scenario with the interested stakeholders. It is in plain Englishthat is intentionalso all stakeholders can be invited to participate and revise this scenario until it represents a consensus view of what the work should be. Once a consensus is reached on the work, start to formalize the scenario. Along the way, you will learn more about the work.

Stakeholders are invited to participate and revise the scenario until it represents a consensus view of what the work should be.

The first part of the formalized scenario identifies it and gives it a meaningful name.

Business Use Case Name: Check passenger onto flight.

Next, you add the start-up mechanism, or trigger, for the business use case. It usually consists of some data or request (often both) arriving from outside your work area. There are also time-triggered business use cases. In this situation, you state the time conditionan hour or a date is reached, an amount of time has passed since another business use case, and so onthat initiates the use case.

Trigger: Passenger's ticket, record locator, or identity and flight.

This is not a perfect situation from the point of view of the work providing a better service. As you are looking at the work, you should be asking whether the business use case could start before the passenger makes it to the desk. For example, could he check in at home, or on the way to the airport, or while standing in line? All of these options are technologically possible and probably offer some business advantage. For the moment, we leave this question as an open issue.

Now you add any preconditions that must exist when the business use case is triggered. Preconditions indicate the state of the work at initiation. Usually this means certain other business events must have occurred before this business use case makes any sense.

Preconditions: The passenger must have a reservation.

The check-in desk is not the place to be if you do not already have a reservation. While it may seem like good service to allow passengers to make a reservation at the check-in desk, the amount of time needed for this transaction would no doubt annoy the rest of the passengers standing in line.

You might consider adding the interested stakeholders to the scenario. These people have an interest in the outcome of the business use case. That is, they will be affected by the manner in which the work is done and what data is produced by it.

Interested Stakeholders: Check-in agent, marketing, baggage handling, reservations, flight manifest system, work flow, security, destination country's immigration.

There are probably more stakeholders, but this list is adequate to show that you are not concerned only with the immediate problem, but recognize that whatever you do here has ramifications on a wider scale.

Active stakeholders are the people or systems that do the work of the business use case. Usually, one active stakeholder triggers the business use case, and then one or more others participate in the work.

Active Stakeholders: Passenger (trigger), check-in agent.

The passenger triggers the business use case by arriving at the check-in desk. He is also the recipient of the business use case's output. The passenger works with the agent to carry out the work of the business use case. Although the agent manipulates any automated product being used, that should be thought of only as the current implementation and has no binding ramifications. The essential business is triggered by the passenger, who, in some future incarnation, might be more closely involved. Self check-in springs to mind here, but (once we have fully understood the work) we should also think of checking in by telephone while on the way to the airport, checking in at the club lounge, using the record locator sent to the passenger's mobile phone by the airline, or any of dozens of possibilities.