 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". |
