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:Specifications -Reply From:Carol Van Natta <CVANNATT -at- ITC -dot- NRCS -dot- USDA -dot- GOV> Date:Tue, 18 Nov 1997 12:08:17 -0700
Can't help with the first, because our projects are probably
not remotely compatible with yours.
As to the second, however (arguments in favor of specs):
1. Protection against scope "enhancements" dictated by
non-team members, esp. when the deadline is looming.
2. Protection against optimistic promises by marketing on
what the product will do.
3. Supporting evidence to justify to the Powers That Be for
additional resources, approved overtime, a new printer or
development tool, new staff member, etc.
4. Useful info. for bringing new team member (from jr.
programmer to the boss's boss) up to speed on what the
team is working on.
>>> Robyn Hume <RobynH -at- XANTREX -dot- COM> 11/18/97
11:36 am >>>
Our tech writing department is making yet another effort to
get the
programmers and engineers at our manufacturing company
to write
Requirements and Specifications documents. We have a
new project in the
works with a partner in Austrailia ( We are in Canada). Two
developers
are working in two continents and no one is using any written
requirements or specifications.
I have given them some samples of software and hardware
specs and want
to develop a template for the company to follow.
I am having trouble accessing the techwr archives and so my
questions
are:
1. Would anyone care to share some favorite
software/hardware spec
contents and samples, Functional or otherwise .
2. Does anyone have any suggestions as to dealing with
stubborn project
leaders who don't seem to think these are important . I have
tried the
"legal liability" argument and the "we need them to write the
manual"
argument but to little avail.
