18 Domain Scenarios

Domain scenarios are one the most commonly used requirements modelling technique. This chapter first describes domain scenarios in a nutshell, then goes into details about the fundamental elements of domain scenarios, multiple notations, structuring principles, modelling guidelines and common mistakes.

18.1 In a Nutshell

What

A domain scenario is a real or imaginary sequence of events happening in the world.

Domain scenarios can be textual or graphical. The graphical notations include domain stories and sequence diagrams.

Figure 18.1 shows a textual domain scenario for an ambulance despatching system. Figure 18.2 shows the same scenario as a domain story, a graphical notation used to facilitate discussions with stakeholders during interviews and workshops.

Figure 18.2: A scenario in domain story form

As another example, Figure 6.1 in Chapter 6 describes the tender process in client projects as a domain story.

A synonym for domain scenario is business scenario. The term business use case is also used to refer to a set of business scenarios that share a common goal.

This chapter is about domain scenarios. A related concept is that of machine-interaction scenarios; scenarios that describe sequences of events happening at the interface between the World and the Machine. We talk about machine-interaction scenarios in Chapter 20 on Specification by Example.

Why

Domain scenarios are used extensively in requirements engineering. They serve four main purposes:

Facilitating discussions with stakeholders. Discussing concrete scenarios is much easier than discussing general properties. Stakeholders find it easier to describe concrete examples of behaviours than to formulate general properties characterizing domain goals, domain assumptions, and machine requirements. Scenarios are thus a great starting point for discussing how things work in the World-as-is and how they could work for the World-to-be.
Discovering how stakeholders see and talk about the World. Discussing scenarios with stakeholders will help you discover what terms they use to describe the World. You will learn who the main actors are, what these actors do, what objects they work with, and what other actors they interact with. Once you’ve modelled a few scenarios, you can organise and consolidate this information in a context diagram (Chapter 16) and domain concept model (Chapter 17).
Discovering examples of desired and undesired behaviours. Asking stakeholders to describe scenarios that represent typical desired and undesired behaviours will help you to gradually understand the stakeholders’ goals and constraints. The scenarios are helpful starting points for creating more complete descriptions of the world in the form of goal models (Chapter 19), process models, and state machines.
Illustrating general properties with concrete examples. General statements of domain goals are not only hard to elicit; they can also be hard to understand. A common way to explain a general property is to illustrate it with a few scenarios. You can use scenarios to explain goals, requirements and assumptions. You can also use scenarios to illustrate the behaviours of an activity diagram or state machine.

Who

Domain scenarios are typically written by requirements engineers in collaboration with stakeholders. They are used and read by everyone.

When

Domain scenarios are used mostly during the investigation phase to learn the stakeholders terminologies and discover examples of desired and undesired behaviours (Chapter 10).

Scenarios are also used in all other phases, primarily for illustrating general properties. You might for example write scenarios to explain how certain goals will be met in the World-to-be.

18.2 Basic Elements

Domain scenarios are composed of basic elements shown in Figure 18.3.

Figure 18.3: A domain conceptual model showing the elements of a scenario

A scenario is a sequence of steps describing actions happening in the World, where each step is composed of:

a primary actor who initiates the action;
the action being performed;
zero, one or more world objects that are used in, or modified by the action;
zero, one or more other secondary actors who participate in or observe the action.

Let’s look at each of these elements in turn.

Actors

The concept of actor was defined in Section 2.5.1. An actor is an entity that can perform actions in the World. An actor can be a person, a department or organisation, a device like a sensor or actuator, or a software system. The machine is also an actor.

The actors in the scenario in Figure 18.1 and Figure 18.2 are:

In domain scenarios, actors are typically described by their role rather than their name (e.g. Call Handler rather than Sarah Smith).

In a domain story, their graphical notation is the same as in context diagrams (Section 16.2.1): An actor is represented by a pictogram. The same pictogram can be used for different actors (in our example: Public and Paramedics). If you do not have time to choose a pictogram, you can draw a generic stick figure for a human actor and a box for any device and computer-based system.

World Objects

A world object in an entity that is manipulated, observed, or talked about by actors. A world object can be a physical object (e.g. an ambulance), an event (e.g. an incident), a physical document (e.g. a paper form), or a digital object (e.g. an electronic message between software systems).

