Page 96 - Software and Systems Requirements Engineering in Practice
P. 96
66 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
the domain experts or may not have the authority to request
their presence at elicitation sessions.
7. Hold sessions in the morning, if feasible, and schedule them to
last half a day. People tend to tire a bit over time, and about
four hours or less is best for sustaining high productivity.
In addition, work will be generated outside of the elicitation
session (see the next item), and it is recommended that assigned
work be completed the same day that the session was held.
8. If heavy writing is assigned during an elicitation session,
have it done offline, preferably the afternoon that the session
was completed. This includes definitions, descriptions of
processes, and so on. Text can then be reviewed the following
morning or offline at a later date.
9. Preferably, find a venue where everyone can see the same
thing at the same time. Whether looking at text or graphics,
all the attendees should be seeing the same information. If
you are able to have the relevant stakeholders in the room
during the elicitation session, the requirements review process
can be shortened, since the reviewers were present during the
elicitation session.
10. Chunk reviews of work. Imagine being sent an e-mail
containing the following request: “Please review this
paragraph [or page] and send your comments by tomorrow.”
Contrast that with “Please review this 200-page requirements
specification and send your comments within the next two
days.” Clearly the former is likely to happen, and the latter
may result in the reader hitting the Delete button. Reviews
are best done online, with everyone reviewing a reasonably
small amount of material together. When that is not feasible,
the review of material should be partitioned, so that only the
relevant stakeholders see the material they need to review,
and the amount of material to be reviewed is kept small.
11. Keep reviews of elicitation sessions short and immediate.
When reviewing the output of an elicitation session, we
normally conduct the reviews the same afternoon, not later
than one or two days after the session (before the domain
experts vanish back into their environments).
12. Keep attendance at an elicitation session (as contrasted with
a brainstorming session, where everyone possible is in the
room) small, no more than six to eight people. A typical
session might consist of: a facilitator or lead analyst, one or
two other analysts (including the designated “smart
ignoramus”), participating stakeholders at the management
level, and one or two domain experts. It is always better to
have two domain experts than one. Two experts can check
each other’s work as the session progresses, minimizing the