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: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:
Requirements
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:
Requirements
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.)
Stuart
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-