CHAPTER 3

SCENARIOS IN REQUIREMENTS DISCOVERY

Suzanne Robertson

The Atlantic Systems Guild Ltd, London, UK

APPLICABILITY

Projects in many different domains have used the approach described in this chapter. These include: stock control for an office products manufacturer, development of motor vehicle electrical components, a television scheduling system, a computer operating system, redesign of the structure of a medical insurance company, calibration and measurement tools for automotive engineers, billing system for mobile phone company, implementation of enterprise resource software, financial management and banking, and tracking shipments.

POSITION IN THE LIFE CYCLE

Building requirements scenarios encourages imagination and exploration and sets the stage for discovering unconscious and undreamed of requirements. Informal sketches (described in this chapter) are especially helpful in requirements discovery.

You can play through a scenario with a number of different stakeholder groups to discover discrepancies and conflicts. The scenarios help you discover the atomic requirements. These requirements—and all their attributes—can be individually validated. If you are using this discipline you can ask testers to help validate the requirements. Each requirement is formally linked to all the scenarios it applies to. So groups of requirements can be validated as a functional group.

You also use the requirements scenarios as input to system specification decisions. The more you explore the scenarios, the more you learn about the subject matter and the better you are able to make decisions about allocation. Which parts of the scenario are inside the system you plan to build and which parts are outside.

The scenario-related groups of atomic requirements are input to designing tests. This provides a feedback loop between the testers, the developers, and the business or subject matter experts.

KEY FEATURES

This approach uses scenarios as a tool for discovering requirements and linking the business investigation to the building of a product. A variety of scenario-building techniques provide options for differing degrees of formality. The requirements knowledge model—illustrated in this chapter—provides a common language for grouping and linking requirements. Business events, business use cases, and product use cases work in conjunction with scenarios to discover and organise the requirements.

STRENGTHS

This is a way to discover requirements that can be used and followed by business people, requirements analysts, and developers. Business events are a consistent stepping-stone for exploring scenarios, leading to product use cases, and for functionally linking requirements. Flexible techniques are underpinned by a formal structure for organising and communicating requirements knowledge.

WEAKNESSES

There is a danger of building too many scenarios and being overcome by “analysis paralysis”. We need to develop more guidelines on recognising which business events will benefit from additional scenarios. Sometimes the whole point of building a scenario is to explore and discover requirements that might otherwise be missed. However, once a scenario is built, I have noticed that people are reluctant to throw it away and this can result in yet more deliverables to maintain. Without the guidance of an experienced requirements engineer, there is a danger of requirements discovery scenarios losing the business focus, turning into product designs, and never discovering the real requirements.

WHAT IS A REQUIREMENTS SCENARIO?

The Shorter Oxford Dictionary defines a scenario as

A scene in a play or a film tells a story with a beginning, middle, and end. Each scene involves specific actors, props, direction, and dialogue. To explore alternatives, the early versions of the scene (scenarios) are rough sketches of the idea. As the live performance draws closer, the details of the scenario become more precise. Let's consider the parallels with requirements discovery.

Suppose that your client is Handsome Cabs, a taxi company in London. This client wants you to build a product to help them deal with the taxi bookings from their customers. They also want help in allocating the jobs to the taxi drivers. In order to discover the requirements, you need to study a system that involves taxi drivers, passengers' booking habits, the rules for allocating jobs, the traffic patterns, new ideas for improving the customer service, and so on. The list goes on and the context of your study is potentially huge, clearly too big to study as one big scenario without missing pieces or wasting time. However, if you can break your context of study into a number of linked scenes then you could explore each scene individually by building a number of scenarios.

For example, one scene tells the story of what happens when the customer decides to book a taxi. You can build a scenario that captures the story of what normally happens in this scene. You can also build some exception case scenarios to discover the requirements that people often forget to mention.

A requirements scenario is a simulation of what happens within the boundaries of a specific scene for the purpose of discovering the business requirements. You will discover more business requirements if your scenario has a business boundary as opposed to a product boundary. Let's have a look at some examples.

A Business Event

When a customer wants to book a taxi, he asks Handsome Cabs to provide a taxi at a specified time to take him to a specified destination. The taxi company responds by carrying out procedures that are based on their pre-planned business policy.

