Interviews

Interviews [3]


Interviews is part of the Ethnographic Techniques, that I blogged about before. Here I will provide a detailed article about this technique.

Despite the fact that interviews are involved in any elicitation technique, what we’re discussing here is a stand-alone interview technique.
The basic form of interviews will aim to meet every stakeholder a one-to-one meeting to note his/her requirements, opinion, and assumptions about the system. This basic approach works handy when we have the following:

• Less disagreement between different stakeholders
• Stakeholders are geographically distributed and can’t meet togeather
• Some stakeholders can’t leave their workplace and engage in workshops and meetings

With the above in mind, it is important to keep the requirements shared between all stakeholders to eliminate any conflicts or disagreements. If any stakeholder disagree with requirements, then a formal walk-through would be needed with the disagreed stakeholder to verify and eliminate it.

Interviews can be categorized in two types as the following:

1. Open-ended interviews: requirements engineer (or interviewer) start the interview with an open-ended questions as the start point, the record the response and elaborate with stakeholder if needed. This type is useful when few we have few stakeholders, and when the interviewer is experienced.
2. Closed-ended interviews (Surveys): in this type, interviewer will design a survey; similar to survey technique; in which interviewer go on the survey questions by question with stakeholder and record the response. This type is beneficial when the interviewer is less experienced, and when we have many stakeholders (less time).

Interview process can be repeated until stakeholder understand and provide his/her best feedback. The following steps describes a good way to prepare an interview:

1. Keep in mind that you can’t interview all stakeholders, so use the stakeholders analysis to select the most important stakeholders (key users) to interview, then for each, identify a high-level goals for the interview; what you want to get from that interview; in which you will focus in the interview to capture a good requirements.
2. Schedule an appointment with stakeholders, and let them know how important are their feedback to the system.
3. Before meeting each stakeholder, learn something about their knowledge about the current system (or business workflow); and try to realize what area on the system they can provide a good feedback about.
4. Write some questions specified for every stakeholder according to their role and knowledge, and then refine the questions.
5. Send out the questions to the customer before meeting, so they can realize how important this meeting is, and how committed you are to the interview.

In addition to the above about preparation, a requirement engineer may use the following type of questions when designing an interview:

• Open-ended questions. When you want the customer (stakeholder) to express his/her opinion about some system process. This is also a useful technique to let the customer open up to you in an interview.
• Closed-ended questions. When you need precise and short answer from the customer.
• Probing questions. Used when you want the customer to elaborate about a requirement they mentioned. For example, if a customer said “ Our system should function 100% in our working hours ” , so you may ask “Can you specify what are the working hours?”.
• Validating questions. To go over requirements and models (i.e charts) and show them to customer and check their agreement, or disagreements.

The main point of interviews is to discover the unknowns. Reference [3] provides a step-by-step process to discover the unknowns throughout interview starting with the known. Steps are as the follows:

1. Interviewer should understand the problem boundaries and describe it using any method; [3] suggested using Functional Decomposition Diagram (FDD) see figure [3] below; then should explain it to the customer and make sure that customer understand it. This will help in bringing the customer in the same page.
2. Interviewer should define the problem being proposed to be solved here, either a system problem or a business problem.  
3. Identify the root causes for the problem being discussed. Interviewer need to be focus causes other than the main root cause which was already identified.
4. “Envision the future.” Discuss with customer what he/she and you think about the current situation (AS-IS) and what they think will be when this system is done (TO-BE).

At the end, interviews is a good elicitation technique, which provides an insight into details needed for good requirements. However, some customers may not be committed to those interviews, and sometimes its hard to control the interruptions in interviews.