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:Specification Dox II From:Mitch Berg <mberg -at- IS -dot- COM> Date:Tue, 24 Dec 1996 11:19:21 -0600
Thanks for the responses I've received on my first post on this thread.
Originally, I asked (broadly) how people approached the process of
documenting system specs and requirements. A broad question, it
received broad (and good) answers. I'd like to go into more detail on
two areas:
* Do you use a Database or a "Living Document"?
Currently, our spec doc is a "Living Document", maintained with a
considerable amount of elbow grease. I can see some advantage to
maintaining a Specs/Reqs database (perhaps on an intranet) which can be
ported to a document as necessary. Does anyone have any experience with
the pros and cons of such an approach?
* Level of Detail?
To what level of detail do you document each "Feature", or "Spec", or
"Requirement"? Currently, each "requirement" in my document receives
several paragraphs. Some responses to my original post advocated a much
shorter format - a statement, a short line of elaboration, perhaps a
lower-level heading describing a "sub-requirement" with more supporting
detail. Any comments?
Thanks in advance, and Merry Christmas!
Mitch
(who, having never shaken his broadcast roots, finds himself in the
office on far too many holidays...)
