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.
It is impossible to create good design spec "from the ground up". A
design spec specifies HOW the system will function. This is the second
thing that needs to be done. The first thing is to create good
requirement spec. A requirement spec specifies WHAT the system must do
from the end user's perspective.
I have a lot of experience in this area. If the requirement spec is
good, creating a good design spec is easy and intuitive. However,
without a good requirement spec, it is next to impossible to create a
good design spec (especially for larger systems). You can have a PHD in
systems design and you will still be ineffective.
Tony Markatos
>From techwr-l -at- listserv -dot- okstate -dot- edu Thu Feb 12 07:44:29 1998
>Received: from listserv (139.78.114.100) by listserv.okstate.edu (LSMTP
for Windows NT v1.1a) with SMTP id <0 -dot- 198F6B50 -at- listserv -dot- okstate -dot- edu>;
Thu, 12 Feb 1998 9:46:32 -0600
>Date: Thu, 12 Feb 1998 08:49:34 -0700
>Reply-To: kblack -at- itsnet -dot- com
>Sender: "Technical Writers List; for all Technical Communication
issues"
> <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
>From: Kristen Black <kblack -at- ITSNET -dot- COM>
>Subject: Writing design specs
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>
>I've been asked to document the programming process of a new piece of
>software. The only work that's been done on the project so far has been
>done by the man in charge. He's designing the interface/screens in
Access;
>they'll soon be ported to Oracle when the programmers go to work on it.
>What I need to do is document the flow and the details of the screens
so
>that the programmers have something to work from. I've created a flow
>chart, tables that list all the screen elements, and a simple process
>document, but what I need help with is the format of the whole
thing--as in
>information on creating design documents. I've been in on the design
>process of other products, but they were completely different (word
>processing software, graphics packages, web development software, etc.)
The
>other products were more modular, where this one is linear. It tracks a
>credit application through the data entry stage through several
decisions
>until a credit card is issued or denied. It's pretty complex.
>
>Have any of you ever written the design specs from the ground up? What
>format did you use? What was most effective? I can use what I've put
>together, but somehow I think that there might be a better way to
organize
>it all.
>
>Thanks in advance for any advice you can pass on.
>
>Kristen Black
>Freelance Editor, Writer, and Indexer
>kblack -at- itsnet -dot- com
>
>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
