Another essential part of project planning is analyzing and tracking the risks involved in developing the project. Even though software cannot directly harm people or equipment, it can cause harm and damage if it provides misleading or wrong information. In some cases these risks can include potential risks to human life or equipment damage. This is the case, for example, in regulated industries such as medicine, defense, and transportation systems.
Unlike these critical software products, the Online Photo Shop application does not impose any kind of risk to human life or equipment. Nevertheless, there are project risks that need to be analyzed and tracked.
Usually risk analysis is based on the project's requirements. Each requirement is analyzed for potential risks in case of malfunction. One approach is the so-called fault tree analysis, which identifies potential software functionality failures that could lead to risks. Another approach is the failure mode analysis, which is a bottom-up approach that analyzes how failures in low-level components alone or in combination can cause potential risks at the application level. In addition to these functionality-related risks, there are general project risks, which also need to be analyzed and tracked. The format shown in Figure 4.7 is used to analyze the risks for this project.
Figure 4.7. Format for Risk Analysis
The initial risk analysis is based on the initial requirements. As with all project planning tasks, risk analysis must be worked on, updated, and extended throughout the development cycle. We need to incorporate all newly identified risks as well as changes that are identified as impacting risk-related items.
For Online Photo Shop, the most critical part, and the only relevant safety requirement, is the online payment. Figure 4.8 shows the risk analysis for this risk. In addition, there are several project risks that are not related to any functional requirement but are still worth analyzing up front. Figure 4.9 shows two examples.
Figure 4.8. Analysis of Online Payment Risk
Figure 4.9. Risk Analysis of Nonfunctional Requirements