Jump to content

User:SabrinaTürker/Goal modeling

From Wikipedia, the free encyclopedia

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[1]. Related elements include stakeholder analysis, context analysis, and scenarios,[2] 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[3]. 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

[edit]

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[4]. 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.

Trend of Google search queries of the last 5 years.



Principles

[edit]

Goals are objectives which a system should achieve through cooperation of actors in the intended software and in the environment.[5] 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 [6]), why the system is needed and how the stakeholders’ interests may be addressed.[7]

Goal models adhere to several core principles. Goal models aim to:

  • 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".[8][9]
  • 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.[8]
  • 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.

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[10]. 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.

Notations

[edit]

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.[8] There are several notations used for goal models in software development, including but not limited to:

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

Goal modeling in i*

[edit]
Main article: 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. [17][18]

Example of an i* model.

The i* framework is composed of several elements, some examples are: [17][19]:

  • 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:[20]

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

[edit]
Main article: KAOS (software development)

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 [18]

KAOS example of a goal with sub goals.

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.[12]

  • 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

[edit]
Main article: Use case diagram

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.[21][22]

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.[23]

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.[23]

Example of a use case diagram.

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

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.[27]

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.

Bibliography

[edit]
  • 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.

See also

[edit]

References

[edit]
  1. ^ de la Vara, Jose Luis; Sánchez, Juan; Pastor, Oscar (2013). "On the Use of Goal Models and Business Process Models for Elicitation of System Requirements". In Nurcan, Selmin; Proper, Henderik A.; Soffer, Pnina; Krogstie, John; Schmidt, Rainer; Halpin, Terry; Bider, Ilia (eds.). Enterprise, Business-Process and Information Systems Modeling. Lecture Notes in Business Information Processing. Vol. 147. Berlin, Heidelberg: Springer. pp. 168–183. doi:10.1007/978-3-642-38484-4_13. ISBN 978-3-642-38484-4.
  2. ^ Alexander and Beus-Dukic, 2009. Pages 17-18
  3. ^ Horkoff, Jennifer, et al. "Goal-oriented requirements engineering: a systematic literature map." 2016 IEEE 24th International Requirements Engineering Conference (RE). IEEE, 2016.
  4. ^ Lapouchnian, A. (2005). Goal-oriented requirements engineering: An overview of the current research. University of Toronto, 32.
  5. ^ Lin Liu and Eric Yu (2003). "Designing information systems in social context: a goal and scenario modelling approach" (PDF). University of Toronto. Archived from the original (PDF) on February 5, 2005.
  6. ^ Ellis-Braithwaite, R.; Lock, R.; Dawson, R.; Haque B. (2013). "Towards an Approach for Analysing the Strategic Alignment of Software Requirements using Quantified Goal Graphs". International Journal on Advances in Software. 6: 119–130. arXiv:1307.2580. Bibcode:2013arXiv1307.2580E.
  7. ^ E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE
  8. ^ a b c Eric Yu and John Mylopoulos. "Why Goal-Oriented Requirements Engineering". University of Toronto.
  9. ^ 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.
  10. ^ Horkoff, Jennifer; Yu, Eric (2016-03-01). "Interactive goal model analysis for early requirements engineering". Requirements Engineering. 21 (1): 29–61. doi:10.1007/s00766-014-0209-8. ISSN 1432-010X. S2CID 254076672.
  11. ^ Yu et al, 2011.
  12. ^ a b van Lamsweerde, 2009.
  13. ^ Fowler, 2004. Pages 99-105
  14. ^ Rolland, Colette; Prakash, Naveen; Benjamen, Adolphe (1999). "A Multi-Model View of Process Modelling" (PDF). Requirements Engineering. 4 (4): 169–187. doi:10.1007/s007660050018. S2CID 6988662.
  15. ^ GSN Community Standard
  16. ^ Feodoroff, R. (2016). "Intentional enterprise architecture". 2016 Annual IEEE Systems Conference (SysCon). pp. 1–8. doi:10.1109/SYSCON.2016.7490555. ISBN 978-1-4673-9519-9. S2CID 206586399.
  17. ^ a b Cares, C.; Franch, X.; Mayol, E.; Alvarez, E. (2006). "Goal-Driven Agent-Oriented Software Processes". 32nd EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO'06). IEEE: 336–347. doi:10.1109/euromicro.2006.39. hdl:2117/135415. ISBN 0-7695-2594-6. S2CID 17538269.
  18. ^ a b Teruel, Miguel A.; Navarro, Elena; López-Jaquero, Víctor; Montero, Francisco; González, Pascual (2011). "A Comparative of Goal-Oriented Approaches to Modelling Requirements for Collaborative Systems". Proceedings of the 6th International Conference on Evaluation of Novel Approaches to Software Engineering. Beijing, China: SCITEPRESS - Science and Technology Publications. pp. 131–142. doi:10.5220/0003466301310142. ISBN 978-989-8425-57-7.
  19. ^ Dalpiaz, Fabiano; Franch, Xavier; Horkoff, Jennifer (2016-06-16). "iStar 2.0 Language Guide". arXiv:1605.07767 [cs.SE].
  20. ^ Yu, Eric (September 6, 2011). "i*". i*: an agent- and goal-oriented modelling framework. University of Toronto. Retrieved December 17, 2011.
  21. ^ Hunt, John (2002), "The Unified Modeling Language", Guide to C# and Object Orientation, London: Springer London, pp. 429–448, doi:10.1007/978-1-4471-0193-2_39, ISBN 978-1-4471-1108-5, retrieved 2023-01-24
  22. ^ James., Rumbaugh (2006). The unified modeling language reference manual. Addison-Wesley. ISBN 978-0-321-71895-2. OCLC 757926160.
  23. ^ a b Abid, Muhammad R.; Amyot, Daniel; Somé, Stéphane S.; Mussbacher, Gunter (2009), A UML Profile for Goal-Oriented Modeling, Lecture Notes in Computer Science, vol. 5719, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 133–148, doi:10.1007/978-3-642-04554-7_9, ISBN 978-3-642-04553-0, retrieved 2023-01-24
  24. ^ Alexander and Beus-Dukic, 2009. Page 121
  25. ^ Cockburn, 2001. Page 62
  26. ^ Cockburn, 2001. Page 221
  27. ^ Alexander and Maiden, 2004. Chapter 7. Pages 119-139.
[edit]

Category:Enterprise modelling Category:Software requirements Category:Goal

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:SabrinaTürker/Goal_modeling&oldid=1176941638"