Listening to the customer's voice

Perhaps the greatest challenge facing the software developer is sharing the vision of the final product with the customer. All stakeholders in a project—developers, end users, software managers, customer managers—must achieve a common understanding of what the product will be and do, or someone will be surprised when it is delivered. Surprises in software are almost never good news. Therefore, we need ways to accurately capture, interpret, and represent the voice of the customer when specifying the requirements for a software product. Often the customer will present as "needs" some combination of: the problems she has in her work that she expects the system to solve; the solutions she has in mind for an expressed or implied problem; the desired attributes of whatever solution ultimately is provided; and the true fundamental needs, that is, the functions the system must let her perform. The problem becomes more complex if the systems analyst is dealing with a surrogate customer, such as a marketing representative, who purports to speak for the actual end users of the application. The challenge to the analyst is to distinguish among these four types of input and identify the real functional requirements that will satisfy the real user's real business needs. Many techniques are used for eliciting user requirements, all of which attempt to include the voice of the customer in the product design process. A typical project might employ a combination of meetings with user representatives and developers, facilitated workshops (for example, joint application design sessions) with analysts and users, individual customer interviews, and user surveys. The use case approach is an especially effective technique for deriving software requirements, analysis models, and test cases. The Use Case Method Use (pronounced "youce," not "youze") cases were introduced as part of an objectoriented development methodology by Ivar Jacobson in Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley, 1992). More recently, Larry Constantine and others have extended the concept into a general technique for requirements analysis and user interface design. Each use case describes a scenario in which a user interacts with the system being defined to achieve a specific goal or accomplish a particular task. Use cases are described in terms of the user's work terminology, not computerese. By focusing on essential use cases, stripped of implementation constraints or alternatives, the analyst can derive software requirements that will enable the user to achieve her objectives in each specific usage scenario. A software team at Eastman Kodak Company recently applied the use case method to specify the requirements for a chemical tracking system. Figure 1 illustrates the overall process we found to be effective with the use case technique and the key deliverables. We used a series of highly interactive sessions with customer representatives to identify and describe use cases. Functional requirements, behavioral characteristics, and business rules fell right out of the use case discussions.