Goal modeling: Difference between revisions

Revision as of 23:17, 7 October 2014

Revision as of 23:20, 7 October 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>{{cite nameweb|author="cs.toronto.edu">E.Eric Yu and [[John Mylopoulos]], “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="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).