Goal modeling: Difference between revisions

Revision as of 12:53, 18 December 2011

Latest revision as of 19:37, 4 September 2023

(45 intermediate revisions by 20 users not shown)

Line 1:

A '''Goalgoal Modelmodel''' is an element of [[Requirementsrequirements Engineeringengineering]] that may also be used more widely in [[Businessbusiness analysis]]. Related elements include [[Stakeholderstakeholder analysis]], [[Contextcontext analysis]], and [[Scenario (computing)|Scenariosscenarios]],<ref>Alexander and Beus-Dukic, 2009. Pages 17-18</ref> among other business and technical areas.

==Principles==

Goals generally describeare objectives which a system should achieve through cooperation of actors in the intended software and in the environment.<ref>L.{{cite web |author=Lin Liu and E.Eric Yu, “Designing|title=Designing information systems in social context: a goal and scenario modelling approach”,approach 2003|url=http://www.cs.toronto.edu/~liu/publications/ISj03.pdf Elsevier|publisher=University Ltd.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-oriented techniquesmodeling areis especially useful in the early-phase REphases of a project. Early-phaseProjects requirementsmay consider e.g. 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"Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”Engineering", 1997 IEEE</ref>

A goal model:

* Expresses the relationships between systemsa system and theirits environmentsenvironment : Earlier, requirements engineering(i.e. focusednot only on what the system is supposed to do. Over the past years, therebut haswhy). beenThe aunderstanding morethis or less mutual understandinggives, that it is also very important to understand and characterizeof the interactionreasons betweenwhy the intendeda system andis itsneeded, environment.in Relationshipsits between systems and their environments are often expressed as goal-based relationships. The motivation for thiscontext, is “partlyuseful today's more dynamic business and organizational environments, wherebecause "systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”practices".<ref name="cs.toronto.edu"ericyu>E.{{cite web |author=Eric Yu and J.John Mylopoulos, “Why|title=Why Goal-Oriented Requirements Engineering”,Engineering |url=http://www.cs.toronto.edu/pub/eric/REFSQ98.html |publisher=University of Toronto}}</ref> Goals can also be useful when modelling contexts.<ref>K.Pohl and P. Haumer, “Modelling"Modelling Contextual Information about Scenarios”Scenarios", Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ ’97, Barcelona, Catalonia, Spain, June 1997 pp. 187-204.</ref>

* Clarifies requirements : Specifying goals leads to asking "why", "how" and "how else".<ref name=ericyu/> Stakeholders' requirements are often revealed in this process, with less risk of either missing requirements, or of over-specifying (asking for things that are not needed).

* Allows large goals to be analyzed into small, realizable goals:

* Deals with conflicts : Goalsgoal maymodeling providecan aidentify usefuland wayhelp ofto dealing with conflicts, such asresolve tradeoffs between costscost, performance, flexibility, etc.,security and other goals. It can reveal divergent interests of thebetween stakeholders. GoalsIt can deal withidentify conflicts because meeting of one goal can interfere with the meeting ofother others. Different opinions on how to meet a goal has led to different ways of handling conflictsgoals.<ref name="cs.toronto.edu"ericyu/>

* DecidesEnables requirementsrequirement completeness to be measured: Requirementsrequirements can be considered complete if they fulfil explicitall the goals in the requirementgoal model.

* Connects requirements to design : Goalsfor can be used in order to connectexample, the requirements to the design. For some, goals are an important mechanism in this matter. (Thei* "Non-Functional Requirements (NFR) framework" uses goals to guide the design process.)

==Notations==

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) and 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*===

{{main article|i*}}

The i* goal modeling notation provides two kinds of diagram:<ref name="i*">{{cite web | url=http://www.cs.toronto.edu/km/istar/ | title=i* | publisher=University of Toronto | work=i*: an agent- and goal-oriented modelling framework | date=September 6, 2011 | accessdate=December 17, 2011 | author=Yu, Eric}} </ref>

* "Strategic Dependency" (SD), defining relationships between roles in terms of specific goals that one role depends on the other role to provide.

* "Strategic Rationale" (SR), analyzing the goals identified on the SD model into subsidiary goals and tasks.

i* shows each role (an actor, agent or position) as a large circle containing the goals, tasks, and resources which that goalrole owns. Ownership in i* means that the role desires the satisfaction of its goals, either for its own benefit or for the benefit of some other role. Goals may be accompanied by "Obstaclesobstacles" (negative goals) to be surmounted. Non-functional goals can be modeled as "soft goals" in i*: they are diagrammed as clouds or indented ovals.

===Goal modeling in KAOS===

{{main article|KAOS (software development)}}

The KAOS goal modeling notation provides a way of defining goals and obstacles, underpinned by a formal (mathematical) method of analysis.<ref>van Lamsweerde,name= "AvL 2009.<"/ref>

===Goal modeling in UML===

{{main article|Use case diagram}}

UML's [[Useuse case diagram]] provides a simple goal modeling notation. The bubbles name functional goals,<ref>Alexander and Beus-Dukic, 2009. Page 121</ref> so a Use case diagram forms a simple functions-only goal model: as Cockburn writes, use cases cover only the behavioral requirements.<ref>Cockburn, 2001. Page 62</ref> Roles are shown as actors (stickmen on the diagram), linked to the use cases in which they take part. The use cases are drawn as elliptical bubbles, representing desired behavioral goals.<ref>Cockburn, 2001. Page 221</ref>

With the addition of "Misuse[[misuse cases"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 requirementsrequirement]]s can to some extent be described in use case style using [[Misusemisuse case]]scases 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 counterpoint 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.

===Goal modeling principles===

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>

* Expresses the relationships between systems and their environments : Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”.<ref name="cs.toronto.edu">E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html</ref> Goals can also be useful when modelling contexts.<ref>K.Pohl and P. Haumer, “Modelling Contextual Information about Scenarios”, Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ ’97, Barcelona, Catalonia, Spain, June 1997 pp. 187-204.</ref>

* Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”.<ref name="cs.toronto.edu"/> Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition.

* Deals with conflicts : Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc., and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts.<ref name="cs.toronto.edu"/>

* Decides requirements completeness : Requirements can be considered complete if they fulfil explicit goals in the requirement model.

* Connects requirements to design : Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)

==Bibliography==

* Alexander, Ian and Beus-Dukic, Ljerka. ''Discovering Requirements: How to Specify Products and Services''. Wiley, 2009.

* 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==

{{reflist|33em}}

{{reflist}}

==External links==

* [http://www.cs.toronto.edu/km/istar/ i* Official Website, with tutorial and bibliography] - "an agent- and goal-oriented modelling framework"

* [https://sites.google.com/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

Line 62 ⟶ 66:

[[Category:Enterprise modelling]]

[[Category:Software requirements]]

[[Category:Goal]]