Java Reference
In-Depth Information
11.6.2
Bob is now back at his desk pondering the conversation he had with Ellen.
“These are not like the requirements we learned about in my software engineer-
ing courses,” he muses. “I've got that sketch of the UI and a brief description
of its functionality. But there seem to be so many unanswered questions.”
So what is Bob supposed to do? He could go back and try to get more
“face time” with Ellen, and ask lots more questions. Sometimes that's a smart
thing to do. Other times such repetition is seen as annoying and a sign of a
slow-witted analyst, never mind how obscure the initial discussions were or
how many times someone changed their mind about what they want. You will
have to judge each situation as you encounter it. At some point, though, you
have to deal with whatever information you've been given, and try to make the
best of it.
So where do you turn? The next best things to do are to begin to docu-
ment the requirements as you understand them, to prototype a solution, and
to start getting buy-in from other stakeholders. Each of these activities may
help bring out more requirements, but that's not a bad side effect.
Back at His Desk
11.7
D
OCUMENTING
, P
ROTOTYPING
,
AND
S
TAKEHOLDER
B
UY
-I
N
Once a project is started, the design must be documented. A prototype may be
built to validate and refine the design. Finally, everyone with a stake in the
success of the design has to be brought up to speed and needs to agree on what
is to be built.
11.7.1
After such a conversation, it's smart to try to get your thoughts down on paper
as soon as possible. Some of what gets said will fade with time, so work quickly
to capture what you can of the requirements that were spoken. Even if you have
to leave lots of blanks, keep moving and get as much of the major requirements
written down as you can, even if they don't sound very formal or polished.
Then go back, revise and edit your statements, filling in the blanks where you
can. Sometimes you will need to ask others to get the answers to fill in the
blanks. Other times you can use your own judgment and initiative to provide
an answer. Out of this process with its subsequent rewrites will come the
requirements document.
Documenting
