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.
(my responses with >. I've tried to provide more context.)
Rebecca,
For requirements gathering, a Web forms solution on your Intranet may
be better still. The results could easily be collected in a no-cost
database (PostgreSQL, perhaps) for later analysis.
Going automatically to a Microsoft solution would not, to me, seem to
be the way to go when you have "no budget."
> Normally I cheerfully hoist my anti-MS banner on all relevant
occasions. :-) This is a case of using the tools at hand.
If you're got someone with some scripting experience around, you could
have that person put together such a requirements input form using
Python very, very quickly...and there are a plethora of database
bindings for Python.
Of course, using Python (free) and PostgreSQL (also free) would be
very budget-friendly.
> I hate to be negative, but "no budget" means no resources, not just
lack of cash -- heck, *I* am technically not assigned to this project
<g>; I'm on loan to another department until the end of March and
working on this when they don't need me to do anything. I have until May
1 to deliver this.
Perhaps what you're after is more complex than I am imagining?
> I think it's actually much *less* so. Or maybe just different.
On the other hand, a CMS properly established keeps such issues as
versioning to be a no-brainer.
There are many other quite creative optionis. For istance, you might
institute a wiki and make it available to the analysts. That way,
everyone could contribute and avoid needless duplication.
I posted a link some days ago for DokuWiki, which seems designed for
this kind of
situation...
> It looks like a good tool. We use a wiki (different vendor) in our
engineering group, and it's very useful. I don't think one would help us
here, though, and let me explain why.
> These documents (for lack of a better term) are collections of
statements about the configuration of Crystal Reports that are sold as
part of our product line. They can be boiled down to a lot of line items
like:
> (Client C) (Report R) (requirement A) -- (implementation B)
> The "requirement -- implementation" pair consists of things like
"currencies supported -- USD and Euro", "text font -- Arial 9" and
"Employee Name data source -- db fields X and Y." The information is
very atomic and suited to a relational database, I think; Client C
probably has another report where Requirement A has a different
implementation, and Client D bought different reports, with still other
implementations of the same requirements and maybe a few custom ideas of
their very own.
> The original plan was for a Word template (requirements are currently
documented any old way in Word), but this would result in very long
documents with navigational problems, plus the analysts would probably
revert to habit and start burying requirements in paragraphs, wasting
time messing around with the formatting, etc.
> Analysts almost always work alone on projects, and work off-line when
they travel to clients (collaboration and Web availability are moot).
They add client-specific information (a familiar UI is a bonus), but it
should be strictly circumscribed (free-form is out). At the end of the
day they hand over a list of requirements to the client for sign-off and
to the report developers who change the standard offering to meet the
requirements (filtering for appropriate information was the main reason
to abandon traditional documents in the first place).
> I'm perfectly certain that there's a better way out there -- we have
consultants lined up who are anxious to provide us with a
(Microsoft-dependent) one in exchange for a great deal of money. My
particular project, limited in scope, timeframe, and resources as it is,
does not have much room for a major change of direction, but the
long-term plan might *if* another solution provides what we need.
Rebecca Stevenson
Technical Publications | Document Development
Workscape, Inc.
PH: x3059 AIM: RJSWriter
***********************************************************************
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you
are not the intended recipient, you are hereby notified that any use,
dissemination, disclosure or copying of this communication is strictly
prohibited. If you have received this communication in error, please
destroy all copies of this message and its attachments and notify us
immediately.
***********************************************************************
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Technical Communication Certificate online - Malaspina-University College, Canada. Online training in technical writing, software (FrameMaker, RoboHelp, Dreamweaver, Acrobat), document & web design, writing manuals, job search. www.pr.mala.bc.ca/tech_comm.htm for details.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
