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:On-line help with requirements documents From:Ben Kovitz <apteryx -at- CHISP -dot- NET> Date:Wed, 24 Feb 1999 22:51:17 -0700
Marc Lederman wrote:
>I am writing to ask for assistance in developing a system requirements
>document. My current project is a software development effort using a
>web-based tool for the front end and a SQL database backend. We are in
>the process of fleshing out the requirements and I'd like a template to
>use for the requirements statement.
>
>Does anyone have a good idea as to what is needed and how it would flow?
Nope, but that's because I'd have to ask you some questions.
I'm currently giving people free help planning out requirements
documents in my Author On-Line forum. Just go to:
and click "Author On-Line". You don't even need to have bought
the book. At the same site, there are a couple chapters on-line.
Obviously, I can't write the document for you, but I can help you
figure out what information needs to go into it. Just post
something about the project, and I probably help get you
started, if only by asking some questions.
Here's what I'd ask about the above project: (1) What do you
expect your users to do with the tool? Get information about
something? If so, what? Design or create something? Control
equipment or a business? Perform calculations? Translate data
from one form to another? Each of those (and more than one might
apply) calls for different information in the document. (2) Why
do you mention the SQL database? Is that of particular interest
to the users?
I have a simple template, but I don't quite have it ready to give
out to the public.
Something I want to caution people about, though, is that
requirements engineering is not a matter of filling in a
template. Strangely, this is a common temptation. But it's like
expecting that programming is just a matter of filling in a code
template. Just as with any other technical writing, coming up
with the content is the hard part and the majority of the work.
