Supported Phrases – An Introduction to Requirements
Requirements documents for simulators often contain very loose definitions for supported phrases. For example, the system shall support all appropriate phrases defined in document XXX and locally supported terminology. Command & Control applications do not typically have the same problem, but often the complete definition of the required phrases is difficult to compile and results in an incomplete specification. These types of definition raise the following issues
Locally supported terminology is an unconstrained requirement. Reference to a document will often result in disparities due to the interpretation of the document. No vendor can truthfully report compliant and furthermore, no vendor can develop estimates for the level of effort to support these requirements. This will result in apples and oranges pricing comparisons.
For command and control systems, requirements difficulties are also present. We might think we have covered every possible phrase until the system encounters a human. In an application that is simply designed to turn on and off the television we develop the following list of supported phrases:
Turn on|off the television
Tee Vee on|off
And probably many others, but we have no real assurance that we have covered all reasonable variations such as please turn on the telly.
Poor Grammar Definitions – Difficulties for the Buyer
If a purchaser selects a vendor based upon these requirements and the vendor turns out to be non-compliant, the purchaser is in a no-win situation. If the buyer can argue that contractually the vendor is responsible for all costs to become compliant, the system may be unusable until the necessary changes are made. The purchaser also has no mechanism to determine how long it will take the vendor to become compliant.
Comparisons between vendor offerings can be difficult if not impossible if specific terminology cannot be documented. This will ultimately lead to arguments and contract disputes. Furthermore, testing for compliance will also present difficulties.
Requirements Specifications
Speech Functions
We recommend that written requirements for supported phrases, focus on the functions that you wish the speech system to support e.g., “Turn On” the television, “Turn Off” the television. System functions are usually the cost drivers as they require the support or addition of sometimes very complex simulation or command & control functionality.
When issuing requirements, a vendor can provide a like for like pricing comparison It is not necessary to document specifically what phrases may be needed. Example
The system shall support the following functions
TV On
TV Off
Volume Up
Volume Down
Definition of Supported Phrases
Arguably the easy part is the definition of supported phrases. A requirements document could add the following,
The system shall support the following phrases, phrase 1, phrase 2, phrase 3…. etc. This may be useful when a list of phrases already exists.
The vendor shall support the inclusion of 100 additional spoken phrases. The additional phrases to be included shall be identified during the test and warranty phases.
The vendor shall provide pricing for the addition of phrases beyond the original requirements.
One final note, give some consideration to what constitutes a phrase. If for example, the system supports the phrase “Turn on Television”, it is not reasonable to consider “Turn on the television” the same as adding a completely new phrase.
For a more detailed discussion of speech recognition requirements definition, check out our free download Speech Recognition Requirements.
