Goal modeling

Goals are objectives which a system should achieve through cooperation of actors in the intended software and in the environment.^[2] Goal modeling is especially useful in the early phases of a project. Projects may consider how the intended system meets organizational goals (see also ^[3]), why the system is needed and how the stakeholders’ interests may be addressed.^[4]

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".^[5][6]
• Clarifies requirements : Specifying goals leads to asking "why", "how" and "how else".^[5] 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.^[5]
• 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.

There are several notations in use for goal models in software development, including:

• i* (pronounced "eye-star") and a variant, GRL^[7]
• KAOS^[8]
• UML Use Case diagram^[9]

Other notations have been proposed by researchers,^[10] while the Goal Structuring Notation (GSN) and GRL are sometimes used to make safety cases to satisfy the regulator in safety-related industries.^[11][12]

The i* goal modeling notation provides two kinds of diagram:^[13]

• "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.

i* shows each role (an actor, agent or position) as a large circle containing the goals, tasks, and resources which that role owns. Ownership in i* means that the role desires the satisfaction of its goals, either for its own benefit or for the benefit of some other role. Goals may be accompanied by "obstacles" (negative goals) to be surmounted. Non-functional goals can be modeled as "soft goals" in i*: they are diagrammed as clouds or indented ovals.

The KAOS goal modeling notation provides a way of defining goals and obstacles, underpinned by a formal (mathematical) method of analysis.^[8]

UML's use case diagram provides a simple goal modeling notation. The bubbles name functional goals,^[14] so a Use case diagram forms a simple functions-only goal model: as Cockburn writes, use cases cover only the behavioral requirements.^[15] 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.^[16]

With the addition of misuse cases, 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 requirements can to some extent be described in use case style using misuse cases 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.^[17]

The counterpoint is that Use Cases are not from Cognitive Science roots, whereas i* and KAOS are. Indeed, the literature behind Use Cases does not include discussion Goal Intention, Goal Refinement, Ends-Means, does not call out Rasmussen et cetera. There may be a predilection to relate Use Cases to Goals because of the visual metaphor of Goals rather than the semantics of Goal Refinement per Cognitive Science.

• Alexander, Ian and Beus-Dukic, Ljerka. Discovering Requirements: How to Specify Products and Services. Wiley, 2009.
• Alexander, Ian F. and Maiden, Neil. Scenarios, Stories, Use Cases. Wiley, 2004.
• Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
• 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.

• Benefit dependency network

• i* Official Website, with tutorial and bibliography - "an agent- and goal-oriented modelling framework"
• i* wiki with guidelines and examples
• KAOS tutorial
• Using EEML for Combined Goal and Process Oriented Modeling: A Case Study - John Krogstie