Summary

In this chapter, we reinforced the concept that the project methodology is designed solely to assure that we mitigate the risks present in our project environment. If in our projects we focus too much on methodology, we add overhead and burden the team with unnecessary activities. If we aren't careful, we'll become slow, expensive, and eventually uncompetitive. Some other team will get the next project, or some other company will get our next customer. If we focus too little on methodology, we assume too much risk on the part of our company or our customers, with perhaps even more severe consequences.

To manage this risk, we looked at three prototypical requirements methods : an extreme requirements method , an agile requirements method , and a robust requirements method , each of which is suitable for a particular project context. Yet we recognize that every project is unique, and every customer and every application is different; therefore, your optimal requirements method will likely be none of the above. Perhaps it will be some obvious hybrid, or perhaps a variant we did not explore. In any case, your team's job is to select the right requirements method for your next project while keeping the project as agile as possible.

Finally, with this understanding behind us, we can now move on to creating that specific requirements prescription you've all been asking for.