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:RE: Requirements From:"Evans, Diane L (Rosetta)" <diane_evans -at- merck -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 13 Aug 2007 07:28:15 -0700
> Do you think that developers should be involved in this process?
Requirements are my life -- it is what I do best.
You need to understand that there are many types of requirements. I
perform validation testing from the user requirements. For example, the
user might have a requirement "I want to start the car with a key." The
user doesn't care how that happens; the developers would need to figure
out how to make the key interface with the car's starter. If the car
starts with a key, the requirement is met.
Should the developers have been in the initial requirements-gathering
process? Only if they will add value to the discussion. Suppose the
user wants a new type of car. You know that they might have
requirements such as, "I want a car with wheels that swivel to make
parallel parking easy." You would want a developer in this discussion
that would say, "We can do that, but it will add xxx time to the
development and xxx to the final cost."
I have both types of requirements meetings. If we are just updating an
existing application, I am most likely meeting with the users alone. If
we are creating an entirely new system, the lead developer is invited
along to add some sanity to the users' desires.
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
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
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-