As defined by Steve McMenamin and John Palmer (1984), a business event is something that happens, within the boundary of your investigation, to which there is a pre-planned business response. The response to the business event is a business use case (Figure 3.1), and that business use case contains all the related business requirements (bear in mind that the business can be related to any kind of domain: management information, electrical engineering, medicine, defence, consumer products, and so on. I am using the taxi system as an example because it is less specialised and hence more likely to be familiar).

Regardless of the domain in which you are working, you can discover requirements by building scenarios for the business event response, commonly referred to as the business use case. In the course of this chapter, I will build up a picture of how all these components are related to each other.

We can apply the business event, business use case pattern to one of the business events for the taxi company. For example, take the business event: Customer wants to book taxi. This event takes place when a Customer makes up his mind that he needs a taxi. The event causes a Taxi Booking Request to be communicated by the customer to the taxi company. When the taxi company receives the Taxi Booking Request it triggers a business use case (Make Taxi Booking) that satisfies all the business requirements that respond to the event.

As we can see in Figure 3.2, one of the requirements is to communicate the Taxi Booking Confirmation to the customer. But what is a taxi booking confirmation, under what circumstances is a confirmation produced, and what are all the other requirements that are related to this business use case? The business event has set the scene, now we can build some scenarios to help discover the detailed requirements.

FIGURE 3.1 Event Response Abstract

FIGURE 3.2 Event Response Specific

FIGURE 3.3 Scenario Types

Normal Case Scenario

You can build a variety of scenarios for the response to a business event. The four main types are the normal case, the alternative cases, the exceptions, and the what-ifs.

You do not necessarily need to build scenarios for each of these viewpoints (Figure 3.3). The most effective approach is, rather than get diverted by alternatives, exceptions and what-ifs, to start with the normal case, and then you will be in a better position to assess how much effort you need to put into the other views.

Later in this chapter I will talk about a number of techniques for building scenarios. For now, let's look at an example of building a normal case scenario using a text-based approach. Here is a guide on what you need to consider when building a scenario. You do not necessarily have to do all of these things; neither do you have to do them in any precise order. But it will help your scenario-building skills if you understand the thinking behind the following points:

1. Identify a business event

   

   FIGURE 3.4 Scope Event: This model illustrates how your scope of investigation identifies the business boundary for a number of business events (the * indicates many)

2. Identify the business use case
3. Identify the stakeholders
4. Write an informal sketch of the scene of the business use case
5. Formalise the sketch to identify scenario steps

Identify a business event The process of discovering requirements involves the study and investigation of many interconnected rules and policies that are specific to your scope of investigation. As this diagram illustrates, your investigation will involve a number of business events. And these business events identify the boundary of the business that will lead you to your requirements. For the moment we will focus on one business event.

The business event provides a way of logically partitioning your investigation and a focus for building a relevant scenario (Figure 3.4). A business event has the following attributes:

• Business Event Name: A name to help understand what the business needs to respond to
• Business Event Number: Unique number for tracing the event and connecting it to the business use cases and atomic requirements
• Input Data: Input data caused by the business event
• Output Data: Output data produced in response to the business event.

For example, the event we have identified from the taxi company project has the following attributes:

• Business Event Name: Customer Wants to Book Taxi
• Business Event Number: 1
• Input Data: Taxi Booking Request
• Output Data: Taxi Booking Confirmation

Identify the business use case Once you find a business event it leads you to the business use case; this is because the event is the reason for the business use case. When a business event happens, it triggers the business use case to respond to the business event.

FIGURE 3.5 B Event B Use Case: When a business event happens, it triggers a business use case

To identify the business use case for the business event, Customer Wants to Book Taxi, we ask what does the business have to do in order to respond to the business event. Well, the business has to do lots of things, but they are all related to making a taxi booking. So we can name this business use case Make Taxi Booking. The business use case (Make Taxi Booking) does not exist unless there is a business event (in this case Customer Wants to Book Taxi) to which the use case must respond (Figure 3.5). A business use case has the following attributes:

