Technique 50: Scenarios
Description of the technique
Scenarios can be used to bring to life either business situations or IT situations
(usually described via use case speciﬁcations – see Technique 62), but are most
powerful when used to describe both of these and the interactions between them.
In addition to helping validate requirements for completeness of coverage, they
also provide a solid base for prototyping, testing and subsequent training for
business users. A scenario describes a speciﬁc situation that the user will
recognise, which works through a single instance to a logical (although not
always successful) conclusion. Each individual scenario is speciﬁc in that it does
not deal in generalities; instead, it homes in on a particular set of circumstances
and ‘walks through’ the task that needs to be performed, in a thread that has a
start point and a stop point.
Each individual scenario can be used to validate the business requirement,
and the development of the scenarios is also likely to identify additions or
enhancements to the requirements during elicitation, analysis and subsequent
deﬁnition. Thus the requirements and their supporting scenarios are developed
together in an iterative way.
To develop a scenario, the business analyst starts by writing down descriptions of
examples of a variety of situations that a range of users might encounter. These
help to ground the analysis in reality and allow all concerned to understand the
detailed steps that typical users go through, and the information they will need to
perform these. This selected set of scenarios should be reviewed with users and
used to reﬁne the initial requirements deﬁnition. Later they can be used as the
basis for the development of prototypes and acceptance test plans.
It is important when developing scenarios to ensure that there is suﬃcient
coverage of both normal and critical conditions, as well as considering some of the
more unusual and less important situations. There is often a temptation to focus
scenarios only on the interesting cases, and ignore more mundane and common
We recommend that the set of scenarios considered should cover: