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.
On Wednesday 26 July 2006 19:31, Diana Ost wrote:
> I have a question for the group:
> How many of you have been asked to document a software application, but
> were not expected to need access to that software?
> It's happened to me a few times where I had to explain that I can't
> document what I can't see. I was wondering how prevalent this attitude
> is from businesses?
It can happen. Best when it does is to get even closer to the software
architect and do the job of writing the software specs, etc. If you can, get
access to the code. This will give you a good understanding of the
functionality. From this stage you can start to get an understanding of what
the interface of application layer will do. You may not be able to write the
user manual to the fullest extent as the interface design often changes
during development, but you will be able do the structuring, concepts and
some of the feature or functional descriptions.
In some cases where you cannot get access to source code, the work can be done
totally in the blind if you have a very patient and communicative team.
Ask me about the Monkey.
sean -at- inwords -dot- co -dot- za
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l