• Business Use Case Name: A name to help understand the business functionality
• Business Use Case Number: Unique number for tracing the use case and connecting it to business events and atomic requirements
• Input Data: Input data to which the business use case must respond
• Output data: Output data produced by the business use case

In our example, the business use case attributes are

• Business Use Case Name: Make Taxi Booking
• Business Use Case Number: 1
• Input Data: Taxi Booking Request
• Output Data: Taxi Booking Confirmation

The boundary for the scenario is everything that normally happens (remember we are starting with the normal case) during the time between the customer deciding to make a taxi booking request and the taxi company producing a taxi booking confirmation.

Identify the stakeholders Given what you know about the business event and business use case, who are the stakeholders who can provide input for the scenario? Of course, the answer to this question depends on the sociology of the particular project that you are doing. It makes sense to do a project sociology analysis at the start of a project (Robertson 2000, Robertson and Suzanne 1999), to discover the people who are the best sources of requirements knowledge. In a very simple world, there would be one person who knows all the requirements but in practice that rarely happens. Instead, you have a number of people in different parts of the organisation and in other organisations, who have some business understanding of the requirements.

To deal with this fragmentation, it is a good strategy to agree on a business owner for each event. The responsibility of the business owner is to help find all the requirements for that business use case. Bear in mind that the business owner will not necessarily know all the requirements but will guide the requirements analysts to the other stakeholders who are the sources of answers.

Let's suppose in the Handsome Cabs example that Erika, the chief despatcher, has agreed to be the owner for the business event Customer Wants to Book Taxi. Erika has agreed to do her best to help you discover the requirements for the business use case Make Taxi Booking (Figure 3.6). She has also suggested some other stakeholders who have some understanding of that part of the business and are likely to be able to answer questions to which she does not know the answers. The result of your identification of the stakeholders for this event is as follows:

• Business Event: Customer Wants to Book a Taxi
• Business Use Case: Make Taxi Booking
• Owner: Erika, the chief despatcher
• Other Stakeholders: Accounting department for details of customer accounts, Customers who use the taxi company's services, Other despatchers who work for the taxi company, Public Carriage Office who are responsible for setting the tariff for taxis.

Now you can start to build your scenario.

Write an informal sketch of the scene You can start to get to grips with the scenario by writing an informal sketch of the scene of the business use case. If you already have a good understanding of the business use case, then you can choose to skip this step and go straight to writing a more formal scenario. However, do not underestimate the power of doing a relaxed investigation before you impose structure and maybe miss asking valuable questions.

FIGURE 3.6 B Event Stakeholder: There are lots of stakeholders who are within the scope of the investigation. You usually need a different subset of stakeholders to help you understand each business use case

In this example, let's suppose that you do not know much about the business use case. You can learn more about it by asking Erika to have a coffee with you, tell her you need 15 minutes of her time and ask her to talk to you about what normally happens when a Customer Wants to Book a Taxi. Tell her that you want to stick to this particular business event and not get sidetracked by anything else. Say that you will help her to concentrate on this use case. Tell her that you have ways of making sure that you cover all the business use cases and the connections between them. Ask her to tell you a story.

It's likely at this point that Erika will start to veer off into another use case, probably the one that is activated when it is time to allocate a taxi for a job. Tell her that you will deal with that as a separate use case but that, with her help, you will establish formal connections between all related use cases.

Keep track of what she tells you in your requirements notebook using whatever mixture of words, pictures, and models that works for you. Try using a mind map as described by Tony Buzan (1997) to help you to recall all of the details.

If you can get Erika to agree to you, recording what she says will help you trap details that might otherwise be missed. By this I mean voice or video recording. The ideal is a small video camera that also captures sound. However, people are often very wary about being recorded; you need to be very formal and agree on precisely how the recording is to be used and who will have access to it. If you do not feel comfortable using this sort of technology, then ask if you can take a photo of her workplace. Tell her that you want to use it to help recall what she has told you, to trigger questions, and to help you remember and show your colleagues how her organisation works. I carry a small digital camera around with me and use it as a note-taking device. I always ask permission and also send a copy of the photo to the stakeholders concerned.

