Specification and design

 

The design of a specific application is a complicated task which in many cases involves the integration of a number of speech technology components. This may include a speaker independent , continuous speech  recogniser , a parser  which is able to perform error-recovery, a speech synthesiser,  and an application, all being controlled in an integrated fashion by the dialogue manager . Interactive dialogue systems, however, have to interact especially with the human user, who may never have used such a system before.

In this section we consider the process which leads from the high level goal of creating a dialogue system to operate in some domain, to the development of a detailed design on which the implementation may be based. This is a non-trivial task which practitioners new to the field should not underestimate.

RECOMMENDATION
Always specify an interactive dialogue system  fully before implementing it.

Full specification is advisable for the following reasons:

• It gives a good indication of the scale of the task.
• It allows potential problems to be spotted early.
• It usually leads to cleaner and more modular code.
• It gives all parties with an interest in the system an opportunity to check that they agree on the proposed functionality of the system prior to implementation.
• Most importantly, it forces the task of system definition to be given the attention it deserves.

This recommendation is no different from good practice in any area of software engineering. However, interactive dialogue systems  engineering is a young discipline, and it still suffers from an attitude which is common amongst software researchers, namely ``implement first, design later''. Experience suggests that dialogue design is a harder and more time consuming activity than dialogue implementation, and it is worth taking this recommendation seriously.

A specification may consist of the following sections:

1. An overview of the proposed system, describing in simple terms what the system is for, who will use it, etc.
2. A formal and explicit description of the proposed dialogue. This could be expressed, for example, as a state machine with a description of all reachable states in the dialogue, together with information on what actions  should be performed in each state and how to decide which state should be the next. It could be portrayed graphically as a flowchart  or a state transition network, or it could be represented as a dialogue grammar . Whatever representational choice is made, the key point is that the specification should be complete and unambiguous. Preferably, it should also be accessible to potential end users, so that their views on the specification can be elicited.
3. A description of the platform  and general computing environment on which the dialogue system will be delivered.
4. Any other relevant technical material, such as communications protocols for interfacing with external databases.

There are currently no flowcharting  standards for spoken language dialogue  system specification. However, general purpose standards do exist which can be appropriated and modified where necessary for this purpose. For example, the SUNSTAR Project, and subsequently the Danish National Project on Spoken Language Dialogue Systems, uses DDL (Dialogue Description Language), whose graphical component is based on SDL (Specification and Description Language), which was standardised by CCITT  [Belina & Hogrefe (1988)]. It is basically a graphical language for describing state transition diagrams for event-driven systems. It has been heavily extended with new symbols, new meanings for existing symbols, new diagram types, and new ways of connecting symbols.

In the following sections we shall examine three approaches to dialogue system design which have been explored by researchers. Few groups have used only one of these approaches to the exclusion of the other two. As we shall see, each approach has different strengths and weaknesses. We shall call these approaches design by intuition, design by observation and design by simulation.

 
• Design by intuition
• Design by observation
• Design by simulation
• Iterative design methodology for spoken language dialogue systems
• Readings in interactive dialogue system specification