i saw this tutorial on functional specifications linked around a few places [ none of which i can remember right now ]. as an overview of the traditional functional spec it's the second best overview i've seen [ incidently, the article links to the best overview i've seen, painless functional specifications , which comes from joel ]:

"When the Functional Spec is completed, anyone who reads it should have a very clear idea about what the application is going to do and what it is going to look like. It should read very much like an instruction manual or cook book, with step-by-step descriptions of what happens and how the individual elements of the application work together.

Another key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut, explains my love affair with the Functional Spec."

unfortunately, while this goal is certainly admirable, it will usually fail from an operational perspective, in part, explaining the horrendous record of estimations of development schedules, project complexity, and programmer productivity. this, in turn, leads to the interest in "lightweight" methods for requirements gathering , which alters the relationship between the developers and the customer:

"The primary vehicle for requirements elicitation in XP is adding a member of the customer’s organization to the team. This customer representative works full time with the team, writing stories – similar to Universal Markup Language (UML) Use Cases – developing system acceptance tests, and prioritizing requirements [4]. The specification is not a single monolithic document; instead, it is a collection of user stories, the acceptance tests written by the customer, and the unit tests written for each module. Since the customer is present throughout the development, that customer can be considered part of the specification since he or she is available to answer questions and clear up ambiguity. "ing from the spec has, ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut, explains my love affair with the Functional Spec."