Objects in the scenario of Figure 18.1 and Figure 18.2 include:

The objects are the passive elements of the action. In the language of movie scripts, the objects are the “props” used by actors.

In a domain story, the icon for a work object can represent the object itself (e.g. an ambulance) or the medium through which information about the object is exchanged (e.g. a speech icon to represent information transmitted verbally, a file to represent information transmitted digitally, etc.).

Within a single scenario, an object can have different icons if the medium changes. For example, in the scenario of Figure 18.2, the mobilisation order is exchanged as an electronic message in step 5, and as a sound and visual notification in step 6.

There is no formal rule for choosing the labels and pictograms: the main concern is readability. If you do not have time to choose a pictogram, just write the label without any pictogram, like this:

Actions

Actions are the things that actors do. They are the verbs in the step sentences. In our ambulance despatching scenario, the actions are: ‘makes’, ‘encodes’, ‘displays’, ‘allocates’, ‘sends’, ‘notifies’ and ‘drives’.

Steps

A step is a sentence in the active voice that describes who (primary actor) does what (action) with what (objects) and with whom (secondary actors). The sentence can be formulated graphically or textually.

As an example, the first step in our ambulance dispatching scenario is:

Every sentence must start with the primary actor followed by the action verb. The rest of the sentence can contain any number of objects and participating actors. They can be written in any order, as long as the sentence make sense and is grammatically correct. Typical sentence structures are shown in Figure 18.4.

Figure 18.4: Examples of sentence structures

Sequence of steps

A scenario is a sequence of steps ordered chronologically. The first step happens before the second, that happens before the third, etc. Some of the steps may overlap; for example, the second step may start before the first is entirely finished. The sequence is shown by numbering the steps. Each step has a different number.

In a domain story, the numbers are shown next to each action.

Occasionally, you can give two steps the same number to express that they happen in parallel. However, this practice is discouraged because it introduces unneeded complexity. When writing a scenario, if two steps happen in parallel, you can simply number the steps in the order in which you want people to read them. Later, you can use other modelling languages, such as activity diagrams or state machines, to model parallelism.

A scenario has no conditionals, no branching and no loops! The simple linear structure is what makes scenarios so effective for communication. If you need to describe branching and loops, other modelling languages such as activity diagrams and state machines are more appropriate and can be used in combination with domain scenarios. In a later section, we will describe techniques for describing multiple scenarios that share common steps in a concise manner.

Annotations

Annotations can be used to enrich a scenario description with information such as:

information about some actor or object that are useful to understand the scenario;
assumptions about the state of the World at specific point in time in the scenario;
information about the duration, cost, and other characteristics of a step;
a justification why a step is needed, what stakeholder goals requires its presence;
a note that some step is optional, or could be done differently;
a note that some steps may overlap in time;
a question to ask to stakeholders;
and so on.

For example, Figure 18.5 shows two annotations on our ambulance response scenario.

Figure 18.5: A domain story with annotations

You can also add textual annotations to the side or bottom of the scenario. A common practice for example is to place all questions to the side and highlight them in a different color (e.g., with a red background).

In textual scenarios, annotations can be added as footnotes at the bottom of the scenario. For example:

Scenario: an ambulance responds to an emergency call
Context: An incident has just occurred.
Outcome: A first ambulance arrives at the incident scene.

A member of the public makes an emergency call to report an incident to a call handler.
The call handler encodes the incident details into the Computer Aided Dispatch (CAD) system.
The CAD displays a map with the incident location and nearest available ambulances to the call handler.
The call handler allocates an ambulance to the incident in the CAD.
The CAD sends a mobilisation order to the ambulance’s Mobile Data Terminal (MDT).
The MDT signals the mobilisation order to the ambulance paramedics.
The paramedics drive the ambulance to the incident location.

Notes:

In step 1, the emergency call is the first call reporting the incident.
In step 5, the mobilised ambulance is on the road. If the mobilised ambulance was waiting at the station, the mobilisation order would have to be sent to the Station Terminal as well as the Mobile Data Terminal.

Do not use too many annotations as it will make the scenario hard to read.

Title, Context, and Outcome

In addition to the basic elements of Figure 1.3, scenarios can have:

a title providing a short description of the scenario’s content (e.g. “An ambulance responds to an emergency call”).
a context providing information about the state of the World at the beginning of the scenario; the context is also called the precondition.
an outcome providing information about the state of the World at the end of the scenario; the outcome is also called the postcondition.

In textual scenarios, these elements are written as follows:

Scenario: an ambulance responds to an emergency call
Context: An incident has just occurred.
Outcome: An ambulance is at the incident scene.

In graphical scenarios, the title can be the figure caption and the context and outcome are added as annotations.

Naming Scenarios

The scenario title should be short and descriptive.

Avoid generic, uninformative titles such as Default Scenario, Normal Response, Exception 1, or Exception 2.

A useful guideline is to name scenarios like episode titles of Friends, a 1990s American sitcom in which each episode title began with “The One Where …”. For example: “The One Where Monica Gets a Roommate”. To avoid repetition, you can omit the “The One Where” part. For example, instead of “The One Where An Ambulance Responds to An Emergency Call”, our scenario is simply named “An ambulance responds to an emergency call”. To generate such titles, you can also start with “This is a scenario where …” and fill in the blank with a short phrase. The resulting phrase will often make a clear and effective scenario title.

Types of Scenario

Scenarios can be of different types:

As-is vs. to-be scenarios. An as-is scenario describes the World-as-is; a to-be scenario the World-to-be.
Positive vs. negative scenarios. A positive scenario describes a desirable sequence of steps; a negative scenario an undesirable sequence, i.e. one that violates some stakeholder goal. These categories are not exclusive: a scenario may be positive for one group of stakeholders but negative for another.
Normal vs. alternative vs. exceptional scenarios. A normal scenario describes the default or typical way to achieve some goal. An alternative scenario describes a variant of the normal scenario. An exceptional scenario is a variant of a normal scenario in which some undesired event occurs.

Examples.

The scenario in Figure 18.1 is a positive scenario that illustrate the typical way to respond to an emergency call.
An alternative scenario is one where in step 4, the dispatcher selects an ambulance that is waiting at an ambulance station, rather than one that is one the road. In the next step, the mobilisation order must then be sent both to the station terminal and the ambulance mobile data terminal, ensuring that the paramedics receive it even if they are inside the station.
An exceptional scenario is one where during step 7, the ambulance breaks down before arriving at the incident scene. In this case, the paramedics call a dispatcher to report the failure, and another ambulance is mobilised.
Negative scenarios include cases where no ambulance arrives at the incident, or where multiple ambulances are mobilised when only one is needed.

18.3 Three Notations

Domain scenarios can be described in many different ways. Three common notations are textual scenarios, domain stories, and sequence diagrams.

Textual Scenarios

In the textual notation, a scenario is written as a numbered list of sentences, as shown in Figure 18.1. This is the most common way to describe scenarios. In the UML, this notation is used to write individual scenarios associated with business use cases.

An advantage of textual scenarios is that they are easy to write. You don’t need to draw icons, and you can create them with any text editor.

A downside is that, because they are so easy to write, you are more likely to produce scenarios that are too long, have weak sentence structures (e.g., a passive sentence with no primary actor), or omit important world objects. These common mistakes will be discussed further in Section 18.6.

Textual scenarios can also be less appealing to read and less engaging than graphical ones, particularly in collaborative workshops with stakeholders.

Many people find that the ease of writing outweighs these downsides in many contexts, including workshops. Ultimately, the extent to which you and your stakeholders prefer textual narratives over visual representations will influence your choice of notation.

Domain Stories

A domain story is a graphical representation of a scenario: actors and objects are shown as icons, and steps as connections between between icons, as shown in Figure 18.2.

A domain story must satisfy two constraints:

Each actor can appear at most once per domain story.
Each step has its own work objects. If an object is used in multiple steps, you must draw the object multiple times.

Additional rules improve the domain story readability:

Actors are drawn larger than objects so they are easier to spot. Stakeholders who identify with an actor can more quickly see their roles in the scenario.
Actors and objects should use distinct icons. The same icon can be used for multiple actors or for multiple objects, but it should not be used once to represent an actor and elsewhere to represent an object.
Keep the set of icons small and simple. Using too many icons makes the scenario harder to create and to read.

The domain story notation was designed for collaborative modelling workshops, where scenarios are drawn on physical or digital whiteboards visible to all participants. Its strength lies in its ability to engage participants in the elaboration and discussion of scenarios during these workshop. The graphical presentation helps to visualise and structure oral discussion.

