After identification and prioritization, the overall goal is to reduce the highly exposed risks by coming up with countermeasures. Countermeasures yield new requirements or possibly modified versions of the elicited requirements. These are mostly for product related risks, and they should really be monitored at system runtime. If alternative countermeasures are anticipated, the system can shift from one or another during runtime in case a selected countermeasure ends up being ineffective. In other words, plan for some kind of backup system. We learn all of these using elicitation techniques, especially these interviews and group sessions that we keep talking about. We can also reuse known countermeasures. For example, there are generic countermeasures of top risks that have been produced. Examples are listed here in the additional reading by bone which is an article from 1989 and still holds very, very true. In conflict management, considered simulation versus poor performance. Consider prototyping, consider doing some kind of task analysis. Compare these to poor usability or poor security and do that balancing act. You can also do a comparison between the use of cost models vs unrealistic budgets and schedules. We weigh these issues using risk reduction techniques. Overall, we need to consider the countermeasures, and then evaluate them, and then select the preferred alternatives. Countermeasures can be evaluated based on their contribution to the critical nonfunctional requirements. Countermeasures also look at the contribution of the resolution to other risks and the overall cost effectiveness. Remember that cost effectiveness includes both time and money just like everything in software engineering. This is a big balancing act as all should be considered equally. They aren't, but we try to get it there. Cost effectiveness can be measured by comparing the exposures of risk and the cost of the counter-measure. The cost of the counter-measure would be for if that counter-measure is selected. Here on the slide, we see an evaluation for risk reduction leverage. The equation is the exposure of risk minus the new exposure of risk if some counter-measure is selected. Then you divide by the cost of the counter-measure. The goal is to select countermeasures with the highest risk reduction leverages or RRL. These are refinable through cumulative countermeasures and risk reduction leverages. Cost exposures can be estimated using qualitative or quantitative measures. We've discussed both quantitative and qualitative measures quite a bit before. But remember that either way that you go, these measures are going to be subjective. Equations like this though can help you to validate and document your reasoning based on the counter-measure selection. To record and explain why you have selected particular countermeasures, make sure you document. We always strive for documentation but just like with security measures and other nonfunctional requirements, we say, "Oh, yeah. I'm going to do that later." However, we need to document here. This will explain the reasoning to others on the team, it'll explain to other developers. And as your system evolves, it will give a support system for that future evolution. Even if you're going to be the one performing the maintenance and adding to the product in the future, it's really easy to forget why you did what you did. So do your documentation. For each identified risk, explain the conditions or the events for different occurrences, estimate the likelihood, list possible causes and their consequences. List the estimated likelihood and the severity of each consequence. Also, indicate all the countermeasures that you did consider and the risk reduction leverages that you have calculated. Obviously, you also want to say, "Here's what I actually chose." Show your selective countermeasures. Also, if you have done any annotated risk trees, include those in your document as well.
