Content deleted Content added
pasted 'Goal modeling principles' (derived from former "Goal modelling" article, via EEML), needs work |
m promoted |
||
Line 29:
With the addition of "Misuse cases", the notation can model both desired goals and active threats. The misuse case notation shows negative (possibly hostile) stakeholders as the primary actors for the misuse cases; these may be grouped on the right-hand side of the diagram. The notation may assist in discovering suitable mitigating or preventative goals, shown as subsidiary use cases. These often have the aim of improving security, safety, or reliability, which are non-functional goals. Non-functional requirements can to some extent be described in use case style using [[Misuse case]]s to define negative goals; but the (positive) goals thus discovered are often functional. For example, if theft is a threat to security, then fitting locks is a mitigation; but that a door can be locked is a functional requirement.<ref name=MisuseCase>Alexander and Maiden, 2004. Chapter 7. Pages 119-139.</ref>
Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment.<ref>L. Liu and E. Yu, “Designing information systems in social context: a goal and scenario modelling approach”, 2003 Elsevier Ltd. http://www.cs.toronto.edu/~liu/publications/ISj03.pdf</ref> Goal-oriented techniques are especially useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed.<ref>E. Yu, “Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”, 1997 IEEE</ref>
| |||