So far in this book, we have described a comprehensive set of practices intended to help teams more effectively manage software requirements imposed on a system under development. Since the systems that teams are building today can be exceedingly complex, often comprising hundreds of thousands or even millions of lines of code and tens to hundreds of person- years in development time, it makes sense that requirements themselves are also likely to be exceedingly complex. Therefore, a significant variety of techniques and processes ”collectively a complete requirements discipline ” are required to manage requirements effectively.
However, lest we lose sight of the purpose of software development, which is to deliver working code that solves customer problems, we must constantly remind ourselves that the entire requirements discipline within the software lifecycle exists for only one reason: to mitigate the risk that requirements- related issues will prevent a successful project outcome. If there were no such risks, then it would be far more efficient to go straight to code and eliminate the overhead of requirements-related activities. Therefore, when your team chooses a requirements method, it must reflect the types of risks inherent in your environment.
Each of the requirements techniques we've discussed was developed solely to address one or more specific types of requirements-related risks. Table 30-1 summarizes these techniques, along with the nature and type of risks that each is intended to mitigate.