Page 122 -

4.5 Requirements elicitation and analysis 105

rarely match the reality of decision making in an organization but interviewees may
not wish to reveal the actual rather than the theoretical structure to a stranger. In gen-
eral, most people are generally reluctant to discuss political and organizational
issues that may affect the requirements.
Effective interviewers have two characteristics:

1. They are open-minded, avoid pre-conceived ideas about the requirements, and
are willing to listen to stakeholders. If the stakeholder comes up with surprising
requirements, then they are willing to change their mind about the system.

2. They prompt the interviewee to get discussions going using a springboard question,
a requirements proposal, or by working together on a prototype system. Saying to
people ‘tell me what you want’ is unlikely to result in useful information. They find
it much easier to talk in a defined context rather than in general terms.

Information from interviews supplements other information about the system from
documentation describing business processes or existing systems, user observations,
etc. Sometimes, apart from the information in the system documents, the interview
information may be the only source of information about the system requirements.
However, interviewing on its own is liable to miss essential information and so it
should be used in conjunction with other requirements elicitation techniques.

4.5.3 Scenarios

People usually find it easier to relate to real-life examples rather than abstract
descriptions. They can understand and criticize a scenario of how they might interact
with a software system. Requirements engineers can use the information gained
from this discussion to formulate the actual system requirements.
Scenarios can be particularly useful for adding detail to an outline requirements
description. They are descriptions of example interaction sessions. Each scenario
usually covers one or a small number of possible interactions. Different forms of
scenarios are developed and they provide different types of information at different
levels of detail about the system. The stories used in extreme programming, dis-
cussed in Chapter 3, are a type of requirements scenario.
A scenario starts with an outline of the interaction. During the elicitation process,
details are added to this to create a complete description of that interaction. At its
most general, a scenario may include:

1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.

5. A description of the system state when the scenario finishes.