Outside of elicitation workshops, domain stories can also be useful to communicate scenarios to a variety of stakeholders, notably to users and to the software development team.

Sequence Diagrams

Sequences diagrams are another notation that can be used to represent domain scenarios. An example is shown in Figure 18.6.

Figure 18.6: A Sequence Diagram for the ambulance response scenario

In a sequence diagram, each actor has a vertical time line showing the sequence of steps the actor is involved in. Each step corresponds to a transfer of a message or information from a source actor (the primary actor) to a target actor (a participating actor). All steps have the same sentence structure:

An actor sends a message to another actor

Sequence diagrams are part of the UML. The notation is based on Message Sequence Chart that was originally created to model scenarios in telecommunication systems. In such systems, scenarios are sequences of messages transmitted from one actor to another.

In software engineering, sequence diagrams are mostly used to describe sequences of interactions between software components at the architecture level, or between objects at the design and implementation levels. For requirements engineering, however, the notation is less useful because it is less expressive than textual scenarios and domain stories, and it often appears more formal and intimidating to stakeholders.

One of its benefits, however, is that it has automated tool support–for checking consistency with state-transition diagrams, for inferring state transition diagrams, and for generating implied scenarios (new scenarios that are implicit in given scenarios due to the distributed nature of the system).

18.4 Structuring Scenarios

It is useful to structure scenarios, either to make a single scenario easier to understand or to organize a collection of scenarios. Here, we describe 4 common techniques for structuring scenarios:

Showing organisational boundaries (in domain stories)
Splitting a scenario into parts.
Describing variants and exceptions.
Visualizing changes between as-is and to-be.

In the modelling guidelines, Section 18.5.2 will also describe how to structure scenarios by goals.

Showing Organisational Boundaries

Structure can be added to a domain story by drawing organizational boundaries around groups of actors.

For example, Figure 18.7, which was introduced in Section 6.1, illustrates a tendering process scenario involving actors from both client and provider organizations.

Figure 18.7: A domain story showing organisational boundaries for the tendering process in client projects

These boundaries can separate actors in different organizations or those in different departments within the same organization. Similarly, boundaries can group actors based on their geographical location.

In textual scenarios, such organizational boundaries cannot be represented.

Splitting a Scenario into Parts

A domain scenario can be split into parts, where each part is a sequence of steps that mark a significant, coherent progression in the scenario. Think of these parts as acts in a theater play or film script.

For example, the ambulance response scenario of Figure 18.1 can be organised into four parts as follows.

Scenario: an ambulance responds to an emergency call

Part I: Call Taking

A member of the public makes an emergency call to report an incident to a call handler.
The call handler encodes the incident details into the Computer Aided Dispatch (CAD) system.

Part II: Ambulance Allocation

The CAD displays a map with the incident location and nearest available ambulances to the call handler.
The call handler allocates an ambulance to the incident in the CAD.

Part III: Ambulance Mobilisation

The CAD sends a mobilisation order to the ambulance’s Mobile Data Terminal (MDT).
The MDT signals the mobilisation order to the ambulance paramedics.

Part IV: Driving to Incident

The paramedics drive the ambulance to the incident location.

The sequence of parts form the scenario outline. This outline can be shown graphically like this:

Figure 18.8: Outline of the normal response scenario

In a visual domain story, we can show parts by drawing boundaries around successive steps and giving a name to the enclosed areas. Figure 18.9 shows an example.

Figure 18.9: Domain story for the ambulance response scenario organised into parts

The usual style for drawing parts is to surround the actions and objects of all steps included in the part, and to leave out actors who play a role in multiple parts. An actor who plays a role in a single part can be shown inside the part boundary (e.g. the Ambulance MData Terminal in the Ambulance Mobilisation part) or left outside (e.g. the Public actor in the Call Taking part).

Describing Variants and Exceptions

We sometimes want to describe variants and exceptions to a main scenario. These are scenarios that share initial steps with the main scenario, diverge at a point of variation, and may converge with it again later. We would like to describe these scenarios in a way that makes their relation to the main scenario explicit without repeating the common steps.

This section presents three common approaches:

Alternative Flows in Textual Scenarios.
Scenario Outline Graphs (to be used with textual scenarios, domain stories, and sequence diagrams).
Showing Variants and Exceptions as Annotations (to be used in a domain story).

