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.
Re: The First Two Questions (Was: Design Document)
Subject:Re: The First Two Questions (Was: Design Document) From:Amy Poos <apoos -at- TREEV -dot- COM> Date:Fri, 18 Dec 1998 13:28:14 -0500
Which one of these is the document that I (the technical writer who does not
write design documents) use? I am expected to review what's in store, to
provide feedback on the plan from a user's perspective and from a logical
perspective, and to start writing the documentation before I see what is
really developed.
My concept of a design document is a document that all groups provide input
to and all groups use to do their jobs. In my software development
environment, these groups include Marketing, Development, Documentation,
Test/QA, Customer Support, and Training. Is this totally out of line with
what other companies do?
Amy Poos
Senior Information Developer
TREEV*, Inc.
apoos -at- treev -dot- com
> -----Original Message-----
> From: Ben Kovitz [SMTP:apteryx -at- CHISP -dot- NET]
> Sent: Thursday, December 17, 1998 10:49 AM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: The First Two Questions (Was: Design Document)
>
[Amy Poos] <SNIP>
> "Design Document" can mean many things to many different people.
>
> One type of "design document" is an interface design: a
> description of all the rules for how the computer's input/output
> devices are to behave while the computer is running a program yet
> to be written. That's the kind of information that programmers
> need in order to write a program. Alas, most companies skip
> interface design, blurring it with requirements or thinking that
> requirements give the programmers all the information they need.
> If this is the kind of document you want to write, then your SME
> is the interface designer.
>
> Another type of "design document", especially as the term is used
> by programmers, is a description of a "high-level design" of a
> program, to to be read by a certain kind of programmer, called a
> "coder", to tell them what subroutines to write and what these
> subroutines' inputs and outputs should be. In this case, your
> SME would be the programmers who invented the high-level design:
> the classes, subroutine specifications, and so on.
>
[Amy Poos] <SNIP>
