Mitigating Requirements Risk with Effective Requirements Practices

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.

Three Points to Remember about Method

1. The purpose of the software development method is to mitigate risks inherent in the project.

2. The purpose of the requirements management method is to mitigate requirements-related risks on the project.

3. No one method fits all projects; therefore, the requirements method must be tailored to the particular project.

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.