Page 95 - Software and Systems Requirements Engineering in Practice

t
n
g
n
e
m
e
t
i
c
i

R
e
r
r
e
t

E
:
3
q
u
i
C
p
a
h
l
s
i
C h a p t e r 3 : E l i c i t i n g R e q u i r e m e n t s 65 65
2. Define the venue and the media. This includes where the
sessions will be held, as well as any audiovisual techniques
used (e.g., whiteboard, stickies, RGB projector). The format
for capturing the results of each elicitation session needs to be
defined. Capture mechanisms may include a requirements
database (viewed using a browser or the database screens),
Excel spreadsheets, modeling tools, or other electronic capture
mechanisms.
3. Define standards, schemas, and processes prior to the start of
the elicitation sessions. When capturing stakeholder requests,
they may be at very different levels (see the earlier section
“Not Identifying Requirements Level”). It is important that
any information captured be properly identified (including
the stakeholder), partitioned (level), and identified as to type
or other project characteristics, at the time of capture. Once
the requests start to be added, it will be very difficult to go
back and revisit the tagging of requirements. In order to have
an electronic system set up to properly capture the relevant
request or requirement attributes (e.g., priority, stakeholder,
level, type), the database schema or model attributes need
to have already been planned and defined in the toolset
being used. Furthermore, having guidelines for conducting
elicitation sessions will help in soliciting the cooperation of
stakeholders or domain experts to provide the needed
information at the time of elicitation.
4. Provide a clearly defined agenda for each elicitation session,
with the role of each attendee clearly understood. The agenda
should be feasible and reasonable given the duration and the
people present. Finally, action items should be recorded and
assigned with short due dates and careful follow-up.
5. Arrange for a senior manager (on the customer side) to
participate in the elicitation sessions. While it may be difficult
to convince clients or customers to have one of their senior
stakeholders participate, it may be the only way to ensure
that customer-provided domain experts actually show up at
the meetings and cooperate. Not that they will be unwilling
to participate, but the priorities of the manager of a domain
expert may be quite different than those of the project manager
for the product under design; they may be in different
organizations or companies. Consequently, when pulling in
domain experts, their presence may not be guaranteed
without the participation of a senior manager in their
organization.
6. If necessary, arrange for someone on the customer side (the
senior manager mentioned above may suffice) to set up the
schedule and manage it. The analyst in charge of requirements
elicitation may not have access to the scheduling system of