Customer/User Requirements

Now you may wonder why I called this ‘Customer/User Requirements’. The reason is simple - you will rarely get user requirements from customer. They’ll be quite happy to tell you what kind of application they want, just don’t expect them to go into any detail. That’s your job.

The customer will most likely have thought about the basic functionality of the application, but what they probably won’t have considered is the error handling. They won’t have spent much time thinking about the “what if” questions.

• What order should the options come in?
• What happens after several mis-recognitions (doesn’t matter if it’s ASR or DTMF)?
• What happens after several no-inputs?
• Should problem calls be routed to the call centre?
• What happens if a caller is now allowed to carry out a particular action?

You’re going to have to work long and hard with the customer to come up with the answers to all these and many more questions. But don’t write a line of code until you do. Most customers don’t appreciate how the application will actually work and sound until they use it. But quite often that will be too late to make changes without major financial or timing issues. Make sure the customer signs off on a very detailed user requirement specification. So when they come running back to you 3 months later, saying that the application that you delivered wasn’t what they asked for, you show them the document and their signature. When they say that they didn’t read it in detail, well then that’s their problem.

If you want to you can use UML to model the user requirements - or at least to list the user requirements. You can start with the basic actors and their use cases. However, it makes sense to do some activity diagrams as well, so that the customer gets a feel for the way the application will react - in particular in the case of errors or inconsistencies.

Once you’ve got the basic functions that are required, as well as the call-flow, it should be possible to write a dialog design based on this. The dialog design is set of question and answer dialog states that the caller interacts with.

By the time you’re finished you should have a document, which not only lists all the desired functionality, but also the call-flow, the error-handling and the first draft of the prompts.

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums