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.
> Where I am now, we call this a Product Requirement Document (PRD).
> The one I have in front of me is a 24 page table, with each row being
> either a requested customer feature or internally driven enhancement.
> They are given a priority, a description of the requirement, a
> comment by product mamagement on its importance, and comments by
> engineering on the amount of effort to include that feature. Each one
> is approved, rejected, or deferred to the next release. This document
> is reviewed ALOT and documentation is at each of the reviews...this
> gives us the anticipated scope of the upcoming product.
>
> However, once they are at the point where they are developing, our
> documentation is a snapshot of the application at the time it is
> being written. I don't care the business reason for having a
> requirement that says "Monitor the LSP end points for status
> changes." If the ability gets developed, I write about it.
>
> Once you have something to write about, BR are not nearly as
> important as the FS documents, which will, in this case, tell me HOW
> the application monitors LSP end point status changes.
Our PRDs are formatted differently than yours, but include much the same
information.
Where I'd differ is that I often find it helpful to know _why_ a feature is
in there, or implemented in a certain way. If nothing else, I can write an
example of "why/how you'd use this" that shows a real-world use of the
feature (because some customer had a specific need that we are satisfying).
When the customer who requested it gets the new version, they recognize it
right away (cuz I tell 'em so) that this is the answer to their requirement.
When another customer encounters the feature, they can read that little bit
of background and either:
a) decide that it'll be useful to them, as-is or,
b) use the scenario as a starting point to develop a work-around that
accommodates them, too or,
c) decide that they need a change/enhancement to make it useful in their
somewhat different circumstances.
For a slightly different example, I could have a couple of features with
obscure little options that I describe:
"You might use this option in a lab/testing environment, where you are
varying the configuration, or setting up multiple units with different
configurations. When you later roll out the final 'production' configuration
to your organization, omit this setting... "
Kevin
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
