Java Reference
In-Depth Information
users and other stakeholders either. Requirements are still key to delivering a
solution.
So with either approach, you'll start with requirements. Let's look at the
art of requirements.
11.4
W
HAT
M
AKES A
G
OOD
R
EQUIREMENT
A good requirement is one that states a need but not a solution. Sounds simple,
but it's easier said than done—especially with solution-oriented technical types.
A typical first cut at a requirement might be something like “Our budget
application should store its data in the database.” While it sounds reasonable,
it is really a solution posing as a requirement.
The first step in refining such a requirement is to ask the simple question:
“Why?” The answer we're looking for is not “Because we've paid so much for
our database software,” nor is it “Because we all know SQL.” Rather, it should
be something dealing with reliability, fault tolerance, the need for transactional
integrity, and so on.
Sometimes you may have to ask the “why” question more than once, to
refine the requirement(s). “Transactional integrity” is, in a way, a solution. You
could ask, “Why do we need that?” For some projects it may be appropriate to
ask this, because there may not be a real need for it after all.
But don't overdo it. Push any requirement in a business setting far enough,
and you could get something like “To make money.” That's not a helpful re-
quirement. You've gone too far. Part of the art of requirements is recognizing
when to stop asking why.
A more detailed description of a requirement is that it should be
SMART—Specific, Measurable, Attainable,Repeatable, and Testable. Consider
the following.
A common concern among users of almost any application is that it be
“fast” or “responsive.” While we can sympathize with the concern, it will need
some refinement before it can be considered a (good) requirement. Applying
the “Specific” and the “Measurable” aspects of SMART, we need to specify
what constitutes “fast enough.”
We can try “No button press in the GUI will delay more than .1 second
before providing some evidence of activity to the user, or more than .5 second
before completing its operation.”
