Page 108 -

inside an organization needs it. If the requirements analyst is talking to that person, he
almost certainly will be happy to talk about it. It is likely that he has been complaining
about specific problems and issues for a long time.
There are many leading questions that an interviewer can ask to help uncover important
information:
• Why is the software being built? What benefits will the interviewee directly see? What
benefits will other people in the organization see?
• What problems need to be addressed with new software? Why do those problems exist?
How would you solve them?
• Who will use the software once it is built? Why do they need it? How frequently will
they be using the software? Who will support the software?
• In what environment will the software be used? Will it be run within the organization
or by its customers? Who will control the hardware?

• Are there any known constraints on the performance, design, or quality of the soft-
ware?
• What inputs will be used by the software? What outputs will it create? (If examples of
these exist, they should be saved for later requirements activities.)
• Are your answers “official,” or is there someone else who might be able to answer these
questions better? Are there “experts” in the organization who may have additional
information?
• How do the users currently do their jobs? How do they expect their jobs to change after
the software goes into production? Are there typical problems they currently encounter
that they would like to fix?
• Are there any “workarounds” that the users perform, in order to make up for the short-
comings of existing software? Can these workarounds be incorporated into planned fea-
tures or turned into additional ones? (If the workarounds are not part of the original
scope of the project, does that scope need to be expanded to include them?)
• “Is there anything that I missed?”

In the early stage of interviews, any kind of open-ended questions are good for getting the
interviewee talking. It is important that the requirements analyst does not interrupt the
interviewee. If he has something to say, it could be important. One key to interviewing is
to make sure that the predispositions of the interviewer do not interfere with the free
exchange of information. Questions should center on the interviewee’s problems. The
requirements analyst should try to gain an understanding of the real problem without
introducing bias into the user’s information.

When there are multiple people with similar job functions or expertise, it is often helpful to
interview them in groups. When there are too many individual interviews, they will often
turn into an endless chain of conflicting statements, making it difficult to reach consensus.

100 CHAPTER SIX