Jump to content

User:LarsVissers1998/Goal-oriented Requirements Language

From Wikipedia, the free encyclopedia

Goal-oriented Requirements Language (GRL), is a modeling language that is used to describe and analyze the goals and requirements of a system. It is based on the idea of goal-oriented modeling, which is a method for specifying and analyzing the requirements of a system in terms of the goals that it is intended to achieve. GRL is an i*-based modeling language which is used to help ensure that the system is developed in a way that meets the needs and expectations of stakeholders by explicitly linking the requirements to the goals of the system, especially the non-functional requirements (NFRs)[1].

Overview

[edit]

GRL is part of Goal-oriented Requirements Engineering (GORE) [2]. It is well suited to analyzing requirements early in the software development cycle, especially with respect to non-functional requirements and the evaluation of alternatives. Whereas other approaches tend to focus more on analyzing requirements in a later stage of the software development cycle with a focus on traceability between requirements and implementation [2].

Numerous languages and notations have been developed over the years to model goals and their relationships in an explicit way. For instance, popular languages include Keep All Objects Satisfied (KAOS) [3], the NFR Framework [4], i* [5], and TROPOS [6]. About 15 years ago, Goal-oriented Requirement Language has become an internationally recognized standard for goal-oriented modeling, as part of a new Recommendation of the International Telecommunications Union named User Requirements Notation (URN) [7][8].

GRL Syntax

[edit]

An advantage of Goal-oriented Requirements Language (GRL) over other goal notations is that GRL uses scenario notations. In addition, GRL supports both qualitative and quantitative attributes. Furthermore, this notation provides a clear distinction between GRL model elements from their graphical representation. This allows for a consistent representation of multiple diagrams or views of the same goal model [9]. The syntax of Goal-oriented Requirements Language is based on the syntax of the i* language [5]. A GRL diagram shows the high-level business goals and NFRs of interest to a stakeholder and the alternatives for achieving these goals and requirements. A goal diagram also documents beliefs (facts) important to the stakeholder [9].

GRL allows to express conflict between goals and helps to make decisions that resolve conflicts. There are three main categories of concepts in GRL:

  • Intentional Elements
  • Element Links
  • Satisfaction Levels

Intentional Elements

[edit]
GRL Intentional Elements

The elements are called intentional because they are used in models that are primarily concerned with answering "why" question of requirements (e.g. why certain choices for behavior or structure were made, what alternatives exist and what is the reason for choosing a certain alternative?)

GRL intentional elements can be goals, soft goals, tasks, resources, actors, and beliefs [9].

  • Goals are related to the functional requirements of the system and it is a situation that can be achieved or not. In the GRL notation a goal is represented by a rounded rectangle with the goal name inside.
  • Softgoals are related to non-functional requirements and there is no clear, objective measure of satisfaction for a softgoal whereas a goal is quantifiable. It’s usually a quality attribute of one of the intentional elements. In a GRL notation softgoals are represented by irregular curvilinear shape with the softgoal name inside.
  • Tasks are used to represent solutions to accomplish goals or subgoals. In a GRL notation tasks are represented by a hexagon with the task name inside.
  • Resources are a physical or informational object that is available for use in the task. To complete softgoals, goals and tasks resources are required to be available. In a GRL notation a resource is represented as a rectangle.
  • Actors are holders of intentions. They are the active entities in the system or its environment who want goals to be achieved, tasks to be performed, resources to be available and softgoals to be satisfied.
  • Beliefs are used to represent assumptions and relevant conditions.
[edit]
GRL Element Links

GRL element links are used to connect isolated elements in the requirement model using structural and intentional relationships. The links in the GRL notation are: contribution, dependency, decomposition, correlation and means-end [9].

GRL Contribution Types
  • Decomposition links are used to allow an element to be decomposed into sub-components of a task. AND, IOR and XOR are supported in decomposition links.
  • Means-end links show how the goal can be achieved. For example, it can be used to connect a task to a goal. Therefore, XOR and IOR decomposition links may alternatively be displayed as means-end links.
  • Contribution links describe how one element can influence another one. A contribution link can have a qualitative contribution type or a quantitative contribution type. These contribution types are as follows [10]
    • Make : The contribution of the element is positive and sufficient.
    • Break : The contribution of the element is negative and sufficient.
    • Help : The contribution of the element is positive but not sufficient.
    • Hurt : The contribution of the element is negative but not sufficient.
    • Some Positive : The contribution is positive, but the extent of the contribution is unknown.
    • Some Negative : The contribution is negative, but the extent of the contribution is unknown.
    • Equal : There is equal contribution in both directions.
    • Unknown : There is some contribution, but the extent and the sense (positive or negative) of the contribution is unknown.
  • Correlation links are actually similar to contribution links, but describe side effects rather than desired impacts.
  • Dependency links describe interdependencies between actors. In other words, they model relationships between actors

