TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Kovitz vs Traditional functional/design specs? From:Geoff Hart <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"Techwr-L (E-mail)" <TECHWR-L -at- lists -dot- raycomm -dot- com> Date:Fri, 4 Feb 2000 09:11:51 -0500
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
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