User:SabrinaTürker/Goal modeling

Goal modeling aims to capture the goals of the stakeholders in a structured and organized manner, which helps to ensure that the goals of the stakeholders are well understood and accurately represented. This is done at the very beginning of the elicitation phase and serves as the foundation for the system-to-be. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.

The goal modeling process involves the use of a goal-oriented framework to express the goals of different stakeholders in a model. This process aims to capture the goals of the stakeholders in a structured and organized manner, which helps to ensure that the goals of the stakeholders are well understood and accurately represented. There are several frameworks available for capturing the goals of stakeholders, such as i*, KAOS and Tropos. Ultimately these goal models will be used to derive requirements which serve as the foundation for the design and development of the system-to-be.

History
Goal modeling has its roots in cognitive psychology, as goals are shown to greatly impact human behavior. Before the early 1990s the paradigm was used to emphasize the system’s functionality and how to execute those functions. With goal modeling, a paradigm shift occurred and the focus included the “why” in addition to the “what” and the “how”. As systems grow increasingly complex, goal modeling has increased in popularity simultaneously, especially for software development. Software systems in particular have grown considerably over time and to help understand and engineer these systems, goal modeling is a useful tool. Goals models are effective in capturing interactions between requirements and their trade-offs. As such, they can be applied in multiple disciplines like Software Engineering, Enterprise modeling and Information System because they improve decision making between different features. Consequently, goal modeling techniques are applied in various fields, for example in Software Engineering, Information Systems, Conceptual Modeling, and Enterprise Modeling.

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

Goal models adhere to several core principles. Goal models aim to: Different models can be used to capture the goals of a stakeholder for the system-to-be, as they can show the true motivations and illustrate how the goals are implemented by using a model that shows a network of dependencies. These models are called agent-goal models, which include agents with interdependent goals. Some examples of these frameworks are i*, GRL, KAOS, and GBRAM. These models are expressed via a goal-oriented language, which are mainly graphical and include their own visual syntax like i* and KAOS. On the other hand, GBRAM is an example of a textual analysis.
 * Express 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".
 * Clarify requirements, since 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).
 * Emphasize the final goal, allowing large goals to be analyzed into small, realizable goals.
 * Deal with conflicts, as goal modeling helps identify and resolve trade offs between cost, performance, flexibility, security and other goals. It can reveal divergent interests between stakeholders or identify conflicts between striving for multiple goals.
 * Enable requirement completeness to be measured: requirements can be considered complete if they fulfill all the goals in the goal model.
 * Connect requirements to design: for example, the i* "Non-Functional Requirements (NFR) framework" uses goals to guide the design process.

Notations
Goal-modeling notations are remarkably diverse. There are several notations which are predominantly used, but there is a considerable amount of other new, less frequently used notations. There are several notations used for goal models in software development, including but not limited to:
 * i* (read as "i-star") and a variant, GRL
 * KAOS
 * UML Use Case diagram

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

Goal modeling in i*
The i* goal modeling framework is a structured approach for addressing requirements throughout the software development process. It provides a method for modeling the strategic dependencies and relationships between actors, goals and resources in an organizational or enterprise system, with the objective of identifying opportunities to improve alignment between the goals of different actors. This approach is intended to be used in various phases of the software development process, providing a holistic view of the organizational system and its requirements. The i* framework is composed of several elements, some examples are: :


 * Actors represent individuals or groups that are involved in achieving goals.
 * Goals represent the desired outcomes that actors strive to achieve.
 * Resources represent the things that actors use to achieve goals.
 * Dependencies represent the relationships between actors, goals, and resources.

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

Goal modeling in KAOS
KAOS (Knowledge Acquisition in automated specification) is a goal-oriented requirements engineering method. The method is based on the idea that the requirements of a system should be derived from the goals of the stakeholders. The framework serves as a tool for defining the objectives of a system, and for determining the requirements necessary to achieve those objectives. Furthermore it provides a method for eliciting, specifying and analyzing the goals, requirements, scenarios, and responsibility assignments of a system The KAOS goal modeling notation provides a way of defining goals and obstacles, underpinned by a formal (mathematical) method of analysis. KAOS involves the following elements to define the system.
 * Agents are active components of the system (e.g. humans).
 * Goals are set to define what the system intends to achieve.
 * Objects are inactive actors interacting with the system, mostly referring to machines..
 * Operations are actions agents can take to achieve their goal.
 * AND/OR decompositions specify the relationship between a goal and its sub goals.
 * Potential conflicts indicate that satisfying one goal influences another goal.
 * Responsibility assignment illustrates the relationship between an actor and a goal, indicating that an agent is responsible for satisfying the linked goal.

Goal modeling in UML
UML (Unified Modeling Language) is a general-purpose modeling language that can be used to specify, visualize, construct, and document the artifacts of a software-intensive system. While UML is not specifically designed for goal modeling, it does provide several diagrams that can be used to model the goals, actors, and resources of a system.

One of the most relevant diagrams for goal modeling in UML is the use case diagram. Use case diagrams are used to model the functional requirements of a system, and they can be used to represent the goals of actors and the resources they use to achieve those goals.

Another diagram that can be used for goal modeling in UML is the activity diagram. Activity diagrams are used to model the flow of activities in a system, and they can be used to represent the steps that actors take to achieve their goals. 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.

The counter point 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.