Java™ Application Development on Linux - Dator

11.4 What Makes a Good Requirement267users and other stakeholders either. Requirements are still key to delivering asolution.So with either approach, you’ll start with requirements. Let’s look at theart of requirements.11.4WHAT MAKES A GOOD REQUIREMENTA 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 budgetapplication 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 forour database software,” nor is it “Because we all know SQL.” Rather, it shouldbe something dealing with reliability, fault tolerance, the need for transactionalintegrity, and so on.Sometimes you may have to ask the “why” question more than once, torefine the requirement(s). “Transactional integrity” is, in a way, a solution. Youcould ask, “Why do we need that?” For some projects it may be appropriate toask 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 requirement.You’ve gone too far. Part of the art of requirements is recognizingwhen to stop asking why.A more detailed description of a requirement is that it should beSMART—Specific, Measurable, Attainable,Repeatable, and Testable. Considerthe 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 needsome refinement before it can be considered a (good) requirement. Applyingthe “Specific” and the “Measurable” aspects of SMART, we need to specifywhat constitutes “fast enough.”We can try “No button press in the GUI will delay more than .1 secondbefore providing some evidence of activity to the user, or more than .5 secondbefore completing its operation.”