Issue 7810: Section 12 (uml-qos-ft-ftf) Source: BAE SYSTEMS (Mr. Kevin Dockerill, kevin.dockerill@baesystems.com) Nature: Enhancement Severity: Significant 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). Resolution: Revised Text: Actions taken: September 30, 2004: received issue March 8, 2006: closed issue Discussion: The purpose of the misuse cases is to make the scenarios containing misuse explicit at the use case level. A misuse case may of course be refined into several scenarios, as with use cases. This is no less generic that deriving risks from scenarios; the difference is an explicit grouping of scenarios into those that contain misuse and those that don't. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 30 Sep 2004 06:26:11 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Kevin Dockerill Company: BAE SYSTEMS, Warton, Lancs UK mailFrom: Kevin.dockerill@baesystems.com Notification: No Specification: UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms Section: Section 12 FormalNumber: Ptc/2004-06-01 Version: Draft RevisionDate: 7/21/2004 Page: 51-68 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Description 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).