Satisfaction Levels

[edit]

GRL provides support for evaluations to analyze trade-offs among goals of stakeholders. In GRL, an evaluation consists of a strategy and this strategy consists of a number of intentional elements. These elements, in turn, will represent a set of initial satisfaction values. These satisfaction values can be qualitative or quantitative. Furthermore, they can capture contextual or future situations as well as choices among alternative means of reaching various goals. These values are then propagated to the other intentional elements through their links taking contribution types into account. This enables a global assessment of the strategy [9].

Satisfaction Levels

The satisfaction levels in GRL are [11]:

  • Denied
  • Weakly Denied
  • Weakly Satisfied
  • Satisfied
  • Conflict
  • Unknown
  • None

GRL in Practice

[edit]

Benefits

[edit]

GRL is a useful tool especially early in the development process where the communication and shared understanding of scenarios and goals between the developers and stakeholders are important [10]. It can be used to analyze non-functional requirements where actors, tasks/scenarios and goals. GRL can be used to make informed decisions as it links between which situations the system should be able to overcome and why these scenarios are important to handle. Furthermore it can help reduce abstraction of goals by making the explicit and possibly reveal goals that would otherwise have been unknown to the developers and stakeholders by linking goals and attributes [11]. These links can either be between goals but also between goals and other aspects of the requirements for the system which can also help explain why a requirement or goal has been set.

By being able to trace these goals back to where they arose will help build a shared understanding between stakeholders but also give the developers who might not see the specific reason for the specification of a goal to share the understanding of its origin with the stakeholders.

These new goals will be elicited through “why” and “how” questions encouraging the people involved in development of a system to set up requirements based on reasoning and specify these even more through the “how” questions. This makes GRL useful in the sense that there is a clear traceability from the overall goals down to more technical detailed solutions in the system.

As shown in the example, the goals are assigned a value and a cost which are helpful for resolving contradictions and interdependencies in the network of goals. In comparison to other RE approaches, this will set restrictions for the system, potentially this is done early in the development process. It will set up constraints for the development team and gives a good overview of interdependencies but will have to be validated and evaluated as the development process moves along to monitor if assumed constraints are still valid [12].

Limitations

[edit]

GRL has limitations in the sense that the model cannot simply stand alone and work as the only foundation for setting up requirements. It demands a shared understanding and clear answers to the “how” and “why” questions [13]. All aspects of the model must be considered and goals can be unreachable if the model is done incorrectly and consists of interdependent goals that will counterwork each other or that are unreachable if other goals have to be met. The goals should be set up in a manner that is understandable for all participants in the development process and will be insufficient if the developers are overruled or the “why” questions are ignored or overlooked.

It is important for GRL that high level goals (the overall goals) of the system are shared and understood. This makes GRL a great tool for development of systems where stakeholders have a shared overall objective with the development of a given system. If the high level goals are not shared this will most likely be revealed quite early in the process of setting up requirements through Goal-oriented Requirements language. Therefore it is also important that the developers are aware of this and validate the goals with the stakeholders, especially when new goals arise throughout the design process since the “why's” and “how's” should be answered in collaboration with stakeholders [14].

Furthermore, it is important in GRL that goals can be formulated and formalized. A limitation here is that in some cases the developers and stakeholders will assign values and costs to the goals which on one hand is good for an overview of these attributes to the system. On the other hand, these values might be based on assumptions and therefore prone to external changing factors that can either influence the cost or the value of a goal. This could for example be increased prices for certain implementations of the system or conflicting findings in what end users appreciate. Furthermore values and costs can be interdependent and abstract in a way that makes it difficult for humans involved in the development process to predict the outcomes of a reached goal, therefore it is important to have diverse teams to be able to correctly analyze the goals as well as the costs and values tied to it [12].

Moreover, a general critique of GRL is scalability. It has been shown that as the network increases in size it will be more difficult to use GRL to find interdependencies and constraints in different goals, which can be problematic for extensive projects with a lot of goals and connections between them [15].

GRL Applied

[edit]

Applications

[edit]

GRL should be used as a decision-making tool for stakeholders and developers. It will ease the process of defining goals, detect what can be implemented within the budget of the stakeholders and what the fulfilling of goals will add of value to the system. It can be used as a great tool for communicating alternatives to a decision and quantifying their attributes. This quantification will lead to informed decisions being made and allows for trade-off analysis in the development process. It should be used to understand what is possible with the system and which goals are contradicting or will affect each other’s values or costs. It is important that stakeholders are involved in the decision process as even though some goals might seem obvious to the developers to reach might be contradictory to the values of the company.  

Goal Models

[edit]

To make objective decisions where the quantified attributes to goals are processed, goals models can be used to clarify what decision should be made based on “objective best decisions” derived from the GRL. Here the goals can be prioritized and ranked to for example understand what goals should add the most value to the system with the lowest costs. Algorithmic measures tools can be used to assess and present these in a favorable manner to inform the development team and have stakeholders validate the conclusions based on GRL [12].