Formalise the sketch and identify scenario steps Now you think you know enough to write a more structured scenario. Your input is the analysis that you have done on the stakeholders, the business event and the business use case together with the informal sketch of the normal use case and any other notes, samples or photographs that you have collected (Figure 3.7). First use the sketch to help you to identify the scenario steps according to your understanding so far.

FIGURE 3.7 B Use Case Scenario: Now you have a rough sketch of the normal case scenario. This model indicates that you might build more than one scenario for the same business case; we will look at that later

Your scenario model now looks like this

FIGURE 3.8 Scenario, Scenario Step: You have partitioned your normal case scenario into a number of steps. The steps reflect your current understanding of the business use case

Normal Case Scenario for Business Use Case 1: Make a Taxi Booking

1.1 A Customer phones us and tells us he wants to book a taxi

1.2 The taxi despatcher asks the customer for his account number and account name and passenger name

1.3 The taxi despatcher verifies the customer's account details and payments

1.4 The despatcher asks for the pickup address the desired pickup time and the destination

1.5 The despatcher tells the customer the optimum pickup time

1.6 The despatcher allocates a job number to the booking

1.7 The despatcher records the booking details

1.8 The despatcher confirms the booking details to the customer

Bear in mind that a scenario is not a use case; however, it does provide content for the use case. Later you can combine the normal, alternative, and exception scenarios to produce the complete use case as per commonly used structures. You will find that Ian Alexander (2003) and Alistair Cockburn (2001) give practical guidance on the contents and structure of a use case. For now, let's have a look at how the normal case scenario provides a starting point for finding the alternative paths and exceptions and hence discovering the requirements that might otherwise be missed (Figure 3.8).

Identifying Alternative Cases

An alternative case is one that indicates a legitimate business choice that significantly alters the normal case. A way to find alternatives is by taking each step in your normal case scenario and questioning it by using a checklist:

• Does this step always happen precisely as stated?
• Do we know the precise meaning of each noun?
• Do we know the precise meaning of each verb?
• Is there any missing data?
• Are there any subjective judgements?
• Am I making any assumptions?
• Does this make sense to me?

Here is an example of looking for alternatives by asking some of the questions in the exception checklist:

• 1.1 A Customer phones us and tells us he wants to book a taxi

Is a customer always an individual or could it be an organisation?

Does the customer always communicate with us by phone?

Do customers always want to book one taxi or could there be a booking for several taxis?

• 1.2 The taxi despatcher asks the customer for his account number and account name and passenger name

Is it always the taxi despatcher who asks the customer or is anyone else involved?

Does the customer always have an account?

Could there be more than one passenger name?

Suppose that you ask these questions and you discover that sometimes (around 25% of the time) the customer does not have an account. Then you could build an alternative case scenario for this situation.

Alternative Case Scenario for Business Use Case 1: Make a Taxi Booking

Note that I have not written down the steps that are identical to those in the normal case scenario. I have limited the alternative case scenario to just those steps that are different from the normal case.

Identifying Exception Cases

An exception case is one where an error or an unwanted processing condition arises. You can discover exception cases by taking each step in your normal case and asking:

• What data conditions could make the step unable to proceed?
• What historical conditions could make the step unable to proceed?
• What human behaviour could make the step unable to proceed?

For example, one of the steps in the normal case is

What happens if the taxi despatcher discovers that the customer has provided incorrect account details?

What about if the customer's account has not been paid within the agreed period?

What happens if the customer is impolite to the despatcher?

The answers to these questions might indicate exceptions that might be worth working into a separate scenario.

What-If Scenarios

People usually ask for what they think is possible or what they already have. When you deliver the finished product it often inspires them to ask for something else. Or maybe there is an unexpected change in the world that creates new requirements for you product. You cannot anticipate every change in the world, but a little creative thinking can help you discover requirements that might otherwise be missed. Here is how you can use scenarios to help.

Take your normal case scenario as a starting point and for each step identify the constraints and say: what would happen if this constraint did not exist? For example, the first step in your normal case is

• 1.1 A Customer phones us and tells us he wants to book a taxi

