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.
> As the software project that I'm working on creeps in scope, I have a simple question about gathering and developing business and functional requirements:
>
> Do you think developers should be involved in this process?
As analysts of the requirements, definitely!
> The developers that I work with have been conducting "requirement" meetings that, in my opinion, resemble design meetings. They're taking 'chunks' of functional requirements and turning these into technical specifications. The problem with this is that they either dismiss some requirements altogether, or do their own interpretation and come up with a specification that misses what the end-users want or need.
Yes, these are design meetings, to be general about it. Requirements
are use cases, business needs, market requirements... all the "soft
and fuzzy" things that define WHY you're employed at the company
producing product. You take these requirements (what people want/need
to be able to do), and begin defining what specifically is needed in
the product to satisfy those needs.That's the birth of functional
requirements. Then you have the design planning from there.
> Today, the developers are headed to a business unit to gather their own business requirements. The problem with this, as I've seen them do before, is that the end-users aren't very adept at expressing what they need in 'software' terms, and the developers can't analyze worth beans. So a typical session with end-users goes something like this:
Well, users know what they want, not what they need. It's up to your
company's own business analysts and product managers to translate the
wants as well as market trends and other "soft and fuzzy" data into
real needs. That's what they're paid to do - needs analysis for their
domain.
> But I digress. The question remains, however: Do you think that developers should be involved in this porcess?
As requirements analysts, yes. As requirements gatherers, no.
--
Bill Swallow
HATT List Owner
WWP-Users List Owner
Senior Member STC, TechValley Chapter
STC Single-Sourcing SIG Manager http://techcommdood.blogspot.com
avid homebrewer and proud beer snob
"I see your OOO message and raise you a clue."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
