Goal modeling: Difference between revisions

Content deleted Content added
m clean up, use arxiv parameter, remove url redundant with arxiv using AWB
m Goal modeling in UML: clean up, typo(s) fixed: counter point → counterpoint
 
(16 intermediate revisions by 10 users not shown)
Line 2:
 
==Principles==
Goals are objectives which a system should achieve through cooperation of actors in the intended software and in the environment.<ref>{{cite web |author=Lin Liu and Eric Yu |title=Designing information systems in social context: a goal and scenario modelling approach |url=http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |publisher=University of Toronto |date=2003 |archiveurl=https://web.archive.org/web/20050205073259/http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |archivedate=February 5, 2005}}</ref> Goal modeling is especially useful in the early phases of a project. Projects may consider how the intended system meets organizational goals (see also <ref>{{cite journal |last=Ellis-Braithwaite |first=R.|author2=Lock, R. |author3=Dawson, R. |author4= Haque B. |title=Towards an Approach for Analysing the Strategic Alignment of Software Requirements using Quantified Goal Graphs|journal=International Journal on Advances in Software |year=2013 |volume=6 |pages=119–130 |arxiv=1307.2580|bibcode=2013arXiv1307.2580E}}</ref>), 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>
 
A goal model:
Line 16:
There are several notations in use for goal models in software development, including:
* [[i*]] (pronounced "eye-star") and a variant, [[Goal-oriented Requirements Language|GRL]]<ref>Yu et al, 2011.</ref>
* [[KAOS (software development)|KAOS]] <ref name= "AvL 2009">[[Axel van Lamsweerde|van Lamsweerde]], 2009.</ref>
* [[Unified Modeling Language|UML]] [[Use Case]] diagram<ref>Fowler, 2004. Pages 99-105</ref>
 
Other notations have been proposed by researchers,<ref>{{cite journal |author=Rolland, Colette | author-link=Colette Rolland |author2=Prakash, Naveen |author3=Benjamen, Adolphe | title=A Multi-Model View of Process Modelling | journal=Requirements Engineering | year=1999 | volume=4 | issue=4 | pages=169–187 | url=http://hal.archives-ouvertes.fr/docs/00/70/75/68/PDF/A_multi_model_view_REJ.pdf| doi=10.1007/s007660050018 | s2cid=6988662 }}</ref> while the Goal Structuring Notation (GSN) isand GRL are sometimes used to make [[safety case]]s to satisfy the regulator in safety-related industries.<ref>[http://www.goalstructuringnotation.info GSN Community Standard]</ref><ref>{{Cite book |last=Feodoroff |first=R. |title=2016 Annual IEEE Systems Conference (SysCon) |chapter=Intentional enterprise architecture |date=2016 |pages=1–8 |doi=10.1109/SYSCON.2016.7490555|isbn=978-1-4673-9519-9 |s2cid=206586399 }}</ref>
 
===Goal modeling in i*===
Line 42:
With the addition of [[misuse case]]s, 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 requirement]]s can to some extent be described in use case style using misuse cases 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>
 
The counter pointcounterpoint is that Use Cases are not from Cognitive Science roots, whereas i* and KAOS are. Indeed, the literature behind Use Cases does not include discussion Goal Intention, Goal Refinement, Ends-Means, does not call out Rasmussen et cetera. There may be a predilection to relate Use Cases to Goals because of the visual metaphor of Goals rather than the semantics of Goal Refinement per Cognitive Science.
 
==Bibliography==
Line 48:
* Alexander, Ian F. and Maiden, Neil. ''Scenarios, Stories, Use Cases''. Wiley, 2004.
* [[Cockburn, Alistair]]. ''Writing Effective Use Cases''. Addison-Wesley, 2001.
* [[Martin Fowler (software engineer)|Fowler, Martin]]. ''UML Distilled''. 3rd Edition. Addison-Wesley, 2004.
* [[Axel van Lamsweerde|van Lamsweerde, Axel]]. ''Requirements Engineering: from system goals to UML models to software specifications''. Wiley, 2009.
* Yu, Eric, Paolo Giorgini, Neil Maiden and [[John Mylopoulos]]. (editors) ''Social Modeling for Requirements Engineering''. MIT Press, 2011.
 
==See also==
*[[Benefit dependency network]]
 
==References==
Line 57 ⟶ 60:
==External links==
* [http://www.cs.toronto.edu/km/istar/ i* Official Website, with tutorial and bibliography] - "an agent- and goal-oriented modelling framework"
* [httphttps://istarsites.rwth-aachengoogle.decom/site/istarlanguage/home i* wiki with guidelines and examples]
* [http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf KAOS tutorial]
* [http://ceur-ws.org/Vol-337/paper9.pdf Using EEML for Combined Goal and Process Oriented Modeling: A Case Study] - John Krogstie