Interviewing the Stakeholders

Interviewing is used by almost all projects, as it is really a part of all elicitation techniques. Despite its omnipresence, we suggest that you do not use interviewing as your only technique for gathering requirements. Rather, conduct interviews in conjunction with the other techniques discussed in this chapter.

Interviewing users is the most commonly employed approach to requirements gathering. In this technique the interviewer relies on the interviewee to know, and be able to verbalize, all of his requirements. This procedure may work very well for requirements that people are conscious of, but few people know all their requirements or can think of them all during an interview. For this reason, it is wise to avoid relying on interviews as your sole method of gathering requirements; instead, use them in conjunction with other techniques.

That cautionary note notwithstanding, interviewing skills are highly useful in other contexts. For example, a requirements analysts can "interview" a model or a document. The skill here is knowing which questions to ask of the model or the appropriate stakeholder for the model.

Often requirements analysts may choose to draw up questionnaires in advance. While this preparatory step gives some structure to the subsequent interview, we have found few stakeholders who are motivated enough, or who have time enough, to fill in a questionnaire prior to meeting the analyst. We suggest that you send an agenda of the topics that you wish to cover to your interview subject. This at least gives the interviewee a chance to have needed material close by or to ask subject matter experts to be present.

Stakeholders should not remain completely passive during the interview. Instead, do your best to involve them by building modelsbusiness event responses, use cases, scenarios, and so onduring the interview. This approach creates a feedback loop between you and your stakeholders, and it means you can iteratively test the accuracy of what you are being told. Follow these guidelines to make your interviews more effective:

• Set the interview in context. This step is necessary to avoid having your stakeholders talk about something irrelevant to your purpose. It also gives them a chance to withdraw gracefully if they have not prepared for the interview.

• Use business use cases as an anchor for the interview. Users recognize business use cases (although they may not necessarily call them by that name), and it makes for more directed conversations if you talk about their work one business use case at a time.

• Ask a question (more on this in a moment), listen to the answer, and then feed back your understanding.

  Feed back your understanding. Build models while you are interviewing the user.

  
  

• Draw models and encourage the user to change them. Plenty of models (e.g., data flow diagrams, activity diagrams, sequence diagrams) are available to help you communicate your understanding of a process. You can also construct data models for information, and mind maps to link different subjects.

• Use the stakeholders' terminology and artifacts, both conceptual and real. If the stakeholders do not use their own language, then you force them to make technological translations into terms they think you will understand. This, sadly, usually leads to misunderstandings. By contrast, if you are forced to ask questions about their terminology, you inevitably make new discoveries.

• Keep samples or copies of artifacts. Artifacts are the things the stakeholders use in their daily work. They can be real things: documents, computers, meters, spreadsheets, machines, pieces of software. They can also be conceptual things: status, contracts, schedules, orders. Artifacts will inevitably cause you to raise questions when you examine them later.

• After all, they have lots of other things to do. Talking to you is not the reason they are employed, and they often view the interview as an interruption.

Thank the stakeholders for their time.

Asking the Right Questions

The technique called neurolinguistic programming (NLP) utilizes a set of models, skills, resources, and techniques for improving communication. One of its resources is a linguistic meta-model for helping interviewers listen to what interviewees are saying and arrive at an unambiguous common understanding. This meta-model consists of a number of patterns together with questions that you can ask to identify potential misunderstandings and clarify meaning.

A linguistic meta-model is a guide for helping interviewers listen to what interviewees are saying and arrive at an unambiguous common understanding.

Suppose that one of your stakeholders says, "We get the sales information . . . ." But what is meant by "we"? Who, specifically, are we talking about? And what about the "sales information"? What is the subject matter of this information? Just in this innocent sentence you uncover two examples of a pattern known as unspecified noun. This pattern is characterized by a term that is not defined consistently and might be interpreted differently by two people who are having a conversation, even though those people are nodding and thinking that they agree with each other.

Another pattern leads to further questions: What is meant by "get the sales information"? Who is getting it from where? Does this imply some other activity associated with the sales information? This pattern is referred to as an unspecified verb.

Some other useful patterns to listen for and trigger questions follow:

• Comparison: When you hear the word "better," ask, "Compared to what?"

• Judgment: Who says that it is better? What is the authority?

• Generalization: When you hear the words "can't" or "must," then ask: What prevents you? Why must you do it? What would happen if you did not?

  

  For more about NLP, refer to O'Connor, J., and J. Seymour, Introducing Neurolinguistic Programming. Thorsons, 1990.

  
  

• Universal Quantifiers: When you hear "never" or "always," it triggers other questions: Is it really never or does it happen sometimes? Is it really always or are there some exceptions?

• Nominalization: In nominalization, a verb that describes an ongoing process is turned into a nounfor example, "Processing renewals over the Internet is better." But what does the speaker mean by "processing"? What activities are implied by the use of that word in this context?

We are often tempted to make assumptions about which meanings people are intending to communicate. In reality, most of the terms we use have a certain amount of elasticity; we can stretch almost any term to accommodate a number of different meanings. As a requirements analyst, you can take advantage of NLP patterns to identify elastic terms and then use those terms as the basis for triggering questions that lead you to a more precise understanding.

Most of the terms we use have a certain amount of elasticity; we can stretch almost any term to accommodate a number of different meanings.