One of the most important and most straightforward requirements-gathering techniques is the user interview, a simple, direct technique that can be used in virtually every situation. This chapter describes the interviewing process and provides a generic template for conducting user and stakeholder interviews. However, the interviewing process is not easy, and it forces us to get "up close and personal" to the "User and the Developer" syndrome.
In addition, one of the key goals of interviewing is to make sure that the biases and predispositions of the interviewer do not interfere with a free exchange of information. This is a subtle and pernicious problem. Sociology (oops, another class we missed!) teaches us that it is impossible to relate to others without the world filter that is the result of our own environment and cumulative experiences.
In addition, as solution providers, we rarely find ourselves in a situation in which we have no idea what types of potential solutions would address the problem. Indeed, in most cases, we operate within a repetitive domain or context in which certain elements of the solution are obvious, or at least appear to be obvious. ("We have solved this type of problem before, and we fully expect that our experience will apply in this new case. After all, we are just building houses, and hammers and nails work just fine.") Of course, this is not all bad, because having context is part of what we get paid for. Our point is that we shouldn't let our context interfere with understanding the real problem to be solved.
So, how do we avoid prejudicing the user's response to our questions? We do so by asking questions about the nature of the user's problem without any context for a potential solution. To address this problem, Gause and Weinberg (1989) introduced the concept of the "context-free question." Examples of such questions are
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?
These questions force us to listen before attempting to invent or to describe a potential solution. Listening gives us a better understanding of the customer's problem and any problems behind the problem. Such problems affect our customer's motivation or behavior and must be addressed before we can deliver a successful solution.
Context-free questions also parallel the questions salespeople are taught to ask as part of a technique called "solutions selling." In solutions selling, the salesperson uses a series of questions focused on first gaining a real understanding of the customer's problem and what solutions, if any, the customer already envisions. The intent of these questions is to allow the salesperson to fully understand the customer's real problem, so that effective solutions can be suggested and weighed on their specific merits. This process illustrates the value of the salesperson's wares as an element of a complete solution to the customer's real problem.
In our search for undiscovered requirements, it may also be appropriate to move the questions to a domain wherein solutions are explored after the context-free questions have been asked and answered. After all, most of us are not typically rewarded for simply understanding the problem but rather for providing solutions appropriate to the problems being solved. This addition of solution context may give the user new insights and perhaps even a different view of problem. And, of course, our users depend on us to have context; otherwise, they would have to teach us everything they know about the subject.
As an aid to building this skill within the development team, we have combined these techniques into our "generic, almost context-free interview," a structured interview that can be used to elicit user or stakeholder requirements in most software application contexts. The template for this interview is provided in Figure 9-1. The interview consists of both context-free and non-context-free sections. It also provides questions designed to make certain that all aspects of requirements, including some of those "gotcha" requirements for reliability, supportability, and so on, are thoroughly explored.
With a little preparation and with the structured interview in one's pocket, any member of the team can do an adequate job of interviewing a user or customer. (But. it may be best to pick those team members who are most "outgoing.") Here are some tips for a successful interview.
Prepare an appropriate context-free interview, and jot it down in a notebook for reference during the interview. Review the questions just prior to the interview.
Before the interview, research the background of the stakeholder and the company to be interviewed. Don't bore the person being interviewed with questions you could have answered in advance. On the other hand, it wouldn't hurt to briefly verify the answers with the interviewee.
Jot down answers in your notebook during the interview. (Don't attempt to capture the data electronically at this time!)
Refer to the template during the interview to make certain that the right questions are being asked.
The interviewer should make sure that the script is not overly constraining. Once rapport has been established, the interview is likely to take on a life of its own. The customer may well launch into a stream-of-consciousness dialogue, describing in gory detail the horrors of the current situation. This is exactly the behavior you are striving for. If this happens to you, do not cut it off prematurely with another question; rather, write everything down as quickly as you can, letting the user exhaust that particular stream of thought! Ask follow-up questions about the information that has just been provided. Then, after this thread has run to its logical end, get back to other questions on the list.
After even a couple of such interviews, the developer/analyst will have gained some knowledge of the problem domain and will have an enhanced understanding of both the problem being solved and the user's insights on the characteristics of a successful solution. In addition, the developer can summarize the key user needs or product features that were defined in the interview. These "user needs" live near the top of our requirements pyramid and serve as the driving force for all of the work that follows.
Your problem analysis will have identified the key stakeholders and users you will need to interview to gain an understanding of the stakeholder's needs. Typically, it does not take many interviews to get a pretty solid feel for the issues.
The last section of the interview form, Analyst's Summary, is used for recording the "three most important needs or problems" uncovered in this interview. In many cases, after just a few interviews, these highest-priority needs will start to be repeated. This means that you may be starting to get convergence on some common needs. This is to be expected, especially among those users or stakeholders who share a common perspective. So, ten interviews will often create only 10–15 different needs. This is the start of your "requirements repository," a set of assets you will build and use to good advantage over the course of your project. This simple, inexpensive data, even by itself, will help you and your team build a more solid foundation with which to initiate your project.
The HOLIS team decided to have the marketing team (Eric and Cathy) develop the questions for the interview but wanted everyone on the team to experience the process and to have the opportunity to meet customers face to face and thereby "see" the problem and a potential solution from the customer's perspective. So, the team divided up the customer and distributor list and had each team member interview two people. The team used the Analyst's Summary to summarize the needs that were provided and weeded out the duplicates. After fifteen interviews, the team had identified 20-some needs to fill in the top of their requirements pyramid.
From the homeowner's perspective:
Flexible and modifiable lighting control for entire house
"Futureproof" ("As technology changes, I'd like compatibility with new technologies that might emerge.")
Attractive, unobtrusive, ergonomic
Fully independent and programmable or (reconfigurable) switches for each room in the house
Additional security and peace of mind
Intuitive operation ("I'd like to be able to explain it to my 'technophobic' mother.")
A reasonable system cost, with low switch costs
Easy and inexpensive to fix
Flexible switch configurations (from one to seven "buttons" per switch)
Out of sight, out of mind
100% reliability
Vacation security settings
Ability to create scenes, such as special housewide lighting settings for a party
No increase in electrical or fire hazard in the home
Ability, after a power failure, to restore the lights the way they were
Program it myself, using my own PC
Dimmers wherever I want them
Can program it myself, without using a PC
Somebody else will program it for me
If system fails, I still want to be able to turn some lights on
Interfaces to my home security system
Interfaces to other home automation (HVAC, audio/video, and so on)
From the Distributor's Perspective:
A competitive product offering
Some strong product differentiation
Easy to train my salespeople
Can be demonstrated in my shop
High gross margins
We are often asked whether the team can substitute a questionnaire for this interviewing process. In some cases, the need expressed is perhaps a simple desire for efficiency ("I could do 100 questionnaires in the time it takes to do one interview.") In other cases, the need itself may come under suspicion ("Do I really have to talk to these people? Couldn't I just send them a letter?")
No matter what the motivation, the answer is no. There is no substitute for the personal contact, rapport building, and free-form interaction of the interview technique. We are confident that after one or two interviews, your world view will have changed. Even more important, the vision for the solution will have changed along with it! Do the interview first. Do it for every new class of problem, and do it for every new project.
However, when used appropriately, the questionnaire technique can also play a legitimate role in gathering user needs. Although the questionnaire technique is often used and appears scientific because of the opportunity for statistical analysis of the quantitative results, the technique is not a substitute for interviewing. When it comes to requirements gathering, the questionnaire technique has some fundamental problems.
Relevant questions cannot be decided in advance.
The assumptions behind the questions bias the answers.
Example: Did this class meet your expectations? Assumption: You had expectations, so this is a meaningful question. It is difficult to explore new domains (What you really should be asking about is … ), and there is no interaction to explore domains that need to be explored.
Unclear responses from the user are difficult to follow up on.
Indeed, some have concluded that the questionnaire technique suppresses almost everything good about requirements gathering, and therefore, we generally do not recommend it for this purpose.
However, the questionnaire technique can be applied with good effect as a corroborating technique after the initial interviewing and analysis activity. For example, if the application has a large number of existing or potential users and if the goal is to provide statistical input about user or customer preferences among a limited set of choices, a questionnaire can be used effectively to gather a significant amount of focused data in a short period of time. In short, the questionnaire technique, like all elicitation techniques, is suited to a subset of the requirements challenges that an organization may face.