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:Re: Definition of a functional spec From:Brent Jones <bjones -at- CITR -dot- COM> Date:Wed, 2 Jun 1999 08:35:43 -0500
Michelle Tuohy wrote:
>
> anyone know a good source of a breakdown of the content of a functional
> spec? depending on who i talk to here (marketing, development, quality
> assurance), i get a different (but similarly vague) idea of what should be
> included.
there's a good reason you are getting vague, contradictory ideas about
what should be in a functional specification. you'll most likely get the
same from this list. that's because func specs aren't discrete,
stand-alone documents. they exist as part of a process.
good functional specifications arise from good requirements analysis.
bad ones occur when little or no requirements analysis is performed, or
the analysis is performed poorly. functional specs cannot be written in
a vacuum, or reverse-engineered.
so, to be honest, a sample outline or template will allow you to write
something that looks like a func spec but that will be of little use to
your project (or to anyone else, for that matter). if you just need to
get a document out, and don't care if it's useful or not, then that
won't matter.
if, however, you'd like to start the project off right, investigate some
requirements analysis resources. my favorite book, and arguable one of
the best, is Ben Kovitz's _Practical Software Requirements, a Manual of
Content and Style_, published by Manning Publications.
another highly regarded book on the subject is Michael Jackson's
_Software Requirements & Specifications: A Lexicon of Practice,
Principles and Prejudices_, published by Acm Press Books. This book is a
true lexicon, and is more oriented toward theory, while Kovitz's is
practical and task-oriented, with real-world examples of requirements
problems and how to solve them.
both books are for sale on amazon.com and elsewhere. in addition, Kovitz
has an online author's forum in which he actually discusses requirements
problems and helps people solve them using his methodology. i don't know
the url off the top of my head, but he posts to this list sometime, and
perhaps he can provide it.
cheers,
brent
--
Brent Jones, Sr. Technical Writer
CiTR, Inc.
"He'd have to trust to the fates, who if not positively smiling
upon him, were at least grinning in his direction." J. P. Blaylock