In order to identify risks, we can go back to our elicitation practices, including group sessions and interviews especially. Use scenarios to point out failures and to really start to ask the big what if questions. Say, what if these particular interactions don't occur? What if they occur too late? Can there be unexpected interactions due to other systems or wrong conditions? In our train example, you might say, well, what if all the tracks are completely covered in snow? What do we do? It might also help you to look at similar systems to see what risks were addressed there. This is a form of knowledge reuse. Lastly, focused, structured group sessions can be used to identify project-specific risks. Identify those, and also try to come up with alternatives. After we've identified risks, the next challenge is the assessment of those risks. The goal of risk assessment is to assess the likelihood of the risks and their severity, and the likelihood of their consequences. The main goal is to control high priority risks. We can do this qualitatively, which is most common, or we can do it quantitatively. In qualitative assessment, we use levels to describe the likelihood and the severity. For example, for likelihood, we can rate each of the risks based on very likely to unlikely. For severity, we can say it's going to be catastrophic, like people die, all security information is leaked, etc., or it could be severe, high, moderate or low. For each risk, you can create a likelihood consequence table, and from that you can do a risk comparison analysis based on the severity levels. This table can also help in generating a list for prioritization of your general requirements, of your non-functional requirements and also of alternatives. A qualitative risk assessment table looks something like this. Each table is for a particular risk. Consequences are listed in the left column., and the risk likelihood is listed in that first row along the top. For example, as seen here, if the doors are open while the train is moving, there are a number of consequences. If there is a loss of life and the risk is likely, we should be listing that as catastrophic. If it's possible, we'd probably also list that as catastrophic. If it's unlikely, we might downgrade it to severe. On the other hand, if the consequence of the doors being open while the train is moving is that you're going to get a worse reputation, that has lesser orders of magnitude of severity. If it's likely to happen, then risk is moderate. If it's possible or unlikely, then you have low risk. Note, that not all will agree on these measures. It's up to you to negotiate, based on all risks and consequences, in order to come up with a reasonable table. Risk assessment tables are great, in that they're easy to use and understand, however, they do have limited conclusions. All measurements are coarse-grained, and are simply subjective estimates. Also, since we're working in a two-dimensional table, rather than something 3D, the likelihood of the consequences is not considered. Using a quantitative assessment, we can get more numeric information that we can actually process. Instead of likely and unlikely, we use numeric estimates. For likelihoods, we usually use some kind of scale between 0 and 1. One way of doing this is through probability values, so 0, 0.1, 0.2, all the way up to 1. We can also use probability intervals, like 0 to 0.3, 0.3 to 0.5, 0.5 to 0.7, 0.7 to 1. This is what we usually do for likelihood. For severity, a scale from 1 to 10 is generally used. Given this, we may then estimate the risk exposure for risk r, with independent consequence, c. Risk exposure is measured for a given risk based on the sum of the likelihood of a consequence times the severity of the consequence. You do this for each consequence. This allows us to do a quantitative risk comparison and risk prioritization based on exposure rate. A quantitative risk assessment is good, in that it's finer grained than the qualitative assessment, and it allows for more automated comparison and prioritization. However, remember that you are still using subjective estimates. They are not grounded on system phenomena. These numbers need to be elicited from domain experts or through data collection from accumulated experiments or from other means in order to be most accurate.
