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.
Since someone already asked one question about requirement/specification
documents, it occurred to me you'd be a great source for advice.
What qualities do you think are most important in requirements and
specifications?
I'm consulting for a startup software company that has never had a firm
documentation flow -- up to now they've been prototyping, mainly, so
didn't see the need (!). But after several miscommunications between
management and programmers, they've decided to set up a documentation
system, starting with formal product specifications. They've asked me to
come up with a firm model for the documents -- primarily for programmers
to write (and yes, I get to teach them how to write the documents, as
well).
My difficulty is that I want to make sure to set good precedents so
problems don't arise in the flow between product inception and
production itself.
I'd be particularly interested in the comments of any who have written
specifications for software companies; most of my experience is in
rather nuts and bolts (as opposed to 1s and 0s) manual and procedure
writing for a defense contractor.
