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
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
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.