Goal modeling: Difference between revisions

Revision as of 17:09, 17 July 2014

Revision as of 12:10, 26 September 2014

Line 5:

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="cs.toronto.edu">E. Yu and J.[[John Mylopoulos]], “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html</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="cs.toronto.edu"/> 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).

Line 53:

* [[Fowler, Martin]]. ''UML Distilled''. 3rd Edition. Addison-Wesley, 2004.

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

==References==