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: Product Limitations From:"Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM> Date:Mon, 11 Apr 1994 07:51:31 -0500
Irene Plokar writes:
When writing about a product or a program, where do you normally
include its limitations? Is the information included within the
documentation as a separate chapter or appendix, or included in a
separate document (e.g., marketing material, Release Notes, README
file)?
Irene:
When including information on product limitations, I usually take two
approaches. In a manual's Overview section, I sometimes place bulleted lists
headed with "What this product will do" and "What this product will not do."
This was when I worked for a small agricultural software company, and
"expectation control" was a big problem. Besides, it keeps the sales folk
honest.
My other approach has been to weave the information into the task/definition or
whatever the major organizational piece of the manual is. If I'm writing
a section describing a feature, and it seems perfectly obvious to me that the
user might expect the system to do something it can't (or that it can do only
with a companion program) I make note of it.
