-
Key: QFTP-28
-
Legacy Issue Number: 7810
-
Status: closed
-
Source: BAE SYSTEMS ( Mr. Kevin Dockerill)
-
Summary:
I think there is a major problem with this whole section. It appears that the 'mis-use cases' are the only way by which risks are defined. This is just not true and I would even suggest that it will be the least used way of identifying risks. I appreciate that there are mis-use cases (e.g. "breaking into a car"), although it could be argued that these could be seen as scenarios (e.g. Use Case is getting into the car and the scenario is "no key"). However, I suspect that most of the risks will arise from scenarios themselves. For example, a use case "configure flight plan" has scenarios involving entry of flight plan data. A risk is that the user is not trained sufficiently or the system does not verify the data. Thus unwanted incidents and threat scenarios are not use cases. I don't have a problem with mis-use cases per se, except when it is proposed as the only solution. Thus the whole profile should reflect a more generic way of capturing risk data to accommodate both the mis-use cases and the mechanisms described here (i.e. derived from scenarios). This generic notion can be reflected in fig 12-5 by defining dependencies between risks and model elements (e.g. use cases, scenarios, components and classes). The dependency has a tag to capture the rationale for the risk (i.e. RiskEvaluation is a tag).
-
Reported: QFTP 1.0b1 — Thu, 30 Sep 2004 04:00 GMT
-
Disposition: Resolved — QFTP 1.0
-
Disposition Summary:
No Data Available
-
Updated: Fri, 6 Mar 2015 20:58 GMT