|
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 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-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"Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”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"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 : goal modeling can identify and help to resolve tradeoffs between cost, performance, flexibility, security and other goals. Goal modelingIt can also reveal divergent interests between stakeholders. Goal modelingIt can identify conflicts because meeting one goal can interfere with meeting other goals.<ref name=ericyu/>
* Enables requirement completeness to be measured: Requirementsrequirements 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.
{{main|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>
==Bibliography==
|
