Goal modeling and analysis with the Goal-oriented Requirement Language (GRL) is taught in software engineering and computer science at the University of Ottawa since 2003. This paper presents the general education approach taken in an undergraduate requirements engineering course and in a graduate software engineering course. Some of the particularities of these courses involve the use of a general GRL modeling pattern, the combined use with Use Case Maps (for operationalization and for business processes), the coverage of qualitative and quantitative analysis approaches, the use of indicators, and automated evaluations of strategies supported by the jUCMNav tool. This paper also reflects on some successes and difficulties observed in the past decade while teaching these concepts.
In the above semester-long courses, goal modeling and analysis with GRL is the topic
of a 3-hour lecture. In addition, one course has a 3-hour laboratory where students can
learn jUCMNav, an Eclipse plug-in for GRL modeling and analysis, with the help of
a teaching assistant [
This paper reports on my experience teaching GRL, mainly for the past decade (the last two courses) because of the availability of tools. The focus here is on the styles of models being taught (section 2) and on the types of analyses they enable (section 3), together with the informal feedback I perceived from students during the courses. 2
GRL is a rich goal-oriented modeling language that can be used for different purposes, from social modeling to decision making and rationale documentation. The courses introduce GRL with the later part. After a bird’s eye introduction to URN, students are taught the need for documenting design rationales in software. Rationales are often described with comments in the code and in repository commits in practice. They are also often represented in a tabular way, where different options (rows) are compared against different criteria (columns), using a coarse-grained qualitative scale or a quantitative scale with some aggregation function (e.g., weighted sum). Students often see such tables in magazines and web sites. They then learn that such tabular representation only captures a partial view of reality: dependencies between criteria are not shown, and “who is concerned with what criteria” is not described either. With these limitations in mind, the concept of goal and its use in software engineering are introduced, followed by the syntax of GRL based on a security example.
This quickly leads to the introduction of a GRL pattern (Fig. 1) that describes general decision making for systems with alternatives. As shown in this figure, system functionalities are captured with goals (that can be AND-decomposed). The various means of achieving these goals are captured as tasks linked with OR-decompositions. Actors capture system stakeholders and softgoals represent their concerns, often non-functional in nature. Some of the alternative tasks will also have some positive or negative impacts on some of the stakeholder concerns.
With such a pattern, the students learn that global decisions (one for each ORdecomposition, in order to satisfy system goals) become non trivial and that it is difficult to satisfy all actors (leading to the notion of trade-off). They also learn that once agreed on, a global decision (defined as a strategy in GRL) combined with the model itself document the “why” aspect of the system, which is a view absent from UML.
GRL supports quantitative scales for contributions ([-100..100]), for satisfaction values, and for the importance of intentional elements to their containing actor. There are also qualitative scales for contributions {Break, ..., Make}, satisfactions {Denied, …, Satisfied}, and importance {None, …, High}. Students generally understand that a qualitative scale is used in the early modeling steps, when little information is available. As the understanding of the problem and of the potential impact of solutions improves, the modeler can move to a more fine-grained quantitative scale.
However, in a quantitative context, it becomes difficult to find proper values (e.g.,
should the weight of a contribution be 30 or 40?). Although jUCMNav and GRL
contain some features that can help cope with such decisions, e.g., value ranges and
contribution overrides [
URN combines GRL with Use Case Maps (UCM), a notation for causal scenarios
superimposed onto a component structure [
Unlike i*, GRL does not distinguish explicitly between strategic dependency (SD)
diagrams and strategic rationale (SR) diagrams. These views can be distinct in GRL,
but they are often intertwined. While several other courses often start with SD
diagrams to introduce goal modeling [
Although the students can distinguish between goals, softgoals and tasks fairly
well, means-end links are no longer taught (as OR-decomposition is used instead).
Correlation links are mentioned but not taught (contributions are used instead), and
resources and beliefs are barely mentioned. In the early years, all of these concepts
were covered, but the students were puzzled by the need for so many types of
intentional elements and links. As students were using them mostly incorrectly, their
coverage was simply minimized, without a real negative impact on the expressiveness of
resulting models. This subset shares many commonalities with what is being taught
by Dalpiaz in his first-year course for information system students [
On a couple of years, both at the undergraduate and graduate levels, my colleagues and I attempted to discuss other goal modeling languages (especially i* and KAOS) and compare them with GRL, but this did not raise any real interest. I suspect this is because small differences between little-known languages do not become attractive until one goal language is actually mastered. Now we only mention their existence. 3
The teaching of analysis techniques is done iteratively and is interleaved with
modeling. Once the GRL syntax is introduced, jUCMNav is used to create a model on the
fly based on suggestions of the students on a domain they know (e.g., a university
registration system). Once a few actors, their intentions, and some links (especially
OR-decompositions) are available, the notion of “what-if” analysis is introduced. In
GRL, what-if situations are captured with strategies, which are initial satisfaction
values assigned to some of the intentional elements. A strategy is evaluated via a
propagation algorithm, and several qualitative and quantitative ones are supported in
jUCMNav [
Special attention is dedicated to trade-off analysis with the help of pre-existing examples. Students learn how to create a reasonable set of potential strategies and select the “best one” based on which actor(s) we want to prioritize in terms of satisfaction. One challenge here is to come up with a set of strategies that is reasonable while not being exhaustive (as sometimes the number of potential combinations explodes rapidly). This is a problem akin to test creation and selection in software testing.
In a different lecture of the graduate course, students are introduced to
aspectoriented modeling (AOM), and GRL and UCM are revisited in that context. Students
are taught the benefits of aspects for handling cross-cutting concerns, with examples
exploiting an aspect-oriented extension of URN [
The graduate students are also given another lecture on the Object Constraint
Language (OCL), and again this is an opportunity to revisit GRL. jUCMNav has over one
hundred predefined static semantic rules described with OCL, and it offers a user
interface to select which ones to apply to a model, and even to create new ones [
This paper provided a brief overview of the GRL education material taught in courses at the University of Ottawa, together with my perception of the student feedback on their learning experience related to modeling and analysis of goal models with GRL.
Students of the undergraduate course have to do a semester-long project in teams, leading to the creation and validation of a software requirements specification for real stakeholders. One encouraging result is that some teams voluntarily choose to use GRL to model stakeholders’ objectives together with the intended functionality of the system, and with alternatives defined and selected through “what-if” analysis of strategies. Similarly in the graduate course, where teams of students need to compare two software engineering tools in a given business context, several teams use GRL to capture stakeholder objectives and the impact of choosing one tool over the other one.
There are yet many opportunities to improve the learning experience of students in these courses. For one, there is a major lack of online video material (e.g., on YouTube) teaching goal modeling with GRL (or other languages), including tool support. We have a series of YouTube videos that were produced in 2010 to explain UCM modeling with jUCMNav. Although they totalize only about half an hour, these videos are much appreciated by the students, who wonder why there is nothing equivalent on the GRL side. Students also ask for more exercises that are smaller than those found in the assignment, with solutions, to better measure their understanding.
Future work is also needed on understanding the best subset of GRL to first introduce, and whether this would be different for undergraduate and graduate students.
Acknowledgments. The undergraduate courses discussed here have been taught in collaboration with at least four other professors over the years (G. v. Bochmann, O. Kabranov, S. Somé, and G. Mussbacher), partly because of the existence of multiple French/English sections and because of sabbatical years. I would like to thank them for a fruitful collaboration over the years. I also thank our numerous teaching assistants who have contributed to the education of GRL and jUCMNav.