Guidelines/ideas for documenting limitations of a tool?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Shilpa Sharma has <<... a list of 200-250 limitations of a software tool
that I need to document. The tool is going to be
EOLed (End-of-life) very soon. The objective of the user guide is to reduce
customer calls by informing users up front as to what all is not
supported.>>

If you already know the limitations, and are prepared to document them, then
your problem becomes relatively simple: sort the limitations into logical
categories (the same ones that the readers would use), then provide good
access to those categories and the topics they contain via an index and
table of contents.

--Geoff Hart, FERIC
580 boul. St-Jean, Pointe-Claire, Quebec H9R 3J9
geoff-h -at- mtl -dot- feric -dot- ca 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

  +++  Miramo -- Database/XML publishing automation.  See us at  +++
  +++  Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion  +++
  +++ More info: http://www.axialinfo.com  http://www.miramo.com +++

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.