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 extremely difficult to truly understand others because each of us is biased by our own conceptual filter, one that results from 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 may even be experts. ("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. The point is that we must not let our context interfere with understanding the real problem to be solved.