HOW TO CARRY OUT AN AAD

AAD addresses these problems in the following way. A one- or two-week-long meeting “ an AAD session “ is arranged. Ideally it will be held offsite. Invited to the meeting are all the decision- makers on a project, be they users and IS/IT people, in the case of an inhouse development, or engineering and marketing people in the case of developing a commercial product. All the people who have a say have to attend .

A useful thing to do in advance of the AAD process is to have a sort of mini-seminar whose objective is to set both the AAD team's and upper management's expectations. This seminar would explain what the process is and what results can be expected. Having done this, there is preparation that needs to be done by each of the AAD team members . Each participant must independently write down:

• the name of the system/product being built/project

• a one- sentence description of what the system/product will do

• either three or four benefits of the system/product, or else three or four problems that it will solve

Apart from the attendees “ and, by the way, eight is about the maximum number you can usefully have on an AAD “ two more people are required. The AAD session needs a leader, and it also needs what we call a technical scribe. The leader works from "eight till late"; the technical scribe works from after lunch until late. This is what they do.

On day one, the leader starts the AAD session with the group. The scribe may or may not be there, it doesn't really matter one way or the other. The group begins to put down the main requirements for the system or product. Typically this is done at a board, flipchart, or (if your budget can rise to it) a photocopying whiteboard “ one of the most wonderful inventions known to man. As the main requirements are hammered out, these are then further broken down, and this process will continue until the required level of detail is achieved.

I'm assuming here that you're doing your requirements and designs in English-language documents, on the basis that this would be the lowest common denominator for all software development organizations. Thus, what you are doing during the AAD is taking a table of contents or template for a requirements or design document and filling in the blanks. If you've progressed from this and are using one of the structured methodologies or CASE, then AAD is even more effective when used with these approaches.

To continue with our AAD. The technical scribe shows up in the afternoon. Typically, this person is a senior designer level person. The AAD session ends at say 5 p.m., and the scribe and the group leader take all the notes from the day and write as much of the requirements spec. as has been created. This document is then on each group member's desk when they arrive next morning.

The process begins again, using the fresh document as a starting point. Typically one would hope to have 95 percent of the requirements nailed down by the end of the second day, but it might take much longer than that. AAD sessions are completely time-driven, and so you plan to do as much as you can in the time allowed, as opposed to having a fixed amount of work to do, and a variable amount of time in which to do it.

The days continue in this way with updated documentation being created each evening, and used as a starting point next morning. Results vary, but at the end of a two-week AAD session, you could expect to have a requirements spec. that was almost 100 percent correct (only small items of detail should be in doubt, if any); and some proportion of the design of the system/product in place.