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.
STRICTLY PRIVATE & CONFIDENTIAL.This email may contain confidential and
proprietary material for the sole use of the intended recipient. Any
review or distribution by others is strictly prohibited. If you are not
the intended recipient please contact the sender and delete all copies.
Sue McKinney <smckinn2001 -at- yahoo -dot- com>
Sent by: techwr-l-bounces+m -dot- vina-baltsas=mindray -dot- com -at- lists -dot- techwr-l -dot- com
03/07/2011 08:56 AM
To
Fred Ridder <docudoc -at- hotmail -dot- com>, techwr-l -at- lists -dot- techwr-l -dot- com
cc
Subject
Re: Software Documentation
Good point, Fred. In my case, we're documenting an enterprise/server
application, for which we currently provide requirements (including use
cases)
and design docs (on the tech side). Those are the docs we're having the
most
trouble with in terms of identifying the audience and making the docs
useful. I
think one issue is that our audience includes management (for approval) as
well
as testers and developers. What I'm looking for is a general accepted
definition
of what, for example, a design specification document should include and
the
audience.
Thanks!
Sue
________________________________
From: Fred Ridder <docudoc -at- hotmail -dot- com>
To: smckinn2001 -at- yahoo -dot- com; techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Mon, March 7, 2011 8:44:21 AM
Subject: RE: Software Documentation
Sue McKinney wrote:
> In my office, some of us are having a debate about the appropriate
content for
>a
>
> document set for software, such as requirements, use cases, design, and
so on.
> Is there a good source that outlines what a good documentation set is
and
> what each document should include? Part of the confusion is over who the
> audience is as well as how to include information that changes
frequently.
I'm afraid your question is too broad to get a answer that will be very
meaningful to your specific situation. "Software" is an *extremely* broad
category, which can include such disparate things as programming
languages,
operating systems, interface protocols, application development interfaces
(APIs, which have become my personal specialty), enterprise/server
applications
(e.g., databases, business management systems, web
services, CMSs), complex
desktop applications (e.g. CAD and photo editing tools), and simple smart
phone
apps. It's all software, but each has its own, different kinds of
audiences
(some have multiple audiences) and its own requirements for documentation.
Create and publish documentation through multiple channels with
Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as M -dot- Vina-Baltsas -at- mindray -dot- com -dot-
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
