Last, but definitely not least, is the review of the functionalspecification. As I mentioned above, this is a document that is approved bythe customer as a token of acceptance of the application you offer him, andtherefore needs to be completely free of loopholes and ambiguity.
The first level of review will be performed by you, the writer. The usualchecks 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 itmakes sense to them.
Next, the project mangers should review the document to see if it isimplementation-worthy. Since these are the people who will be using thefunctional specification in the next level, you can expect them to get backto you if they find that any of your design decisions violate theconstraints under which they will be working.
Incorporation of changes suggested during the review stage needs to be donevery carefully. Be sure to incorporate changes at all points in the designthat are affected by them. Noticing an incompatibility after customersign-off is extremely time- and cost-consuming.
Once you have a functional specification that has been amply thumbed throughby 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 customerasks for, and incorporate the changes for re-review only when you arecompletely clear on their impact.
Once you're all done and your team has started using the document to build amore technical design specifications, you can relax - your job is done, andyou're all ready to take on the next challenge. Happy writing!
Note: Examples are illustrative only, and are not meant for a productionenvironment. Melonfire provides no warranties or support for the source codedescribed in this article. YMMV!
/ 73 
