Writing A Functional Specification - Sealed With A Kiss (
Page 9 of 9 )
Last, but definitely not least, is the review of the functional
specification. As I mentioned above, this is a document that is approved by
the customer as a token of acceptance of the application you offer him, and
therefore needs to be completely free of loopholes and ambiguity.
The first level of review will be performed by you, the writer. The usual
checks that any written document goes through - proof-reading, editing,
formatting, spell-check and grammar-check - definitely apply. Beyond this,
you might want to test the document on a designer or developer, to see if it
makes sense to them.
Next, the project mangers should review the document to see if it is
implementation-worthy. Since these are the people who will be using the
functional specification in the next level, you can expect them to get back
to you if they find that any of your design decisions violate the
constraints under which they will be working.
Incorporation of changes suggested during the review stage needs to be done
very carefully. Be sure to incorporate changes at all points in the design
that are affected by them. Noticing an incompatibility after customer
sign-off is extremely time- and cost-consuming.
Once you have a functional specification that has been amply thumbed through
by the internal team, you will be ready to show it off to the customer.
Remember to discuss, in detail, any changes or additions that the customer
asks for, and incorporate the changes for re-review only when you are
completely clear on their impact.
Once you're all done and your team has started using the document to build a
more technical design specifications, you can relax - your job is done, and
you're all ready to take on the next challenge. Happy writing!
Note: Examples are illustrative only, and are not meant for a production
environment. Melonfire provides no warranties or support for the source code
described in this article. YMMV!
/ 60 
