This worksheet is the main destination for SARM and the focus of the trade-off analysis activity in Part 2 of the SARM Process. It contains a lot of information, and guidance on how to navigate it and use it to reach a decision or recommendation, is provided in the page linked above.
Although the worksheet contains a wealth of information, there are only four input fields, cell D2, cell G2, cell K2 and cell D33. The first of these allows the user to select one of the five levels of Impact in the Risk Model. It will then filter all of the information that lies behind the worksheet (and behind the ‘Stakeholder Views‘, ‘Tradeoff Details‘ and ‘Charts‘ worksheets) so that the display only takes account of requirements that have the selected level of risk or higher. By default, it is set to Negligible, which is the lowest level of impact, and so the worksheet will reflect risk information from all requirements. Changing this option enables the team to test the sensitivity of the information on which their decision or recommendation is based. It might be that a different decision would be indicated when considering, for example, only those scenarios that have Major or Catastrophic impact.
Cell G2 allows the user to change the mathematical basis on which ‘Quality Characteristic Burden’ risk scores are calculated. Two options are provided: Averaging by Sub-characteristic and Averaging by Requirement. Either may be valid in particular circumstances, but each may lead to slightly different results being shown under Quality Characteristic Burden and Aggregate Risk Burden. With ‘Averaging by Sub-characteristic’ the average burden for each quality characteristic is calculated by taking the average risk score for each sub-characteristic that belongs to that characteristic and producing the average across that set. This gives equal weight to each sub-characteristic (but not necessarily to each requirement, as there may be different numbers of requirements associated with each sub-characteristic). The alternative approach, ‘Averaging by Requirement’, calculates the average risk score for a given characteristic by taking the total risk scores across all requirements that fall within any of the sub-characteristics that belong to that characteristic, and dividing it by the number of such requirements. This therefore gives equal weight to each requirement within that characteristic (but not necessarily to each sub-characteristic, as there may be different numbers of requirements associated with each sub-characteristic).
If you’re using version 9.3 or later, the term “Aggregate Risk Burden” has been replaced with the term “Overall Risk Burden”. By default there is no difference, the number simply totals the risk scores for each Quality Characteristic. However, in the ‘References‘ worksheet, a weight is provided for each Quality Characteristic, so the term “Overall Risk Burden” refers to a weighted score, allowing the evaluation team to apply different weights to each Quality Characteristic.
Cell K2 is only of relevance if you have associated some requirements to intangible benefits in the ‘Benefits‘ worksheet. It applies a filter based on your selection of one of the four intangible benefits, and will limit visibility to just those requirements that have been associated with the selected benefit. In this way, it is easy to see how the competing solution options fare in terms of each of the four intangible benefits. By default, the filter is set to Off.
Cell D33 allows you to apply a filter on the risk information show against each requirement in row 36 and beyond. By default it is set to 1, so all levels of risk will be shown. Increasing this number will mask all option risks that have levels of risk below that level, allowing the viewer to pick out more easily the requirement / solution combinations that exhibit higher levels of risk.
Conducting a thorough analysis of the information may also involve switching between this worksheet and the ‘Tradeoff Details‘ and ‘Charts‘ worksheets to help the team really understand the risk profile and distribution across the requirement / solution landscape.