Goal modeling: Difference between revisions

Revision as of 11:01, 20 May 2015

Revision as of 09:15, 31 March 2016

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-130119–130 |url=http://arxiv.org/pdf/1307.2580v2}}</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:

* Expresses the relationships between a system and its environment (i.e. not only on what the system is supposed to do, but why). The understanding this gives, of the reasons why a system is needed, in its context, is useful because "systems are increasingly used to fundamentally change business processes rather than to automate long-established practices".<ref name=ericyu>{{cite web |author=Eric Yu and John Mylopoulos |title=Why Goal-Oriented Requirements Engineering |url=http://www.cs.toronto.edu/pub/eric/REFSQ98.html |publisher=University of Toronto}}</ref><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=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:

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

* Deals with conflicts : goal modeling can identify and help to resolve tradeoffs between cost, performance, flexibility, security and other goals. It can reveal divergent interests between stakeholders. It can identify conflicts because meeting one goal can interfere with meeting other goals.<ref name=ericyu/>

* Enables requirement completeness to be measured: requirements can be considered complete if they fulfil all the goals in the goal model.

* Connects requirements to design: for example, the i* "Non-Functional Requirements (NFR) framework" uses goals to guide the design process.

Line 21 ⟶ 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>

Line 29 ⟶ 24:

{{main|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.

Line 61 ⟶ 56:

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

* [http://istar.rwth-aachen.de 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