GRL Example

[edit]

Below is an example from GRL. This example is derived from the template of Amyot et al.[9]. This template has been extended and improved based on current GRL notation. The different elements, the links connecting these elements, the contribution links, and the satisfaction levels have been incorporated within the example.

Goal-oriented Requirements Language Example

See also

[edit]

References

[edit]
  1. ^ Lin Liu, Eric Yu (2003). "Designing information systems in social context: a goal and scenario modelling approach" in: Information Systems, Volume 29, Number 2, April 2004 , pp. 187-203(17)
  2. ^ a b Yijun Yu; Yiqiao Wang; Mylopoulos, J.; Liaskos, S.; Lapouchnian, A.; do Prado Leite, J.C.S. (2005). "Reverse engineering goal models from legacy code". 13th IEEE International Conference on Requirements Engineering (RE'05). IEEE. doi:10.1109/re.2005.61.
  3. ^ Heaven, W.; Finkelstein, A. (2004). "UML profile to support requirements engineering with KAOS". IEE Proceedings - Software. 151 (1): 10. doi:10.1049/ip-sen:20040297. ISSN 1462-5970.
  4. ^ Chung, Lawrence; Nixon, Brian A.; Yu, Eric; Mylopoulos, John (2000). "Non-Functional Requirements in Software Engineering". doi:10.1007/978-1-4615-5269-7. {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ a b Yu, E.S.K. "Towards modelling and reasoning support for early-phase requirements engineering". Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering. IEEE Comput. Soc. Press. doi:10.1109/isre.1997.566873.
  6. ^ Giorgini, Paolo; Kolp, Manuel; Mylopoulos, John; Castro, Jaelson, "Tropos", Agent-Oriented Methodologies, IGI Global, retrieved 2023-01-13
  7. ^ Radulovic, Filip. RIDER - A Recommendation Framework for Exploiting Evaluation Results and User Quality Requirements (Thesis). Universidad Politecnica de Madrid - University Library.
  8. ^ Hold, Trevor (2008-04-03). "THE NOTATION OF BIRD-SONG:A REVIEW AND A RECOMMENDATION". Ibis. 112 (2): 151–172. doi:10.1111/j.1474-919x.1970.tb00090.x. ISSN 0019-1019.
  9. ^ a b c d e f Amyot, Daniel; Ghanavati, Sepideh; Horkoff, Jennifer; Mussbacher, Gunter; Peyton, Liam; Yu, Eric (2010-06-02). "Evaluating goal models within the goal-oriented requirement language". International Journal of Intelligent Systems. 25 (8): 841–877. doi:10.1002/int.20433. ISSN 0884-8173.
  10. ^ a b "GRL". www.cs.toronto.edu. Retrieved 2023-01-13.
  11. ^ a b Weiss, Michael; Amyot, Daniel (2005-07-01). "Business Process Modeling with URN". International Journal of E-Business Research. 1 (3): 63–90. doi:10.4018/jebr.2005070104. ISSN 1548-1131.
  12. ^ a b c Giorgini, Paolo; Mylopoulos, John; Nicchiarelli, Eleonora; Sebastiani, Roberto (2003), Spaccapietra, Stefano; March, Sal; Aberer, Karl (eds.), "Formal Reasoning Techniques for Goal Models", Journal on Data Semantics I, Berlin, Heidelberg: Springer, pp. 1–20, doi:10.1007/978-3-540-39733-5_1, ISBN 978-3-540-39733-5, retrieved 2023-01-24
  13. ^ F, Naviaux A; E, Banse; A, Guedes; P, Janne; M, Gourdin (2021-04-14). "« What a Catch! »: A Case Report on Denial and Myocardial Infarction". Austin Journal of Public Health and Epidemiology. 8 (1). doi:10.26420/austinjpublichealthepidemiol.2021.1095. ISSN 2381-9014.
  14. ^ Quartel, Dick; Engelsman, Wilco; Jonkers, Henk; van Sinderen, Marten (2009). "A Goal-Oriented Requirements Modelling Language for Enterprise Architecture". 2009 IEEE International Enterprise Distributed Object Computing Conference. IEEE. doi:10.1109/edoc.2009.22.
  15. ^ Aydemir, Fatma Basak; Dalpiaz, Fabiano; Brinkkemper, Sjaak; Giorgini, Paolo; Mylopoulos, John (2018). "The Next Release Problem Revisited: A New Avenue for Goal Models". 2018 IEEE 26th International Requirements Engineering Conference (RE). Banff, AB: IEEE: 5–16. doi:10.1109/RE.2018.00-56. ISBN 978-1-5386-7418-5.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:LarsVissers1998/Goal-oriented_Requirements_Language&oldid=1135473873"