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.
> Specifically, I'm talking about a Project Management Office saying "We
> need no stinking requirements" and an Architecture Department saying "We
> can't build it without requirements." Even more specifically, the
> Architecture Department cannot measure nor report any successes
> without the requirements.
In this case, The Architecture Department needs to send an e-mail to:
a) the Project Management Office
b) whomever Project Management reports to,
and follow up with a paper copy, sent registered mail, asking roughly the
What is this project you wish us to undertake?
What will it be called?
When does it need to be ready for production?
What color is it?
How big is it?
What does it mass (give a range or the limits that we should aim for)?
What does it smell like?
What does it sound like?
Why is it that size, shape, color, and why does it emit those particular
odors and sounds?
Who wants it?
What, precisely, do they wish/expect to be able to accomplish with the
product? Why? Why did they choose our non-existent solution over something
that's already on the market? What IS on the market? Who makes a similar
product, or is this niche wide open? That is, is there a defacto standard
that we need to meet or exceed? What would constitute "exceeding"?
How much is the prospective customer willing to pay (what's the
Will the end-user be the purchaser? Do we care?
Will the person who uses the <thing-we-make> be the same person who sets it
up, and the same person who performs ongoing maintenance
(driver-pilot/bombardier/tail-gunner, IT-prep/admin/lowly-user, ...)?
Or will there be separate, defined roles? What are those roles, and what is
the intended separation?
Is this <what-we-make> to be user-serviceable or must it be returned to us
for any repair?
Or, will it be considered a throw-away item?
If throw-away, how long should we make this thing good for (mttf) so that we
don't get too many failures before the warranty expires - how long will we
Should it be easy to use, or are we going to make all our profit by selling
consultation and training?
Can the cloaking device draw power from the shields or from the weapons
systems? Or should that be configurable?
How "finished" is the product expected to be?
Is it expected to be "stand-alone" or to integrate with other
<stuff-like-we-do-here>? If standalone, is it to be "turn-key" or merely a
starting point (like a toolkit) for customers to go on to make their own,
Should the product be self-shielding, or should the installation
instructions specify the emissions and the shielding requirements?
For normal use by an average user, how much chromosomal damage is
Must the result of this project conform to any published standards (provide
specific versions and other identifying info for each such standard)?
What, if any, certifications or validations must this thing meet?
To what standards is this thing to be tested? If the answer to that is not
the same as the answers to the previous questions, why not?
[ Insert some of your own questions, that would be applicable to your
Be as precise as possible in your answers to all the above questions. Be as
complete as possible. Any omissions or ambiguities in the answers to the
above questions will result in delay of the project and will necessitate
costly re-work and re-testing.
In all cases, word your answer to the above questions with this further
question in mind: How will we and you know that we have met this need?
For each /r/e/q/u/i/r/e/m/e/n/t/ answer to a question, provide a rank - no
more than two items may have the same rank. Also categorize as "critical" or
"nice-to-have/can-wait". If any "critical" item falls lower in rank than
any non-critical item, explain.
Architecture planning and resource allotment starts after the Architecture
Department has received the answers to the above questions and has received
such clarifications and further detail as we deem necessary, to be sure that
we understand what you need. We'll need your signature confirming that our
understanding coincides with yours, in order to scope our portion of the
project. Our output will be an overall architecture and a design
specification for Engineering Department.
Engineering department will have their own requirements, resource
constraints, etc. which they will be able to begin to address once we have
given them the scope and requirements of the project. Waiting on your reply
to start /n/e/g/o/t/i/a/t/i/o/n/s/ the first round of discussion...
Your Architecture Department, standing by, ready to go as soon as we know
where we're heading...
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-