See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4035245

Scenario-Based Requirements Engineering

Conference Paper · October 2003

DOI: 10.1109/ICRE.2003.1232776 · Source: IEEE Xplore

CITATIONS READS
250 18,149

1 author:

Alistair G. Sutcliffe
The University of Manchester
365 PUBLICATIONS 11,376 CITATIONS

SEE PROFILE

All content following this page was uploaded by Alistair G. Sutcliffe on 21 May 2014.

The user has requested enhancement of the downloaded file.

 RE 2003 Mini-tutorial

Scenario-based Requirements Engineering

Alistair Sutcliffe
Centre for HCI Design, Department of Computation
University of Manchester Institute of Science & Technology (UMIST)
PO Box 88, Manchester, M60 1QD, UK
[email protected]

Abstract behaviour thereof), through to implementation, training

and documentation. Kutti [4] distinguishes between
This mini tutorial explains the concepts and process of scenarios in the wide, which describe the system and its
scenario based requirements engineering. Definitions of social environment, and scenarios in the small that
scenarios are reviewed, with their informal and more contain event sequences pertaining to a specific design.
formal representations, and roles in the requirements Anton and Potts [5] survey the different representations of
process. The relationships between scenarios, scenarios in HCI, object-oriented software engineering
specifications and prototypes is explored, and set in the and RE, ranging from informal narrative to formatted
perspective of human reasoning about requirements. texts and more formal models. They also compare
Methods for scenario based RE are described and one scenarios as models with concrete scenarios or instances
method, SCRAM, is covered in more depth. The tutorial that represent a single example of an event sequence [6].
concludes with a look forward to the future of scenario Scenarios can vary from rich narrative descriptions of a
based RE and research directions. system’s use with information about the social
environment [7] to descriptions of event sequences in
1. Introduction tabular formats (e.g [8]) to more formal models of system
behaviour [9, 10]). In object-oriented design it becomes
Scenarios have attracted considerable attention in RE, difficult to distinguish between use cases, alternative
but unfortunately the term scenario has been interpreted paths through use cases, and scenarios, which are just
by too many authors to have a commonly accepted another path through a use case [11, 12, 13].
meaning. The Oxford English Dictionary defines a Probably the best way to understand scenarios is as a
scenario as “the outline or script of a film, with details of continuum from the real world descriptions and stories to
scenes or an imagined sequence of future events”. models and specifications. At one end of this dimension,
Scenarios are used in business systems analysis as well as scenarios are examples of real world experience,
RE, the most common form being examples or stories expressed in natural language, pictures, or other media
grounded in real world experience. [14, 15]). At the specification end are scenarios which are
Jarke et al. [1] reviewed approaches to scenario- arguably models such as use cases, threads through use
based RE, research issues, and different scenario cases and other event sequence descriptions [11, 16].
concepts; indeed their article introduces a whole issue of Within the space of scenarios are representations that vary
the Requirements Engineering journal devoted to use of in the formality of expression in terms of language and
scenarios. Rolland et al. [2] provide a good survey which media on one dimension and the phenomena they refer to
distinguishes between the purpose or intended use of a on the other; ranging from real world experience, to
scenario, the knowledge content contained within a invented experience, to behavioural specifications of
scenario, how a scenario is represented, and how it can be designed artefacts.
changed or manipulated. Another taxonomy by Carroll [3]
classifies scenarios according to their use in systems 2. Scenarios as design representations
development ranging from requirements analysis (stories
of current use), user-designer communication, examples Scenarios are related to models by a process of
to motivate design rationale, envisionment (imagined use abstraction and to prototypes by a process of design (see
of a future design), software design (examples of figure 1). Scenarios which are representations of the real
world are generalised during requirements analysis to description [7]. In this case the scenario comes
produce models, which are familiar to practitioners in close to a design mock up.
requirements engineering (e.g. i* [17]) or software 3. A single thread or pathway through a model
engineering (e.g. UML, [18]). Other informal (usually a use case). This is the sense in which
representations such as design rationale [19] can capture the object-oriented community use the word [11,
design decisions that are anchored in a scenario-based 13, 18]. This might be represented as an
expression of a problem. Models and requirements animated display of an event sequence in a
specifications become transformed into designs and message sequence or state transition diagram
eventually implemented. During that process scenarios Thus scenarios may vary according to their content,
which represent behaviour of designed artefacts have a how closely they relate to the real world, and their role in
role to play in validation. In this case scenarios are similar the design process. A scenario of the following form
to models in both format and content, although they clearly relates to the real world, is a narrative text, and
usually illustrate possible sequences of behaviour that expresses a user’s requirements in some sense. Although
might be valid within the constraints of a requirements it relates to the real world it is in fact made up by myself,
specification [9]. albeit from case study experience:
In an alternative development route via prototyping, Dr Patel has been given health education targets
scenarios function as design inspiration, and material to to fulfil by the government. He hasn’t time to
test the prototype design [3, 15, 20]. Scenarios can be counsel individual patients about life style and
used for reasoning about design and as test scripts in healthy living, but he is interested in how
evaluation methods [21, 22]. Carroll has articulated computers might help. He thinks that if a
several different roles for scenarios in the design process computer “advisor”-type system were placed in
including as envisionment for design exploration, his surgery waiting room, patients with time on
requirements elicitation and validation [3, 23]. their hands might explore the system out of
curiosity and learn something about healthy
User living. He wants to target heart disease and
behaviour System
Problems context educate the public about the dangers of smoking,
lack of exercise and other lifestyle causes of
Requirements
Requirements
Real world heart disease. Unfortunately most of the people
scenarios who come into his surgery have seen many
generalise to create & validate
warnings about smoking before and seem to take
no notice.
Design rationale create Storyboards
Models Concept demonstrators This scenario can funtion as a design brief to initiate a
Specifications Prototypes requirements capture process. A more detailed scenario
reflect,
thread validate
could record a day in the life of Dr Patel and his
traces from illustrate interaction with one individual patient, Mr Hardcastle. In
Designed artefact the latter case a scenario would be drawn from directly
scenarios recorded conversation as found in ethnographic studies
[24].
Simulations
Visions Depending on one’s usage, scenarios are represented
in different media. Scenarios that describe the real world
System event User are captured as speech or text narratives and may be
+
sequences behaviour
embellished with photographs or videos to illustrate the
context. Real world scenarios may be interpreted and then
Figure 1. Role of scenarios and their relationship represented as formatted text and by pathways in use case
to requirements specifications and prototypes. or activity sequence diagrams. Designed world scenarios
can be represented by anything from a storyboard sketch
These views of scenarios point to three different roles: to animated sequences in a formal specification [25] or in
1. A story or example of events as a grounded a concept demonstrator [20], so scenarios start out as
narrative taken from real world experience [3]. stories and examples but converge with models and
These stories are close to the common sense use prototypes during design.
of the word and may include details of the
system context (scenes).
2. A future vision of a designed system with
sequences of behaviour and possibly contextual
3. Advantages and disadvantages of scenarios
 The advantage of scenarios lies in the way they Ideally the more scenarios the better to increase test
ground argument and reasoning in specific detail or coverage, but gathering and using more scenarios incurs
examples, but the disadvantage is that being specific loses cost. The problem is that we need many scenarios to test a
generality. We all naturally look for patterns and general requirements specification, but how can we be
similarities in the world, which is the cognitive process of sure we have a complete or even an adequate set? This
generalisation. In RE our reasoning process is the same. can be summarised as the 20/20 foresight problem: how
Scenarios in the real world sense are specific examples. to capture (or generate) a sufficient set of scenarios to
The act of analysis and modelling is to look for patterns in cover all the important problems in the application. I will
real world detail, then extract the essence, thereby return to this in section 7.
creating a model. So scenarios fit into the process of
requirements elicitation which gathers stories and 4. Scenarios in the requirements and design
examples from users and then looks for the generalities. process
Another advantage of scenarios lies in their focus on
reality that forces us to address the “devil in the detail” One particular role of scenariosis to act as a
during requirements specification and validation. In this “cognitive prosthesis” or an example to stimulate the
case we confront abstract models with scenarios as test designer’s imagination. Scenarios can guide thought and
data. Whereas an abstract model can go unquestioned, support reasoning in the design process [15, 31].
unless rigorous automated reasoning is used via formal However, this approach can lead to errors. A scenario, or
methods [26], the detail in scenarios naturally challenges even a set of scenarios, does not explicitly guide a
assumptions in models. Examples exert a powerful effect designer towards a correct model of the required system.
on our reasoning because we can identify with detail An extreme scenario might bias reasoning towards
through our experience. Real world scenarios are a form exceptional and rare events, or towards the viewpoint of
of episodic memory [27] that can give rich details of an unrepresentative stakeholder. These biases are an
events and scenes, but the requirements engineer has to acknowledged weakness of scenarios; however, we can
beware that people’s episodic memory can be highly trust designers as knowledgeable, responsible people who
selective, so a sample of scenarios may represent atypical are capable of recognising such biases and dealing with
events from a personal viewpoint. Since scenarios situate them productively. Indeed, some propose scenarios that
examples with existing memory they help in are deliberately exceptional to provoke constructive
understanding requirements problems. The concept of thought [32]. Although scenarios are useful as cognitive
obstacles analysis in RE [28] draws on scenarios to situate probes for design, this is not their only role.
our thought about how problems in the real world (i.e.
obstacles) might prevent a requirement being met.
Scenarios can help to counteract pathologies in Visioning
Scenarios
scenarios inspiration
human reasoning [29], such as not testing hypotheses and of use
assumptions in models. In RE scenarios can help to test
models and specifications during requirements validation; Problem Requirements input for
statement motivation Analysis modelling
unfortunately, scenarios can also encourage other scenarios Context & use
pathologies, so we need to be on our guard. First is scenarios

confirmation bias: we tend to seek only positive examples Maintenance generalisation

Specification for model
that agree with our preconceptions [30]. Scenarios should & Design
be collected which include errors, counter-examples and
exceptions as well as the norm. Encysting, or not being
able to see the wood for the trees, can result from Implementation
becoming obsessed with the detail in scenarios. Both the & Testing Requirements
model, abstract and detailed scenario views are necessary. Validation
Context & use
test data
Unfortunately the products of the generalisation process, scenarios
Usage test data
abstract models, are not so easily understood; however, scenarios
reasoning with concrete examples as well as abstract
models helps comprehension by building a memory
Figure 2. Roles of scenarios in requirements and
schema linking the specific (scenario) with the general
design.
(model). This can improve requirements elicitation and
Scenarios are arguably the starting point for all
validation. Scenarios can bias beliefs in frequencies of
modelling and design, and contribute to several parts of
events and probabilities [29], so it is important to ensure
the design process (see figure 2). Scenarios of use
that a wide ranging sample of scenarios are gathered. This
describe system operations at different stages of
exposes one of the dilemmas in scenario based RE.
development. Context scenarios add information about
the system’s physical and social environment. At the In HCI scenario-based methods have become an
initiation of development, scenarios play three roles: first accepted approach for requirements discovery and design
as descriptions of the unsatisfactory state of affairs with a exploration. For example, Carroll [15] proposes scenarios
current system which the new system has to solve; of use with claims, a design rationale that represents a
secondly as visions of how the new system might operate; design principle with advantages and disadvantages.
and thirdly as descriptions of behaviour, representing both Beyer and Holtzblatt [33] argue for rich scenarios which
users and the existing system. Usage or behavioural describe a business environment as well as system use in
scenarios are a common form and can be used later in the context. Their method uses scenarios in conjunction with
life cycle as test data to validate requirements a suite of models analysing the business, social
specifications, designs and implemented systems. relationships and user tasks, whereas Carroll adopts a
Information on the system’s physical and social context prototyping approach with scenarios functioning as “tools
can be added to usage scenarios, to provide a richer input for thought”.
to requirements specification and validation, for instance Two RE methods have placed considerable
allowing reasoning about obstacles in the system importance on the role of scenarios, the ScenIC method
enivornment which may prevent nt requirements being [27] and SCRAM [20, 29, 34], while many other RE
achieved [27]. methods include scenarios as part of the process (e.g. [35,
Narrative descriptions of the real world provide input 24]).
to the process of generalisation that produces specific ScenIC [27] proposes a schema (see figure 3) of
action sequences (i.e. formatted scenarios) and then a scenario-related knowledge composed of goals,
general model that represents typical behaviour of a group objectives, tasks, obstacles and actors. Scenarios are
of users interacting with a system. The process of composed of episodes and action carried out by actors,
generalisation inevitably loses detail and the analyst has who are usually people but may also be machines.
to make judgements about when unusual or exceptional
behaviours are omitted, or explicitly incorporate them as
alternative paths in use cases or in action sequences [11]. Scenario
Indeed there is merit is eliciting or creating mis-use cases
thwart
that describe threats and exception conditions that will
test the system [12]. A criticism of model approaches to
Goal Obstacle Episodes
requirements engineering is that they inevitably omit
detail which may be vital, whereas scenarios might be express
able to gather such detail but at the price of effort in mitigate
capturing and analysing a “necessary and sufficient” set Objective Task Actions
of scenarios. prevent

Actor represent
5. Methods for scenario-based requirements
engineering
One productive juxtaposition of scenarios and models Figure 3. Schema of scenario-related knowledge
is to use scenarios as test data to validate design models. after Potts [27].
This approach, proposed in the Inquiry Cycle [8] and its
scuccessor ScenIC, uses scenarios as specific contexts to Goals are classified into achieving, maintainting or
test the utility and acceptability of system output. By avoiding states, while obstacles prevent goals from being
questioning the relevance of system output for a set of achieved, or inhibits successful completion of tasks. The
stakeholders and their tasks described in a scenario, the method proceeds in a cycle of expressing scenarios in a
analyst can discover obstacles to achieving system semi-structured format, criticising and inspecting
requirements. Input obstacles can be derived from scenarios in walkthroughs which leads to refining
scenarios to test validation routines and other functional requirements and specifications and the next cycle.
requirements. Obstacle analysis has since been refined Guidelines are given for formatting scenario narratives
into a formal process for discovering the achievability of and identifying goals, actions and obstacles. Scenario
system goals with respect to a set of environmental states, episodes are assessed with challenges to see if goals can
taken from scenarios [28]. Scenarios, therefore, can fulfil be achieved by the system tasks, whether the actors can
useful roles either as test data, as a stimulant to reasoning carry out the tasks, whether obstacles prevent the actors
in validating system requirements, or by providing data carrying out the tasks, etc. In this manner dependencies
for formal model checking. between goals, tasks, actors and resources can be checked
to make sure the system meets its requirements.
Dependency analysis and means-ends analysis, in which x Initial requirements capture and domain
tasks and the capabilities of actors are examined to ensure familiarisation. This is conducted by
goals can be achieved, are also present in RE methods conventional interviewing and fact-finding
such as i* [17], and this illustrates the convergence of techniques to gain sufficient information to
scenario- and model-based analysis in requirements develop a first concept demonstrator. In practice
engineering. Two paragraphs hardly do justice to ScenIC; this takes 1-2 client visits.
however, my purpose was to draw attention to the x Storyboarding and design visioning. This phase
importance of obstacle analysis, and urge the reader to creates early visions of the required system that
consult more detail in Potts [27]. are explained to users in storyboard
In SCRAM (Scenario-based Requirements Analysis walkthroughs to get feedback on feasibility.
Method), scenarios are used with early prototypes to elicit x Requirements exploration. This uses concept
requirements in reaction to a preliminary design. The demonstrators and early prototypes to present more
approach is based on the hypothesis that technique detailed designs to users in scenario-driven, semi-
integration provides the best avenue for improving RE interactive demonstrations so the design can be
and that active engagement of users in trying out designs critiqued and requirements validated.
is the best way to get effective feedback for requirements x Prototyping and requirements validation. This phase
validation. Another motivation is to use scenarios as a develops more fully functional prototypes and
means of situating discussion about the design, so that continues refining requirements until a prototype is
new requirements can be elicited by reasoning about agreed to be acceptable by all the users.
problems posed by scenarios describing a context of use. The method provides process guidance for conducting
This approach essentially merges the elicitation and walkthroughs and organising the requirements analysis
validation role of scenarios by providing the context for process, with guidelines for interviewing and managing
the user to assess a design which itself is presenting a requirements conversations. Initial requirements capture
scenario of use. The method steps of SCRAM are gathers facts about the domain and captures users’ high-
illustrated in figure 4. level goals for the new system. Scenarios are elicited as
examples of everyday use of the current system, with
stories of problems encountered and how they are dealt
Managers, project with. Gathering a sufficient set of scenarios is a vexed
users initiation Scenarios
user tasks question. There are several problems that might be
Initial
requirements encountered:
capture x Users tend to miss out steps in scenarios that
high level
vision/requirements Storyboarding Mockups, they assume are known to the analyst: the
and design storyboards implicit or tacit knowledge problem.
visioning
Concept x Each person may give an individual view of
demonstrator
requirements & problems encountered. It can be difficult to distil
Initial design
Requirements
exploration and Users
a set of common problems from users with
validation diverse views.
x Acquiring a sufficient set of scenarios to cover
Scenarios requirements & not only normal use but also situations when
design rationale interactive design Prototyping and things go wrong can take considerable effort.
requirements validated
validation requirements
The volume of scenarios can become daunting,
& refined design and this presents a problem of finding a valid
Final
sub-set.
Test tasks development x People tend to either forget abnormal examples
scenarios
or to exaggerate problems. Problems
encountered most frequently and recently will be
Figure 4. Process road map of the SCRAM recalled first, but individuals will remember
method. different episodes. Unravelling these potential
biases can be difficult, e.g. a personality clash
SCRAM does not explicitly cover modelling and may make a particular problem vivid for one
specification, as this is assumed to progress in parallel, individual whereas for everyone else, the
following the software engineering method of the problem was minor.
designer’s choice (e.g. UML and Unified Process [18]). The best way to proceed is to gather scenarios of
The method consists of four phases: normal system use; look for commonalties between
different individual versions and create a common
“normal use case”. Note that where individual variations
occur, these can be useful hooks for questions later on Figure 5. Storyboard sketches for a ship
about different individual strategies for using the system. emergency management system.
Once the normal use case is in place, gather a set of
exceptions (c.f. alternative paths in use cases). The Storyboards are created by developing a preliminary
number of alternatives necessary depends on system design from a sub-set of the usage scenarios gathered in
complexity and safety criticality. This phase also captures phase 1. Storyboards are sketches or mock up screens that
users’ high-level goals. show key steps in user system interaction. Figure 5
Scenarios complement goal modelling because, while illustrates a storyboard sequence derived from the
goals focus on abstractions that describe users’ intentions, scenario script. The analyst walks through the storyboard
scenarios make abstract intentions clearer by giving explaining what happens at each stage in terms of system
examples of how a new system might work to fulfil users’ functionality, and asks for the users’ opinions. The
goals. Policies and high-level aims are decomposed into limitation of storyboards is their poor interactivity. Users
lower-level goals, and scenarios of business strategy, can be asked to simulate the actions they would carry out,
competitors’ actions and system operation can help this but mimicking the system response is more difficult. One
process. To give an example, in safety critical systems the of the merits of storyboards and scenarios is that they help
top level policy might be “to expedite the safe navigation involve users in design. When users voice concerns about
of the ship within the constraints of operational a design, users’ reactions and suggestions for
efficiency”. The weakness of goal modelling is recording improvements are recorded. Storyboards and paper
vague intentions without real thought about their practical prototyping allow for quick iterations of a design, but they
implications. Scenarios can help by making the abstract can mask the system functionality. Better feedback will
concrete. As visions of the future system’s usage, be obtained by demonstrating an interactive prototype in
scenarios cannot be created until analysis has decomposed the next phase of requirements exploration.
the system to a level where some detail of sub-goals is Prior to the session the concept demonstrator is
apparent. An example might be “the system diagnoses the developed and tested. A concept demonstrator is an early
potential fire hazards with different types of cargo and prototype with limited functionality and interactivity (see
recommends safety measures to take if the cargo is likely figure 6), so it can only be run as a “script”. Scripts
to be explosive or emit noxious chemicals. The illustrate a scenario of typical user actions with effects
information is passed to the fire fighting crew who can mimicked by the designer. Concept demonstrators differ
take appropriate action.” This scenario suggests further from prototypes in that only minimal functionality is
questions (and hence discovers further goals) about implemented and the user cannot easily interact with the
assumptions concerning the system’s knowledge of the demonstrator. A contextual scenario is developed based
cargo – which may not be accurate –and whether the crew on the preliminary domain analysis. This is a short
know what the appropriate action is (prompting a possible narrative (half to one page) describing a situation taken
training requirement). Scenarios therefore have their role from the users’ work context, e.g. “a typical day in the life
to play in complementing goal models that record a of ...” running through key tasks. It should also contain
hierarchy of user intentions and their relationships. sufficient background material to “situate” the action, that
1.
is to give the users enough information to interpret the
script. An example for a ship emergency management
+ system follows.
2. Display of hazardous cargo

CO2 Hold 2-L1

alarm isolate colour
sprinkler code for
Fire detected in no. 2
hazard
hold; alarm sounds cargo

3.
Evacuation instructions
Activate automatic systems
? ?
v
v
crew
team status status
engines ready CO2
forward standby evacn x
aft muster x
4. Advice on fire fighting
cargo
Crew muster instructions
and report status
?v strategy
CO2 x
hose
isolate

Give instructions to crew

 session. In a follow-up phase, the users are encouraged to
Figure 6. Concept demonstrator for ship clarify any points they found ambiguous, go back to any
emergency management system. parts of the demonstration, and elaborate further
requirements. The requirements engineers may also
follow up points raised or user comments made during the
session.
Contextual scenario Scenarios can be linked to design decisions
Your ship is a modern container ship of 30,000 tons represented in design rationale diagrams that illustrate
displacement with a multinational (mainly Filipino) crew trade-offs and assumptions affecting choice (see figure 7).
of 36 with five UK officers. The cargo manifest lists Further links can complete the pathway from scenarios to
containers with a mixture of industrial goods and more formal requirements specifications.
domestic removals. You have left Southampton at 10
Steps in scenario Design rationale diagram
a.m. this morning en route to Cape Town and
Fire is detected
are proceeding west down the English Channel + Broadcast
Sound warning warning
heading 250 degrees at 15 knots, position 50 Alarm raised How to raise
-
the alarm Visual alarm Reliable warning
miles south of Plymouth. The weather is fine,
Cause of problem Sound and Provides
visibility range 15 miles, wind NW force 3. At diagnosed visual alarm more
indicates location + information
3.10 a member of the crew reports smoke in
Response planned Requirements Design options Assessment
number two hold, and a fire alarm sounds. issues criteria
A scenario script, based on the captain’s emergency
management task, is used for the concept demonstrator. Figure 7. Design rationale diagram illustrating
1. The location of the fire is investigated and alternative design solutions for requirements
preliminary instructions given to the crew to issues linked to the concept demonstrator
evacuate the area if necessary. scenario script.
2. Automatic fire suppression systems are activated
if present, such as flooding compartments with Once the demonstration has been completed, a
CO2. summary of the requirements is listed on a whiteboard (or
3. Instructions are given by tannoy to the crew to another appropriate medium). The requirements are
proceed to fire muster stations and start to fight discussed and prioritised using an essential/
the fire. useful/optional scale. Design rationale may be introduced
4. Junior officers are assigned to manage key fire in this step to help structure discussion about design
fighting teams. trade-offs with assessment criteria (often non-functional
5. The cargo manifest is checked to see if any requirements) that can be used to judge the merits of
dangerous (explosive, flammable, corrosive, etc) alternative solutions. The process can be repeated using a
cargo is present near the fire. more functional prototype as necessary.
6. Fire fighting tactics are planned to account for
any dangerous cargo and other hazards, e.g. 6. Tool support for scenario-based RE
electrical equipment.
7. Instructions are given to fire fighting crews. The While commercial requirements management tools
progress of fire fighting is monitored and further such as DOORS and Rationale Rose enable scenarios to
instructions given as necessary, until the fire is be recorded either explicitly or in general narrative
under control. comment fields, there are few tools which support the
Note that the scenarios do not attempt to cover all aspects process of scenario-based RE. Formatting and checking
of the users’ tasks or the situation; for instance the scenarios for consistency can be helped by lexicial
damage assessment phase is not described, nor is the approaches which provide a database of keywords and
means of communication between the captain and crew. templates for formatting scenario-related knowledge [36].
A number of validation sessions may be necessary to test The RETH hypertext tool [10] links scenarios, goals and
different parts of the design. functional requirements to support scenario inspections.
Probe questions are asked at key points in the The CREWS-SAVRE tool [37] helped the generation of
demonstration script. The users are invited to critique the variations on a seed scenario by first expanding possible
concept demonstrator. The concept demonstrator is event sequences that could be traced from a use case-like
explained by the analyst, while another member of the behaviour model, then suggesting possible permutations
design team runs and interacts with the system. Limited
hands-on testing may be provided at the end of the
to an event sequence using a taxonomy of errors drawn There are approaches to eliciting and generating
from the human factors literature [38, 39]. better sets of test scenarios besides brute force validation
Scenario-based requirements validation has been by volume. One approach is to use constraint relaxation
explored using high-level descriptions of systems having started with worst case scenarios, and this can be
expressed as Bayesian Belief Nets (BBNs) [40]. Scenarios partially automated by converting scenarios into event
expressed as task-based episodes in a similar manner to sequence models and then running these against a
ScenIC are evaluated with a BBN tool that automatically requirements specification [40].
tests variations in the scenario for environmental While scenarios have become an established
conditions such as weather, and training of human actors. technique in RE and elsewhere, many questions remain
This approach was taken further by applying evolutionary for future research. The trade-off between informal
computing techniques to generate variations in a scenarios as tools for thought and more formal scenarios
requirements specification, then running the specifications which converge with models may vary between domains.
against a set of scenarios, determining which design In some cases scenarios are throw-away examples to
variation had better performance and breeding these stimulate thought; in other cases scenarios become
variations following the principles of evolution [41]. In transformed into models by a systematic process. The
spite of these initiatives, support for scenario-based RE is process of extracting knowledge from and testing with
still primitive. Tools are needed that automatically extract scenarios is still in its infancy. Furthermore, scenarios lie
interesting facts from scenarios, to produce models which on the boundary of informal and formal representations of
can then be checked for consistency, completeness etc. knowledge. The bottleneck is human ability to process
large volumes of narratives and examples. In the future,
7. Reflections and outstanding problems tools that extract information from speech, text and image
may play an increasingly important role in scenario-based
While scenarios are an important and useful addition to RE.
the battery of RE techniques they are not without
problems. The two most critical problems are sampling References
and coverage. Both reflect the tension between specific
detail in scenarios and abstraction in requirements [1] M. Jarke, X.T. Bui and J.M. Carroll, “Scenario
specifications. Sampling is difficult because of Management: An Interdisciplinary Approach,”
representativeness, i.e. how do you know when you have Requirements Engineering, vol. 3, 155-173, 1998.
collected an appropriate and representative set of
scenarios for the current problem? This is linked to [2] C. Rolland, C.B. Achour, C. Cauvet, J. Ralyte, A.G.
coverage: how do you know when you have a sufficient Sutcliffe, N.A.M. Maiden, et al., “A Proposal for a
set of scenarios for adequate testing in requirements Scenario Classification Framework,” Requirements
validation? There are no easy answers to these problems. Engineering, vol. 3, 23-47, 1998.
One approach is to generate variations from a single seed
scenario [29, 34, 42] by using a schema to suggest [3] J.M. Carroll, Ed. Scenario-Based Design: Envisioning
variation points. However, this assumes a formatted Work and Technology in System Development, New York:
scenario which is closer to a model; furthermore, Wiley, 1995.
automatic generation creates too many scenario variants
which swamp the requirements engineer in excessive [4] K. Kuutti, “Workprocess: Scenarios As a Preliminary
detail [16]. The silver bullet of scenario-based RE is the Vocabulary,” in Scenario Based Design, J.M. Carroll, Ed.
20/20 foresight, or how to anticipate critical aspects in a New York: Wiley, 1995, 19-36.
future system environment that will impact on system
requirements. Of course that doesn’t exist otherwise [5] A.I. Anton and C. Potts, “A Representational
governments (e.g. socio-economic scenarios), the military Framework for Scenarios of System Use,” Requirements
(e.g. wargame scenarios) and manufacturers of complex Engineering, vol. 3, 219-241, 1998.
systems (e.g. scenarios for avionics systems) would not
experience the unexpected. Creative brainstorming and [6] A.I. Anton and C. Potts, “The Use of Goals to Surface
reuse of knowledge can improve the practice of scenario- Requirements for Evolving Systems,” 1998 International
based RE. Further research needs to be undertaken to Conference on Software Engineering: Forging New
investigate the dependencies between scenarios and Links, 1998, 157-166, Los Alamitos CA: IEEE Computer
models at different levels of granularity from enterprise Society Press.
business models and competition scenarios [43] to
requirements for designed systems that we are familiar [7] M. Kyng, “Creating Contexts for Design,” in Scenario
with in RE. Based Design, J.M. Carroll, Ed. New York: Wiley, 1995,
85-108.
[20] A.G. Sutcliffe, “Scenario-Based Requirements
[8] C. Potts, K. Takahashi and A.I. Anton, “Inquiry-Based Analysis,” Requirements Engineering, vol. 3, 48-65,
Requirements Analysis,” IEEE Software, vol. 11, 21-32, 1998.
1994.
[21] A.G. Monk and P. Wright, Improving Your Human-
[9] P. Heymans and E. Dubois, “Scenario-Based Computer Interface: A Practical Technique: Prentice
Techniques for Supporting the Elaboration and Validation Hall, 1993.
of Formal Requirements,” Requirements Engineering,
vol. 3, 1998. [22] A.G. Sutcliffe, “Bridging the Communications Gap:
Developing a Lingua Franca for Software Developers and
[10] H. Kaindl, “An Integration of Scenarios with Their Users,” INFORSID, 2000, 13-32, Toulouse: Inforsid.
Purposes in Task Modelling,” DIS 95 Conference
Proceedings, 1995, 227-235, New York: ACM Press. [23] A.G. Sutcliffe and J.M. Carroll, “Generalizing
Claims and Reuse of HCI Knowledge,” BCS-HCI
[11] A. Cockburn, Writing Effective Use Cases, Boston Conference, 1998, 159-176, Berlin: Springer-Verlag.
MA: Addison-Wesley, 2001.
[24] I. Sommerville and G. Kotonya, Requirements
[12] I. Alexander, “Initial industrial experience of misuse Engineering: Processes and Techniques, Chichester:
cases in trade-off analysis”, Proceedings IEEE Joint Wiley, 1998.
International Conference on Requirements Engineering,
2002, 61-70, Los Alamitos CA: IEEE Computer Society [25] P. Dubois, E. Dubois and J. Zeippen, “On the Use of
Press. a Formal Representation,” ISRE '97: 3rd IEEE
International Symposium on Requirements Engineering,
[13] I. Jacobson, M. Christerson, P. Jonsson and G. 1997, 128-137, Los Alamitos CA: IEEE Computer
Overgaard, Object-Oriented Software Engineering: A Society Press.
Use-Case Driven Approach, Reading MA: Addison
Wesley, 1992. [26] C.L. Heitmeyer, R.D. Jeffords and B.G. Labaw,
“Automated Consistency Checking of Requirements
[14] P.A. Gough, F.T. Fodemski, S.A. Higgins and S.J. Specifications,” ACM Transactions on Software
Ray, “Scenarios: An Industrial Case Study and Engineering and Methodology, vol. 5, 231-261, 1996.
Hypermedia Enhancements,” 1995 IEEE International
Symposium on Requirements Engineering (RE '95), 1995, [27] C. Potts, “ScenIC: A Strategy for Inquiry-Driven
10-17, Los Alamitos CA: IEEE Computer Society Press. Requirements Determination,” 4th IEEE International
Symposium on Requirements Engineering, 1999, 58-65,
[15] J.M. Carroll, Making Use: Scenario-Based Design of Los Alamitos CA: IEEE Computer Society Press.
Human-Computer Interactions, Cambridge MA: MIT
Press, 2000. [28] A. Van Lamsweerde and E. Letier, “Handling
Obstacles in Goal-Oriented Requirements Engineering,”
[16] A.G. Sutcliffe, N.A.M. Maiden, S. Minocha and D. IEEE Transactions on Software Engineering, vol. 26,
Manuel, “Supporting Scenario-Based Requirements 978-1005, 2000.
Engineering,” IEEE Transactions on Software
Engineering, vol. 24, 1072-1088, 1998. [29] A.G. Sutcliffe, User-Centred Requirements
Engineering, London: Springer-Verlag, 2002.
[17] J. Mylopoulos, L. Chung and E. Yu, “From Object-
Oriented to Goal-Oriented Requirements Analysis,” [30] P.N. Johnson-Laird, The Computer and the Mind: An
Communications of the ACM, vol. 42, 31-37, 1999. Introduction to Cognitive Science, Cambridge MA:
Harvard University Press, 1988.
[18] Rational Corporation, UML: Unified Modelling
Language Method, [http://www.rational.com], 1999. [31] J.M. Carroll, Ed. HCI Models, Theories, and
Frameworks: Toward a Multidisciplinary Science, San
[19] J. Conklin and M.L. Begeman, “GIBIS: A Hypertext Francisco: Morgan Kaufmann, 2003.
Tool for Exploratory Policy Discussion,” ACM
Transactions on Office Information Systems, vol. 64, 303- [32] J.P. Djajadiningrat, W.W. Gaver and J.W. Frens,
331, 1988. “Interaction Relabelling and Extreme Characters:
 Methods for Exploring Aesthetic Interactions,” DIS2000 [39] J. Reason, Human Error, Cambridge: Cambridge
Designing Interactive Systems: Processes, Practices University Press, 1990.
Methods and Techniques, 2000, 66-71, New York: ACM
Press. [40] A.G. Sutcliffe and A. Gregoriades, “Validating
Functional System Requirements with Scenarios,” IEEE
[33] H. Beyer and K. Holtzblatt, Contextual Design: Joint International Conference on Requirements
Defining Customer-Centered Systems, San Francisco: Engineering, 2002, 181-188, Los Alamitos CA: IEEE
Morgan Kaufmann, 1998. Computer Society Press.

[34] A.G. Sutcliffe and M. Ryan, “Experience with [41] A.G. Sutcliffe, “Evolutionary Requirements
SCRAM: A SCenario Requirements Analysis Method,” Analysis,” IEEE Joint International Conference on
IEEE International Symposium on Requirements Requirements Engineering, 2003,Los Alamitos CA: IEEE
Engineering: RE '98, 1998, 164-171, Los Alamitos, CA: Computer Society Press.
IEEE Computer Society Press.
[42] A.G. Sutcliffe, J.E. Shin and A. Gregoriades, “Tool
[35] J. Robertson and S. Robertson, Mastering the Support for Scenario-Based Functional Allocation,” 21st
Requirements Process, Harlow: Addison Wesley, 1999. European Conference on Human Decision Making and
Control, 2002,.
[36] J. Leite, G.D.S. Hadad, J. HoracioDoorn and G.N.
Kaplan, “A Scenario Construction Process,” [43] X.T. Bui, G. Kersten and P.C. Ma, “Supporting
Requirements Engineering, vol. 5, 38-61, 2000. Negotiation with Scenario Management,” 29th Hawaii
International Conference on System Sciences, 1996, 209-
[37] N.A.M. Maiden, S. Minocha, K. Manning and M. 219, Honolulu: University of Hawaii.
Ryan, “CREWS-SAVRE: Systematic Scenario
Generation and Use,” IEEE International Symposium on
Requirements Engineering: RE '98, 1998, 148-155, Los
Alamitos CA: IEEE Computer Society Press.

[38] E. Hollnagel, Human Reliability Analysis: Context

and Control, London: Academic Press, 1993.

View publication stats