Like all beginning specifications, the specification provided by the dinner napkin is ambiguous or mute on a number of important points. Because we need to clarify these with the client, we need a tool that will help us uncover the desired behavior. A very useful technique is to describe the application by means of a series of scenarios, sometimes called use-cases.
You pretend that a working application already exists. You walk through the various uses of the system, describing in detail what is happening at each moment. You can perhaps even create dummy screen shots.
One purpose is to establish the ``look and feel'' of the system, and make certain this agrees with the clients vision.
Another purpose is to make certain we have uncovered all the intended uses. As we brainstorm, some new applications for the system might become apparent that were not forseen in the first analysis.
As part of ensuring the vision for the application matches that of the client, we can create descriptive documentation. This can be the basis for later artificats, such as a user manual. It is at this stage of the process that the view held by the design team most closely matches that of the eventual users, and the questions raised by the design team will mirror the eventual questions that will be asked by users.
Finally, and what is most useful, we can at this point lay the foundations for the eventual software system, by creating a high level software design.