One of the constraints is that the customer contacts you by phone. If you remove that constraint how else could the customer contact you. An obvious answer is the Internet. But maybe you could have bookings made by travel agents as part of a package deal. Or you could include taxi vouchers as part of tube tickets for the parts of the journey that are not serviced by tube. Or you could issue people with special ultrasonic devices that would pick up the nearest taxi in the area, and so on. Once you remove the constraints and you are in brainstorming mode, the possibilities are endless. By doing this, you uncover business ideas that will not otherwise occur as most of the time we are imprisoned by the present.

While this is a very powerful technique for encouraging creativity and invention, you also have to be careful to review each of the requirements ideas and formally grade them as being inside or outside your business scope. Otherwise you can derail your project by never making any decisions.

FROM SCENARIOS TO ATOMIC REQUIREMENTS

Scenarios are a vehicle for discovering the atomic business requirements (Figure 3.9). Another advantage is that scenarios that are derived from business events provide a logical business grouping for individual requirements. And that business grouping in turn connects to a product grouping and to the resulting system requirements. In other words, you are laying the foundations for traceability.

FIGURE 3.9 Atomic Requirement in the Volere Template

Before we talk about how to derive the requirements from the steps, it is worth pointing out that an atomic requirement has a number of attributes. The following is an atomic requirement that I have derived from the scenario step:

• 1.2 The taxi despatcher verifies the customer's account details and payments

The requirement's attributes are as follows:

