7.2 Requirements Definition
| Our goal for this phase is to understand the business, the end users, and the application details. We also want to come up with a set of metrics that will measure our success and point us to important issues that need attention. We begin by looking at the business. 7.2.1 Understanding the Business Goals and ContextBefore our first meeting with Lexington, we do some quick homework. First, we explore the Web site. Luckily, a colleague has an account, so we can try some of the services offered. We note the variety of services offered on the site as well as the look and feel. The feel of the site is "down to business," with very little in the way of extra graphics. When you request a quote on a given company's stock, you also get additional company information such as trading volume and high and low prices for the year. Another click can get you details on company financial performance or headlines. Next, we call the Lexington touchtone system. We notice an earcon at the very beginning, just before the welcome prompt. It sounds familiar, and we remember hearing it on a recent radio ad. We use the touchtone system to get some quotes, get account information, and transfer some money back and forth between two accounts. The system uses a male voice that is fairly emotionless and dry. Now we send Lexington a proposed agenda for our meeting, and we call to make sure the right people will be there to answer the variety of questions we have. At the beginning of the meeting, we ask the Lexington personnel why they want to deploy a speech application. Jack Farmer, the marketing representative, tells us that Lexington wants to expand its service. "We want our customers to be able to get up-to-date information on their portfolios twenty-four by seven," he tells us. Lexington also wants to offer automated trading over the phone for customers who are often away from their desks and trade frequently. This service has never been available in the touchtone system. We learn from Jack that customer service is extremely important to Lexington; it wants a system that is efficient and easy to use and makes it easy to connect to a live broker if desired. Another goal is to attract and retain customers. The firm has some concern about losing customers to competitors, so it would like to make its service more "sticky" (one that hangs on to customers) by using personalized features. Next, we meet with Jane Brody, who coordinates advertising and is responsible for branding. "What do people think of when they hear your company name?" we ask her. "Value, dependability, reliability," Jane says, "The professional, helping hand." We ask what else they should think after using the system. "Efficiency and helpfulness," she says. "We help them get the job done." We ask about the voice and tone of the touchtone system. Jane explains that the goal was to sound professional and authoritative. However, Lexington marketers are not happy with the result. They would like our help finding a better voice and defining an improved look and feel. She also explains that all the Lexington systems will begin with the branding earcon we heard on the touchtone system. In the afternoon, we meet again with Jack and his team. We learn a number of things. The speech application will be one of many services that are available to Lexington customers. Traditional person-to-person services will always be offered. The Web site offers a superset of the functionality that will be offered by the speech system. The touchtone system presents a subset of the functions. A growing number of customers use the Web site, and many of them conduct their trades on the Web. These facts will influence design decisions. For example, if callers are accustomed to specific terminology on the Web site and even a certain organization of information, they will be more likely to generalize and apply these concepts when interacting with the spoken language system. We request a copy of the specification for the touchtone system. Our goal is not to map touchtones onto speech. Speech systems should be designed with speech in mind. What we do want to glean from the touchtone spec is the type of language that is used and the functionality available, because callers will be familiar with these things from previous interactions. We ask Jack's group how they foresee getting their customers to use the new system. Lexington has found that mailers included with statements are not very effective. They are considering advertising the service by using a postcard that describes some of the basic commands (although they are relying on the application itself to teach callers all they need to know about how to use the service). They will also advertise the speech system on the Web site, emphasizing that now customers can have complete access even when away from their desks. Our discussions with Lexington have been fruitful. We now have an understanding of the business goals and context. The motivation for deploying the speech system is to expand the firm's automated service offerings (thereby cutting costs), increase customer satisfaction, and retain customers. It wants to promote its corporate image of value, dependability, and facilitation. All the functionality of the touchtone system will need to be supported by the speech system, but the goal is to make the interaction more user-friendly. Finally, the application should not rely on any outside instruction to teach users how to interact with it. Callers must be able to learn the system simply by using it. We agree with Lexington on a number of success metrics that correspond to the business goals. It is important to keep in mind that, during the tuning phase, we will measure many other characteristics of system performance in order to improve the system. However, the metrics we agree on now are the highest-priority indicators of success. We select the following metrics:
7.2.2 Understanding the CallerWe want to learn as much about the customers (our potential callers) as we can. What is their demographic group? Are they older, more mature customers or young go-getters? Do they use any jargon? Is a particular dialect prevalent? What about technological sophistication? Are they comfortable with computers? How do they feel about new technology such as speech recognition? What would they like from a system such as this? What are the typical usage patterns we should expect? We sit down with the Lexington team members and ask them some questions about their customers. They tell us that their customers are mainstream traders in the moderate- to high-income range. They have customers of all different ages, but most tend to be in their 30s and 40s. There is an even mix of males and females. We're given a document with statistical information about the customers. It covers demographics as well as usage statistics for both the Web site and the touchtone system: how often customers call or log in, frequency of use of each feature, and so on. In addition to Lexington's own information, we decide to talk directly to the users. We want to understand their state of mind and image of themselves as traders. Lexington's statistics can get us only so far in probing the internal thoughts of the customers. We decide to explore the needs of the customers by convening a focus group, and Lexington provides us with contact information of people who might be willing to spend some time telling us their opinions. With the help of a small monetary incentive, we find eight willing volunteers. In a group discussion headed by one of our usability specialists, we learn that these folks are generally very receptive to automated services. They like the fact that they can get information and conduct transactions without waiting on hold. Saving time is important to everyone there, so the convenience of automated services is a definite plus. Here's what three of the participants Rachel, Gordon, and Mike had to say:
What we learn from these comments is that it's not only the convenience that is important to these folks but also the fact that the service is an enabler. It allows them to be self-reliant, which has been a growing trend in financial decision making ever since the dawn of online trading. The participants also tell us that they are concerned with accuracy. After all, they are managing their money. They want to be sure that if they get information from the service, such as stock quotes, this information is up-to-date. Security risks and accuracy make them a bit cautious about telephone services. When using the Web, they can see the information right in front of them and confirm it. For some reason, just hearing the information over the phone makes them a bit wary. What if they hear the information wrong and mistakenly confirm it? It's important to note these concerns and address them in later design decisions. The focus group has given us some insight into the mind-set of the customer: We have discovered that they enjoy convenience and like being in control of their money. They want to be sure that the decisions they make are based on correct information and that transactions are executed accurately. We now probe deeper into their thoughts about the service. How do they use online brokerage Web sites today? How might they use something like an automated telephone system that they can talk to? We want to learn what customers use services for, how often, and from where (are they in their car, at home, at work?). Here's another snippet from the focus group:
We learn several things from this conversation. These users care about easy access to get information and make trades (facilitation). They are not looking for advice from a broker. They are repeat users, although some would use the system far more frequently than others. Some would call from their cars, others from home. We now have important information about who the customers are and what they want to see (or hear) in a service. We will do two things with this information: Feed it into the high-level design and use it to help make design tradeoffs during detailed design. To help us further understand the customer, we ask the client whether we can hear some live interactions between brokers and customers. We want to listen to the language that is being used and the order in which information is shared between the two. We also want to get a sense of how knowledgeable these traders are and how much help the brokers provide them. In the course of a day, we work with four brokers and listen in on eight to twelve calls with each one. We also ask them questions to get their view of the needs and concerns of their callers. A few trends emerge: Callers always ask for a few stock quotes before placing trades. Often, they ask not only about the company they are trading but also about other companies in the same industry. Before placing a buy order, they usually check the cash balance in their account to help decide how many shares to buy. The brokers always carefully confirm the details of a trade before placing it. If the caller sounds at all unsure (e.g., "Um, yeah, I guess that'll do"), the broker asks for a more definitive confirmation, if necessary repeating the details of the trade. Occasionally, a caller does not know his or her account number. In that case, the broker solicits some personal information, such as name, address, and mother's maiden name, to access the account. 7.2.3 Understanding the ApplicationGiven everything we know about the end users and everything we know about the client's motivations, we work with Lexington on a complete definition of the functionality. It seems clear from customers that gathering and monitoring information are key. They want to get up-to-the-minute stock quotes, updates on their portfolios, account information, and even financial news. Lexington emphasizes the need to incorporate personalization features into the application to make it sticky. We agree on three personalization features: personal watch lists (lists of companies callers can get quotes for in a single request), a portfolio performance summary (account value and quotes for companies callers own), and account settings such as default accounts for balance inquiries. Trading of stocks and mutual funds is clearly needed. Other features that go hand-in-hand with placing trades are learning about executed orders, reviewing open orders, and canceling and changing orders. A number of other features allow the customer to manage money and get account information. They include transferring money between accounts, withdrawing money, and requesting copies of monthly statements. We compile a list of all the features (see Table 7-1) and consider what information the caller will need to supply to the application and the type of information it will provide to the caller. The client agrees on this list of features. We discuss a feature that allows the caller to request news headlines and reports for companies. Given the complexity of this feature and the desire to deploy quickly, we agree to delay it until a later version. Similarly, we decide to wait on speaker verification (as a replacement for PINs) until a later version. Any other requests for new features will also be considered for a later version.
Before our next meeting with Lexington, we review each feature for recognition complexity. The only recognition challenge we identify is account numbers, which are 12-digit strings. We want extremely high recognition accuracy for account numbers, because that is the first item requested by the system when callers log in. We want that interaction to be seamless. This issue is put on the agenda for our next meeting. At this point, we bring in the technical members of the team at Lexington and talk about the application environment. The system will need to connect to data feeds that supply quote information. It will also require access to the database that stores user account information and to the backend transaction services. Additionally, there will be an interface with the CTI (computer telephony integration) software to pass caller information to a broker when a call is transferred. We discuss the recognition of account numbers. Lexington informs us that the last digit of the account number is a checksum. We agree to use N-best recognition. The application will test each item on the N-best list for a valid checksum and, if it is valid, will check the account database to see whether it is an existing account number. The account number chosen will be the one having the highest recognition confidence that has a valid checksum and exists in the database. (See Chapter 13 for more details on this and other approaches to solving tough recognition problems.) The tech team gives us copies of the specifications for all the data feeds and the CTI system. This documentation details all the inputs and outputs for the transactions and all the failure modes (all failure messages that may be returned to the application). We review these together to make sure we have all the details we need. For each integration, they provide figures on average latency. A summary of everything we have learned from the requirements process, including an exhaustive feature list and the success metrics, is written up in a formal requirements definition document. Lexington quickly signs off on the requirements definition. Given how closely we have been working, there are no surprises. It is now time to move to the next design phase, high-level design. We take a step back to reflect on what we have learned from the requirements phase. We now have a thorough understanding of who the callers are, how they view themselves, and what features they want in a service. We also know about the business's perspective: what its motivation is, the key features that will help the business case, the corporate image it wants to promote, and its rollout plans. We have mapped out the service's functionality, and we have prepared a list of the databases and data feeds that must be integrated with the system. Although it has taken a bit of time to collect all this information, the time has been well spent: Our design decisions going forward will be well grounded, and we will be able to look back at our finished product and accurately assess whether the goals we have set out to achieve have been met. |
