Re: Requirements

Subject: Re: Requirements
From: Stuart Burnfield <slb -at- westnet -dot- com -dot- au>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Tue, 14 Aug 2007 14:10:18 +0800

Jim Barrow said:
> So a typical session with end-users goes something like this:
> End-user: "We need to be able to see the status of a task in
> real time."
> Developer: "You need a portal that can do a single sign-on."
> End-user: "Um...okay."
> But I digress. The question remains, however: Do you think
> that developers should be involved in this porcess?

Yes, definitely, but depending on the developers they probably shouldn't
be the ones driving the process.

In Jim's example I suspect that a TW or a person experienced in
gathering requirements would write down something like:

1. Need to be able to see the status of a task in real time.
(poss. impl: portal with single sign-on?)

The developer might well write down:

1. Need a portal with single sign-on to view tasks.

The crunch comes when the developer delivers a prototype that features a
portal but which makes it difficult or inefficient to do what the users
really wanted. Users are dismayed; developers fume that users don't know
what they want, always change their minds...

I would also expect the person running the show to ask more questions to
pin down exactly what the users mean.

- who would need to check the status of a task and in what situations?

- What might they do just before checking task status?

- What would they do next if the status is active? pending? successful?

- What do you mean by real-time?

... and so on. Knowing the context of the requirement helps you
understand how it fits into broader sequence of tasks. You wouldn't want
to implement this task view in isolation and then discover it takes
users another 11 mouse clicks to get to a different part of the system
where they take some action based on the status of a task. (At one place
I worked the testers and I referred to one of these as the "at this
point, scribble the ID on a Post-It and stick it on the monitor" step.)


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: How do freelance technical writers deal with the thorny issue of payment?
Next by Author: Re: No Time to Read
Previous by Thread: Re: Requirements
Next by Thread: re: Requirements

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

Sponsored Ads