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.
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.
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.
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:
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.
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. |