Section 11.4. What Makes a Good Requirement


11.4. What Makes a Good Requirement

A good requirement is one that states a need but not a solution. Sounds simple, but it's easier said than doneespecially 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 requirement. 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 SMARTSpecific, 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."

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 requirement 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, however, 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.



    Java Application Development with Linux
    Java Application Development on Linux
    ISBN: 013143697X
    EAN: 2147483647
    Year: 2004
    Pages: 292

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net