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: Documenting from Program Specs From:"Bergen, Jane" <janeb -at- ANSWERSOFT -dot- COM> Date:Thu, 5 Feb 1998 13:22:13 -0600
In theory, it sounds great....the problem is, at least with our company,
that the program specs are just not adequate for documenting the program
for the user. Rather, they are internal engineering/marketing
information. In addition to the inadequacies (or maybe because of
them...), the final product usual varies widely from the original specs.
I can offer some advice: get in early on the team that develops the
program specs. Go to all the meetings, attend all the demo sessions, and
participate in the discussions. If you see something that needs
changing, speak up. Offer to check the error messages, interface
features (buttons, field labels, menus, etc.), and insist on editing the
final cut of the specs.
Good luck,
Jane Bergen
Jane Bergen, Technical Writer,
AnswerSoft, Inc. Richardson, TX
(972) 997-8355
janeb -at- answersoft -dot- com
On Thursday, February 05, 1998 12:14 PM, Tom Johnson
[SMTP:johnsont -at- FREEWAY -dot- NET] wrote:
> Wow! Our company is taking a big step in the process maturity model.
> I've been asked to write a manual based on the program specs. Up until
> now, I've felt like software documentation would always be like
> "changing a tire on a moving truck." Now the programmers will build
> prototypes and I will base the documentation on those; kind of a
> parallel development instead of a reactive one.
>
> The goal is to have the documentation completed the same time as the
> program. The programmers will be responsible for making sure the code
> matches the specs and the manual. I remember a brief thread about this
a
> year or more ago and I wondered if it ever works in real life.
>
> Have others found this to be a workable approach? Have you found fewer
> revisions are necessary? Right now I'm looking forward to trying this
> approach. I've also been asked to voice any concerns I have regarding
> usability. Any comments?
> --
> Tom Johnson
> Technical Writer
> Elk Rapids Engineering - A Division of Star Cutter Company
