Interview the Users (Process Notes 2.1.5)

Interviewing the users is the traditional approach to requirements gathering. However, when used on its own, it may not be the most effective strategy. We strongly suggest that interviews not be used as the sole method of gathering, but that they be used in conjunction with other techniques when they will be more effective.

The requirements engineer can draw up questionnaires in advance. While this gives some structure to the following interview, we have found that users have to be highly motivated to actually fill them in prior to meeting the engineer. We suggest that you send the user, or whomever you are interviewing, an agenda of the topics that you wish to cover. This gives the user a chance to have material at hand or to ask subject-matter experts to be present.

The user should not be completely passive during the interview. We strongly urge you to build models (e.g., event-response, use case, scenario) while you are talking with the user during the interview. This gives you and your user immediate feedback, and allows you to test the accuracy of what you are being told. We also prefer that the user participate in the modeling efforts. You must make allowances for their notational idiosyncrasies: You can correct them later.

You can also interview the user while watching the work being done. This has the advantage of you being able to direct your questions to the task at hand, and gives the user a better chance to describe the task. People are not good at describing their jobs, but are usually good at telling you what they are doing while they are doing it.

When people describe things to you, especially such conceptual and difficult things such as requirements, they usually have difficulty being precise. They will also describe things in abstract terms, and have difficulty defining precisely what they mean. The idea of laddering is that you can conceptually go up or down from what they are saying, depending on what you need to know. Going down the ladder means that you decompose what you are told to find the layer of fact below the statement, then decompose again to find the next lowest layer. You might also need to ladder upthat is, move the conversation to a higher level of abstraction.

For example, you may be asked for a system that responds quickly to customers' needs. To go down the ladder, you would ask for a meaning or measurement for "quickly." "While the customer is on the telephone" is a measurement, and the next lowest level will yield "You have to find the customer's record in one second." By going down the ladder of abstraction, you arrive at a deterministic answer.

Going up the ladder is also useful. It leads to outcomes and criteria: "The system has to respond quickly so customers do not become impatient."

Think about the level of the interview, and always try other levels. They are often very revealing.