Re: Documenting System Under Development

Subject: Re: Documenting System Under Development
From: Harvey Kaniel <hkan -at- NETVISION -dot- NET -dot- IL>
Date: Fri, 26 Apr 1996 17:29:06 +0300

===============On Tue, 16 Apr 1996, Karen Gaignard
wrote:=======================

I don't mean to ask silly questions, but this is my first documentation
project. (Sort of).
The system I am trying to document is still very much under development.
<SNIP>
Can someone(s) give me some advice/techniques for how to handle this?
Detailed advice is much appreciated.
Sorry if this is a ridiculous question, but I am frustrated!

KEG
keg0 -at- atsoaa1 -dot- em -dot- cdc -dot- gov
==================END ORIGINAL MESSAGE================================
Karen:

Your question is neither silly, nor ridiculous. It is very frustrating! I'm
currently concluding the primary stage of documenting a product under
similar circumstances, so I have some observations and recommedations that
could help.

Insist, as much as possible,on participating in meetings where design,
functionality, etc. are decided. Ask questions! At least, demand to review
notes taken during that meeting. Make sure you get your hands on any
existing papers (spec sheet, marketing blurb, existing documentation, if
any, etc.) dealing with the system you are writing about. If available,
obtain a demo of the product (keeping in mind the final product may be
substantially different from the demo . . .). Try to regularly be in contact
with the head of the development team to obtain accurate and current
information and input. If this is not possible, try to locate someone who
can be a liason between you and the development team. In general, make sure
you are "in the loop" as much as possible, trying your best not wasting time
documenting modules, features, etc. that are known to be tentative.
Concentrate (if possible) on parts that are definitely "in" or "finalized."
(You might discover there are none!) Ultimately, as a last resort to pass
(maybe 'kill'!) time, concentrate (if applicable) on other aspects of the
documentation, e.g., graphics (if there are any in existance . . .), page
layout, or the manual's outline.
But possibly the most important thing is be sure whoever is in charge of
your project realizes what is transpiring: that you are waiting for
information! The onus should clearly be on the developers/programmers, etc.
and not you. (Be careful about this. It requires some tact . . .) Your
superiors may have other tasks you can do in the meantime. If they don't
suggest it, ask. It it surely as important to 'be' busy as it is to 'appear'
busy.

Hope this helps.

Harvey Kaniel
Technical Writer
LiveLink Systems, Ltd.
Jerusalem, Israel

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net


Previous by Author: FW: Reference works for UK-US English
Next by Author: Macintosh screen captures
Previous by Thread: Documenting System Under Development
Next by Thread: Frame 5.0 vs. HoTMETAL Pro


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads