Look for Likely Risks (Process Notes 7.2.1)

This task looks for all the risks that could potentially affect your project. The completeness of the requirements specification is a powerful indicator of likely risks. There is nothing wrong with having risks, provided you look for them, define them, and monitor them. The real problems come when people deny the risks and then get a nasty surprise when a concealed risk turns into a problem.

Many risk checklists have been produced by researchers; some of these are suggested in the bibliography in this book. Use one of these checklists as your starting point and add new risks as you encounter them.

For each risk on the checklist, review your requirements specification to see whether there is any indication of this risk. For instance, one of the risks on your checklist might be inadequate customer involvement. Does anything in your requirements specification indicate that you have this risk? Suppose that in the section on user participation requirements, you see that specific user names and roles have not been specified. This omission indicates a likely risk. If you can't specify who will be involved, then it's likely that no one will be available when needed for the project.

For each requirement in your specification, if the requirement measurement is not specified, then it is an indication of a likely risk. Can you think of anything that might go wrong with analyzing, designing, and/or implementing a solution to this requirement? If your answer is yes, then you have discovered a likely risk.

If you discover a risk for a requirement, then dependent requirements will probably be affected by the same risk.