Java Reference
In-Depth Information
Sounds more formal, and more specific, but is it realistic (i.e., attainable)?
If the “button press” is one that updates a database across a network, what effect
will network traffic have? What about the size of the operation? If the button
press starts an operation that is dependent on the size of some data set, what's
the largest it could be and how long will that take?
Depending on how obsessive you or some colleague will be in enforcing
these requirements, you would do well to add a few “weasel words” to give you
some flexibility in the requirements. Phrases like “on average” or “most” will
help. Notice, though, that such words are also the cause of much ambiguity,
working against the “Specific” and “Measurable” aspects of good requirements.
Use them sparingly, if at all.
We should also consider the “testable” aspect of our requirement for speed.
Will we be able to measure this? Can we do so repeatedly? Consider the effect
of network traffic on response times. Under what network load will the tests
be done and the real usage occur? If you want to test under “normal” network
loads, how can you control this (for the sake of repeatability)?
It really is an art to craft good requirements. Moreover, a good require-
ment for one organization may not work well for another. Some teams, groups,
or companies want to be very precise in their use of requirements, viewing them
almost like legal contracts for what will be delivered. Such requirements, how-
ever, would be greeted with derision in other, more informal, organizations.
It's not that the one will produce good software and the other garbage (well,
they might). It's more a matter of style. Excessively formal organizations will
drown in the details and spend way too much time (and money) arguing over
the minutiae of the requirements. Overly informal groups will get sloppy with
their requirements and not reap the benefits of building the right thing the first
time. As is so often the case in life, the answer lies in striking a balance between
two forces, one pushing for exactitude and the other pulling you to get going
and do something.
So let's keep going.
11.5
W
HOM TO
A
SK FOR
R
EQUIREMENTS
There are many people to ask about the requirements for a software project or
product. Ask yourself the following questions:
• Who is going to use the software that you develop?
