Kovitz vs Traditional functional/design specs?

[Geoff Hart <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Tara Charter wondered <<Kovitz (in Practical Software Requirements) states
that the functional specification is the 'what' and the design specification
is the 'how'. I believe that, traditionally, with step-by-step development,
the design spec was the 'what' and the functional spec was the 'how'.
Although I'm inclined to go Kovitz' way, I'm wondering how you have declared
the 'what' and the 'how' in your endeavors to provide useful
documentation.>>

How you define the two specifications, and what labels you use, are purely
irrelevant outside the academic discourse community; that's splitting
linguistic hairs. What's truly important is that everyone involved in the
process understands and agrees upon the meaning of the labels, and that
someone is responsible for ensuring that this understanding and agreement
happens. As a technical communicator, you're ideally suited to serve as the
glue that binds the various parties together, both in the original process
of defining the two forms of specification and in the ensuing
"follow-through" on that definition. If you do this really well, and get
people listening to what you have to say, you may even be able to achieve
the holy grail of technical communication: convincing the developers to
stick to the contract, freeze the interface, and let you begin documenting
things while they tinker with the parts that you can't see and that don't
affect your work. Good luck!

--Geoff Hart, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca 
"The paperless office will arrive when the paperless toilet
arrives."--Matthew Stevens