Page 76 - Software and Systems Requirements Engineering in Practice

48 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

Stakeholders Omit Important, Well-Understood, Tacit Information
On occasion, a stakeholder or domain expert may be “too close” to
the material he or she is describing and forget to include salient
points, assuming that the material is so basic that it does not need to
be communicated. You may have been in a situation where you were
reading the instructions for doing something, could not get it to work,
and then found out that steps were missing from the instructions. For
example,
“To drive a stick-shift car, start the engine, put the car in gear,
and go!”
Of course, there are a few missing steps such as putting the key in
the ignition and making sure that the clutch is pressed in order to
start the engine. But a driver who uses such a car every day might
take for granted putting the key in the ignition and pressing down on
the clutch, while someone who has never driven before might realize
that some steps had been left out. The “smart ignoramus” (see the
earlier section “The Missing Ignoramus”) can help, but a trained
analyst or facilitator is really necessary during elicitation sessions to
ensure that every last detail needed to define a product is captured.
There is also a crossover point between elicitation and analysis;
sometimes the boundary between the two activities is clearly defined,
and sometimes it is not.

Stakeholders Have Conflicting Views
When stakeholders have conflicting views, a heated discussion
(possibly started by the “smart ignoramus” asking a question) may
ensue. The conflict must be resolved, but not during the elicitation
session (unless it is just a matter of a minute or two). Conducting an
elicitation session requires the same skill at moderation or facilitation
as any other professional meeting, and complex or lengthy discussions
need to take place elsewhere to avoid a loss of productivity. Facilitation
of brainstorming sessions is described in more detail in the next
section.

3.3 Requirements Elicitation Methods
As mentioned early in this chapter, requirements elicitation is the
interaction with stakeholders to capture their needs. No decisions
have been made at this point about which of the needs will become
requirements, and which of the requirements will be included in a
release of the product that is yet to be built. Furthermore, in many
cases the same techniques can be used for both elicitation and analysis
(Figure 3.4). As there are so many different ways to capture stakeholder
needs, we only mention a few here. The reader is encouraged to seek
out techniques that are appropriate to their situation.