 Requirements
definition! We learn that in school. Or on the job.
Wherever it is we learned, it just somehow doesn't
work in the real word, does it?
There are times
when in the rush of things to do, we overlook some
of the "requirements" of requirements
definition. While formal training on requirements
definition is beyond what we're trying to do here,
let's look at the most common errors we make in such
situations. We will then look at why that
happens and how we can possibly avoid them.
What's NOT included?
Do most of the
objections you get take the form of "I thought
it was going to do that too?"
That is, it was so obvious and simple that they
never bothered to let you know. They assumed it
would be there, of course.
Such arguments are
sometimes a defensive move on their part. They
forgot and they're covering up. OK, but who's going
to take the hit? You will take some of it, you know.
Let's imagine that
it wasn't forgetfulness, but it was "what a
reasonable person would expect." So now you're
being charged with being unreasonable.
A good defensive
tactic on your part would be to document what is
"not included" in the requirements. While
it goes against our general advice of only putting
things in a positive light, it sometimes helps to
explicitly exclude certain functionality. Or to
state where such functionality / design /
description could be found.
Error
processing
Another
area that causes a lot of frustration is error
processing: which errors had to be caught, and how
that error was going to be processed. We usually do
better in identifying error conditions (some of you
will remember 2000 page abend listings) than in the
proper, graceful processing of error conditions. To
your users, how the error was processed is as
important as the normal processing of your system.
Make
sure error processing is in your requirements.
As I
said, we need to refer you to other locations for
requirements definitions. Some of the names that come
to mind are
-
Yourdon
Press, DeMarco, Tom Structured
Analysis and System Specification,
-
Orr,
Ken, Structured Requirements
Definition
-
Gerald
Weinberg's books
-
"Mastering
the Requirements Process" seminar by the
Atlantic Systems Guild
-
Mastering
the Requirements Process,
Robertson, Suzanne and Robertson,
James, Addison Wesley, 1999
It's not easy
to describe requirements
It's
your job
to get the requirements,
not their job
to
give them
to you. |
If
nothing else, here is the only sentence I would
suggest you try to remember from this article: It's
your job to obtain the requirements, not their job to
give them to you.
That's
because describing needs is not a common skill. So we
need to use the proper techniques to do that.
How do you get
it out of them?
First, understand
that describing needs is stressful. You need to make
your counterpart feel at ease. It's best to be
conversational, not interrogative. Let the subject
wander around, if the other person feels like doing
it.
Second, do not start
with "features" of the system. Start with
their business, their problems.
When practical,
discuss a "straw man" or
"prototype" or other example. This
accomplishes two things: It shows that you've been
listening (always a challenge), and it helps you
confirm whether you're headed in the right direction.
"Tell me, John, it sounds like it should be
moderately secure but very fast."
Use questions to
juggle their memories: "What happened when you
had the other system", "Which problems were
most common?"
When giving the other
person choices, put the most likely choice first.
Use their words.
Don't find equivalent words. People like to hear their
own words. Play back their own statements: "John
you said you would be willing to take 'a small
performance hit in exchange for full
user-friendliness', right?"
But never let
ambiguities lie there forever. If possible, go back
and ask, "what did you mean by a little
performance hit? Is it 1 percent, 5 percent or 25
percent?"
Use
consensus-building language, such as:
- "Are you with
me on this?"
- "Does this
make sense to you?"
- "Is this OK
with you?"
And last, never
leave a meeting or conversation on requirements
without asking if they think you’ve covered it all.
This gives you a chance to cover . . . "what you
should have covered!"
I hope
this helps. For more, visit our forums.
P.S.
Don't overlook the checkpoint
technique as you try to validate that you have the
right requirements.
Next
article
Copyright
© 1999,2000 Brazos Consulting . You may reprint or
distribute this document as long as it has not been
modified and proper credit is given to Brazos Consulting
and The Consulting Academy. Web links are permitted only
in a "new window". |
|
Random tips from our
|
Random tips from our "73 tips for IT
professionals" booklet:
|
Tip #38 (Client relationships)
The key to good communication with clients is
to have frequent contact, preferably face to face
and one on one. Artificial communications
such as e-mail, voice-mail, and PowerPoint
presentations are nowhere as effective. "Face
time" requires considerable effort, but it's the
most effective way to understand each other.
And when one understands, one listens, adapts
and becomes a partner.
|
|
Click Refresh or F5 to get another tip right here. Or
click
here
and get another tip.
|
Also:
Are
you an engineer?
Why
are clients the way they are?
Managing
Expectations
"Is
that your final answer? Consulting and the
Millionaire show"
Surprises
are for Valentine’s Day
. . . how you can gain your client’s confidence by
keeping an even keel and how you can reduce your grief
by learning how to reduce what surprises you.
Enjoy
the S.I.P.s
where we discuss the Strategic Inflection Points of
client projects. If you learn to understand the hows and
whys of SIP's you will feel stronger and more confident.
|
