Page 121 -

104 Chapter 4 Requirements engineering

requirements for the system. Different viewpoints on a problem see the problem in
different ways. However, their perspectives are not completely independent but usu-
ally overlap so that they have common requirements. You can use these viewpoints
to structure both the discovery and the documentation of the system requirements.

4.5.2 Interviewing
Formal or informal interviews with system stakeholders are part of most require-
ments engineering processes. In these interviews, the requirements engineering team
puts questions to stakeholders about the system that they currently use and the sys-
tem to be developed. Requirements are derived from the answers to these questions.
Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements
engineering team explores a range of issues with system stakeholders and hence
develop a better understanding of their needs.

In practice, interviews with stakeholders are normally a mixture of both of these.
You may have to obtain the answer to certain questions but these usually lead on to
other issues that are discussed in a less structured way. Completely open-ended dis-
cussions rarely work well. You usually have to ask some questions to get started and
to keep the interview focused on the system to be developed.
Interviews are good for getting an overall understanding of what stakeholders do,
how they might interact with the new system, and the difficulties that they face with
current systems. People like talking about their work so are usually happy to get
involved in interviews. However, interviews are not so helpful in understanding the
requirements from the application domain.
It can be difficult to elicit domain knowledge through interviews for two reasons:

1. All application specialists use terminology and jargon that are specific to a
domain. It is impossible for them to discuss domain requirements without using
this terminology. They normally use terminology in a precise and subtle way
that is easy for requirements engineers to misunderstand.
2. Some domain knowledge is so familiar to stakeholders that they either find it
difficult to explain or they think it is so fundamental that it isn’t worth mention-
ing. For example, for a librarian, it goes without saying that all acquisitions are
catalogued before they are added to the library. However, this may not be obvi-
ous to the interviewer, and so it isn’t taken into account in the requirements.

Interviews are also not an effective technique for eliciting knowledge about orga-
nizational requirements and constraints because there are subtle power relationships
between the different people in the organization. Published organizational structures