| Once you complete all the research, you'll be ready to write the Requirements Specification document. The Requirements Specification answers the question "What needs to be done to make the system real?" not: " How will the system work?" The Requirements Specification is essentially an agreement between the designer and the client that: -
The designer does indeed understand the client's needs, the objectives of the systems, and for whom the system will be deployed. -
The designer will perform what is spelled out ”and no less. Most of the time, a client doesn't mind if a design does more than is described in the Requirements Specification, so long as it doesn't exceed the budget or cause schedule slippage. The reason that you should not describe the specifics of how the design will work is because usually at this point you have not fully considered all aspects of the solution. Therefore, there is a risk of setting the client's expectations either too high or too low. It's best to think of the Requirements Specification as part recipe (where all the particulars of the system are clearly spelled out) and part story (a description of how the system will feel). Keep in mind that the language of this document doesn't need to be stilted and stuffy. It should be written in simple, vivid language because often this document will be read by a variety of people, including lawyers , project managers, technical specialists, marketing managers, and vice presidents . You should ensure that it flows clearly from big picture ideas to specific details. Above all, the Requirements Specification needs to be cogent, because the contractual obligations between the designer and the client will be based on it. Included in the document are: -
A description of the overall functional goal of the system. Example: The system will allow callers to conduct banking transactions from any telephone . -
A description of the callers and calling behavior. Example: 80% of the callers are expected to be in their 30s with an average income of $45,000 a year. They are expected to call in to the system from home about 50% of the time, from work 25% of the time, and from other locations, including the outdoors, 25% of the time . -
A description of the specific functions of the system. Example: The caller will be able to transfer funds among savings, checking, and money-market accounts only. However, a caller might have up to three accounts of each type that may differ only in the account number . -
A description of the database functionality that will provide the information to the application and the components to be used. Example: The database will provide the system with all the customer's account information based on their account number . The Requirements Specification may state that the client will provide certain things that don't currently exist. For example, the client might have to change the database to work in a different way to support a particular functionality. By putting this in the document, the designer is assured that the system will work as planned once it's completed. A typical example of how the database might be expanded is when a speech system would be able to take advantage of knowledge of usage patterns of the caller. In this case the ability of the speech system to be able to store just a few bytes of data can allow the system to remember what actions the caller has or has not performed in the past and can teach the caller new functionality of the system ”on a personalized, as-needed basis. -
A description of the feel of the system, including any elements of the company brand. Example: The company's audio logo and tag line will be used when the system greets the caller . The Requirements Specification should discuss the feel or stylistic elements of the system, such as the type of language used in the prompts (formal or informal) and any elements of the company brand that need to be incorporated. For example, if Intel created a speech-recognition system, they may want it to include the four-note audio logo used in their TV commercials. A bank may want to specify that the text of the prompts be consistent with the exacting, grammatically correct style of its literature. -
A list of specific, measurable goals for the system. Example: The system will enable 90% of callers to complete 95% of their transactions . This is a key component of the Requirements Specification, because it provides a yardstick for measuring and evaluating the success of the system. The goals can be both objective and subjective . Here are a few more examples. -
70% of callers surveyed after using the system will give it a rating of seven or higher on a ten-point scale. -
99% of callers will understand every word the system says. -
80% of callers will never need to invoke "Help" after they've used a particular function of the system twice. |
