Recognize and track them from the moment
requirements are written. While it may not be possible to assign a cost to the risk from the outset, it
should be possible to assign a hazard potential (
High, Medium,
or
Low
) to each requirement such that
it can be eventually transformed into a risk. In this way you can:
??? Identify the features most in need of early prototyping, or formal specification.
??? Determine the level and rigor of tests needing to be written.
??? Assign the bug fixing priorities.
??? Assign effort.
??? Monitor the feature status.
??? Identify when the features are likely to be used, from the operational profile (this will give you
the risk exposure factor).
Table 3.1 lists some frequently-mentioned risks and things you can do to mitigate them.
3.1.4 Risk Exposure
Every component or feature represents a risk however small. However it may not represent a risk
all
the
time. It may be very rarely used. So it??™s useful to understand how often it will be used in order to gauge
whether to devote a lot of resources to testing it. Risk is only exposed when a threat is present.
Why is this important? You need to be able to:
??? Identify costs in order to assess the value of taking some mitigating action.
??? Factor in the exposure to the hazard of a project, user, or product, however brief.
??? Ensure both that the exposure period is valid and that your testing represents it.
??? Distinguish between a low-risk, constant-exposure threat and a high-risk, low-exposure one.
Pages:
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142