• A Unique Requirement Number
• The requirement type (Functional, Non-Functional (there are many subtypes of non-functional requirements (Robertson 2000) or Constraint)
• The Business Event Number
• The Product Use Case Number
• Requirement Description
• The Rationale for why we have this requirement
• Source of this requirement
• Fit Criterion, specifies how we will know whether the requirement has been met. This is the input to writing tests.
• Customer Satisfaction/Dissatisfaction. On a scale from 1 to 5, how satisfied will the customer be if we meet this requirement and how dissatisfied will the customer be if we do not meet this requirement. This is the first informal thinking about prioritising the requirements.
• Dependencies, other requirements that depend on the implementation of this one
• Conflicts, other requirements that are in conflict with this one
• Supporting materials, support for the fit criterion and for further understanding of the requirement.
• History, keeping track of creation, reviews, disputes, and decisions.

These attributes combine to specify the requirement so that there is a common understanding between all the relevant stakeholders. In other words, if you have stakeholders who are working very closely together then your requirements definition procedures (and the attributes you define) can afford to be less formal than if you have stakeholders who are separated in terms of geography, time, and experience. Some organisations, especially large ones who want to reuse requirements, choose to record many more attributes of a requirement. Other organisations make do with fewer attributes, especially when the stakeholders have a lot of experience in working together.

I discovered the atomic requirement in the example by examining a step in the scenario. You will find that, because each of your steps will be at a different level of abstraction, some of the steps will result in one requirement and others will result in a number (Figure 3.10). In the case of this step:

• 1.3 The taxi despatcher verifies the customer's account details and payments

FIGURE 3.10 Requirements Knowledge: This model summarises the connections between atomic requirements and other requirements-related knowledge

We would have one requirement, as per the example, which is concerned with verifying the payments have been made for outstanding invoices and another requirement that specifies the verification of the customer's account details. If the customer's account details are made up of a number of disparate parts, then there might be a case for having more than one requirement. When you write the fit criterion it helps you to decide whether you really have one atomic requirement or whether you need to divide it.

As you can see, there is a great deal of detail necessary to define an atomic requirement. So do you need to define all of the atomic requirements for all of the steps of every scenario? The answer depends on who needs to know about each requirement and how many translations the requirement will go through.

Here is a real example from one of my client's projects. The requirements are being specified by a group of business people and requirements analysts. Then the requirements will be sent to a group of implementers in another country. The people in the two countries do not know each other. Clearly, in a case like this the risk of misinterpretation is high and the investment in precise requirements will pay off.

Another question to help you decide which atomic requirements should be specified in detail is: for each step, do I know whether the requirements related to this step will be included within the scope of the product or not?

If you are sure that the answer is no, then it is likely that you do not need to define each of the atomic requirements for the step. If the answer is partly, then you need to define some of the atomic requirements for the step—those that will be included in the product. If the answer is don't know or maybe, then you should define the atomic requirements for the step.

KEEPING TRACK OF THE INVESTIGATION

As you see in the knowledge model, the investigation scope is concerned with a number of business events and their resulting business use cases. We have focused on one business event in order to explore how to use scenarios to discover requirements. The Handsome cabs project would have a number of business events as summarised in this context diagram (Figure 3.11).

WHO PRODUCES THE SCENARIOS?

Who should be involved in writing the scenario? My ideal is to have a small group (up to six) of representative stakeholders do it together in a workshop session. For more on how to run requirements workshops see (Gottesdiener 2002). However, it is not always possible to get the necessary stakeholders together at the same time. Often, the requirements analyst has to gather input from a number of different stakeholders, derive the scenario, and then help individual stakeholders review it.

FIGURE 3.11 Taxi Context: This model summarises the business events that are part of the taxi booking investigation. In our exploration of scenarios we have focused on just one business event and its related business use case

TECHNIQUES FOR BUILDING SCENARIOS

We identified the business use case Make a Booking, as the response to the business event Customer Wants to Book Taxi. As already discussed we can build a number of different scenario views (normal, alternative, exception) for the business use case. We can also use a variety of techniques for building the scenarios. I have had most success with techniques that we refer to as Low-Fidelity techniques. In other words techniques that do not require a lot of technical equipment and props, but rely on using tools that people are used to. Like paper, pencils, coloured markers, post it notes, white boards, and flip charts. To start with, a new tool like a digital camera is a High-Fidelity tool. People are not used to it and have to concentrate on learning how it works rather than using it to help build a scenario. When the tool becomes more of an everyday fixture then it becomes a tool that you can use to build low-fi scenarios.

Text Scenarios

In this chapter, I have focused on building scenarios using text. As illustrated with the Handsome Cabs example, text scenarios range from very informal stories to very structured steps. We have seen that an informal story is a very good way of getting started. Then as you get a better understanding you can derive a more structured scenario by identifying scenario steps and eventually deriving atomic requirements.

Story Boards

Anyone who has seen a cartoon strip is familiar with the concept of storyboards. They are widely used by the film industry to plan a scene in a movie. Instead of writing the scenario steps in plain English, you draw a picture of each step (Figure 3.12). You use a combination of drawing and words to explore a scenario. This works well as a technique for exploring the “what-if” scenarios mentioned earlier in this chapter.

As Neil Maiden (2001) illustrated during our creative design workshops with Eurocontrol, people find it easier to build storyboards if you give them a starting point. Instead of a blank sheet of paper we started with an A3 piece of paper marked like this (Figure 3.13).

When we provided this starting point people immediately got involved in the building of a storyboard without having any delays. People who believed that they could not draw just went ahead and drew their own representations of the story. We also provided room for writing comments to expand on each frame of the story.

FIGURE 3.12 Storyboard: This storyboard explores a scenario where there is an emergency and no taxis are available

FIGURE 3.13 Storyboard Form

FIGURE 3.14 Process Model Scenario: This scenario process model is a picture of the business use case that responds to the event: customer wants to book taxi

Scenario Process Models

A scenario process model is a picture of the fragments of process together with the dependencies between them (Figure 3.14).

Building a scenario process model is rather like doing a jigsaw puzzle. You are trying to find all the processes that are part of the response to the business event (the business use case). You are also looking for the data that connects those processes: data that is flowing is indicated by an arrow, data that is stored is indicated by two horizontal parallel lines.

The advantages of a scenario process model are as follows:

• You are not forced to write things in a sequential order, so you can identify the true dependencies between processes.
• The medium helps you to expose missing data and raise questions.
• You verify your investigation context by identifying necessary connections with other business use cases. For example, this model is looking at Payments and Invoices, so there must be another use case that is creating this data.

Disadvantages of a scenario process model are as follows:

• You need to be a skilled modeller to be able to build one of these models (or any other analytical model), especially if you are doing it while asking questions and getting input.
• The model exposes details that can lead you away from the normal case before you really understand it.
• Sometimes people are not used to working with models and are more responsive if you show them text.

Scenario Playthroughs

Rob Austin and Lee Devin (2002) draw parallels between the activities involved in producing a play and the activities involved in discovering requirements. We can make use of some of the ideas developed in the theatre to discover requirements. A scenario playthrough brings a scenario to life by acting out a specific scene.

In the Handsome Cabs example, someone plays the part of a customer wanting to book a taxi. The customer asks the despatcher for a taxi at a particular time on a particular day. The despatcher responds accordingly. Then maybe the customer changes his mind, or asks for two taxis instead of one or elects to pay by credit card rather than account. This prompts the despatcher to remember facts he has not yet mentioned or to realise that there are other business possibilities that nobody has yet thought of.

To be effective, a playthrough has to have an element of fun or silliness. Maybe the customer can have a silly name or have an address like Fawlty Towers. Or the customer could talk with a strong accent or have a very long-winded way of explaining what he wants. This makes people more relaxed and relaxation prompts questions and ideas that otherwise do not occur.

WHEN TO USE SCENARIOS

There are a number of situations when scenarios are the best tool for requirements discovery: when you do not know where to start, when you have difficulty involving a stakeholder, when you want to encourage invention and creativity, when you want to establish relevant boundaries.

Suppose that you want to talk to the Erika, the chief despatcher at the taxi company, about what happens when a passenger wants to book a taxi on his account. Erika does not seem keen to talk to you. Maybe, like almost everybody these days, she is very busy. Or maybe she can't see the relevance of talking to you. Or maybe she is afraid. Afraid that you will ask her questions she cannot answer or make her feel confused or inadequate by talking to her in technospeak. A scenario can help you to overcome these obstacles because you can use the technique to ground the questions in terms of Erika's world.

Scenarios do not work well if people use them as an excuse for not exploring and defining the detailed requirements. If you hear comments like, “Well this seems clear enough, let's go ahead and build the product without bothering about details,” it is likely that you will miss requirements.

This chapter has focused on using scenarios to discover business requirements by exploring the investigation scope for each business event. As illustrated in the knowledge model, you can also use scenarios to help you explore alternative product use cases for each of the business use cases. In other words, you can focus on a scenario that helps you understand the business and you can also focus on a scenario that helps you decide which parts of the business will be implemented by the eventual product.

KEYWORDS

Business Event

Business Use Case

Requirements

Product Use Case

Scenario

Stakeholders

REFERENCES

Alexander, I., Scenario Plus, 2003, http://www.scenarioplus.org.uk

On this website you can find downloadable templates for structuring use cases and including relevant content.

Austin, R. and Devin, L., Beyond requirements: software making as art, IEEE Software, 19 2002. The authors draw many parallels between the work of collaborative artists in the theatre and the work of systems developers. In particular they draw attention to the iterative nature of the work and the use of play to discover unknown requirements.

Buzan, T., The Mindmap Book, BBC Books, London, 1997.

Mindmaps are a creative tool for taking notes so that you can easily recall the details. This books teaches you how to combine colours, shapes, keywords to capture understanding and ideas. The skill of building mindmaps is invaluable for anyone who is trying to capture complex parallel details.

Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley, NJ, 2001.

Read this for practical guidance on how to write use cases and what to include in their content. Useful way of identifying use cases at different levels of detail but would benefit from a formal classification system.

Gottesdiener, E., Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002.

A valuable source of advice on techniques for planning and running requirements workshops.

Maiden, N. and Gizikis, A., Where do requirements come from? IEEE Software, 18 2001.

McMenamin, S. and Palmer, J., Essential Systems Analysis, Yourdon Press, New York, 1984.

Definitive work on identifying business investigation scope and how to partition it into business events.

Robertson, S., Project Sociology: Identifying and Involving the Stakeholders, The Atlantic Systems Guild Ltd, 2000, http://www.systemsguild.com An overview of how to find the right stakeholders for your project and how to involve them in requirements discovery and specification.

Robertson, James and Suzanne, Mastering the Requirements Process, Addison-Wesley, 1999.

A process for gathering and specifying requirements that is based on producing the relevant deliverables for each project. The Volere requirements template provides a structure for identifying stakeholders and gathering requirements.