Java™ Application Development on Linux - Dator

268Chapter 11Balancing Acts: An Imaginary ScenarioSounds 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 effectwill network traffic have? What about the size of the operation? If the buttonpress starts an operation that is dependent on the size of some data set, what’sthe largest it could be and how long will that take?Depending on how obsessive you or some colleague will be in enforcingthese requirements, you would do well to add a few “weasel words” to give yousome flexibility in the requirements. Phrases like “on average” or “most” willhelp. 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 effectof network traffic on response times. Under what network load will the testsbe done and the real usage occur? If you want to test under “normal” networkloads, how can you control this (for the sake of repeatability)?It really is an art to craft good requirements. Moreover, a good requirementfor one organization may not work well for another. Some teams, groups,or companies want to be very precise in their use of requirements, viewing themalmost 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 willdrown in the details and spend way too much time (and money) arguing overthe minutiae of the requirements. Overly informal groups will get sloppy withtheir requirements and not reap the benefits of building the right thing the firsttime. As is so often the case in life, the answer lies in striking a balance betweentwo forces, one pushing for exactitude and the other pulling you to get goingand do something.So let’s keep going.11.5WHOM TO ASK FOR REQUIREMENTSThere are many people to ask about the requirements for a software project orproduct. Ask yourself the following questions:• Who is going to use the software that you develop?