Alternative Flows in Textual Scenarios

A first approach, used in textual scenarios, is extend the main scenario with alternative flows. For example, this is our ambulance response scenario extended with two alternative flows:

Scenario: an ambulance responds to an emergency call

Part I: Call Taking

A member of the public makes an emergency call to report an incident to a call handler.
The call handler encodes the incident details into the Computer Aided Dispatch (CAD) system.

Part II: Ambulance Allocation

The CAD displays a map with the incident location and nearest available ambulances to the call handler.
The call handler allocates an ambulance to the incident in the CAD.

Part III: Ambulance Mobilisation

The CAD sends a mobilisation order to the ambulance’s Mobile Data Terminal (MDT).
The MDT signals the mobilisation order to the ambulance paramedics.

Part IV: Driving to Incident

The paramedics drive the ambulance to the incident location.

Alternative flows

Part III variant: Mobilisation of an ambulance waiting at the station

5.a. If the allocated ambulance is waiting at an ambulance station:

The CAD sends a mobilisation order to the ambulance’s Mobile Data Terminal (MDT) and to the station’s terminal
The paramedics see the mobilisation order on the station display.

Continue to Part IV of the main scenario.

Part IV exception: Failed mobilisation

7.a If the ambulance does not respond to the mobilisation instruction within 3 minutes:

The CAD signals a failed mobilisation to a call handler.

Continue to Part II of the main scenario.

An alternative flow is read as follows:

The first line specifies the step where the alternative flow deviates from the main flow (e.g. 5), gives this alternative flow an identified (e.g. a), and an optional condition for entering the alternative flow (e.g. “If the allocated ambulance is waiting at an ambulance station”). If the condition is missing, it is interpreted as “true”.
This is followed by a sequence of numbered steps. Each of these steps can be referred to by prefixing their number with the alternative flow’s starting step and identifier (e.g. 5.a.1 and 5.a.2).
The alternative flow may branch back to the main scenario, or terminate after its last step. Branching back can be to a part (e.g. “Continue to Part IV”) or a step (e.g. “Continue to step 7”).

In our example, the full sequence of steps for the scenario described by the first alternative flow is [1, 2, 3, 4, 5.a.1, 5.a.2, 7]. If written independently, this scenario would list only these seven steps. The activation condition and branch-back instruction are meta-information for structuring the narrative and are not part of the scenario itself.

Remember, a scenario is a partial description of a world. It does not include branching logic, nor must it describe every event occurring between its start and end. For example, the alternative scenario where the ambulance is waiting at the station omits the main scenario’s step 6, even though that event would still occur in the world.

Variants and exceptions can only be used to describe scenarios within the same world as the main scenario-either the world-as-is or the same version of the world-to-be. They represent alternative sequences of events within the same world, not alternative ways to achieve the same goal in a different world. Techniques for contrasting scenarios across different worlds (e.g., As-Is vs. To-Be) will be discussed later.

Do not try to model all possible variants and exceptions to the main scenario. You would have to write so many variants and exceptions (including alternative flows within alternative flows) that your scenarios would become incomprehensible and difficult to maintain. The primary purpose of domain scenarios is to facilitate discussions with stakeholders, not to exhaustively capture all possible behaviors. For complete behavioral specifications, other modelling languages like process models, activity diagrams, or state machines are far more effective.

Although domain scenarios are inefficient for modelling large number of variants and exceptions, they are an excellent starting point for identifying the many variants and exceptions that need to be investigated (see Chapter 10).

Scenario Outline Graphs

Another way to describe variants and exceptions is by drawing a scenario outline graph that shows the connection between scenario parts. Figure 18.10 illustrates this for our ambulance response scenario.

Figure 18.10: Scenario outline for a normal ambulance response with a variant and exception

Each part of a scenario outline graph represents a sequence of events that can be expressed either as a textual scenario, a domain story, or a sequence diagram. A single part may be reused across multiple scenario outline graphs.

Scenario outline graphs are best known for their use with Message Sequence Charts (a variant of Sequence Diagrams), where they are referred to as high-level Message Sequence Charts (hMSC).

The recommendation for drawing scenario outline graphs is the same as for alternative flows in textual scenarios: use them to illustrate a few important variants and exceptions only, rather than attempting to model every possible scenario.

