Agility Guide


We imagine at this point in the book hard-core agilists are forcefully saying, "What happened to 'Working software over comprehensive documentation'? Why are you asking me to write the requirements when I can build working software?" Despite the title of this chapter, we are not asking you to actually write the requirements. We merely want you to formalize them to a point where all concerned stakeholders can agree that you have the correct requirement.

The important point to keep in mind here is the difference between a requirement and a solution. Working software is great, providing it solves the right business problem. The intention of formalizing the requirement is to ensure all interested stakeholders agree on the requirement, and to allow the designer and the software builder to construct the right implementation on the first attempt. We know of no more efficient way of arriving at working software.

Rabbit projects should not write a specification, but should consider some of the attributes of the requirement. Things such as rationale, fit criterion, and customer value can be added to your blog or wiki. This expansion can be done at any time once the requirement has been proposed. Think of this chapter as not so much writing a specification, but rather as enhancing your blog. The intention is not to make requirements gathering more bureaucratic, but to make software development more effective.

Horse projects should start with the requirements knowledge model (shown in Figure 10.2 later in this chapter). Make sure you know where and how these components are recorded. It is not necessary to have them all in one specification, but it is necessary to have them somewhere. Horses should consider the amount of specification they need. We describe here a complete and rigorous specification, but please assess your needs before producing each part of the specification.

Figure 10.2.

The requirements knowledge model represents the information gathered during the requirements process. For convenience we use a UML class diagram to model this information. Each of the classes (shown as rectangles) is a repository of information about the subject (name of the class). The information can be in any form. The associations (lines) between the classes are relationships needed to make use of the information. The numbers attached to the classes correspond to the section numbers in the Volere Requirements Specification Template.


Elephant projects will build a complete specification and should use some kind of automated tool to contain it. Many such tools are available, and the prime consideration is to allow the team of requirements analysts to access the specification simultaneously. Because of their size and fragmentation, elephant projects need to be ultra-concerned with having enough formality to ensure their requirements are traceable from the product to the work, and from the work to the product.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

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