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: Dev. Cycle and the Manual From:Svi Ben-Elya <svi -dot- ben-elya -at- AKS -dot- COM> Date:Thu, 10 Jun 1999 08:19:06 GMT
Ideally the techwriter should be involved in the design stage. This allows
the writer to prepare in-house preliminary manuals of the product before it
is ready. As the product develops, you continually make changes to the
manual to reflect the actual operation of the product. This serves two
purposes.
1. R&D can use the manual as a guide for developing the product.
2. At the end, when the product is ready to be released, you have most of
the work completed and are able to meet any deadline with an up to date
manual. Most of the work at the end is placing the finishing touches, such
as reformatting, page breaks, indexing, rebuilding the TOC, and last minute
proofing.
-Svi-
On 6/10/99 1:59:51 AM Anthony Markatos wrote:
>
>Brian Martin said:
>
>I also agree that creating a user manual would be virtually impossible
>at the end of the requirements phase. Assuming that development starts
>with requirements and continues with architecture, system design, and
>component design, it seems unreasonable to attempt a user manual so
>early. If functionality is detailed in the System Design and widgets
>are described in the Component Design, what would you be writing about?
>
>Tony Markatos responds:
>
>As someone with significant experience both creating software end user
>manuals AND creating functional requirements specs I know that, while you
>may not be able to WRITE the manual from the specs, you sure can PLAN and
>ORGANIZE a manual from good specs (not to the last detail, of course, but
>pretty in-depth). Good requirements specs capture the essential end user
>tasks that must be performed and how all of those tasks interrelate. This
>is exactly what is needed to plan and organize task oriented manuals.
>
>Tony Markatos
>(tonymar -at- hotmail -dot- com)
>
>
>
>
____________________________________
Svi Ben-Elya
svib -at- aks -dot- com
chase -at- netvision -dot- net -dot- il
_____________________________________
