Agility Guide


This chapter discusses prototypes as a way of discovering the requirements. So far in this book, we have made it plain enough that, regardless of your aspirations for agility, learning and understanding the requirements make the difference between building the right product and the wrong one. We also hope we have clarified the difference between requirements and the solution to those requirements.

With that in mind, we advocate building prototypesusually a paper or whiteboard prototypeand testing them to see if they would satisfy the users' work. Of course, the users' agreement is not the end of it. Requirements analysis is a much broader church than "Do you like this one?" The analyst has to ensure the particular piece of work fits with the overall architecture of the work. Security, maintenance, and other nonfunctional requirements must be considered. In short, the prototypes are merely the beginning albeit a very useful beginningand not the end of the requirements gathering.

Rabbit projects almost always use prototypes. However, we want to make a distinction between developing a prototype with the intention that once the stakeholder agrees, the prototype becomes the working version, and developing a throwaway requirements prototype. Prototypes as we discuss them here are considered expendable. They are an aid to understanding the users' work, without which you cannot deliver the optimal product.

Horse projects have a larger number of stakeholders than rabbit projects, and use prototypes slightly differently. Although horse projects use requirements prototypes to gather requirements, they need a mechanism with which to test the prototypes against different stakeholders in different locations. These projects also write a specification, and we suggest you rely more on stakeholders' agreement with the prototypes rather than asking them to read through the entire requirements specification.

Despite the formality of elephant projects, prototyping also has a role here. Prototypes should be used when stakeholders, or groups of stakeholders, are having problems explaining what they need. In these situations, prototypes act to clarify the stakeholders' intentions. The formal requirements are still written once the prototype has served this purpose.

We should mention some numbers given to us by software statistician Capers Jones. For smaller applications of about 1,000 function points, Jones discovered that, on average, the prototypes built by the project team contained about 10 percent of the final delivered functionality. For large applications (typical of elephant projects) of 100,000 function points, prototypes covered only about 2 percent of the total functionality. This research points out a problem unique to elephant projects: They are bigger and they have more complex functionality. As a consequence, they should take more advantage of prototyping to discover that functionality.




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