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: Business and Technology Requirements documents
Subject:Re: Business and Technology Requirements documents From:"Kristine J. Olberg" <kjolberg -at- IX -dot- NETCOM -dot- COM> Date:Wed, 23 Apr 1997 19:43:51 -0500
Business requirement docs should do this: state the reasons why the product
is being developed or enhanced (from the perspective of the customer). When
writing a B.R. doc, ask this question first: What problem(s) does the
product solve for the customer? Then state what the product or enhancements
will do to solve that problem. For historical reasons, you might want to
include information about the problem itself but without a lot of detail.
I prefer a one or two page doc that briefly describes the problem and then
bullet-points the requirements. The doc should not attempt to answer the
requirements, only state them. Here's an example of requirements for
enhancements to a credit card verification system (hardware and software)
used in a retail business:
"This product must:
- Eliminate Form XYZ, which was used to apply credit when goods are
- Automatically generate a credit receipt for the card owner when goods are
- Digitally verify the card owner's signature.
- Automatically generate journal entries for the card owner's account.
- Run on the Thingamagig hardware."
Obviously, the items in the list are solving business or technology
problems. Everyone else then uses these requirements to generate their
specific documentation, whether it be marketing literature, functional
specifications (which detail how the product will be enhanced to meet the
requirements), end user documentation, etc.
kris -at- olberg -dot- com
kolberg -at- actamed -dot- com