Preparing the Customer

The guided interview will provide the requirements analyst with a wealth of information. However, without both sides of the interview being properly prepared, there will be periods of inefficiency while the customer searches for answers to the analysts questions. To help the customer prepare for the interview, there will be a series of documents sent to them about User Stories and Business Events/Use Cases. It is important to acclimate the customer to both of these requirements gathering tools to ensure that we have access to requirements concepts at multiple levels of abstraction.

The customer should be immediately sent a document describing both the concept of User Stories and Business Events/Use Cases following the initial contact. This document should describe both concepts in enough detail to get the customer thinking about their request from the concept of the Business Events that drive the process and the simple User Stories that can be helpful in describing to the requirements analyst the day to day activities of the department/customers. The document should also include a set of examples of both Business Events/Use Cases and the corresponding User Stories. The use of a fictional, very simple, generic project should be used to link all of the examples into a coherent whole.

Preparing the Interview Guide

Concurrently with the customer learning about Business Events/Use Cases and User Stories, the requirements analyst should be taking the answers to questions from the initial contact and preparing the Interview Guide. This document will be sent to the customer at least three business days BEFORE the scheduled interview to allow the customer to prepare answers and have any materials (forms, examples) on hand.

Purpose Statement

Every interview guide should begin with an overall statement of purpose for the interview. This purpose statement is to ensure that the interview has a clear overall goal. It should also be used during the interview to ensure the interview stays on topic. Should there be a significant discovery of new functionality or problem areas, additional interviews can be scheduled. The purpose statement should generally be phrased as:

To Verb for gaining information Customer Focus in order to Business Focus

An example of this from previous projects would be:

To discover the methods and standard practices that the MRC uses to provide AV and technical support to events in order to help design a system which will automate and track equipment/inventory as well as provide additional billing capabilities.

Interview Objectives

To ensure that the interview produces the required information, it is critical to have a set of interview objectives listed in the interview guide as well. These objectives should be measurable pieces of information. All interview objectives should support the general purpose statement of the interview. A good list of Interview Objectives contains between five and ten objectives.
Crafting the Interview Questions

The interview guide should begin with the requirements analyst choosing general categories that need to be explored, such as:

• Regulatory Issues
• Customer Expectations
• Interdepartmental Data/Process Ownership Concerns
• Process Efficiency
• Information Scope/Capacity

After deciding on which categories to cover within the scope of this interview (remember that subsequent interviews can be scheduled as needed), the requirements analyst should craft the interview questions through brainstorming with another team member. Each category should have a series of questions to elicit information about both the current situation and the ideal future situation. Below are some sample questions for each category, they do not need to be used verbatim. In fact, each interview team should come up with their own variations on these questions based on the information gained in the Initial Contact

Conducting the Interview

The recommended interview team size is three analysts. A team leader actually asks most of the questions, one team member is the scribe to catch verbatim the customer's responses and the third team member is an observer/asks additional follow-up/probing questions. Given the size of ETC this will most likely need to be reduced to two member interview teams on everything except the most intensive and large projects.

During the interview process, any time that the customer is describing how something works, or the flow of information, one analyst should begin diagramming their understand and giving immediate feedback to the customer to ensure complete understanding of the process/information flow. This immediate feedback loop helps prevent future misunderstandings of the customer’s goals and the analysts understanding of those goals.

Additionally, analysts should be aware of language cues to ask follow up questions such as:

• When the customer uses judging terms, such as “better”, analysts should probe for information about
  • What criteria are used for comparison? Better compared to what?
  • Who is the judge of “better”? Our customers or the end-users?
• When the customer uses exclusionary terms, such as “never” or “always”, analysts should probe for more information about
  • Is it truly always or never?
  • If there are exceptions how are they handled?

Output from the Interview

After the interview is complete, the customer should be thanked for their time and asked to go over their Business Event/Use Cases and User Stories again using the information that has been covered in the interview. The analysts should ask for the customer to send them copies of the updated documents within a week if possible. The analyst team should adjourn to debrief on the results of the interview and begin the process of creating a set of Business Events/Use Case and User Story documents of their own.

The information captured in the interview will be used in conjunction with the Business Event/Use Case and User Stories from the customer to develop a complete set of Use Cases that will be sent to the customer to verify that the requirements analyst has captured the entire project scope.