Goal modeling: Difference between revisions

Revision as of 06:11, 18 October 2017

Revision as of 08:11, 18 October 2017

Line 6:

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", "whohow" 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 : 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/>