Java Reference
In-Depth Information
After each meeting, review your requirements and see what more you need
to add. Likely at such meetings, you'll begin to get requests for new features.
You have, in fact, begun the iterative process. Even the most bare-bones
prototype that may only consist of a sequence of pictures is a first cut of your
product. The sooner you can get to a running version, the sooner you will be
able to respond to stakeholder suggestions by adding real features.
11.8
R
EVIEW
A good requirement is one that states a need but not a solution. Your first step
is to uncover the needs, while listening to everyone's solutions. These require-
ments will develop into feature descriptions. These should be documented and
then prototyped. The prototype, which is in effect the first release of your
product, can then be shown to various groups—stakeholders—as a way to
elicit their feedback. This feedback should begin to factor in to what you will
build, so now you need to move quickly on to building the real product; do
not get stuck enhancing the prototype.
11.9
W
HAT
Y
OU
S
TILL
D
ON
'
T
K
NOW
Writing good requirements is as much art as it is science, and it involves politi-
cal science as well. This is not something easily taught in a book, but learned
through hard experience.
11.10
R
ESOURCES
One of the original purposes of the World Wide Web was to allow researchers
to share their results. So, you should be able to search the Web for requirements
documents from various projects for examples of requirements specification.
As with any Web search, remember to consider your source. Just because
someone has posted a requirements specification or a template doesn't make it
a good example.
Here are three examples that we found on a single simple Google search.
They may still be there by now.
