Functional Specifications

There are two levels of specifications, Functional and Design.  A good functional spec describes what the product should do and how it should operate.  Design specs describe how a product will be built; these are covered under the Design process.

Functional specifications are often done in parallel with the MRD to save time and to help drive the MRD process; after all, it's no use requiring something that can't be done !!  Parallel spec and requirement development fine tunes each to the objective realities necessary to design, build and delivery the product.  It also better integrates the technical and marketing groups in a joint effort to work out the product details, since, in the end, they will all agree on what's being done and why.  After this process, the technology group can focus on good design and execution of the product, while the marketing group focuses on designing and executing a marketing and sales plan.

The functional specification should be quite detailed and will often run 50-100 pages.  It  should cover every subsystem, including those often overlooked pieces such as configuration, administration and error handling.  

Capture Every Detail

It should simply describe every possible detail of the system, at a level just above the implementation, essentially from the user's perspective.  For instance, it generally covers installation, all configuration options, the entire user interface, all error messages and handling, each feature and menu item, each function, every report and printout, all administrative functions and issues, system requirements, and everything else you can think of.  When in doubt, cover it in the spec, since the development group is not allowed to build anything that it not in there.

Do Not Let Developers Overbuild or Adjust Features

Basically, if it's not in the spec, it cannot be built and the actual product must implement the spec.  Developers cannot deviate from the spec, say by adding or changing a feature, without prior discussion and adjustment of the spec.  "Overbuilding" or adjusting functions is a leading cause of bugs and application issues, where developers think they know better than the spec; this must be avoided at all costs.

Value of the Functional Specification

The spec serves several key functions in the development process.  First, it describes what is being built; this is more complex than it appears on the surface, largely because different people hold different views of how much detail should be used to describe something.

First and foremost, the spec drives good design thinking.  It allows the vast majority of issues to be sorted out and resolved on paper, before any code is written.  The goal it to mentally create the entire system, with all the interfaces and issues satisfactorily resolved before coding.  This will usually involve numerous rounds of discussion and revision, such that people are often amazed how different the final spec looks in comparison to where they started.  It's much, much better to revise a few paragraphs in a word processor than to be changing already implemented code and screens.

Of course,  the specification drives each developers' activities.  It tells them what the product should do and how it should do it.  From that, they can develop design specs and actually build and test the system.

The spec is used by QA to develop test plans and to actually test the product.  Normally, any deviation from the spec is considered a bug; if the developers didn't follow the spec closely, it will be very difficult to distinguish between actual bugs and implementation changes; this will occur late in the development cycle and will only serve to delay the project while everything is argued about and sorted out.

The spec is used by the Documentation Group to develop manuals, help systems, support procedures and training guides, usually in parallel with the development effort.  If the actual product deviates from the spec, these documents will be incorrect, confusing everyone and requiring costly updates.