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:Brian Martin <martin -at- SODALIA -dot- IT> Date:Thu, 10 Jun 1999 09:00:50 +0200
I think your points are correct. My understanding was that the originator of
the mail needed to start writing the manual. So one has to define terms. When
does writing begin? In the case of technical manuals certainly planning and
organizing begin the process of writing. If you had to complete the writing
process without a good component design, you'd probably be in trouble.
In my company we use Product Descriptions to describe the "essential end user
tasks" to the the client audiences before the product is created. We try to
create the document shortly after the initial requirements phase.
While the Product Description is essentially a marketing tool, a sort of
laypersons white paper, it is an excellent way for the technical writer to get
familiar with the product in its earliest phases.
Brian
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)
>
> _______________________________________________________________
> Get Free Email and Do More On The Web. Visit http://www.msn.com
