Java™ Application Development on Linux - Dator

276Chapter 11Balancing Acts: An Imaginary ScenarioAfter each meeting, review your requirements and see what more you needto add. Likely at such meetings, you’ll begin to get requests for new features.You have, in fact, begun the iterative process. Even the most bare-bonesprototype that may only consist of a sequence of pictures is a first cut of yourproduct. The sooner you can get to a running version, the sooner you will beable to respond to stakeholder suggestions by adding real features.11.8REVIEWA good requirement is one that states a need but not a solution. Your first stepis to uncover the needs, while listening to everyone’s solutions. These requirementswill develop into feature descriptions. These should be documented andthen prototyped. The prototype, which is in effect the first release of yourproduct, can then be shown to various groups—stakeholders—as a way toelicit their feedback. This feedback should begin to factor in to what you willbuild, so now you need to move quickly on to building the real product; donot get stuck enhancing the prototype.11.9WHAT YOU STILL DON’T KNOWWriting good requirements is as much art as it is science, and it involves politicalscience as well. This is not something easily taught in a book, but learnedthrough hard experience.11.10RESOURCESOne of the original purposes of the World Wide Web was to allow researchersto share their results. So, you should be able to search the Web for requirementsdocuments from various projects for examples of requirements specification.As with any Web search, remember to consider your source. Just becausesomeone has posted a requirements specification or a template doesn’t make ita good example.Here are three examples that we found on a single simple Google search.They may still be there by now.