Aspects of Research
Performing research for a speech-recognition system is not done in a
It's important to remember that when you finish the research phase, you should have a full understanding of the requirements of the system. At that moment the designer and the client will agree on what the completed system will comprise. This will all be documented in a Requirements Specification.
The most successful products are usually those that are designed for the needs of a specific audience. Apple Computer's original Macintosh computer is a great example. Because the Mac was intended to be "a computer for the rest of us," its developers made it as simple to learn and use as possible. To ensure that you create a system that works for its intended audience, you also need to research the
One of the most
One of the most common ways designers solve problems is by drawing parallels to previous problems or real-life experiences. This approach can be particularly useful when designing a speech-recognition system due to the relatively few deployments of speech systems (in comparison to graphical
To perform a morphological analysis literally means to analyze the structure of something, but here the definition is expanded to include the analysis of features as well. For example, if we were asked to design a new VCR, we might look at many of the popular (and not so popular) VCRs and other similar types of video playback/recording systems (like TiVo and DVD players) sold today, and compare them to each other. We would create a grid, listing all the devices on one axis and their features on the other. By placing marks in the grid to specify which models have which features, we could begin to see trends forming. For example, we would learn that all video delivery
Different designers may very well draw different ideas from these data. For example, one designer might conclude that because the one-touch recording feature is rare, having this feature on a new VCR would help differentiate it in the
Table 4.1. A Morphological Analysis of Video Playback/Recording Systems
Sometimes it's helpful to expand the morphological analysis beyond the obvious comparisons. A person designing a VCR might learn something important ”or become inspired ”by performing a morphological analysis of audio cassette players or other
But how can we perform morphological analyses with speech systems? At the moment, there aren't as many types of speech-recognition systems in the world as there are VCRs, so it's not easy to compare them directly to each other. However, we are able to compare the various features of different types of systems that perform similar tasks.
If we wanted to design a telephone-based banking system using speech recognition, we could examine the features of different banking channels (phone, Web, live-teller, ATM, and so on). By comparing these different channels, we could gain an understanding about the kinds of features to put in a speech system. Table 4.2 shows how the beginning of a banking morphological chart might look.
This simple analysis might suggest that the speech-recognition system should perform all the tasks that the touchtone system can, as well as some others that can be automated using a speech-recognition system. In this hypothetical example, we might know that a large number of people reorder checks most often because they move, rather than because they just want the
Table 4.2. A Morphological Analysis of Banking Features
Every speech-recognition system is a service channel ”and it can provide many types of services. That's why it's important to know not only what services the system will provide, but also what services it
provide. Besides helping to determine the scope and structure of the system, understanding the limitations of the system can allow you to create a system that
What Clients Say versus What Clients Want
It is the rare client or caller who will tell the designer exactly what he or she wants in a speech-recognition system; most clients simply don't understand the technology and design issues well enough to know its capabilities and limitations ”particularly since technologies and standards change over the course of months and
For example, if we were trying to design a flight information system, and we asked several people what they wanted to know about their flights, many of them might tell us that they want to know "when the plane is going to arrive." If we were to interpret this requirement literally, we might have the design provide the exact time of arrival ”"Flight 1687 will
Another way to examine this is to think about the delayed flight. Let's say we were about to take a trip and we called the airline to check on our flight, which was scheduled to depart at 1:55
If the system response only said "Flight 16 is leaving at 4:45
" ”a three-
An airline might also want to include the on-time information if its high
As these examples
Although technology is advancing
But understanding the limitations is only one aspect of a larger issue ”feasibility. A particular design feature may be desirable to the client or callers, but it may not be feasible because of cost, complexity, resource issues, schedule deadlines, or performance requirements. In such cases, you must work with the client to develop a more feasible alternative, or determine whether the feature is essential to the success of the application.
Designers must know the limitations (particularly the technical ones) so they can design something that will actually work. That sounds obvious ”and it is ”but it is extremely important, because as designers start the brainstorming process, they will be better prepared to let their ideas flow if they know the boundaries. And of course, boundaries are not always absolute or even detrimental; some of the best ideas come when designers are confronted with barriers to
Risk Assessment/Hazard Analysis
Many designs don't pose any risk to callers or clients, but if, for example, a system could mistakenly execute a stock purchase or sale (or
A simple way to evaluate risk is to determine if a user error is recoverable or unrecoverable. A recoverable error is one that can be easily rectified. For example, if a system were to transfer funds incorrectly from one linked bank account to another (perhaps due to a recognition error), then the caller could simply move the funds back and rectify the situation. However, imagine what would happen if a system were to buy the wrong stock; the caller might not be able to recover from the error before the price of the stock dropped. This unrecoverable error could lead to lawsuits and potential financial ruin (for either the company or the caller!).
By asking clients "What's the worst that could happen?" ”
the system is designed ”you can build in security features that are needed to prevent or minimize the risk of such a worst-case scenario from ever occurring. Some typical security features range from design practices to technologies. For example, after a caller logs in to a stock trading system using an account number and a PIN number, we might assume that the caller is in control for the rest of the call and there is no further need to verify their identity. However, many callers and service providers want to ensure that
Several steps can be taken to protect both parties. First, the system can explicitly confirm a trade and not allow a caller to interrupt the prompt while it's playing. Second, the caller can then either be required to enter or say his PIN number again, or enter or say a separate trading pass code to confirm the trade. Sometimes a caller might become familiar with the touchtone equivalents for some of the commands. Typically a system would assign the 1-key to indicate a confirmation, and the 2-key to
And last, there is technology known as
, the best of which enables a system to