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.
Always specify an interactive dialogue system fully before implementing it.
Full specification is advisable for the following reasons:
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:
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.