Showing Variants and Exceptions as Annotations

In domain stories, a simple way to represent variants and exceptions is by annotating the main domain story. Figure 18.11 shows an example.

Figure 18.11: Variants and exceptions as annotations in a domain story

Visualising changes between as-is and to-be

Sometimes, we want to describe how a scenario in the world to-be differs from the corresponding scenario in the world as-is.

A useful approach is to present the two scenarios side by side, highlighting what is removed from the as-is and what is added in the to-be.

For domain stories, the default convention is to use colours:

Red for elements that are removed or changed in the as-is scenario.
Green for elements that are new or changed in the to-be scenario.

For accessibility, note that red and green will not appear together in the same story: red is used only in the as-is scenario, and green only in the to-be.

As an alternative or supplement to colours, you can use line styles:

Dashed lines for elements removed or changed in the as-is scenario.
Thicker lines for elements added or changed in the to-be scenario.

For textual scenarios, you can adopt a similar visualisation to text file comparison tools. For example:

Red background for lines removed or changed in the as-is.
Green background for lines added or changed in the to-be.

18.5 Modelling Guidelines

Good scenarios are easy to read, but not always easy to write. This section provides general guidelines to help you write clearer and more effective scenarios.

General Guidelines

Remember Your Objective

When writing scenarios, it is important to keep your objective in mind. You may be modelling solely for your own understanding, engaging in collaborative modelling to support shared learning, or preparing scenarios to explain ideas to others. Each purpose requires a slightly different emphasis.

If you are modelling alone, treat your scenarios as rough sketches that you may later refine or discard. The goal is to explore and learn about the application domain—for example, in preparation for meeting stakeholders. You might sketch domain stories while reading a system description to familiarise yourself with the domain, learn its terminology, and identify gaps or ambiguities that you can later clarify with stakeholders.

If you are working with stakeholders during interviews or workshops, the priority is to keep them engaged. Scenarios should be easy to read and should reflect how stakeholders see their world. Do not obsess over presentation—the scenarios are only a means to support discussion and to build a shared understanding of the world-as-is and ideas for the world-to-be.

If you are writing scenarios to serve as documentation, then you can invest more effort in polishing their presentation. In this case, scenarios are not just temporary sketches but also communication artefacts intended to be read later.

Aim for Clarity

Clarity is more important than detail. Scenarios should be engaging and easy for stakeholders to read and understand.

Do Not Aim for Completeness

The purpose of domain scenarios is to support learning and discussion, not to document every possible behaviour. A few well-chosen scenarios are usually enough to explore the application domain productively. Scenarios should be seen as a starting point—one that can later be developed into more complete models such as goal models, state machines, or process models.

Structuring Scenarios with Goals

An overarching principle for writing effective scenarios is to structure them around goals.

Goals serve two important roles in domain scenarios:

Shaping the narrative. A scenario should never be an aimless sequence of events. Each one illustrates how a particular domain goal is achieved or failed.
Organising scenarios. Goals provide a natural way to group related scenarios. Different scenarios that illustrate the same goal can be presented together, making the overall model easier to understand.

For example, the scenario in Figure 18.1 illustrates the domain goal:

When an incident is reported, an ambulance must arrive at the incident scene within 14 minutes.

The variants and exceptions in Section 18.4.3 illustrate the same goal.

To write domain scenarios illustrating a goal, follow these guidelines:

1. Start at the goal’s triggering event

Begin the scenario with the goal’s triggering event—the domain event that creates the need for a response.

For example, the first step in Figure 18.1 corresponds to the goal’s triggering condition: “an incident is reported.” The scenario should not include prior events, such as the incident’s occurrence or events leading up to it. If necessary, the state of the world at the start of the scenario can be described in the scenario’s context (its precondition).

2. End when the goal is achieved or fails

Continue the scenario until the goal is completed or fails. The final step must correspond to an event that either achieves or violates the goal.

For example, the last step in Figure 18.1 corresponds to the goal’s achievement: an ambulance arriving at the incident scene. The scenario should not end earlier or continue beyond this point. Do not extend the scenario to subsequent actions, such as attending to the injured or transporting them to a hospital.

3. Keep to the storyline (“avoid incidental details”)

Include only steps that are directly relevant to showing how the goal is achieved or fails. Steps unrelated to the goal should be omitted.

For example, in the ambulance response scenario, the scenario does not include steps such as the call handler logging into the CAD system, paramedics starting their shift, or the CAD updating the ambulance’s location from GPS messages.

Events that occur during the scenario but do not affect the goal’s outcome should be left out. A scenario is intentionally a partial description of the world, focusing only on the events that matter for achieving or failing the goal.

4. Move the story forward (“choose the right level of details/abstraction”)

Each step must make significant progress towards achieving or failing the goal. Avoid breaking the scenario into long sequences of minor steps that do not significantly advance the goal.

For example, in Figure 18.1, the call-taking process is represented in two steps: the caller reports the incident, and the call handler encodes the details into the CAD system. The scenario does not include a long sequence of questions and answers between the caller and call handler, nor the individual interactions between the call handler and the CAD.

5. Group scenarios by goals

A single goal may be illustrated by more than one scenario: - scenarios as-is and to-be - variants and exceptions in the same world - multiple main scenarios in the same world

Explicitly linking each scenario to the goal it illustrates and grouping scenarios by goal makes the overall collection of scenarios much easier to understand.

Choosing the Goal Level

Scenarios can be written to illustrate goals at different levels:

End-to-end scenarios (top-level): These illustrate the satisfaction (or failure) of a domain boundary goal.
Example: When an incident is reported, an ambulance must arrive at the incident scene within 14 minutes.
Subgoal scenarios (intermediate-level): These illustrate specific subgoals that support the domain boundary goals.
Example: scenarios describing the process of call taking.
Interface scenarios (lowest-level): These illustrate specific machine requirements. They will be elaborated in greater detail in Section Chapter 20.

During requirements exploration, you typically start with end-to-end scenarios and then move to subgoal scenarios to understand and explore how to satisfy specific subgoals in more detail. Interface scenarios are typically developed during the requirements formulation phase.

Essential vs Concrete Scenarios

When modelling domain scenarios, you can represent them either as essential or concrete scenarios:

An essential domain scenario describes fundamental domain concepts, independent of specific technologies.
A concrete domain scenario describes domain actors, objects, and actions in terms of specific technologies.

A common process for modelling domain scenarios is to:

model concrete scenarios for the world-as-is;
abstract these concrete scenarios into essential scenarios;
derive concrete scenarios for the world-to-be.

18.6 Common Mistakes

…

Mistake #1: Scenario is too long

Mistake #2: Missing primary actor

…

Mistake #3: Scenario describes an implementation instead of the domain

…

Mistake #4: Incorrect syntax in domain story

…

18.7 Notes and Further Readings

Use cases were originally introduced to describe sequences of interactions between a user and a machine (Jacobson 1992). They were later extended to domain scenarios, representing sequence of events in the world, not necessarily at the interface between the world and the machine. This chapter focusses on domain scenarios, whereas Chapter 20 covers interaction scenarios, such as those captured by traditional use cases.

Our presentation of domain stories is based on Hofer and Schwentner’s book Domain Storytelling (Hofer and Schwentner 2021). The book, together with its accompanying website domainstorytelling.org, includes practical guidance for applying domain stories in practice. The authors describe domain stories as a descendant of Rich Pictures, an informal diagramming technique central to the Soft Systems Methodology (SSM), one of the earliest approaches to dealing with wicked (ill-defined) problems in system analysis and information systems (Checkland and Poulter 2007).

Guidance on discovering and elaborating domain scenarios in the context of the VOLERE requirements engineering method can be found in the “Business Use Cases” chapter of Mastering the Requirements Process (Robertson and Robertson 2012).

The guideline for structuring scenarios around goals originates from Alastair Cockburn in the context of use case modeling (Cockburn 1997). The presentation in this chapter is based on guidance from his seminal book on writing effective use cases (Cockburn 2000).

A wide range of scenario-based requirements engineering techniques—featuring contributions from leading industry consultants and experience reports from various organisations—are presented in Scenarios, Stories, Use Cases : Through the Systems Development Life-Cycle (Alexander and Maiden 2005). The book, edited by Ian Alexander and Neil Maiden, two early champions of scenario-based requirements engineering, provides detailed guidance on discovering, elaborating and analysing scenarios across a variety of contexts throughout the software lifecycle.