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
   91   92   93   94   95   96   97   98   99   100   101