Goal modeling

A Goal Model is an element of Requirements Engineering that may also be used more widely in Business analysis. Related elements include Stakeholder analysis, Context analysis, and Scenarios, among other business and technical areas.

Notations

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

• i* (pronounced "eye-star") and a variant, GRL
• KAOS
• UML Use Case diagram

Goal modeling in i*

Main article: i*

The i* goal modeling notation provides two kinds of diagram:

• "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 as a large circle containing the goals which that goal owns. 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.

Goal modeling in KAOS

Main article: KAOS (software development)

The KAOS goal modeling notation provides a way of defining goals, underpinned by a formal (mathematical) method of analysis.

Goal modeling in UML

Main article: Use case diagram

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

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.

Goal modeling principles

Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment. Goal-oriented techniques are especially useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed.

• Expresses the relationships between systems and their environments : Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”. Goals can also be useful when modelling contexts.

• Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”. Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition.

• Deals with conflicts : Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc., and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts.
• Decides requirements completeness : Requirements can be considered complete if they fulfil explicit goals in the requirement model.
• Connects requirements to design : Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)

Bibliography

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

External links

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