Page 107 -

When a software system is developed, the first step is to determine what the system will
do. This sounds trivial to some people—the vision and scope document tells us what fea-
tures will be developed, so why not start designing the software once everyone agrees that
it’s complete? This might seem like a reasonable course of action, but there’s a big differ-
ence between deciding the features that will go into the software and defining the behav-
ior of each of those features. (If a vision and scope document does not yet exist,
developing one will do much more good for the project than jumping directly into the
requirements. The requirements engineering activities should wait until after the vision
and scope document is ready—see Chapter 2.)
The objective of all elicitation activities is to create a complete list of what the users and
stakeholders believe are the important needs that must be filled by the software, the
behavior that the software must exhibit, and the constraints to which the software must
adhere. A variety of elicitation practices can be used to gain a complete understanding of
user needs. Each practice should be considered carefully, to determine which is best suited
for a particular project; in addition, several techniques can be used in combination. The
goal of using any of the techniques is to gain the commitment of the users so a common
view of the system is established.
Conduct Interviews
It’s been said that users don’t have requirements; they have information. The require-
ments analyst must figure out how to get that information out of each user, stakeholder,
expert, and anyone else who has information that may impact the project. The most
straightforward and effective practice for doing this is by conducting interviews.

Interviews with users and stakeholders are the requirements analyst’s most important
elicitation tool. The goal of the interview is to identify specific needs that the person being
interviewed has for the software. This generally requires understanding what the inter-
viewee does on a day-to-day basis that will require her to interact with the software.

The first step in conducting interviews is to identify who the interviewees should be. Start
with the list of users and stakeholders listed in the vision and scope document. While they
are being interviewed, additional people may be mentioned. The interviewer should

determine whether any of those people should be interviewed as well. If the software is
being built for a specific industry or area of expertise, the requirements analyst may need
to seek out subject matter experts in that area in order to ensure that the software meets
the needs of a typical professional familiar with the subject.
When the software is intended to be marketed or sold by the organization, many of the
market needs will originate in a sales or marketing department. In this case, it is important
that sales and marketing personnel are considered subject matter experts and are inter-
viewed for requirements. If the goal of the project is to enhance or maintain software that
is already out in the field, then the interviewees should include actual external users.
The most important rule of the interview is to get the interviewee talking. Software gener-
ally doesn’t get developed for its own good; a project is usually started because somebody

SOFTWARE REQUIREMENTS 99