re: Requirements

Subject: re: Requirements
From: "Sean Hower" <hokumhome -at- freehomepage -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 14 Aug 2007 07:49:21 -0700

>> Jim Barrow wrote:
>> 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?
My initial response is no. There are, of course, caveats. The biggest problem I have with developers being involved with the requirements phase is that--in my experience--developers have a difficult time seeing past their code and, in some instances, their own self interest ("that will be too hard to code"). Every business level discussion that I've been in that involves a developer has instantly drilled down to the "how" and specific technical issues before the "what," "why," and "who" have been defined. There is a time when developers are valuable, but I think that comes later, once the what, why, and who have been established.

Of course, I'm sure that there are developers out there who are capable of discussing the what, why, and who without drilling into the how, in which case, I would certainly involve those individuals because they are more likely to add the _right_ kind of value at the _right_ time.

But my response also assumes that there is some sort of step-by-step process when in fact requirements gathering is often iterative in nature involving much back and forth between the business side and the development side.

>> Gordon McLean wrote:
>> I'd venture that it's beneficial to take developers along but, as Dori
>> suggests, the tech writers should be the interpreters.
It's only beneficial if the technical writer has the skills to elicit the what, why, and who; ie if the technical writer can add the _right_ kind of value at the _right_ time. Some technical writers can. Some technical writers can't. Again, it depends on the individual and what value the individual can add to the discussion. I know that technical writers have always fought to position themselves as user advocates and that's great if the technical writers have the business knowledge and skills to do that. If they don't have those skills, however, you run a higher risk of missing a critical path or leading development down the wrong path. I say this because there are areas of knowledge that the client assumes everyone knows and while good interviewing techniques can expose some of these areas, an understanding of the business combined with those techniques will expose more.

In the OP, if the scenario you decribe is occurring, then the developers should not be talking to clients. There's a whole business aspect involved that they appear to be missing.

Sean Hower - communications specialist

Create your own web site for FREE at

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.

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: Re: Automating repetitive task?
Next by Author: RE: Photoshop/ImageReady Layers - web buttons
Previous by Thread: Re: Requirements
Next by Thread: The Big Deal (was Re: No Time to Read)

What this post helpful? Share it with friends and colleagues:

Sponsored Ads