Page 305 -

276 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

formal position papers, documents, and question and answer sessions. History has
shown that this approach doesn't work very well. Misunderstandings abound, impor-
tant information is omitted, and a successful working relationship is never estab-
lished.
WebRef It is with these problems in mind that a number of independent investigators have
One approach to FAST is developed a team-oriented approach to requirements gathering that is applied dur-
called “joint application ing early stages of analysis and specification. Called facilitated application specifica-
design” (JAD). A detailed
discussion of JAD can be tion techniques (FAST), this approach encourages the creation of a joint team of
found at customers and developers who work together to identify the problem, propose ele-
www.bee.net/ ments of the solution, negotiate different approaches and specify a preliminary set
bluebird/jaddoc.htm
of solution requirements [ZAH90]. FAST has been used predominantly by the infor-
mation systems community, but the technique offers potential for improved com-
munication in applications of all kinds.
2
Many different approaches to FAST have been proposed. Each makes use of a
slightly different scenario, but all apply some variation on the following basic guide-
lines:

? What makes • A meeting is conducted at a neutral site and attended by both software engi-
a FAST
neers and customers.
meeting different
from an ordinary • Rules for preparation and participation are established.
meeting? • An agenda is suggested that is formal enough to cover all important points
but informal enough to encourage the free flow of ideas.
• A "facilitator" (can be a customer, a developer, or an outsider) controls the
meeting.
• A "definition mechanism" (can be work sheets, flip charts, or wall stickers or
an electronic bulletin board, chat room or virtual forum) is used.
• The goal is to identify the problem, propose elements of the solution, negoti-
ate different approaches, and specify a preliminary set of solution require-
ments in an atmosphere that is conducive to the accomplishment of the goal.
To better understand the flow of events as they occur in a typical FAST meeting, we
present a brief scenario that outlines the sequence of events that lead up to the meet-
“Facts do not cease ing, occur during the meeting, and follow the meeting.
to exist because
they are ignored.” Initial meetings between the developer and customer (Section 11.2.1) occur and
Aldous Huxley basic questions and answers help to establish the scope of the problem and the over-
all perception of a solution. Out of these initial meetings, the developer and customer
write a one- or two-page "product request." A meeting place, time, and date for FAST
are selected and a facilitator is chosen. Attendees from both the development and
customer/user organizations are invited to attend. The product request is distributed
to all attendees before the meeting date.

2 Two of the more popular approaches to FAST are joint application development (JAD), developed
by IBM and the METHOD, developed by Performance Resources, Inc., Falls Church, VA.