Argument & Computation 1 (2016) 1–5
IOS Press

1

1

1

2

2

3
4
5
6
7

RationalGRL: A Framework for
Argumentation and Goal Modeling

8
9
10
11
12
13
14
15
16
17

3
4
5
6
7
8

Marc van Zee a,∗ , Floris Bex b and Sepideh Ghanavati caBrain Team, Google Research, The Netherlands
E-mail: marcvanzee@google.comb
Department of Information and Computing Sciences, Utrecht University & Department of Law,
Technology, Markets and Society, Tilburg University, The Netherlands
E-mail: F.J.Bex@uu.nlcSchool of Computing and Information Science (SCIS), University of Maine, ME, USA
E-mail: sepideh.ghanavati@maine.edu

18

9
10
11
12
13
14
15
16
17
18
19

26

Abstract. Goal-oriented requirements modeling approaches aim to capture the intentions of the stakeholders involved in thedevelopment of an information system as goals and tasks. The process of constructing such goal models usually involves
discussions between a requirements engineer and a group of stakeholders. Not all the arguments in such discussions can be
captured as goals or tasks: e.g., the discussion whether to accept or reject a certain goal and the rationale for acceptance orrejection cannot be captured in goal models. In this paper, we apply techniques from computational argumentation to a goalmodeling approach by using a coding analysis in which stakeholders discuss requirements for a Traffic Simulator. We combine a
simplified version of a traditional goal model, the Goal-oriented Requirements Language (GRL), with ideas from argumentation
on schemes for practical reasoning into a new framework (RationalGRL). RationalGRL provides a formal semantics and tool
support to capture the discussions and outcomes of the argumentation process that leads to a goal model. We also define the
RationalGRL development process to create a RationalGRL model.

27

Keywords: Goal Modeling, Argumentation, Goal-oriented requirements engineering, Practical Reasoning

27

19
20
21
22
23
24
25

20
21
22
23
24
25
26

28

28

29

29

30

30

31
32

31

1. Introduction

33
34
35
36
37
38
39
40
41
42
43

33

Requirements Engineering (RE) is about producing a consistent and comprehensive set of requirements of an information system, such as general functional requirements, operational environment constraints, and non-functional requirements such as security and performance. Among the “early-phase”
requirements engineering activities are those that consider how the intended system should meet organizational goals, why it is needed, what alternatives may exist, what the implications of the alternatives arefor different stakeholders, and how the interests and concerns of stakeholders might be addressed [1].
These activities fall under the umbrella of goal modeling approaches. There are a large number of established RE methods using goal models in the early stage of requirements analysis [2], and a number ofgoal modeling languages have been developed in the last two decades, with i∗ [1] being a very influential
example and the Goal-oriented Requirements Language (GRL) [3] being a fairly recent extension of i∗.

44
45

32
34
35
36
37
38
39
40
41
42
43
44

*

Corresponding author. E-mail: marcvanzee@google.com.

46

45
46

1946-2166/16/$35.00 c 2016 – IOS Press and the authors. All rights reserved

2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

M. van Zee et al. / RationalGRL

A goal model is the result of a discussion process. Goal models for complex information systems– e.g., air-traffic management systems, systems that support industrial production processes, government or healthcare services – are constructed over the course of several workshops with stakeholders
and requirements engineers. Failing to record the discussions underlying these complex goal models ina structured manner may harm the success of the RE phase of the system development process. The
challenge here is that goal modeling is a dynamic process: models continuously change and evolve, andstakeholders change their opinions in between sessions. If the rationales behind goal model revisions
are not properly documented, alternative ideas and opposing views that could potentially lead to different goal models will be lost. The problem is further exacerbated if the stakeholders constructing thegoal model change, since modeling decisions made by one group of stakeholders may conflict with theopinions of another group of stakeholders. The disconnect between goal models and their underlying
beliefs and opinions may thus lead to a poor understanding of the problem and its solution, which is an
important reason for an RE project to fail [4].
Current goal modeling languages have limited support for capturing and reasoning about changing
beliefs and opinions: the resulting goal model only shows the end product of a long process and not thediscussions of the stakeholders during the modeling process, and with existing goal modeling languages
one might change part of a goal model without being able to reason about whether or not this new goalmodel is consistent with the underlying beliefs and arguments. What is needed is a systematic approachto record the rationales (beliefs, opinions, discussions, ideas) underlying a goal model. It should bepossible to see how these rationales change during the goal modeling process and to clearly link therationales to the elements of the resulting goal model. In order to do this, we propose a framework with its
tool support which combines traditional goal modeling approaches with techniques from computational
argumentation [5]. We have identified five important requirements for our framework:

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

(1) The argumentation must capture the actual discussions of the stakeholders in the early requirements engineering phase.
(2) The framework must have formal traceability links between elements of the goal model and theirunderlying arguments.
(3) Using these traceability links, it must be possible to compute the effect of changes in the underlying arguments on the goal model, and vice versa.
(4) A process explaining how practitioners can develop models in the framework must be identified.
(5) The framework must have accessible tool support.

25

Based on our previous work [6, 7], we develop the RationalGRL framework, which extends an existing goal modeling approach, the Goal-oriented Requirements Language (GRL) [3], with ideas from(computational) argumentation, namely critical questions and argumentation semantics. Critical questions find their origins in the literature on argument schemes [8, 9]), which represent (stereotypical)
patterns of non-monotonic reasoning. Part of each scheme are critical questions, which point to typicalsources of doubt or (implicit) assumptions in arguments based on schemes. These questions can thenbe used to make explicit the counterarguments to the original argument. Such counterarguments can be
attacked in turn by their own counterarguments and thus an argumentation framework [10] of mutuallyattacking arguments can be constructed. Given such an argumentation framework, the acceptability ofsets of arguments can be computed using argumentation semantics [10]. Thus, computational argumentation based on schemes and critical questions can guide users in systematically deriving conclusions
and making assumptions explicit [9, 11].

34

26
27
28
29
30
31
32
33
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

3

Documenting choices and considerations in software or systems design using argumentation has along tradition. Already in 1970, the first article on Issue-based Information Systems [12] talked about“argumentative processes” in information system design. IBIS was further developed in the 80’s and90’s in the influential work on issue-driven design methods such as gIBIS [13] (see also [14, 15] for further work on arguments or rationales in software design). For reasons unknown, this work was largely
ignored by the goal-modeling community, which is why we propose our RationalGRL framework thatincorporates the core ideas from issue-driven design methods into goal-oriented requirements engineering by explicitly including arguments for and against the various options into a goal model.
We first extend existing work on modelling goals and arguments by developing a list of critical questions that can be used to analyze and guide stakeholders’ discussions about goal models. Inspired by
the work on practical reasoning from computational argumentation, most notably Atkinson and BenchCapon [16], we performed a coding analysis in which we analyzed a set of transcripts containing morethan 4 hours of discussions among designers of a traffic simulator information system, finding 222 instances of arguments and critical questions about goals and tasks (Requirement 1).
We then specify clearly in what way RationalGRL extends GRL by developing a metamodel, which
specifies the traceability links between the arguments based on the schemes and critical questions andthe GRL models (Requirement 2). In addition to this metamodel, we provide formal semantics for RationalGRL by formalizing the GRL language in propositional logic and rendering arguments about a
GRL model as a formal argumentation framework to which we can apply argumentation semantics [10].
We, then, formally capture the links between argumentation and goal models as a set of algorithms for
applying argument schemes and critical questions about goal models (Requirement 3).
In order to support practitioners in using the RationalGRL framework, we propose the RationalGRL
development process, which explains steps for developing goal models and posing arguments based on
critical; questions in an integrated way (Requirement 4). We implement and briefly evaluate a web-based
tool for the RationalGRL framework, which works on any modern browser and is developed in Javascript(Requirement 5).1 The tool is open-source, and designed such that new argument schemes and criticalquestions can be added easily.
The rest of this article is organized as follows. Section 2 introduces our running example and briefly
discusses the basics of GRL and argumentation about goals using argument schemes. Section 3 contains
the coding analysis and an explanation of how we obtained an initial set of argument schemes andcritical questions by coding transcripts from discussions about an information system. Section 4 provides
an overview of the RationalGRL framework and the RationalGRL metamodel, and examples from thecoding analysis that illustrate the framework and its language. In Section 5, we provide formal semantics
for GRL and RationalGRL, show how RationalGRL models can be translated to GRL models and viceversa, and we develop various algorithms that change a RationalGRL model according to an argument
scheme or a critical question. Section 6 discusses the RationalGRL development process and explainsvarious features of our tool. Finally, Section 8 covers related work, future work, and the conclusion.

39
40

43

2. Background: Goal-oriented Requirements Language and Practical Reasoning

46

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
40
41

In this section, we introduce our running example, after which we give a brief overview of the Goaloriented Requirements Language (GRL) [3], which is the goal modeling language we use to integrate

44
45

2

39

41
42

1

42
43
44

1

The tool and source code can be found at http://www.rationalgrl.com.

45
46

4
1
2
3
4
5
6
7
8

M. van Zee et al. / RationalGRL

with the argumentation framework. We consider a slightly simplified version of GRL, which includes
all the core elements of GRL but, for example, has only one level of contribution strength, whereas GRL
contains different levels of positive and negative contribution. This simplification does not in any way
influence the coding analysis. Furthermore, extending the GRL part of RationalGRL to include the fullset of GRL elements is straightforward. Next, we discuss the ideas behind computational argumentation.
In particular, we focus on the practical reasoning argument scheme (PRAS) [16], an argument schemethat is used to form arguments and counter-arguments about situations involving goals, and we giveinformal examples of how argument and counterargument can influence the status of beliefs about goals.

9
10

13
14
15
16
17
18
19
20
21
22

3
4
5
6
7
8
10
11

Our examples and coding analysis are based on the data produced by a series of experiments by Tanget al. [17], who in turn base their work on the so-called Irvine experiment [18]. This experiment contains
a design reasoning assignment in software engineering about a traffic simulator. In this assignment (seeAppendix A), designers are provided with a problem description, requirements, and a description of
the desired outcomes. The client of the project is Professor E, who teaches civil engineering courses at
an American university. In order for the professor to teach students various theories concerning traffic(such as queuing theory), traffic simulator software needs to be developed in which students can create
visual maps of an area, regulate traffic, and so forth. Tang et al. asked designers (groups of students) to
discuss the requirements of this traffic simulator. These discussions were recorded and transcribed. We
performed a coding analysis on these transcripts, which we used to develop our RationalGRL framework.
Furthermore, we also use the traffic simulator case as a running example throughout this paper.

23
24

2

9

2.1. Running example: Traffic Simulator

11
12

1

12
13
14
15
16
17
18
19
20
21
22
23

2.2. Goal-oriented Requirements Language (GRL)

24

25

25

26

26

27
28

Goal

Softgoal

Task

Resource

29
30
31
32
33
34

+

-

Positive
contibution

Negative
contibution

27

Actor w.
boundary

Actor

37
38
39
40
41
42
43
44
45
46

29
30

D

Decomposition Dependency

31
32
33

Fig. 1. Basic Elements and Relationships of GRL.

35
36

28

34
35

GRL is a modeling language for specifying intentions, business goals, and non-functional requirements of multiple stakeholders [3], based on i∗ [1] and the NFR Framework [19]. GRL is part of theUser Requirements Notation, an ITU-T standard, that combines goals and non-functional requirementswith functional and operational requirements (i.e. use case maps). GRL can be used to specify alternatives that have to be considered, decisions that have been made, and rationales for making decisions. A
GRL model is a connected graph of intentional elements that optionally are part of the actors. The GRL
intentional elements (IEs) and relationships used in this paper are shown in Figure 1.
Figure 2 illustrates a simplified GRL diagram from the traffic simulator design exercise. An actor represents a stakeholder of a system or the system itself (Traffic Simulator, Figure 2). Actors are holders ofintentions; they are the active entities in the system or its environment who want goals to be achieved,

36
37
38
39
40
41
42
43
44
45
46

5

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

tasks to be performed, resources to be available, and softgoals to be satisfied. Softgoals differentiatethemselves from goals in that there is no clear, objective measure of satisfaction for a softgoal whereasa goal is quantifiable. Softgoals (e.g. Realistic simulation) are often related to non-functional requirements, whereas goals (such as Generate Cars) are related to functional requirements. Tasks represent
solutions to (or operationalizations of) goals and softgoals. In Figure 2, there are two tasks Create newcars and Keep same cars: in order to achieve the goal Generate cars, the simulation can either constantly
generate new ones or keep the same cars and have them reappear after they disappear off-screen. In order
to be achieved or completed, softgoals, goals, and tasks may require resources to be available (e.g., Car
Objects). Finally, the full version of GRL allows design rationale to be captured using beliefs. Since we
capture the reasoning and rationales behind goal models using arguments, we do not include beliefs inour simplified version of GRL (but see the discussion at the end of this section).
Different links connect the elements in a GRL model. AND, IOR (Inclusive OR), and XOR (eXclusive OR) decomposition links allow an element to be decomposed into sub-elements. In Figure 2, thegoal Generate cars is XOR-decomposed to the tasks Create new cars and Keep same cars, as they arealternative ways of achieving the goal Generate cars. Contribution links indicate impacts of one element
on another element, which can be positive or negative. Task Create new cars has a positive contribution
to the softgoal Realistic simulation, and a negative contribution to the softgoal Simple design. Note thatthe full GRL specification considers different levels of positive and negative contribution values (bothquantitative and qualitative), which are not directly relevant for our current purpose. Dependency links
are relationships between intentional elements, which can model dependencies between actors. Here,the goal Generate cars depends on the resource Car objects.
The GRL model in Figure 2 shows the softgoals, goals, tasks and the relationship between the different
intentional elements in the model. However, the rationales and arguments behind certain intentional
elements are not shown in the GRL model. Some of the questions that might be interesting to reason
about are the following:

26
27
28

31

Car
objects

Easy to
use

42

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
27
28

32

Simpledesign+34

Generate
cars

35

XOR

37

36
38

-

39

40
41

6

31

D
Realistic
simulation

37
39

5

33

34

38

4

30

Traffic
Simulator

33

36

3

29

32

35

2

26

• Why is softgoal Easy to use not linked to any of the goals or tasks?
• What does Keep same cars mean?

29
30

1

40

Create newcars

Keep same
cars

41
42

43

43

44

44

45
46

Fig. 2. Partial GRL Model of the Traffic Simulator Example.

45
46

6
1
2
3

M. van Zee et al. / RationalGRL• Why does the task Create new cars contribute negatively to Simple design and positively to Realistic simulation?
• Why does Generate cars XOR-decompose into two tasks?

4
5
6
7
8
9
10
11
12
13

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

2
3
4

These are the types of the questions that we cannot answer by just looking at GRL models. The modelin Figure 2 does not contain information about discussions that led to the model, such as clarification
steps for the naming, or alternatives that have been considered for the relationships. The idea behind theoriginal GRL specification is that so-called belief elements can be used to capture such design rationales
that make later justification and review of a model easier. In the original GRL specification, however,
the exact semantics of these belief elements and the ways in which they should be used remain unclear.
Furthermore, belief elements cannot be attached to links between elements, which makes answering thefourth and fifth question above impossible. We further discuss belief elements in light of our proposedargumentation-based framework in Section 8.1.

14
15

1

5
6
7
8
9
10
11
12
13
14

2.3. Argumentation about goals and actions
An important characteristic of human reasoning is its non-monotonic, or defeasible, nature: conclusions that are accepted at one moment may be retracted later in view of new information; on the other
hand, new information may cause conclusions that were rejected earlier to be reinstated. Computational
argumentation is an approach to non-monotonic reasoning that focuses on interactions between arguments and counterarguments. With applications in multi-agent systems, decision-making tools, medical
and legal-reasoning, argumentation has become a major subfield of artificial intelligence [5].
One central concept in argumentation is that of argument schemes [8, 9]), stereotypical patterns of nonmonotonic reasoning – for example, “if an expert says something, we can usually accept his claims”.
Part of argument schemes are the critical questions, which point to typical sources of doubt or implicit
assumptions in arguments based on schemes – for example, “is the expert biased?” or “is the expert
a recognized expert in the field that he claims?”. Critical questions can be used to make explicit thecounterarguments to the original argument – e.g. “we should not accept the expert’s claim since heis biased”. Such counterarguments can be attacked in turn by their own counterarguments – “no he’s
not biased since he has no stake in the case” – and thus an argumentation framework [10] of mutuallyattacking arguments can be constructed.
In early-phase requirements engineering, we can imagine many different argument schemes, such as
for example the Appeal to Expert Opinion Scheme illustrated above. Central, however, in discussions
surrounding goal models is obviously the reasoning about which goals to pursue and which actions
to take, often referred to as practical reasoning. Practical reasoning has been studied extensively incomputational argumentation, mainly by Atkinson and Bench-Capon [16], who have developed andformalized the Practical Reasoning Argument Scheme. A simplified version of this argument scheme,
presented in syllogistic form, is as follows:
G is a goal,
Performing action A realizes goal G,
Therefore
Action A should be performed
Here, G and A are variables, which can be instantiated with concrete goals and actions to provide a
specific practical argument. For example, a concrete argument about the traffic simulator is as follows:

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL(A2) Action Create new cars
realizes goal Generate cars
Therefore Create new cars
should be performed

1
2
3

7

(A3) Create newcars has a negative
effect on Simple
design

1
2
3

4

4

5

5

6

6

(A1) Action Keep same cars
realizes goal Generate cars
Therefore Keep same cars
should be performed

7
8
9
10
12
14
15
16
17

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

9
11
12

Generate cars is a goal,
Performing action Keep same cars realizes goal Generate cars,
Therefore
Action Keep same cars should be performed

13

19

8
10

Fig. 3. PRAS Arguments and Attacks in the Traffic Simulation Example.

11

18

7

13
14
15
16
17

Like in all argumentation, practical reasoning is also about counterarguments. For example, we may
argue that, in fact, performing action Keep same cars does not realize goal Generate cars, thus giving acounterargument to the above argument. Atkinson et al. [16] define a set of critical questions that point
to typical ways in which practical reasoning arguments can be criticized. Some examples of criticalquestions are as follows.
CQ1 Will the action realize the desired goal?
CQ2 Are there alternative ways of realizing the same goal?
CQ3 Does performing the action have a negative side effect?
Answers to these critical questions are counterarguments to the original argument. These counterarguments also follow a scheme; for example, a negative answer to CQ1 follows the scheme “Action A will
not realize goal G”, which can be instantiated (e.g. “Keep same cars does not realize Generate cars”)
to form a counterargument to the original argument. Another way to criticize an argument for an action
is to suggest an alternative action that realizes the same goal (CQ2). For example, we can argue that
performing Create new cars also realizes the goal Generate cars. Also, it is possible that performing anaction has a negative side effect (CQ3). For example, while the action Create new cars realizes the goal
Generate cars, it has a negative side effect, namely hurting Simple design: having the simulation constantly create new cars is fairly complex design choice. Note that argument schemes and the arguments
based on them can thus be of a more syllogistic form (i.e., “G, A realizes G, Therefore A”) but also of asimpler, more propositional form (i.e., “A does not realize G”).
Counterarguments attack the original arguments. Given a set of arguments and attacks between thesearguments, we can compute which arguments are accepted and which are rejected using different argumentation semantics [10]2 . Figure 3 shows three arguments from the traffic simulation example, wherearguments are rendered as boxes and attack relations as arrows. There are two arguments for a goal:argument A1 for Keep Same Cars and argument A2 for Create new cars. Argument A2 proposes analternative way of realizing the same goal Generate cars with respect to argument A1 and vice versa (cf.
2Formal definitions of argumentation frameworks and semantics will be given in Section 3.

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

M. van Zee et al. / RationalGRL

CQ2). Thus, A1 and A2 mutually attack each other, denoted by the arrows between A1 and A2. Argument A3 says that Create new cars has a negative effect on Static Simulation, therefore, A3 attacks A2,
as it points to a negative side-effect of Create new cars (CQ3). The intuition here is that an argument is
acceptable if any argument that attacks it is itself rejected. In Figure 3, argument A3 is accepted because
it has no attackers. This makes A2 rejected (indicated by the lighter grey color), because its attacker A3
is accepted. A1 is then also accepted, since its only attacker, A2, is rejected.
The practical reasoning scheme and its critical questions as given above could be used to argue about
goal models. In fact, in some of our early work on RationalGRL [6, 7] we used practical reasoning arguments such as A1 and A2 to capture reasoning about goals, combined with arguments based on otherschemes such as the scheme from Expert Opinion. We then translated these arguments to goal models.
However, our later coding analysis (Section 3) shows that when discussing requirements, people very
often do not structure their reasoning nicely along the lines of the full argument schemes, that is, theyrarely utter an argument along the lines “We have goal G, A realizes G Therefore we should perform
A”. A typical discussion is much more unstructured, as is clear from the transcript excerpts in Appendix B. Stakeholders propose and debate possible goals of the system, alternative options, and so on,
but the argumentation is more about making different (propositional) claims, questioning these claims
and proposing counterclaims than about building inference structures from premises to conclusions.
Furthermore, it turned out that the stakeholders did not use many other types of argument or argument
scheme, such as Expert Opinion. Hence, we decided to develop our own set of argument schemes andcritical questions by coding the transcripts of discussions about the traffic simulator, so that we would
meet Requirement 1: The argumentation techniques must capture the actual discussions of the stakeholders or designers in the early requirements engineering phase. Our set of schemes, questions and ourcoding analysis are described in the next section.

24

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
25

3. Argument Schemes for Goal Modeling: A Coding Analysis

27
28

2

24

25
26

1

26
27

Recall that Requirement 1 of our RationalGRL framework is that the argumentation should be close
to the actual discussions of stakeholders or designers in the early requirements engineering phase. To
get a sense of such discussions, we performed a coding analysis to examine which types of discourse
are used during discussions of system requirements, and how these discourse types can be captured asarguments and critical questions [20]. The type of coding we performed is a priori coding: we manuallycoded transcripts of discussions using a pre-existing list of argument schemes and critical questions
based on GRL and the practical reasoning scheme. In this section, we present our coding analysis.3
In order to obtain actual requirements discussions, we turned to a recent series of experiments by Tanget al. [17]. In these experiments, 12 groups of two or three students in a Software Architecture course
at MSc level were given the traffic simulator assignment (Appendix A). These groups had a maximumof two hours to design a traffic simulator, which included a discussion of the requirements of this traffic
simulator. The students did not use any goal modeling technique in the course or during the discussions.
They were asked to record their design sessions, and the recordings were subsequently transcribed. We
used three of these transcripts, totaling 153 pages, for our coding analysis.
Before coding the transcripts, we came up with an initial list of 11 argument schemes (AS0-AS10 inTable 1) based on GRL, practical reasoning, and an initial quick reading of some of the transcripts. As
3All original transcripts, codings, and models are available in our online repository, which can be found at http://www.
rationalgrl.com.

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

9

M. van Zee et al. / RationalGRL

AS0
AS1
AS2
AS3
AS4
AS5
AS6
AS7
AS8
AS9
AS10

Scheme/Question
Actor
Resource
Task/action
Goal
Softgoal
Goal decomposes into tasks
Task contributes (negatively) to softgoal
Goal contributes (negatively) to softgoal
Resource contributes to task
Actor depends on actor
Task decomposes into tasks

t1
2
2
20
0
3
4
8
0
0
0
11

t2
2
4
21
2
4
0
3
1
4
1
14

t3
5
5
17
2
2
4
0
1
3
3
11

total
9
11
58
4
9
8
11
2
7
4
36

CQ2
CQ5a
CQ5b
CQ6b
CQ10a
CQ10b

Task is possible?
Does the goal decompose into the tasks?
Goal decomposes into other tasks?
Task has negative side effects?
Task decompose into other tasks?
Decomposition type correct?

2
0
1
2
1
1

2
1
0
0
2
0

1
0
0
0
0
1

5
1
1
2
3
2

CQ11
CQ12

Is the element relevant/useful?
Is the element clear/unambiguous?

2
3

3
10

2
3

7
16

Att

Generic counterargument

0

2

2

4

69

80

69

222

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

TOTAL

Table 1
Occurrences of Argument Schemes AS and Critical Questions CQ in the three transcripts t1 , t2 and t3 .

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

discussed in the previous section, we found that the discussion has a particular argumentative structure
consisting of claims, questions and counterclaims. Hence, our argument schemes are not of the more
traditional, syllogistic form but rather represent types of claims about a goal model.
AS0 to AS4 are schemes that concern a single element of a goal model. For example, AS0 represents
the claim ‘a is a relevant actor for the system’, and AS3 represents the claim ‘G is a goal for the system’.
AS5 to AS10 are claims about the links between GRL intentional elements. Our initial list also contained
18 critical questions, inspired by the questions associated with the original Practical Reasoning Argumentation Scheme [21]. CQ2 to CQ12 (Table 1) are examples of these critical questions, other examples
are ‘Is the softgoal legitimate?’ and ‘Are there alternative ways to contribute to the same softgoal?’.
Using the initial list of arguments and critical questions, we coded three transcripts of requirements
discussions. The coding was performed by one author and subsequently checked by other authors. As thetranscripts contain spoken language, the coding involved some interpretation. For example, the students
almost never literally say ‘actor a has task T ’. Rather, they say things such as ‘...we have a set of actions.
Save map, open map, ...’ (Table 5, Appendix B) and ‘We also have to be able to change the inflow ofcars. How many car come out in here on the side’ (Table 6, Appendix B). Furthermore, in some cases
the critical questions are explicit. For example, CQ10b is found in the transcripts as ‘...is this an OR
or an AND?’ (Table 7, Appendix B). In other cases, however, the question remains implicit but we
added it in the coding. For example, CQ11 (‘Is the element relevant/useful?’) is not found directly in thetranscripts, but it can be inferred from statements such as ‘...you don’t have to specifically add a traffic
light’ (Table 5, Appendix B).

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

10
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

M. van Zee et al. / RationalGRL

During the coding, new argument schemes and critical questions were added to the list. For example,
we found that the discussants often talk about tasks decomposing into sub-tasks, therefore, we added
AS10 and CQ10a. Furthermore, since there were many discussions on the relevance and the clarity of
the names of elements, two generic critical questions CQ12 and CQ13 were added. The final resultsof the coding can be found in Table 1. We found a total of 159 instantiations of argument schemes
AS0-AS10. The most used argument scheme was AS2: “Actor A has task T ”, however, each argument
scheme is found in transcripts at least twice. A large portion (about 60%) of argument schemes involved
discussions about tasks of the information system (AS2, AS10). We coded 41 applications of criticalquestions. Many critical questions (about 55%) involved clarifying the name of an element, or discussing
its relevance (CQ12, Gen).
Our coding further led us to identify three different operations, that represent different effects an argument or critical question can have on a goal model: an argument can introduce a new element in the goalmodel (INTRO); it can disable (i.e. attack) a goal model element (DISABLE); or it can replace an elementin the goal model with another one (REPLACE). Consider, for example, Table 5 in Appendix B. First,
an argument is posed that introduces a number of tasks. A counterargument is then given against one ofthese tasks (add traffic light), which is subsequently disabled. An example of replacement is given in Table 7 (Appendix B): what used to be an AND-decomposition is changed into an OR-decomposition. We
will further discuss these operations in Section 4 with various examples, and we formalize the operationsin Section 5 with algorithms.

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

4. The RationalGRL Framework
We now give an overview of our RationalGRL framework. Through a metamodel and informal examples from our coding analysis we will show that it is possible to trace elements of the goal model back totheir underlying arguments (Requirement 2), and that it is possible to determine the effect of changes
in the underlying argumentation on the goal model, and vice versa (Requirement 3). A formalization of
our framework using formal logic can be found in Section 5.
Figure 4 presents an overview of the RationalGRL framework. There are two activities (bottom), Practical reasoning & argumentation and Goal model construction, which give rise to two different models(top), a RationalGRL model and a GRL model. A RationalGRL model is a model in the language that
we will explain in the next subsection, while a GRL model is a model in the language we described in
Section 2.2. The Goal model construction part of the RationalGRL framework allows for the creation ofgoal models by analyzing the non-functional requirements and refining the high-level goals into operationalized tasks. In the Practical reasoning & argumentation part, arguments and counterarguments canbe put forward about various parts of the goal model. These two parts, GRL and argumentation, can impact the other side so that the models can be refined or new critical questions and argument schemes canbe instantiated. For example, answering a critical question Is the task A possible? can result in removing
or adding a task in the GRL model. Similarly, if, for example, we add a new intentional element to the
GRL model, it can lead to a new critical question relevant to this intentional element and its relationships. Thus, in the framework it is possible to trace a goal model back to the original discussions about
goals, tasks and requirements. The GRL model is shown on the right-hand side of the framework while
the argumentation model is on the left-hand side. The links between the two sides illustrate the impacts
and relationships between two sides. Note that answer to critical questions and argument schemes thatare instantiated during the analysis phase of the GRL model are documented with the GRL model andcan be referred to in the future.

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

11

M. van Zee et al. / RationalGRL
1RationalGRL model1

GRL model

22

examples (4.3), algorithms
(5.3)

3
4

3
4

Practical reasoning &argumentation

5
6
7

Goal model
construction

5
6
7

Fig. 4. The RationalGRL Framework.

8

8

9

9

10
11
12
13

AS0
AS1
AS2

Argument schemea is an actor
Actor a has resource R
Actor a can perform task T

14
15
16
17
18

CQ0
CQ1
CQ2a
CQ2b

AS3
AS4

Actor a has goal G
Actor a has softgoal S

CQ3
CQ4

AS5

Goal G decomposes into task T

CQ5a

19

CQ5b

20
21
22

AS6

Task T contributes (negatively) to softgoal S

CQ5c
CQ6a

23

CQ6b

24
25

CQ6c

26
27

AS7

Goal G contributes to softgoal S

CQ7a

28

CQ7b

29
30

AS8

Task T depends on resource R

CQ8

31
32

AS9

Actor a depends on actor b

CQ9

AS10

Task T i decomposes into task T j

CQ10a

33
34
35

CQ10b

36
37
38
39
40
41
42
43

AS11
AS12

Element IE is relevant
Element IE has name nAtt

Generic counterargument

CQ10c
CQ11
CQ12

Critical Questions
Is the actor relevant?
Is the resource available?
Is the task possible?
Does the task have negative sideeffects?
Can the desired goal be realized?
Is the softgoal a legitimate softgoal?

Effect10

DISABLE (no)11

DISABLE (no)12

DISABLE (no)DISABLE (yes)13

Does the goal decompose into thetask?
Does the goal decompose into othertasks?
Is the decomposition type correct?
Does the task contribute to the softgoal?
Are there alternative ways of contributing to the same softgoal?
Does the task contribute (negatively)
to some other softgoal?
Does the goal contribute to the softgoal?
Does the goal contribute to someother softgoal?
Is the resource required in order toperform the task?
Does the actor depend on any actors?
Does the task decompose into thetask?
Does the task decompose into othertasks?
Is the decomposition type correct?
Is the element relevant/useful?
Is the name clear/unambiguous?

DISABLE (no)DISABLE (no)DISABLE (no)INTRO (yes)

46

15
16
17
18
19
20

REPLACE (no)21

DISABLE (no)22
23

INTRO (yes)
INTRO (yes)

24
25
26

DISABLE (no)27
28

INTRO (yes)DISABLE (no)

29
30
31

INTRO (yes)32
33

DISABLE (no)INTRO (yes)

34
35
36

REPLACE (no)37

DISABLE (no)38

REPLACE (no)39

AttGeneric counterargument
DISABLE
Table 2
List of argument schemes (AS0-AS12, Att), critical questions (CQ0-CQ12), and the effect of answering the CQs (right column).
The effects are for the CQs only, and do not apply to the argument schemes.

44
45

14

40
41
42
43
44

In the rest of this section we discuss the individual parts of the RationalGRL framework. In Section 4.1,

45
46

12
1
2
3
4

M. van Zee et al. / RationalGRL

we continue our discussion of the argument schemes and critical questions for practical reasoning andargumentation, fitting these schemes and questions into our framework. In Section 4.2, we discuss thelanguage for RationalGRL models and we provide a metamodel, linking the new concepts of our language to GRL. In Section 4.3, we provide extensive examples from our coding analysis.

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

34
35
36
37
38
39
40
41
42
43
44
45
46

2
3
4
5

4.1. The RationalGRL Critical Questions and Argument Schemes for Practical Reasoning
A core aspect of the RationalGRL framework are the argument schemes – in particular the criticalquestions – which should be close to the actual discussions of stakeholders (Requirement 1). Recall
from Section 3 that we ended up with a list of argument schemes and critical questions that were foundin the transcripts (Table 1). Using this list as a basis, we further refined the set of argument schemes
and critical questions for RationalGRL into the list shown in Table 2. Again, we note that the argument schemes are not of the traditional, syllogistic form, but rather represent types of claims about goalmodels. These schemes could be rendered in a syllogistic form: for example, we could say that thefull reasoning encapsulated by scheme AS0 is something like “a is an actor in the information system
Therefore a should be included as an actor in the goal model”
It is important to note that the list we provide here is not exhaustive – it is the result of our empirical
study, but new argument schemes and questions can be added depending on the problem domain. In fact,
our tool (Section 6.2) contains many more critical questions, and it is fully extensible, meaning that newargument schemes and critical questions can be added easily. See Section 8.2 for more details.
AS0-AS4 and AS11-AS12 are arguments for an element of a goal model, and AS5-AS10 are related tolinks in a goal model. The last scheme (Att) is a scheme for a generic counterargument against any typeof argument. Arguments based on the schemes in Table 2 can be used to form arguments about elements
in a GRL model. Making an argument based on one of the schemes effectively adds the corresponding
GRL element to the model. See, for example, Table 5 in Appendix B: the participants argue for the
addition of several tasks to the goal model using argument scheme AS2.
An important part of arguing about goal models is asking the right critical questions. The criticalquestions presented in Table 2 are therefore related to their respective argument schemes. These questions can be answered with “yes” or “no”, and the type of answer has an effect on the original argument(INTRO, DISABLE, REPLACE). This will be further explained in Section 4.3 and in Section 5.
4.2. The RationalGRL Modeling Language

32
33

1

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

RationalGRL is an extension of GRL and includes all the elements shown in Figure 1. However, there
are also new elements corresponding to argumentation-related concepts. Figure 5 shows these elements.
• Argument: This represents an argument that does not directly correspond to a GRL element.
• Rejected (Disabled) GRL element: If an argument or a GRL element is attacked by an argumentthat itself is not attacked, then this GRL element will be rejected. Note Figure 5 only shows
one type of disabled element, a Task, but all the elements (IEs and links) can be disabled in
RationalGRL.
• Attack Link: An attack link can occur between an argument and another argument or GRL element.
It means that the source argument attacks the target argument or the GRL element.

The complete metamodel of the language can be found in Figure 6. This metamodel represents theabstract grammar of the language, independently of the notation. The metamodel also formalizes the
GRL concepts and constructs introduced in Section 2.2.

33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2

Generic
Argument

Attack link

13

Rejectedelement

3
4
5

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

The metamodel consists of two packages, Practical reasoning & argumentation and Goal model construction, which correspond to the relevant activities in the RationalGRL framework (cf. Figure 4). The
goal model construction package is simply the GRL metamodel. It consists of GRLModelElements,
which can be either GRLLinkableElements or ElementLinks. A GRLLinkableElement can again be specialized into an Actor or an IntentionalElement (which is either a Softgoal, Goal, Task, Resource, or aBelief). Intentional elements can be part of an actor, and GRLLinkableElements are connected throughElementLinks of different types (i.e., Contribution, Decomposition, or Dependency). Finally, a GRLmodel
is composed of GRLModelElements.
The practical reasoning and argumentation package depicts the concepts we introduced in Section 4.1.
An ArgumentScheme represents a scheme containing variables, and by instantiating such a scheme we
obtain an Argument. Therefore, each argument is associated with at most one scheme, but a scheme canbe instantiated in multiple ways. A RationalGRLmodel is composed of arguments and attack relations.
The OperationTypes in the argumentation package correspond to the operations we informally introduced in Section 4. These operations are performed by instantiating an argument scheme or answeringa critical question. An INTRO operation introduces a new RationalGRL element. A DISABLE operation creates a new argument that attacks another argument or GRL element, effectively disabling it. The
REPLACE operation replaces a RationalGRL element with a new element. Instantiating an argument
scheme from Table 2 always leads to an INTRO operation, that is, it always introduces a new RationalGRL element. Answering a critical question can have different effects depending on the critical question
and the answer. Table 2 shows these effects for the different critical questions and answers. For example,
answering CQ0 with “no” disables the argument based on AS0.
There are two important links between the practical reasoning & argumentation and goal model construction packages. First, each GRLModelElement is an Argument. This means that each model element
inherits the AcceptStatus as well, allowing GRL elements to be accepted or rejected. This, furthermore,means that argument schemes can be applied to all GRL elements, capturing the intuition that each GRL
element can be regarded as an instantiated argument scheme. Note that besides arguments about elements of the GRL model, we also have a GenericArgument which is simply a counter-argument to an
existing argument that does not relate to any of the GRL elements. Finally, the relation between GRLModelElement and Argument means that, as we already briefly indicated when discussing the framework in
Figure 4, the class of RationalGRLmodel is a superclass of GRLmodel: besides arguments about GRL
elements, we can also have arguments that do not relate to any of the GRL elements.

43
44
45
46

5
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

4.3. From Practical Reasoning to RationalGRL Models: Examples from the Coding Analysis

41
42

4
6

39
40

2
3

Fig. 5. The new elements and link of RationalGRL. Generic argument (left), attack link (middle), and disabled element (right).
The disabled element in this figure is a task, but all IEs and links can be disabled in RationalGRL.

6
7

1

40
41

We now discuss the interactions between the practical reasoning & argumentation (bottom left element of the framework in Figure 4) on the one hand, and RationalGRL models (top left element of theframework in Figure 4) on the other hand. We provide informal examples of the links between the practical reasoning found in our coding analysis transcripts and RationalGRL models – the formal grounding

42
43
44
45
46

14

M. van Zee et al. / RationalGRL

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32
33
34

32

Fig. 6. The RationalGRL Metamodel. The Goal model construction package (bottom) is the GRL metamodel. The Practicalreasoning & argumentation package is the RationalGRL extension.

35
36
37
38
39
40
41
42
43
44
45
46

33
34
35

for this connection can be found in the RationalGRL metamodel (Section 4.2) and in the logical formalization in the next section. The connection between the RationalGRL models shown in this section andregular GRL models is further formally defined in Section 5.3.
Example 1 - Introducing GRL elements with arguments (INTRO).. We first show how instantiatingargument schemes leads to the introduction of new RationalGRL elements in a model. Take the example
in Figure 7, which is based on the excerpt from transcript t3 shown in Table 7 (Appendix B). On theleft side, the arguments found in the transcript are shown, together with the argument scheme they arebased on. The participants in the discussion argue that actor System has a goal and two tasks, and thatthe goal AND-decomposes into the two tasks. By putting forward these arguments, new GRL elements
are introduced. These GRL elements are shown on the right side of Figure 7; the dashed arrows indicate

36
37
38
39
40
41
42
43
44
45
46

15

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13

(AS3) Actor System
has goal Simulate
Traffic

Simulate
Traffic

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

6
7

Dynamic
Simulation

StaticSimulation

42
43

46

9
11

(AS2) Actor System
has task Static
Simulation

12
13
14

Fig. 7. RationalGRL Model (right) with Instantiated Argument Schemes (left): Introducing New Elements (Operation INTRO).

the links between the practical reasoning and argumentation on the left and the RationalGRL model on
the right.
Example 2: Disabling GRL elements by answering critical questions (DISABLE).. The excerpt fromtranscript t1 used in this example is shown in Table 5 (Appendix B). Here, participants first sum up
functionality of the traffic simulator, which can be captured as instantiations of AS2. On left side of
Figure 8 one such instantiation is shown, which leads to the addition of the task Add traffic light in
the RationalGRL model on the right side of Figure 8. However, participant P1 notes that the problem
description states that all intersections have traffic lights by default, so the task Add traffic light is notnecessary. This is captured using critical question CQ11. A negative answer to this question (cf. Table 2)should disable the original argument based on AS2 by attacking it. On the left side of Figure 8 a newargument (CQ11) attacks the original argument based on argument scheme AS2. This new argument isalso added to the RationalGRL model on the right-hand side of Figure 8, where it attacks the originaltask Add traffic light. This attack leads to the original argument being rejected (cf. Section 2.3 andSection 5.2), indicated by being greyed out. As a result of this, the corresponding GRL task Add traffic
light is also disabled.
Example 3: Changing a decomposition type by answering critical questions (REPLACE).. The excerptof transcript t3 used for this example is shown in Table 7 in Appendix B. It consists of a discussion
about the type of decomposition relationship for the goal Simulate Traffic (Figure 9). Recall that in
Example 1, an AND-decomposition was introduced for this goal with AS5. In the discussion of the(AS2) Actor Student
has task Add traffic
light

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

Add traffic
light

38
39
40

(CQ11) Add traffic
light is not necessary(all intersections
have traffic lights)

41

All intersections
have lights (CQ11)

44
45

8
10

40
41

4
5

14
15

2
3

And

(AS5) Goal Simulate
Traffic AND-decomposes
into Dynamic Simulationand Static simulation(AS2) Actor System
has task Dynamic
Simulation

1

42
43
44

Fig. 8. Disabling Elements (Operation DISABLE).

45
46

16
1
2
3

M. van Zee et al. / RationalGRL(AS5) Goal Simulate
Traffic AND-decomposes
into Dynamic Simulationand Static simulation

4

1

Simulate
Traffic

Simulate
Traffic

2

And

Or

4

5

5

6
7
8
9

6

(CQ10b) Goal Simulate
Traffic OR-decomposes
into Dynamic Simulationand Static simulation

7

Dynamic
Simulation

StaticSimulation

10
11

14
15
16

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

38
39

Example 5: Defending the addition of an actor (DISABLE).. The excerpt from transcript t3 used in thisexample is shown in Table 8 in Appendix B. Actor Development Team is introduced with an argument
based on AS0 (Figure 11). This is then attacked by arguing that the professor will develop the software,thus, there will not be any development team (CQ0).
Further in the discussion, it is then argued that the development team should be considered, since theprofessor does not develop the software. This is captured using a generic counterargument Att, whichattacks the earlier argument based on CQ0. Figure 12 shows the situation after the counterargument has
been put forward: the argument (Att) now attacks the argument (CQ0), which in turn attacks the original
argument (AS0). As a result, the argument (AS0) is acceptable (cf. Section 2.3 and Section 5.2), whichcauses the actor in the RationalGRL model to be enabled again.
(AS2) Actor
Student has task Set
car influx

46

15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

38
39
40
41

(CQ12) Actor
Student has task Set
car influx per roadSet car influx
per road

44
45

14

37

Set car influx

41
43

13

36

40
42

11

17

Example 4: Clarifying a task by answering critical questions (REPLACE).. The transcript excerpt of
this example is shown in Table 6 in Appendix B and comes from transcript t1 . The discussion starts
with an instantiation of argument scheme AS2: “Actor Student has task Set car influx” (Figure 10). This
argument is then challenged with critical question CQ12: “Is the task Set car influx specific enough?”.
This is answered negatively, creating a new argument “Actor Student has task Set car influx per road”,
which attacks the original argument for Set car influx. Note how the new task Set car influx per roadalso attacks (and disables) the original RationalGRL task Set car influx.

36
37

9

12

current example, CQ5c – “Is the decomposition type correct?” – is explicitly asked. The answer is “No,it should be OR”. The original argument for AND-decomposition is now attacked by the argument for
the OR-decomposition, and the new argument is linked to the OR-decomposition in the RationalGRL
model.

17
18

8
10

Fig. 9. Replacing an Element (Operation REPLACE).

12
13

3

42
43
44

Fig. 10. Renaming an Element Name (Operation REPLACE).

45
46

M. van Zee et al. / RationalGRL
12
3(CQ0) Development
team is not relevant(professor develops
software)17

Professor
develops
software (CQ0)

1
2
3

4

4

5

5

6
7
8

(AS0) Actor
Development teamis relevant

Development
Team

9Fig. 11. Disabling an Element (Operation DISABLE).

11
12

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

12

5. RationalGRL: Logical Framework

13

In Section 4, we have shown through a language definition and informal examples from our coding analysis that it is possible to trace elements of a goal model back to their underlying arguments(Requirement 2), and that it is possible to determine the effect of changes in the underlying argumentation on a goal model, and vice versa (Requirement 3). A formal rendition of this traceability will bepresented in this section, in which we present a logical formalization of the RationalGRL framework.
This is done for multiple reasons: (i) Most approaches in formal argumentation (cf. Section 2.3) use
formal logic, allowing us to employ existing technique directly in order to compute which arguments are
accepted and which are rejected, (ii) we can be more precise about how critical questions are answered,(iii) we can show that RationalGRL models can be translated to valid GRL models and vice versa ina precise way, and (iv) the formal approach is a basis for automating the framework in terms of tool
support, which we present in the next section.
In Sections 5.1 and 5.2 we formalize a static representation of our framework based on the metamodel(Figure 6). We first provide a formal specification of a GRL model in Section 5.1, and we extend it witharguments and attack links in the Section 5.2, hereby obtaining a formal specification of a RationalGRL
model. In Section 5.3 we then present algorithms in order to translate a GRL model into a RationalGRL model, and vice versa. Finally, in Section 5.4, we develop algorithms for instantiating argument

31
32
33

36
37
38

Professor does
not develop
software (Att)(CQ0) Development
team is not relevant(professor develops
software)

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
32
33
35

Professor
develops
software (CQ0)

36
37
38
39

40
42

15

34

39
41

14

31

(Att) Professor does
not develop
software

34
35

10
11

13
14

7
8

9
10

6

40

(AS0) Actor
Development teamis relevant

Development
Team

41
42

43

43

44

44

45
46

Fig. 12. Defending an Element by Attacking its Disabling Attacker (Operation DISABLE).

45
46

18
1
2

M. van Zee et al. / RationalGRL

schemes and answering critical questions and thus formally capture the INTRO, REPLACE and DISABLE
operations of which examples were previously given in Section 4.3.

3
4

7
8
9
10

• IETypes = {Softgoal, Goal, Task, Resource},• LinkTypes = {PosContr, NegContr, Dep, Decomp}4 ,• Types = IETypes ∪ LinkTypes ∪ {Actor, ActIE, GenArg},• Names is a finite set of strings,• DecompTypes = {AND, OR, XOR}.

14
15
16
17
18
20
21
22
23

Next, we define an intentional element.
Definition 2 (Intentional Element). An intentional element is a tuple ie = (id, type, name, decomptype),
where:

24• id ∈ N is a unique identifier for the element,• type ∈ IETypes specifies the type of the element,• name ∈ Names is a string description of the element,• decomptype ∈ DecompTypes refers to the type of decomposition.

25
26
27
28
29

A set of intentional elements is denoted by IE.

30
31
32
33
34
35
36
37
38

The definition above is sufficient to capture all intentional elements (IEs) used in GRL. Note that
according to the definition above, all IEs have a decomposition type, even when the IE is not decomposed
into other IEs. This is in line with the GRL metamodel. However, in the following, we sometimes leaveout the decomptype if the IE is not decomposed to simplify the notation and improve readability.
Throughout this section, we use the example in Figure 2. This example contains various IEs which
can be formalized using Definition 2, for example, (1, Resource, Car objects), (2, Softgoal, Realistic
simulation) and (5, Goal, Generate cars, XOR).
We now define actors.

• id ∈ N is the identifier of the actor,• type = Actor states that this tuple is an actor.

42
43
45
46

8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
38
39

Definition 3 (Actor). An actor is a tuple act = (id, type, name), where:

41

44

7

30

39
40

6

11

Definition 1 (General Definitions). We define the following sets:

13

19

4
5

We formalize a GRL model based on the metamodel (Figure 6), starting with intentional elements andactors.
Throughout this section, we adopt the convention that variables start with a lowercase letter (e.g, id, i,j, name, goal), and sets and constants start with an uppercase letter (e.g., T ype, AND, Goal). We begin
by defining general elements of our language that we use in subsequent definitions.

11
12

2
3

5.1. Formal Specification of GRL

5
6

1

4

Recall from Section 2 that for contribution links we only distinguish between positive and negative contributions. Extending
the formalization model to include all the GRL values is straightforward but has been omitted here for conciseness.

40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1

19• name ∈ Names is a string description of its name.

2
3

2

A set of actors is denoted by Act.

4
5
6

11
12
13
14

17
18
19
20
21
22

A set of Actor-IE relations is denoted by RActIE .

25
26
27
28
29
30
31

Note that Actor-IE relations do not have an id: they are themselves not elements of a GRL model but
rather indicate relations between elements of a GRL model (i.e., intentional elements and actors). The
relation between the Traffic Simulator actor (id = 0) and the Car objects resource (id = 1), for example,
can be formalized as (ActIE, 0, 1).
At this point we have defined all intentional elements in GRL and a containment relation between
actors and intentional elements. We now discuss the GRL links.

34
35• id ∈ N is the unique identifier of the link,• type ∈ LinkTypes specifies the type of the link,• src ∈ N is the identifier of the source IE,• dest ∈ N is the identifier of the destination IE.

A set of links is denoted by Link.

38
39
40
41
42
43

Similar to IEs, links have identifiers as well. Some of the links in our example (Figure 2) are(8, Dep, 4, 1), (9, PosContr, 5, 2) and (11, Decomp, 5, 4).
We can now form GRL models as follows.

46

12
13
14
16
17
18
19
20
21
22
24
25
26
27
28
29
30
31
33
34
35
36

Definition 6 (GRL Model). A GRL model GRL = (IE, Act, RActIE , Link) consists of:• A set IE of intentional elements (Def. 2),• A set Act of actors (Def. 3),• A set RActIE of Actor-IE relations (Def. 4),• A set Link of GRL links (Def. 5).

44
45

11

32

36
37

10

23

Definition 5 (GRL Link). A GRL link is a tuple link = (id, type, src, dest), where:

32
33

8

15

23
24

6

9

• type = ActIE states that this tuple is an Actor-IE relation,• i ∈ N is an id of an actor,• j ∈ N is an id of an IE.

15
16

5
7

Definition 4 (Actor-IE Relations). An Actor-IE relation is a tuple (type, i, j), where:

9
10

3
4

We can formalize the actor in our example (Figure 2) as (0, Actor, Traffic Simulator).
The relation between actors and their intentional element is formalized as follows.

7
8

1

37
38
39
40
41
42
43
44

The full specification of Figure 2 is as follows.

45
46

20

M. van Zee et al. / RationalGRL

1

1

2

IE =

3

{(1, Resource, Car objects),

2
3

4(2, Softgoal, Realistic simulation),

45(3, Softgoal, Simple design),

56
7(4, Softgoal, Easy to use),78(5, Goal, Generate cars, XOR),

8

9(6, Task, Create new cars),

10
11(7, Task, Keep same cars)}

12

6

9
10
11
12

13

Act =

{(0, Actor, Traffic Simulator)}

13

14

RActIE ={(ActIE, 0, 1), . . . , (ActIE, 0, 7)}

14

Link ={(8, Dep, 4, 1)

16(9, PosContr, 6, 2)

17

15
16
17
18

15

(10, NegContr, 6, 3)

19(11, Decomp, 6, 5)

20
21(12, Decomp, 7, 5)}

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

41
42

19
20
21
22
23

Definition 6 only sums up the elements of the model and not the constraints that make a valid GRL
model. We will do so in the next definition. Note that in this definition, we use a subscript notation torefer to an element with a specific id. That is, IEi , Linkj , and Actk refer respectively to the IE with id i,
the link with id j, and the actor with id k.

24
25
26
27

Definition 7 (Valid GRL Model). A GRL model GRL = (IE, Act, RActIE , Link) (Def. 6) is a valid GRL
model5 iff the following conditions are satisfied:28(1) ids are globally unique across IEs, Links, and Actors, i.e., let X, Y ∈ {IE, Act, Link}. For all Xi
and Y j : if i = j then X = Y and Xi = Y j .
(2) Intentional elements of actors exist: ∀(ActIE, i, j) ∈ RActIE : ∃acti ∈ Act ∧ ∃ie j ∈ IE.
(3) An intentional element belongs at most to one actor: ∀iei ∈ IE : |{(ActIE, j, i) ∈ RActIE }| 6 1.
(4) Links connect intentional elements: ∀(i, type, j, k) ∈ Link : {ie j , iek } ⊆ IE.

31

Let us briefly verify that our previous formalization of Figure 2 satisfies all the constraints of Definition 7:

37

39
40

18

29
30
32
33
34
35
36
38
39

(1) All elements in the formalization have different ids, so this constraint is satisfied.
(2) RActIE contains one element for each IE with id i, so this constraint is satisfied as well. Note that,in line with the GRL metamodel, RActIE does not relate links with actors.

43

40
41
42
43

5

44
45
46

Note that validity is a bit of an overloaded term and has different meanings in different areas of research. In our setting, avalid model simply means that certain criteria are satisfied. It does not imply any real world “validation”, in the sense that themodel makes sense in the “real world”.

44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5

21

(3) There is one actor (id = 0) and this is the only actor that appears in RActIE so this constraint issatisfied.
(4) All links connect IEs: the contribution links connect elements with ids 2, 3, and 6, which are all
IEs; the decomposition links connect elements with ids 5, 6, and 7, which are all IEs; and thedependency link connects id 1 with 4, which are both IEs.

6
7

10
11
12

2
3
4
5
6

5.2. Formal Specification of RationalGRL

8
9

1

7
8

In order to develop a logical framework for RationalGRL, we extend the GRL logical framework of
the previous section by adding two elements (see Figure 5), namely generic arguments and attack links.
We illustrate the new elements using the RationalGRL model in Figure 13, which is an extension of
Figure 2.

9
10
11
12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32

32

33

33

34

34

35

35

36

Fig. 13. Example RationalGRL Model (Extension of Figure 2).

36

37

37

38

38

39

Definition 8 (Generic Argument). A generic argument is a tuple ga = (id, type, name), where:

40
41
42
43
44
45
46

39
40

• id ∈ N is the identifier of the generic argument,• type = GenArg states that the tuple is a generic argument,• name ∈ Names is a string description of its name.

A set of generic arguments is denoted by GA.

41
42
43
44
45
46

22
1
2
3
4
5

M. van Zee et al. / RationalGRL

Thus, a generic argument is any element in the RationalGRL model that is not an intentional element or
an actor. In the example, some of the generic arguments are (13, GenArg, Redundant) and (14, GenArg,
Necessary). Note that a constraint of a GRL model (Definition 6) is that GRL links should connect IEs,
which means that in generic arguments cannot be connected with GRL links.
We can now define arguments.

6
7

10
11
12
13
14

Definition 9 (Argument). An argument A is on of the following tuples:

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

• An intentional element ie (Def. 2),• An actor act (Def. 3),• An Actor-IE relation rActIE (Def. 4),• A link link (Def. 5),• A generic argument ga (Def. 8).

34This definition captures the specification in the RationalGRL metamodel (Figure 6) in which the class
Argument is a superclass of GenericArgument and GRLModelElement. In sum, we define an argument
as any one of the GRL IEs or links, or a generic argument. This corresponds with the argument schemesin Table 2: an argument that is a GRL model element, can be seen as a claim that this element should bepart of the model.
Examples of arguments in Figure 13 are A5 = (5, Goal, Generate cars, AND), A05 = (5, Goal, Generate cars, XOR), A4 = (4, Softgoal, Easy to use) and A13 = (13, ArgElem, Redundant). Note that thetwo arguments A5 and A05 show an important difference between RationalGRL models and valid GRL
models: While a valid GRL model disallows multiple elements with the same identifier (Definition 7,
condition 1), RationalGRL models do not enforce this restriction. This is because it is possible to create
multiple arguments for the same element, where each argument contains different content for the sameelement. However, the set of accepted elements in a RationalGRL should all have unique identifier (seeDefinition 15).
Definition 10 (Attack Link). Given a set of arguments Arg, an attack link att = (Ai , A j ) means:

39
40
41
42

45
46

9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
33
34
36
37

As an example, take the arguments A5 for the goal ‘Generate cars’ (AND decomposition), A05 for thegoal ‘Generate cars’ (XOR decomposition), A4 for the softgoal ‘Easy to use’ and the generic argument
A13 (‘Redundant’) against the softgoal (‘Easy to use’). Given these arguments, there are two attack links(Figure 13), namely (A05 , A5 ) and (A13 , A4 ).
We now define a RationalGRL model.

43
44

7

35

A set of attack links is denoted by Att.

37
38

5

32

• Ai ∈ Arg is the argument performing that attack,• A j ∈ Arg is the argument being attacked.

35
36

4

15

32
33

3

8

15
16

2

6

8
9

1

38
39
40
41
42
43

Definition 11 (RationalGRL Model). A RationalGRL model RatGRL = (Arg, Att) consists of a set ofarguments Arg (Def. 9) and a set of attack links Att (Def. 10).

44
45
46

M. van Zee et al. / RationalGRL
1
2
3

23

The definition of a RationalGRL model collects all the previously defined GRL and RationalGRL
elements in a single definition. For completeness, we now provide the full specification of Figure 13. Let
us first enumerate all the arguments used in this example:

1
2
3

4

4

5

5

6
7
8
9
10
11
12
13
14
15
16
17

A0 =(0, Actor, Traffic simulator)
A1 =(1, Task, Car objects),
A2 =(2, Softgoal, Realistic simulation),
A3 =(3, Softgoal, Simple design),
A4 =(4, Softgoal, Easy to use),
A5 =(5, Goal, Generate cars, AND),
A05 =(5, Goal, Generate cars, XOR),
A6 =(6, Task, Create new cars),

6
7
8
9
10
11
12
13
14
15
16
17

18

A7 =(7, Task, Wrap cars),

18

19

A07 =(7, Task, Keep same cars),

19

21

A8 =(8, Dep, 4, 1),

21

22

A9 =(9, PosContr, 6, 2),

22

24

A10 =(10, NegContr, 6, 3),

24

25

A11 =(11, Decomp, 6, 5),25

27

A12 =(12, Decomp, 7, 5),27

28

A13 =(13, GenArg, Redundant),

28

29
30

A14 =(14, GenArg, Necessary),30

31

A15 =(15, GenArg, No effect),

31

32
33

A16 =(16, GenArg, Changes traffic flow),33

34

A17 =(ActIE, 0, 1), . . . , A23 = (ActIE, 0, 7 )

34

20

23

26

35

20

23

26

29

32

35

36

36

37

37

38

This model is then formalized as RatGRL = (Arg, Att) where:

39
40

39

41

Arg ={A0 , . . . , A5 , A05 , A6 , A7 , A07 . . . , A23 }42

Att ={(A05 , A5 ), (A07 , A7 ), (A13 , A4 ), (A14 , A13 ),

43
44

38

(A15 , A9 ), (A16 , A15 )}

40
41
42
43
44

45

45

46

46

24
1
2
3

M. van Zee et al. / RationalGRLIn Figure 13, it can be read from that arguments A5 , A7 , A13 and A15 are currently disabled (rejected).
However, we have not yet make it clear how exactly this is computed. We will do so in the following
definitions. In order to compute when an argument is accepted and when it is not we use argumentation

4

A'5

A5

A14

A13

6

7

A4

8
10

14
15
16
17
18
19
20
21

Definition 12 (Argumentation Framework). An argumentation framework AF = (Arg, Att) consists of aset of arguments Arg and a set of attack relations Att ⊆ Arg × Arg.
Note that the definition of a RationalGRL model (Definition 11) is exactly the same as the definition
for an argumentation framework. This allows us to use the following definitions directly.
Definition 13 (Attack, conflict-freeness, defense, admissibility, grounded extension). Suppose an argumentation framework AF = (Arg, Att), two sets of arguments S ∪ S 0 ⊆ Arg, and some argument A ∈ Arg.
Then:
• S attacks A if some argument in S attacks A,• S defends A if for each B such that B attacks A, S attacks B,• S is conflict-free if there are no A1 , A2 ∈ S such that (A1 , A2 ) ∈ Att,
• S is admissible if S is conflict-free and defends each argument in it.
• S is a complete extension if it is an admissible set that contains all the arguments that it defends.
• S is the grounded extension if it is the minimal (with respect to ⊆) complete extension.

23
24
25
26
27
28
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

9
10

semantics. We use the standard approach by Dung [10].

22

29

7
8

Fig. 14. Example argumentation framework, subset of the RationalGRL model from Figure 13.

9

13

3
5

6

12

2
4

5

11

1

Let us explain these definitions using the example argumentation framework, in Figure 14, which is asubset of our RationalGRL model from Figure 13, containing only arguments A4 , A5 , A05 , A13 , and A14 .
In this example, there are five admissible sets: {A05 }, {A14 }, {A05 , A14 }, {A4 , A14 } and {A4 , A05 , A14 }. In
the admissible sets that contain both A4 and A14 , we say that A14 defends A4 against its attacker A13 6 .
Sets containing both A5 and A05 , or both A13 and either A4 or A14 are not conflict free. Sets containing A5
are not admissible, as they do not defend A5 . Similarly, sets containing A4 but not A14 are not admissible
as they do not defend themselves against A13 .
The notion of admissible sets gives rise to various possible extensions of an argumentation framework;
we use the grounded extension, which is the minimal admissible set that contains all the arguments it
defends all the arguments. In Figure 14, there is one grounded extension, namely {A4 , A05 , A14 }. Notethat there are many more semantics and types of extensions in the literature. However, for current purposes the grounded semantics are sufficient, also because the algorithms in Section 5.4 do not generatemutually attacking arguments.
The status of arguments can now be determined based on the grounded extension. Recall from themetamodel (Figure 6) that an argument can be accepted or rejected.
6

In the argumentation literature, argument A14 is often said to reinstate argument A4

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

25

Definition 14 (Argument Acceptability). An argument is accepted w.r.t. an argumentation framework
AF if it is in the grounded extension of AF, and rejected if it is not in the grounded extension of AF.
In Figure 14, we have that arguments A4 , A05 and A14 are accepted and arguments A5 and A13 arerejected. Returning to our larger example from Figure 13, we can see that arguments A5 , A7 , A13 andA15 are rejected and all the other arguments are accepted.
5.3. Translating between RationalGRL and GRL
Now that we have formalized both GRL and RationalGRL models, we present algorithms to translate
between these two models. Both of these two translation algorithms are straightforward, which is resultof the fact that the two models are formalized in a very similar way.
We start with the translation algorithm from GRL to RationalGRL, which is shown in Algorithm 1.
The translation algorithm takes a GRL model GR = (IE, Act, RActIE , Link) (Definition 6) as an input. On
line 2, it collects all the elements of the GRL model into a set Arg, which represents the set of argumentsof the RationalGRL model. On line 3, the set of attack links is initialized with an empty set, and the new
RationalGRL model (Arg, Att) is returned on line 4.
The translation from a RationalGRL model to a GRL model is given in Algorithm 2. First. the arguments are each put in the corresponding GRL component sets. The procedure ComputeExtensions(Arg, Att)(line 2) computes the (grounded) extensions of the RationalGRL model (Definition 13). A GRL modelis then generated from the grounded extension. This is done by iterating over all arguments in the extension in line 5. The switch statement on line 6 then does a case distinction on the type of the arguments –here, Arg.type refers to the type element in an argument tuple Arg – and each case ensures the argument
is put in the right GRL component. Finally, the algorithm returns a GRL model on line 16. As an example, compare the RationalGRL model in Figure 13 to the GRL model in Figure 2, where the latter is atranslation of the former.
While we have defined a notion of a valid GRL model (Definition 7), we have not yet done the samefor a RationalGRL model. We define a RationalGRL model as valid if and only if the RationalGRL to
GRL translation results in a valid GRL model. Thus, we do not have to reiterate all conditions on a GRL
model, but use the translation algorithm.

30
31
32

Definition 15 (Valid RationalGRL Model). A RationalGRL model RatGRL = (Arg, Att) (Def. 11) is avalid RationalGRL model iff ToGRL(RatGRL) (Algorithm 2) is a valid GRL model (Def. 7).

37
38
39
40
41
42
43
44
45
46

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33

5.4. Algorithms for Argument Schemes and Critical Questions

35
36

2

30

33
34

1

34
35

We have now formalized a static representation of the RationalGRL framework. In this section, we
formalize algorithms for applying argument schemes and critical questions. These algorithms are applied
to RationalGRL models (Definition 11) and produce new arguments and attack relations.
Algorithm 1 GRL to RationalGRL Translation
1: procedure ToRationalGRL(GRL)2:
Arg ← IE ∪ Act ∪ RActIE ∪ Link
3:
Att ← ∅
4:
return (Arg, Att)
5: end procedure

36
37
38
39
40
41
42
43
44
45
46

26
1
2
3
4
5
6
7
8
9
10
11
12

M. van Zee et al. / RationalGRLAs discussed in Section 4, the argument schemes and critical questions of Table 2 all lead to one ofthree operations: INTRO introduces a new RationalGRL element and DISABLE creates a new argumentthat attacks another argument. The REPLACE operation can be seen as a combination of INTRO andDISABLE: a new argument corresponding to a GRL element is added and this new argument attacks
a previous version of the element or link. We will discuss all three operations in separate subsections
below.
In all of the following algorithms, we assume that:• The algorithms are applied to some valid RationalGRL model RatGRL (Definition 15),• The procedure mintId() generates a new unique id.

5.4.1. INTRO Algorithms
The following arguments schemes and critical questions of Table 2 fall into this category:

13
14
15

18
19
20
21
22
23
24

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

3
4
5
6
7
8
9
10
11
12
14
15
16

These type of algorithms are short, and consist simply of adding an argument for the element that isbeing added. We illustrate this with a single example algorithm for AS5.
We have slightly reworded critical question AS5 in Algorithm 3. We assume that a goal G exists
already with identifier i, and that some new task with name T is a decomposition of G. In the algorithm,
on line 2 a unique identifier is created for the task, which is created on line 3. On line 4 an argument iscreated for the decomposition link (mintId(), Decomp, i, task_id) (Def. 5, going from the existing goalwith identifier i to the new task with identifier task_id. On line 5 the two arguments are added to the setof arguments Arg.

25
26

2

13

• AS0-AS12• CQ5b, CQ6b, CQ6c, CQ7b, CQ9, CQ10b

16
17

1

17
18
19
20
21
22
23
24
25

Algorithm 2 RationalGRL to GRL Translation
1: procedure ToGRL(RatGRL)
2:
Ext ← ComputeExtensions(Arg, Att)
3:
for E ∈ Ext do
4:
IE ← ∅, Act ← ∅, RActIE ← ∅, Link ← ∅5:
for A ∈ E do
6:
switch A.type do
7:case IETypes
8:
IE ← IE ∪ {A}9:case Actor
10:
Actor ← Actor ∪ {A}11:case ActIE
12:
ActIE ← ActIE ∪ {A}13:case LinkTypes
14:
Link ← Link ∪ {A}15:
end for16:
return (IE, Act, RActIE , Link)
17:
end for
18: end procedure

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10

27

As an example, suppose we add the decomposition of goal “Generate cars”, expressed as argument A5 = (5, Goal, Generate cars, AND), into task “Keep same cars”, and suppose we havethe following argument for the goal: . Adding the decomposition can be formalized as executing
AS 5 (5, Keep same cars), and results in two new arguments: A7 = (7, Task, Keep same cars) and A12 =(12, Decomp, 7, 5), which are both added to the set of arguments Arg.
The critical questions of type INTRO are all very similar, with one exception: they require an answer.
For instance, suppose CQ5b: “Does goal G decompose into other tasks?” is answered with: “Yes, namely
into task T ”. In this case, we simply obtain an instantiation of argument scheme AS5: “Goal G decomposes into task T ”, which can be executed with Algorithm 3. This is the same for all the other criticalquestions of type INTRO. Therefore, they are not shown here as well.

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

29
30
31
32
33
34
35

38
39
40
41
42
43
44
45
46

3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Algorithm 3 AS5: Goal with id i decomposes into task T
1: procedure AS 5 (i, T )2:task_id ← mintId()
3:
A1 ← (task_id, Task, T )4:A2 ← (mintId(), Decomp, i, task_id)
5:
Arg ← Arg ∪ {A1 , A2 }6: end procedure

36
37

2

11

5.4.2. DISABLE Algorithms
As discussed before, algorithms of type DISABLE consist of adding a new argument attacking an
existing argument. The argument that is added is not an argument for a GRL element or link, but it israther a generic argument (Definition 8).
In the following algorithm, we assume the critical question is answered affirmatively, as indicated in
the right-most column of Table 2. For instance, for critical question CQ0 “Is the actor relevant?”, we
assume it is answered with “No”. In this case, an action is required. In contrary, if the answer to thequestion is “Yes”, no action is required.
Algorithm 4 is executed when critical question CQ0 is answered with “No”. First, on lines 2 and 3,
an argument is created for the critical question and added to the set of arguments Arg. Since this argument is not an argument for a GRL element or link, it is formalized as a generic counterargument(mintId(), GenArg, CQ0) (Def. 8). The for loop starting at line 4 then iterates over all arguments foractors, where i is the id of the actor that is no longer relevant. The reason why there could be multipleof such actors is that the actor can be refined by an algorithm of type REPLACE. We will explain this in
more detail in the example below. Then, on line 5, an attack link is created from the generic argument A

27
28

1

28
29
30
31
32
33
34
35
36

Algorithm 4 CQ0: Is actor with id i relevant? No
1: procedure CQ0 (i)2:A ← (mintId(), GenArg, CQ0)
3:
Arg ← Arg ∪ {A}4:
for Aj ∈ {A = (i, Actor, n) | A ∈ Arg} do
5:Att ← Att ∪ {(A, Aj )}6:
end for
7: end procedure

37
38
39
40
41
42
43
44
45
46

28
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

M. van Zee et al. / RationalGRL

to the argument for the actor A j . After executing the algorithm, all existing arguments for the actor withidentifier i are attacked by a newly created argument A.
Consider for example the RationalGRL model in Figures 11, which consists of an actor and a genericcounterargument. Let us reconstruct this model using the application of argument schemes and critical questions to an initially empty RationalGRL model (Arg = ∅ and Att = ∅). The algorithm
AS 0 (Development team) is executed, which results in A1 = {(0, Actor, Development team}). After this,critical question CQ0: “Is the actor Development team relevant?” is answered with “No, because theprofessor develops the software”. We can formalize this as executing algorithm CQ0 (0) (Algorithm 4),
which results in adding a generic counter argument A2 = (1, GenArg, CQ0: Professor develops software)and an attack link (A2 , A1 ). The RationalGRL model now consists of two arguments, and the grounded
extension is {A2 }, which means that the resulting GRL model is empty, because generic arguments are
not translated to GRL.
Algorithms for the remaining critical questions are omitted here since they are not very complex.
5.4.3. REPLACE Algorithms
Recall that REPLACE algorithms create a new argument that attacks all arguments for an existingelement.
While the original critical question CQ5c is specific to the decomposition between a goal and a task,
Algorithm 5 is more generally applicable to the decomposition type of any IE, since all IEs have a

20
21
22

Ask & Answer
Critical Questions

INTRO, DISABLE or REPLACE
elements in RationalGRL model

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
21
22

25
26

Fig. 15. The RationalGRL Development Process.

28
30

4

24

Modify GRL model

26

29

3

23

24

27

2

20

Instantiate
Argument Schemes

23
25

1

27
28

Algorithm 5 CQ5c: Is the decomposition type of element iei correct? No, it should be X
1: procedure CQDecomp (iei , X)
2:
A ← iei3:
A.decomptype ← X
4:
IEArgs ← IEi ⊆ Arg
5:
for {(Ai , Aj ) ∈ Att | Aj ∈ IEArgs} do
6:Att ← (Ai , A)7:
end for8:
for {(Ai , Aj ) ∈ Att | Ai ∈ IEArgs} do
9:Att ← (A, Aj )10:
for Ai ∈ IEArgs do
11:
Att ← Att ∪ {(A, Ai )}12:
end for13:
end for14:
Arg ← Arg ∪ {A}
15: end procedure

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12

29

decomposition type (Definition 2).
Let us go through this algorithm step by step. On line 2, a new argument A is created which is identicalto original IE. On line 3 the decomposition type of the argument is changed to X – here, Arg.decomptyperefers to the decomptype element in an argument tuple Arg. On line 4, the set IEArgs is assigned withall existing arguments for the input IE – here IEi is the set of all IEs with id i. The first two for loops on
respectively lines 5 and 8 ensure that all attack links that existing from and to the previous versions of
the IE are also carried over to the new argument A. Then, in the third for loop on line 10, we add attack
links from the argument that has just been created to all existing arguments for the IE. This ensures thatall previous versions of the IE are not part of the grounded extension, and as a result do not show up in
the resulting GRL model. Finally, one line 14, the new argument is added to the set of arguments.
As an example, take Figure 7. The initial RationalGRL model (before applying CQ10b), can be formalized as follows: RatGRL = (Arg, Att), with Arg = {A1 , A2 , A3 , A4 , A5 } and Att = ∅, where:

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

1
2
3
4
5
6
7
8
9
10
11
12
13

• A1 = (0, Goal, Simulate traffic, AND)
• A2 = (1, Task, Dynamic simulation, AND)
• A3 = (2, Task, Static simulation, AND)
• A4 = (3, Decomp, 1, 0)• A5 = (4, Decomp, 2, 0)

Suppose algorithm CQDecomp (0, XOR) is executed for this RationalGRL model. On lines 2 and 3 a
new argument A6 = (0, Goal, Simulate traffic, OR) is created. On line 4, IEArgs contains all arguments
for element 0, which is {A1 } (note this does not yet include argument A6 , since it is not yet added to
the RationalGRL model). The first two for loops on lines 5 and 8 do not do anything in the case of our
example, since A1 is itself not attack or does not attack any other argument. The for loop on line 10
ensures all previous versions of the element with id 0 are now attacked, which means in our case the(A6 , A1 ) is added to Att. Finally, on line 14 the new argument A6 is added to Arg.
The other REPLACE algorithms are similar to Algorithm 5, which can be used directly for CQ10c.
For CQ12, we should make a small modification: instead of replacing the decomposition type of the IE,
we replace its name. Since this is a very minor modification we do not show it here.

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

30

30

31

31

32

6. The RationalGRL Development Process and Tool

33
34
35
36
37
38
39

33

In previous sections, we have shown how the RationalGRL framework can capture stakeholders discussions, and how interactions between two types of reasoning, practical reasoning and goal modeling,leads to two interlinked models, RationalGRL and GRL models. The previous section contained a formalization of RationalGRL, which forms the starting point of this section. In this section we clarify
how practitioners can actually use the RationalGRL framework by proposing a development process(Requirement 4) and discussing a prototype RationalGRL tool (Requirement 5).

40
41

44
45
46

34
35
36
37
38
39
40

6.1. RationalGRL Development Process

42
43

32

41
42

We propose the development process shown in Figure 15 to develop a RationalGRL model (see [22]).
We assume that the initial GRL models have been created based on requirements specification documents. The rest of the steps are as follows:

43
44
45
46

30
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

M. van Zee et al. / RationalGRL(1) Instantiate Argument Schemes (AS) – Here we start from the list of arguments schemes (Table 2). Whilst discussing the requirements, we select schemes from the list and instantiate them to form
arguments for GRL IEs or links. In this way we build the GRL model by introducing new GRL elements (INTRO). For example, an argument scheme can be "Goal G contributes to softgoal S". When anargument scheme is instantiated, it corresponds to an argument for or against part of a goal model.
(2) Answer Critical Questions (CQs) – After building or modifying the initial GRL model, we ask
the relevant critical questions. Since each element in the GRL model corresponds to an instantiatedscheme, we can look at Table 2) to see which questions are relevant given our GRL model. For example,
for the argument scheme, "Goal G contributes to softgoal S", there are two critical questions as follows:
Does the goal contributes to the softgoal? and Does the goal contributes to some other softgoals?. Whenthe analyst answers a critical question, a new argument scheme may be instantiated. This is done in step(3) when the operation INTRO is executed.
(3) Decide on Intentional Elements and their Relationships – By answering a critical question,
one of the three operations (INTRO, DISABLE or REPLACE) is applied to the GRL model. Any of these
operations impact the arguments and corresponding GRL intentional elements, modifying the initial
GRL model into a RationalGRL model. Recall that INTRO means that a new argument scheme is created.
That means, the current argument related to the critical question does not get attacked. In the case of
DISABLE, the intentional element or its related links are disabled in the model. REPLACE introduces a
new argument and attacks the original argument at the same time. This means that the original elementof the argument scheme is replaced with a new one.
(4) Modify GRL Models – Based on the RationalGRL model of step (3), the GRL model can be
modified: 1) a new intentional element or a new link is introduced; 2) an existing intentional element or
an existing link gets disabled (removed) from the model; or 3) an existing intentional element or link isreplaced by a new one. This results in a new, modified GRL model, which can be used as the basis foranother cycle of the RationalGRL Development Process.
We can continue these four steps until there is no more intentional element or link to analyze or wereach a satisfactory model. In the next section, we will give an example of how our tool can be used
together with the methodology to build a GRL model.

29
30

33
34
35
36
37
38
39
40
41
42
43
44
45
46

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

6.2. The RationalGRL Tool

31
32

1

30
31

The final requirement of our framework is that it has tool support (Requirement 5). This is importantfor various reasons: i) although there are various approaches attempting to combine goal modeling withargumentation, we are not aware of an existing tool support (see Section 8), ii) it allows us to conduct
user studies in the next section, exploring the usability and usefulness of the RationalGRL frameworkcompared to other goal modeling languages, and iii) tool support is an excellent demonstration to showthat our formal framework and algorithms actually work. In this section, we briefly highlight somefeatures of the tool, and we explain some of its current limitations. The tool can be accessed from:www.rationalgrl.com
Tool overview.. The RationalGRL tool is an open-source web-based Javascript application, which runson all modern browsers. It is based on our formalization in Section 5 and provides export functionality to
jUCMNav, using the translation algorithm (Algorithm 2). It contains all of the GRL elements and links,
except for beliefs and actors. We have argued in Section 2.2 that arguments can be seen as an extension
to beliefs, which is the reason why we did not implement them. Actors are also missing, but they will be
added in the future.

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL

31

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23
24

Fig. 16. Overview of the RationalGRL tool.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

23
24
25

When the tool starts, the user is presented with a screen as in Figure 16. This screen shows the paletteof elements and links (top left pane), a canvas on which RationalGRL models can be built (top rightpane), an ‘Export to GRL’ button (bottom left pane), and a details pane of the currently selected elements(bottom right pane). Elements and links can be added to the canvas by selecting them on the left andclicking on the canvas, thus capturing the INTRO operation (Section 5.4.1). This makes it possible tobuild and modify GRL models using the tool.
In total, there are four different types of details panes, which we now explain in turn.

26
27
28
29
30
31
32

IE and links details pane.. Figure 16 shows the details pane for the goal ‘Generate cars’. The user canchange the name of the IE by clicking ‘Rename’, which will update the naming history on the bottomof the pane. The naming history is (simplified) implementation of the REPLACE operation on IEs, since
it is a very simple form of clarification. The main difference with jUCMNav is that we have a renaming
history, so the user can see which names the IE had prior to the current one. If the IE has decomposition
links, the user can change the decomposition type as well. Each IE and link has a set of associated criticalquestions, which can be answered in the details pane by click on the button next to the question.

33

Critical question details pane.. The details pane can be used to answer the critical questions of the
RationalGRL framework (Table 2): Figure 16, for example, shows two critical questions for the goal IE“Generate cars”, namely “Can the goal be realized?” (CQ3) and “Is the goal relevant/useful?” (CQ11).
Consider Figure 17, where the softgoal “Easy to use” is questioned with the relevancy question (CQ11).
It is possible to select the answer and provide an explanation for the answer.

41

34
35
36
37
38
39
40
42
43
44
45
46

32

M. van Zee et al. / RationalGRL

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

Fig. 17. Critical Question Details Pane for “Is the softgoal relevant/useful?”.

12
13
14
15
16

12

If in the example of Figure 17, the user selects “No” and clicks the “Answer question” button. A newargument is then automatically created that attacks the softgoal and the details pane shows the criticalquestion as answered (Figure 18). This is an implementation of a DISABLE algorithm (Section 5.4.2)
similar to Algorithm 4: a new argument is added that attacks the existing argument.

17
18
19
20
21
22
23
24
25
26
27
28
29

11
13
14
15
16
17

Argument details pane.. It is also possible to attack arguments by adding an “Argument” element andan “Attack” link manually. Consider, for example, Figure 19. A new argument “Necessary”, which attacks the previously generated argument based on CQ11, has been added by the user. As the details paneshows, this new argument is not based on a CQ. It is further worth noting that it is possible to provide
further a explanation in argument elements, allowing for more fine-grained rationalizations.
Argumentation semantics.. The RationalGRL tool computes the acceptability of arguments on the fly.
In the example of Figure 18, the original (argument for) softgoal “Easy to use” is rejected because
its only attacker “CQ11 - Redundant” is accepted. However, if we then attack “CQ11 - Redundant”
with a new argument “Necessary”, the original argument for “Easy to use” is again accepted because
its only attacker is rejected (Figure 19). Note that when computing the acceptability of arguments, theRationalGRL tool makes the assumption that there are no attack cycles in the model and that hence there

18
19
20
21
22
23
24
25
26
27
28
29

30

30

31

31

32

32

33

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45
46

Fig. 18. Effect of Answering CQ11: “Is the softgoal relevant/useful?” with “No”.

45
46

M. van Zee et al. / RationalGRL

33

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

Fig. 19. Attacking an Argument with a Generic Argument “Necessary”.

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

16

is one, non-empty grounded extension (cf. Section 5.2) – if the user creates an attack cycle, an error
message is shown.
Argument schemes and critical questions.. The tool contains more argument schemes and critical questions than those that we initially collected in Table 2 – for example, we have added extra critical questions
for contribution links from task to goal, which are not in Table 2. As mentioned before, our table is notmeant to be exhaustive, and it is straightforward to add more argument schemes and critical questions if
necessary.
Export to jUCMNav.. GRL is implemented in the open-source tool jUCMNav [23]7 . jUCMNav isused actively in research, and the tool has been extended in many directions. The jUCMNav tool isimplemented as an Eclipse plugin. While we aim to integrate our framework into jUCMNav in the future,a web-based version of RationalGRL (and GRL) is more suited for current purposes. Since RationalGRL
does not make use of the many features of jUCMNav, we believe a light-weight version, web-based issufficient for our current aims, and may benefit the community in general. Our tool is thus not meant toreplace jUCMNav.
The connection to jUCMNav is maintained in the form of an export function from the RationalGRL
tool to jUCMNav, essentially an implementation of the RationalGRL to GRL translation (Algorithm 2).
RationalGRL models built in the RationalGRL tool can be exported to the .grl file format, which
can be imported in jUCMNav. Note that in order for the GRL models to be rendered correctly, we
recommend using the Graphviz dot8 as the auto-layout tool (this can be selected under “Auto layout
preferences” when importing the file in jUCMNav).
Two examples of this export are provided in Appendix C. Figure 20 shows the model that was discussed earlier in this paper (Figure 13) in the RationalGRL tool. Recall that translating this model to
GRL provided us with the model in Figure 2. This is also what follows from our export: if we export
the RationalGRL model and then import the resulting GRL model in jUCMNav, we get the model in
Figure 21, which is the same as Figure 2.

43
44
45
46

15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

7

http://jucmnav.softwareengineering.ca/foswiki/ProjetSEG.
8
http://www.graphviz.org/.

44
45
46

34
1
2
3
4
5
6
7
8
9
10

M. van Zee et al. / RationalGRL

Our translation and export function uses the argument acceptability as a way of determining the GRL
model. Take for example, the RationalGRL model in Figure 22. A positive contribution is added from
“Keep same cars” to “Simple design”. More importantly, an argument “not enough CPU” has been added
to the model. This argument attacks the “Realistic simulation” softgoal and the “Create new cars” task,arguing that there is not enough processing power for either of these to be feasible in the traffic simulator.
Now, if we export this to GRL, the GRL elements that are rejected or disabled (greyed out in Figure 22)
are not included. This can be seen in Figure 23, where the jUCMNav GRL model that was exported
from the RationalGRL tool is shown. The pair of figures 22 and 23 also nicely shows the added value ofRationalGRL: Figure 22 shows that there can be a larger discussion and rationalization underlying evena fairly simple goal model such as the one in Figure 23.

11
12
13
14
15
16
17
18
19
20
21
22
23

30
31
32
33

36
37
38

In addition to the coding analysis (Section 3), which forms the basis of the RationalGRL framework,
we also performed a user evaluation with 16 expert users. The objective of this evaluation was to determine whether the users found the components of RationalGRL (arguments, argumentation semantics,
critical questions) useful, and whether they found it easier to keep track of and express opinions andbeliefs using RationalGRL compared to standard GRL. Regarding the usefulness of the RationalGRl
features and the to GRL, the following two broad hypotheses follow from our main points in this paper:

41
42
43
44
45
46

6
7
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23

26
28
29
30
31
32
33
34

H1 The components of RationalGRL – arguments, critical questions and determination of the statusof arguments – are a useful extension to standard goal modeling in GRL.
H2 The components of RationalGRL make it easier to express, determine the effect of and communicate to other stakeholders one’s opinions and beliefs about a goal model.

39
40

5

27

34
35

4

25

7. RationalGRL Evaluation

27
29

3

24

25

28

2

11

Limitations.. For usability purposes, the REPLACE operation has been implemented differently than in
our formal framework (Section 5.4.2). In the formal framework, a REPLACE introduces a new argumentthat replaces (and therefore attacks) all previous arguments with the same identifier. Including REPLACE
like this in the tool would mean that, when the name of an element is changed, we would need to render
all the previous versions of the element on the canvas of the tool. Since this would quickly become very
cumbersome, we decided to implement a naming history for each element. For example, in Figure 16,
the goal “Generate cars” was previously named “Add cars”. In this way, a history is kept of how anelement name was clarified without cluttering the model canvas. This feature is currently very limited
and can be extended in various was, for instance by changing the IE type. Similarly, the decomposition
type can be changed in the details pane (Figure 16) without introducing new elements that attack theoriginal ones (cf. Figure 13, where the old decomposition type AND of “Generate traffic” is shown as
an explicit argument).

24
26

1

35
36
37
38
39

In the rest of this section, we will describe our experiment in more detail and further specify thesehypotheses. In addition, we wanted to know some basics about the user experience. The aim was not to
conduct a full user experience study for the RationalGRL tool, but usability could influence the participants ideas about the RationalGRL framework and language – a very nice and easy to use tool tends tomake people more positive towards a particular modeling language, whereas irritations about a bad tool
will lead to a more negative disposition.

40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1

35

7.1. Experiment design

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

2

The idea was to have our participants perform a small modeling task, and then ask them what they
thought of RationalGRL. Thus, our experiment consists of three parts:(1) Explanation: We explain to the participants the basics of the RationalGRL development process
and the RationalGRL tool.
(2) Modeling: We ask the participants to model a summarized discussion in the RationalGRL tool.
(3) Survey: We present the participants with a survey containing questions about the features of RationalGRL, and some questions about the usability of the RationalGRL tool.

35
36

41
42

45
46

7
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
28
29
30
31
32
33

The following questions ask the participants to rate RationalGRL vs. a standard goal modeling language
on a Likert scale from 1 (much more difficult) to 5 (much easier):

9

40

6

27

44

39

5

Q1 Do you think the arguments and counterarguments of RationalGRL are a useful extension to standard goal modeling?
Q2 Do you think the critical questions and answers in the details pane are a useful extension to standard goal modeling?
Q3 Do you think the automatic determination of the status of arguments and elements is a usefulextension to standard goal modeling?

43

38

4

11

Q4 Do you think using RationalGRL instead of a standard goal modeling language makes it easier ormore difficult to for someone to express beliefs and opinions in a goal model?
Q5 Do you think using RationalGRL instead of a standard goal modeling language makes it easier ormore difficult to for someone to determine the effect of beliefs and opinions on the resulting goalmodel?
Q6 Do you think using RationalGRL instead of a standard goal modeling language makes it easier ormore difficult to for someone who is not the original author to understand the goal model?

37

3

The instructions for these three parts are provided in a single document that we sent out to the participants.9 The explanation (Part 1) starts with a general explanation of GRL and standard goal modelingsimilar to the explanation provided in Section 2.2, then briefly discusses the components of RationalGRL(argument, attack, critical questions) and finally the tool is briefly described (similar to Section 6.2). For
Part 2, we provided a small section of a transcript and some context information (see Appendix D)
and asked the participants to model this in the RationalGRL tool and take a screenshot of their final
model. The idea is that the participants act as if they are “present” at a discussion about the early-stage
requirements and are asked to model the goal model corresponding to these requirements.
In order to allow the participants to compare their models to standard GRL models, after the modelingexercise we provide the participants with Figure 2, which models the discussion for Part 2 (Appendix D)
in standard GRL.
For Part 3, we provided the participants with a survey.10 The survey starts with general questions about
the participants (years of experience etc.). The second part of the survey concerns the specific featuresof RationalGRL, asking participants to rate RationalGRL on a Likert scale from 1 (very useless) to 5
(very useful):

33
34

1

See www.rationalgrl.com, page “Empirical Study”
10
https://goo.gl/forms/fDSMUnAV20wy7kbY2

34
35
36
37
38
39
40
41
42
43
44
45
46

36
1
2
3
4
5
6
7
8
9
10

M. van Zee et al. / RationalGRL

We also ask two open questions regarding the strengths and weaknesses of RationalGRL compared
to GRL. The survey further contains questions about the RationalGRL tool user experience, such aswhether it was easy or difficult to get started with the tool and to model the example case. We, furthermore, ask open questions about the strengths and weaknesses of the tool, possible improvements andwhether the participant thinks the tool could be used in practice in future.
In order to test our main hypotheses H1 and H2, we have to formulate the appropriate null hypotheses
and alternative hypotheses. For H1 and H2, we hypothesize that the participants will, on average, rate
the components of RationalGRL as useful (rating 4) or very useful (rating 5) for Q1, Q2 and Q3, and as
making it easier (rating 4) or significantly easier (rating 5) for questions Q4, Q5 and Q6. In other words,
the null hypothesis and alternative hypothesis for H1 and H2 are as follows:

11
12
13
14
15
16
17

20
21
22
23
24
25
26
27
28
29
30
31
32
33

• H10 and H20 : median rating for questions Q1-Q6 is 3 or lower.
• H1a and H2a : median rating for questions Q1-Q6 is higher than 3.

3
4
5
6
7
8
9
10
12
13
14

Note that for each question (Q1-Q6), we can test the null and alternative hypothesis separately, giving
insight into exactly which components of RationalGRL were deemed useful. We set the significancelevel for each hypothesis at α = 0.05.

15
16
17
18

Participants. We asked 16 participants in our network to participate in the experiment. Most of theparticipants were therefore either employed in industry or staff and (ex-)students from university. For
those working in industry, all participants took the experiment outside of working hours to avoid conflictsof interest. Two thirds of the participants had either a PhD or Master degree, 20% a Bachelor degree,
and one respondent responded with “Other”. All but one participant had a year or more experience
with software development. The average experience was 6.2 years (standard deviation 6.7), with 10
participants having less than 5 years of experience, 6 participants having 8 or more years of experienceand one participant having 25 years of experience. The participants also judged themselves to be quite
competent in early-phase requirements engineering: on average they gave themselves a rating of 3.2 outof 5 (standard deviation 1.3) with half of the participants claiming they were at least “competent” (rating4) or “very competent” (rating 5). However, experience with goal modeling languages was markedly
less: the average rating was 1.9 (standard deviation 1.3), with 9 participants claiming never used a goalmodeling language (rating 1), and only two participants displaying regular use (monthly, rating 4, or
weekly, rating 5). The participants that had experience with goal modeling languages had mostly used i*(5 users), with 2 users being familiar with GRL and 2 users having used another goal modeling language.

34
35

2

11

18
19

1

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

7.2. Results

36

36

37

37

38
39
40
41
42
43
44

Q1
Q2
Q3

very useless
0 (0.0%)0 (0.0%)0 (0.0%)useless0 (0.0%)3 (21.4%)
0 (0.0%)neutral
3 (21.4%)
3 (21.4%)
2 (14.3%)

useful8 (57.1%)
6 (42.9%)
7 (50.0%)

very useful
3 (21.4%)
2 (14.3%)
5 (35.7%)

median
4
4
4

mode
4
4
4

Table 3
Participant ratings and statistical results of the usefulness of the components of RationalGRL

p-value
0.00050.11330.0002

38
39
40
41
42
43
44

45

45

46

46

37

M. van Zee et al. / RationalGRL
1
2
3
4
5
6

Q4
Q5
Q6

very difficult
0 (0.0%)0 (0.0%)0 (0.0%)difficult0 (0.0%)0 (0.0%)1 (8.3%)neutral
4 (30.8%)
6 (46.2%)
4 (33.3%)easy
4 (30.8%)
5 (38.5%)
7 (58.3%)

very easy
5 (38.5%)
2 (15.4%)
0 (0.0%)median
4
4
4

mode
5
3
4

p-value
0.00200.00780.0352

Table 4
Participant ratings and statistical results of whether the components of RationalGRL make reasoning about a goal model easier

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
2
3
4
5
6
7

First, the participants had to perform the modeling task. They produced RationalGRL models containing on average three arguments (in addition to goals, tasks, etc.) from the short transcript. Some of theexamples of RationalGRL models, created by the users, can be found in Appendix D.1.11
After the modeling task, the survey questions were asked. We first asked the participants some questions about user experience. The users where generally positive about RationalGRL’s clear User Interface (UI), the fact that the tool gives a nice overview of the goals and opinions in a case and that it
was straightforward to use and understand. With respect to weaknesses and improvements to the RationalGRL tool, the users mentioned additional UI functionalities such as the possibility to save models, having an “undo” function, and flipping the arrow after adding them. Users also suggested various
language-related improvements. Some users mentioned they missed the possibility to attack links, whileothers mentioned that not all GRL elements are supported (for instance, it is currently not possible to
add actors).
The next set of questions concerned the specific features of the RationalGRL modeling language
and the difference with standard goal modeling languages. Table 3 shows the respondents’ answers toquestions Q1-Q3, and Table 4 shows the answers to questions Q4-Q6. We concluded with two open
questions about the comparison between RationalGRL and other goal modeling languages. When asked
about the advantages of RationalGRL over standard goal modeling languages, many users agreed thatmaking arguments explicit may force end users to have a more structured discussion: “Yes, having thepossibility to add arguments seems quite useful”, ‘Generally I think its useful to explicitly document
arguments of a discussion”, “Clear communication about argumentation and forcing people to thinkin those clear terms.”, “...you can add arguments and that you can answer questions that help you todevelop arguments”, “It’s useful that discussion and explanation are close to the diagrams”, “a way tosee how decisions are being shaped.”. Furthermore, one user stated that RationalGRL successfully “tries
to capture the rationale behind the modeling process’ and “has a simple way to compute the status of thearguments”.
When asked about the weaknesses, users mentioned the complexity as the most important weakness:“The apparent increase in complexity might lead to negative perceptions”, “adding yet another layer ofcomplexity scares me”. The concern that the modeling process may involve too much cognitive overhead was mentioned a few times though: “I think the overhead of inputting a (detailed) discussion ina structured manner into any system makes adoption difficult”, “the manual input is too complex andtakes too much time. An automated process of parsing the conversation log would be much more helpful”, and “I still believe in the value of arguments, but there should be less confusing ways to capturethem”. One user mentioned that complexity and cognitive overload is a problem with goal modelingin general: “Goal models are already complex (...) I have worked for years on the effect of context on
goal models, and my conclusion is that this was very interesting academic work but with close-to-zeropractical implications, unfortunately.”.
11

The full results of the survey can be downloaded from www.rationalgrl.com, on the page “Empirical study”.

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

38
1

M. van Zee et al. / RationalGRL

7.3. Analysis of Results

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
2

Hypothesis H1. The first analysis concerns hypothesis H1, whether the components of RationalGRL –i.e. arguments, critical questions and determination of the status of arguments – are a useful extension to
standard goal modelling in GRL. Table 3 summarizes the medians, modes, and p-values for a one-tailed
single-sample sign test for the relevant questions Q1-Q3. We chose the simplest non-parametric test
available so as to have to take as few assumptions as possible w.r.t. the distribution of answers for eachquestion. As it is evident from the results, the participants were generally positive about the componentsof RationalGRL. For Q1 and Q3 the p-values are both significantly lower than α = 0.05, which meansthat for these questions we can accept H1a and reject H10 . This means that the addition of arguments
and the use of arguments to determine the acceptability of elements of the goal model are deemed to be
useful to very useful by the participants. As can be seen in Table 3: no participant found the addition ofarguments and argument status useless or very useless, and 78.6% (Q1) respectively 85.7% (Q3) foundthe new components useful or very useful. Furthermore, these findings fit with the answers to the open
questions (see Section 7.2). For Q2, the p-value indicates that the result is not significant with α = 0.05,
which means we cannot reject the null hypothesis H10 . This means that the participants did not think
the addition of critical questions like to the RationalGRL tool was significantly useful. Thus, we can saythat the addition of critical questions is perhaps not as useful as we had hypothesized. This again fits thedescriptive statistics in Table3: 21.4% of respondents found critical questions “useless”. Furthermore,in the open questions a number of participants indicated that the exact difference between some of thecritical questions was unclear, and that some of the critical questions seemed unnecessary, at least forthe small modeling exercise given in the experiment.

3

Hypothesis H2. The second hypothesis states that components of RationalGRL make it easier to express one’s opinions and beliefs about a goal model, determine the effect of one’s opinions and beliefs
about a goal model and communicate one’s opinions and beliefs about a goal model to other stakeholders. Table 4 provides a summary of the statistical analysis of the relevant questions Q4-Q6. As can beseen, all the scores are significantly higher than the median of 3 for α = 0.05, which means that we
can accept H2a and reject H20 for all the separate questions Q4-Q6. In other words, the fact that theparticipants rate the components of RationalGRL as making it, on average, easier to reason with theirbeliefs and opinions about a goal model is very unlikely to be due to chance.
With respect to Q4, participants stated that arguments make it much easier to express their opinions.
None of the participants found expressing their beliefs (much) more difficult, and 69.3% found it easieror much easier. This corresponds to the answers to Q1, where participants said the arguments were auseful addition. For Q5, participants agree that RationalGRL makes it easier to determine the effect of
one’s beliefs on the goal model. Combining this with the results for question Q3, which asked about theusefulness of determining the status, we can say that the participants overall found this a useful feature
which makes working with conflicting beliefs easier. One participant remarked that “The reasoning [inthe example] seems simplistic [...] the added value of [the formal argumentation] would be justified if thereasoning is more complex”. Thus, the simplistic case in the modeling exercise possibly detracts from theresults for Q5 and Q3. Finally, participants were less sure that arguments would help in communicating
the goal model to others. This may be due to the fact that in the experiment, communication of opinions
to others was not really tested, leaving the participants to guess what this effect would be.

25

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1

39

7.4. Threats to validity

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

2

Internal validity is about the validity of the experiment results given our experiment setup and interpretation of findings. The main threat here is that the modeling task the participants were asked to do is
not realistic. The task is quite small, and based on an existing transcript of a requirements discussion.
In a realistic setting, users of RationalGRL would model much more complex requirements together
with the stakeholders. The problems with complexity and cognitive overload only start to play a role forlarger models, so while the participants were generally positive in the ranking questions Q1-Q6, somereservations were expressed in the open questions as to whether this approach would work in a realistic
setting.
Another threat to internal validity is that many of the participants had no experience with goal modeling languages at all. Hence, the perceived usefulness of the arguments could be influenced by the factthat the participants, for the first time, were given a goal modeling language to perform structured requirements analysis. In other words, perhaps they found a structured modeling language generally quite
useful. One way to better check the difference between standard goal modeling and RationalGRL would
be to first provide users with a standard goal modeling tool and then have them use RationalGRL. An
even more thorough way to test the usefulness of RationalGRL over, for example, standard GRL would
be to compare a test and control group, where the test group uses RationalGRL and the control groupuses standard GRL. We leave these types of further empirical studies for future research.
External validity concerns the generalizability of the results. As the number of participants is fairly
small (16), this threatens the generalizability of our findings. However, the type of participants is realistic: software engineers having a lot of experience with requirements engineering, as opposed to, forexample, engineering students with little experience. Furthermore, the results are in line with existing
research on design rationale. On the one hand, these existing studies, like our study, show that structured modeling languages suffer from the common problem of high cognitive overhead [24]. One theother hand, these studies show that the inclusion of argumentation and critical questions in design andrequirements discussions improve the reasoning [17, 25].

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

7.5. Discussion
Our results point in some interesting directions for further discussion and research.
(1) Arguments and automatically determining acceptability are useful. Participants were enthusiastic
about adding arguments to a goal modeling language, and they believed the grounded argumentation semantics in the tool are intuitive. This is a positive signal for the addition of techniques fromcomputational argumentation to goal modeling languages: just adding arguments as, for example,
labels on goals and tasks does not allow one to compute the status of elements in a goal modelin the way our approach does. Furthermore, automatically determining the status of elements will
have a bigger impact when working with larger, more complex goal models, for which manually
determining the impact of arguments is not feasible.
(2) Critical questions need to be clear and have a prominent place in the process of building a goalmodel. While participants overall found the critical questions (CQ’s) useful, their impact wasmarkedly less than the addition of arguments. This can have various causes. Participants mentioned they did not use the details pane of the tool, which can be used to ask and answer criticalquestions, that much. Furthermore, it was also mentioned that the difference between different
questions was not always clear. Finally, the experiment task, modeling an existing discussion,

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

40
1
2
3
4
5
6
7

M. van Zee et al. / RationalGRL

may also have influenced the CQ’s perceived usefulness. The CQ’s are meant to be asked during
the actual RationalGRL development process in which goal models are constructed and criticallyanalyzed from scratch.
(3) High cognitive overhead. A concern that was raised often in the evaluation is that, in its current
form, RationalGRL has a relatively high cognitive overhead. Goal modeling is by itself already acognitively high-effort activity, and the fact that we add more elements to the language does not
improve this.

8
9
10
11
12
13
14
15

1
2
3
4
5
6
7
8

Taking the above into account, it seems natural in future work to focus more on the RationalGRL
development process12 . Users like to be guided during modeling phase, and making arguments explicitin the modeling process was indicated as useful, but argumentation should be integrated into the processof goal modeling more than in the goal models themselves, keeping the goal models simple and thus
lessening cognitive overhead. Critical questions are a natural fit for this, as they play a key role in the
RationalGRL development process, but in its current form they are only mentioned in the details paneof the tool.

9
10
11
12
13
14
15

16

16

17

17

18

8. Discussion

19
20

19

8.1. Related Work

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

18
20
21

Design Rationale.. Argumentation in software design has been the subject of research in so-called design rationale (DR) [14, 15], which deals with an explicit documentation of the reasons behind decisions
made when designing a system or software architecture. Already in 1970, the first article on Issue-based
Information Systems ([12]) talked about “argumentative processes” in information system design. IBIS
was further developed in the 80’s and 90’s in the influential work on issue-driven design methods suchas gIBIS [13] (see also [14, 15] for further work on arguments or rationales in software design).
DR looks at issues, options and arguments for and against these options in the design of, for example, a software system. Similar to the literature on goal modeling, much of the traditional DR literatureprovides modeling languages and diagramming tool support for building design rationales. It is in thisdiagramming functionality that the link with argument diagrams from philosophy, law and AI [26, 27]
has been made, where argument diagrams represent reasoning from premises to conclusions. One of the
problems of such methods and tools is the cognitive overload that results from having to learn and use
such tools at the same time as having to discuss and think about complex software designs. Furthermore,
not much of the research on design reasoning has empirically investigated which techniques and how
much information designers use in design reasoning, which information is missing, and how the use ofdesign reasoning techniques affects design discussions and eventually the quality of design discourse.
More recent research on DR, therefore, moves away from the idea that all decisions have to be explicitly diagrammed and focuses more on empirically investigating how critical reflection can help when
designing [17, 25], or which parts of the design process are best explicitly documented [28].
Two relevant articles [29, 30] capture software design processes as argumentation dialogues between
parties. Black et al. [30] provide a more formal rendering of the initial informal ideas by Finkelstein and
12Note that in order to keep the study simple for the users, we did not explicitly ask the respondents to follow the development
process from Section 6.1

22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

41

Fuks [29], and propose a simple argumentation dialogue protocol. Similar to us, they base their argumentation on an analysis of transcripts of software engineers arguing in the Traffic Signal Simulator task
[18]. They provide different argumentative move types, such as propose and challenge (similar to our
critical questions). This preliminary work showed how techniques from computational argumentation
can be applied in software design discussions.
Software design and requirements engineering (RE) are very closely related [31] and hence, the insights from the DR literature are directly applicable to RE – although for reasons unknown, the DR
literature has been largely ignored by the goal-modeling community. The RationalGRL framework essentially incorporates the core ideas from DR into goal-oriented requirements engineering by explicitly
including arguments for and against the various options into a goal model. In this respect, we may seemto go against the trend in DR research to focus less on diagramming and more on guidelines for design
processes. There are two reasons for this: first, as opposed to DR diagramming, goal modeling is still
very much an active area of research [32] with clear practical applications [33]. Secondly, we note that
RationalGRL also includes a development process and critical questions that encourage reflection when
thinking about the possible goals and functionalities of a system, which connects with the research ideas
on DR [17, 25].

1Requirements Engineering.. There are numerous examples in the RE literature that mentions arguments, questions or conflicts in some way. Already in 1997, Smith [34] proposed a framework to develop arguments, which related a model of a proposed software system to a model of its environment,
and showed that these together achieve properties described by a model of requirements. In a similarvein, Lockerbie et al. [35] describe procedures that analysts follow to use satisfaction arguments incombination with i∗. Horkoff and Yu [36] introduce analysis procedures for the i∗ goal-oriented framework, allowing users to ask questions such as “what if?”, or “are certain goals achievable? how? or why
not?”. Finally, Hassin and Amyot [37] analyze the correctness of GRL models by performing statisticalanalysis on generated questionnaires, which allows for early detection of potential conflicts between
stakeholders of the system. The mentioned work, however, does not consider arguments in a similar way
as RationalGRL, that is, to include the explicit opinions of stakeholders.
A number of approaches in the field of requirements engineering take arguments into account explicitly. One early example comes from Haley et al. [38], who use formal logical arguments to showthat the system behavior satisfies certain security requirements, and more informal arguments to capture
and validate the assumptions underlying the system behavior. This system behavior is defined by thetasks it executes and thus, arguments are given for and against system tasks, similar to how beliefs andcounterarguments can be provided for tasks in RationalGRL. What Haley et al. leave implicit in theirargumentation are the goals of the stakeholders on which the system tasks depend – they include thegoals in their framework and mention that there will often be conflicting goals between stakeholders,
but they do not explicitly model them. Furthermore, the argumentative part of their framework does notinclude formal semantics for resolving conflicts among arguments or determining the acceptability ofarguments. Yu et al. [39] further extend the framework proposed by Haley et al., including algorithms
for Dung-style argumentation semantics [10] and a database including specific ways in which to attack(or mitigate) risks. This extension can be likened to a set of critical questions for risks and security
requirements (cf. Yu et al. [39] Section 3.1).
Another recent example of the use of arguments in goal-oriented requirements engineering is the workby Murukannaiah et al. [11], who propose Arg-ACH, where beliefs underlying conflicting goals can bemade explicit using argumentation. Murukannaiah et al. start with the basic technique of Analysis ofCompeting Hypotheses (ACH), where for conflicting goals, beliefs that are consistent and inconsistent

17

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

42
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL

with goals are included in a matrix and counted. They, then, extend this technique into Arg-ACH: instead of just indicating whether a belief is consistent or inconsistent with a goal, each belief becomesan argument for or against a goal, which is, then, modeled using the Carneades tool [27]. Belief scores
are assigned to arguments, which can be aggregated to provide one’s belief in a goal. The arguments
for and against goals can be based on argument schemes, and critical questions can be used to find newarguments for or against the goals or the existing arguments. One example provided in the paper is theargument scheme from expert opinion, which allows one to draw conclusions based on expert statements
and subsequently question, for example, the objectivity and veracity of the expert using critical questions. Murukannaiah et al. conducted an experiment in which two groups, one with ACH and one with
Arg-ACH, performed an analysis of several conflicting goals regarding security at transport hubs. They
found that, while the group that used Arg-ACH took longer, they also covered more possibilities in theirbelief search and the conclusions were more consistent among the group.
Another example of argumentation in RE concerns the use of argumentation in requirements elicitation. Ionita et al. [40] propose a simple argumentation dialogue game in which risk assessors try to
attack each other’s arguments for certain risks attached to a system design. Dung’s semantics [10] arethen used to determine the risks that are still valid, and those that have been successfully rejected. Elrakaiby et al. [41] use argumentation to explain ambiguity. They define when a statement by a client who
is being interviewed about the requirements of a system presents an inconsistency or an insufficiency.
An inconsistency can be either with the client’s previous statements or with the requirement engineer’s
beliefs. An insufficiency occurs when an analyst needs more information from the client to accept aclient’s statement.
It is clear from these literature that arguments play a core role in RE. Murukannaiah et al. [11] showthat critical reflection using argument schemes and critical questions – in the same way that RationalGRL proposes – improves the quality of the reasoning in the RE process. Elrakaiby et al. [41] provide
a case study similar to our research, identifying, many counterarguments specifically with respect to realizability, relevance and clarity (cf. CQ2a, CQ3, CQ11 and CQ12 in Table 2). Similar to RationalGRL,
the use of Dung-style argumentation semantics to compute the acceptable claims in RE is also advocatedby the literature [39–41].
The work on RationalGRL puts the insights from the literature in a broader framework. For example,
there is a specific focus on security requirements [38–40] or the reasoning is about single goals or tasks
instead of about the wider context as represented in a goal model [11, 38, 39, 41]. RationalGRL provides
a generic and extensible framework for arguing about goals and tasks in RE. At the moment, there is onlya “generic argument” in addition to arguments about goals and tasks. However, new argument schemes
and critical questions about, for example, security risks or expert opinions, can be easily added: themetamodel (Figure 6) accommodates this and the formal specification in Section 5 is set up in such a
way that extending the definition of argument and adding new algorithms for specific critical questions
is easy.

1

Goal Modeling.. Argumentation has already been included implicitly in existing goal modeling languages. At its core, goal modeling is a process of argumentation: high-level goals are reasons for lowerlevel goals, tasks and resources. Hence, refinement and decomposition techniques used in requirements
engineering [42] can be seen as explicit argumentation steps in the goal modeling process. Take, forexample, CQ2 of PRAS (Section 2.3), which asks whether there are alternative ways for realizing thesame goal. Providing an alternative subgoal or task in a goal model is, then, an explicit argumentative
move in the discussion. In this sense, a goal model provides a justification for itself. This idea is alsoprevalent in our RationalGRL framework: many arguments are in fact GRL elements, and many critical

38

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

43

questions can be answered by introducing new GRL elements. However, as was already argued in Section 1 (and also by [43]), argumentation produces different, richer and complementary information to
the goal model. The goal model is the product of a process of argumentation, and does not include, forexample, goals and tasks that were at some point considered but discarded. Furthermore, for goal models, it is only possible to determine the satisfiability of goals given the possible tasks and resources; whatcannot be determined is the acceptability of goals, that is, whether they are acceptable (cf. Definition 14
given potentially contradictory opinions of stakeholders).
More explicit rationales for goal models are included in the original GRL specification [3] in the formof belief elements, which can be attached to other intentional elements (goals, tasks). The content ofa belief is a textual description, which can explain, for instance, the rationale for including a goal in amodel. In this regard, they seem like arguments or reasons for the different elements in a goal model.
However, in the literature the precise usage and semantics of belief elements in GRL remain unclear:according to the metamodel [3], they can be connected to other intentional elements (including beliefs)
through any type of link, but in jUCMNav tool, there is a separate belief link for connecting beliefs togoals and tasks only, and beliefs are not used in any of the algorithms to compute the satisfiability ofgoals and tasks. We are also not aware of many examples of the usage of belief elements in the literature.
Thus, GRL belief elements can be understood as metadata that can be attached to an element.
There are further advantages of using RationalGRL over GRL with belief elements. For example, noneof the GRL specifications allows to attach beliefs to other elements, thus it is not possible, for example,
to provide a rationale for why some tasks positively contributes to a goal. Furthermore, the RationalGRL
arguments follow clear schemes with associated critical questions explicitly tailored towards reasoning
about goals and actions or tasks, while beliefs in GRL offer no further guidance as to what kinds ofrationales can be given for elements in a goal model. In addition, beliefs in GRL seem not to influencea goal model in any way. Arguments in RationalGRL, in contrast, play an important role in forming theresulting goal model: if an element is defeated by an argument, it is not part of the resulting goal model.

1

Goal Modeling and Argumentation.. There are several contributions to the literature that explicitly
relate argumentation-based techniques with goal modeling. Bagheri and Ensan [44] and Mirbel andVillata [45] use abstract argumentation frameworks (see Definition 12) to capture individual goals andthe relations between them as modeled in a goal model, so that consistent (i.e., acceptable) subsets ofgoals can be computed using the relevant argumentation semantics [10]. For example, if in a goal model,
there is a conflict between goals G1 and G2 , there is an attack between the arguments representing thesegoals and hence G1 and G2 cannot be in the same extension. Or if there is a dependency link between
G1 and G2 , then G1 should be in every extension G2 is in and vice versa. AND- and OR-decomposition
are also modeled as such, that is, if G3 AND-decomposes into G1 and G2 then G1 and G2 should be inevery extension G3 is in, and if G3 OR-decomposes into G1 and G2 then either G1 or G2 should be inevery extension G3 is in.
Modeling goal models as argumentation frameworks allows the computation of consistent sets ofgoals and tasks in a goal model. In RationalGRL, we have opted not to provide such an argumentationtheoretic semantics to goal models, because GRL already has quite fine-grained satisfiability semantics[3], which take into account conflicts, decompositions and dependencies. RationalGRL focuses on what
is not captured in the work discussed above [44, 45], namely the arguments and beliefs underlying a goalmodel, and the way these arguments and beliefs interact with the elements of the goal model. If desired,however, it would be easy to provide Dung semantics similar to [44, 45] for goal models, as the elementsof a goal model are already arguments in RationalGRL (Figure 6).

27

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

44
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

M. van Zee et al. / RationalGRL

The contribution most closely related to ours is the work by Jureta et al. [43]. Jureta et al. proposea “Goal Argumentation Method (GAM)” to guide argumentation and justification of modeling choices
during the construction of goal models. GAM is a high-level decision process, in which alternative
solutions for an RE problem are evaluated and compared using argumentation. Jureta et al. use a wellknown fictitious example of an argumentative discussion regarding a meeting scheduler, in which a goalmodel is being built by the stakeholders proposing tasks, goals, and alternative solutions for goals. They
include clarification as an important step in their GAM process, and discuss various types of clarity
problems (vagueness, ambiguity, overgenerality, synonymy) and basic techniques for dealing with them(e.g. thesaurus checks, labeling vague expressions).
The GAM process is essentially a generic, high-level process for problem solving, not specificallytailored towards goal modeling. In this sense, the RationalGRL Development Process in Figure 15 canbe seen as a more specific version of GAM explicitly meant for goal modeling. The argument schemes
and critical questions in RationalGRL provide clearer handles for goal modeling (cf. requirement 4 ofour framework, Section 1). Furthermore, the RationalGRL framework adds full tool support for the goalmodeling and reasoning process, which GAM lacks. GAM does contain more specific ways of dealing
with different types of clarity problems; in RationalGRL clarification is captured as a single criticalquestion (CQ12, Table 2). However, as argued above, further critical questions can easily be added to
RationalGRL if needed.
Jureta et al.’s framework also includes an argumentation part, where reasons for conclusions are given
as formal structured arguments13 . Arguments and alternatives are, then, captured as structured arguments
or argument diagrams with reasons for or against goals and tasks. Given these arguments, the set of
undefeated (i.e., acceptable) propositions can be computed to determine which alternative solution to a
problem is acceptable. Thus, the arguments and beliefs underlying a goal model and possible alternativemodelings are captured as formal arguments. In addition, a mapping from goal models to argument
diagrams is given, so that it is possible to start arguing about an already existing goal model.
RationalGRL allows for two-way translation between arguments about goals and standard goal models (cf. Section 5.3). In contrast, Jureta et al. only provide a mapping from goal models to structured
arguments, and the step from structured arguments or argument diagrams to goal models is never formally defined. In previous work on the RationalGRL framework [6, 7], we extended Jureta et al.’s workand translated argument diagrams to GRL models (an automatic translation tool is discussed in [7]).
This gives us two complex diagrams, an argument diagram and a goal diagram, and a mapping between
them. This was, in our opinion, ultimately an unsatisfying solution given the problems and requirements
described in Section 1. One problem is that the argument diagram is at least as complex as the GRL
diagram. This means that any stakeholder trying to understand the discussion has to parse two complex diagrams containing goals, alternative solutions, tasks, and so forth. RationalGRL overcomes thisproblem by integrating argumentation and goal modeling in a single modeling language.

38
39

42
43

46

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
39
40

RationalGRL provides a basic framework for argumentation in requirements engineering, and all aspects of this framework are intended to be fully extensible. We see many open issues to be explored infuture research.

44
45

2

38

8.2. Future work

40
41

1

41
42
43
44

13

there f ore

Informally, a structured argument is similar to the PRAS argument in Section 2.3, i.e., a, b −−−−−→ c.

4546

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

45

Specific domains.. The argumentation schemes and critical questions presented in this paper are focused only on the core goal modeling process, that is, the discussion about the goals and functionalityof an information system. In the RE process, there are many more domain specific discussions that also
take place, such as discussions involving expert opinions [11], discussions about security requirements[38–40], architectural principles [46], legal compliance [47], and so forth. From a knowledge engineering perspective, including argument schemes and critical questions associated with these domains in
the RationalGRL framework is a time-consuming task. However, from a formal perspective adding newschemes and questions is easy: as already discussed by Bex et al. [9], critical questions for argument
schemes always lead to either new information being introduced, new information replacing old information, or new information attacking old information. This corresponds to the INTRO, REPLACE andDISABLE operations in the RationalGRL framework, which have been formalized in Algorithms 3-9 in
Section 5.4, hence it would be suitable for other types of schemes and questions as well.

1

Formal argumentation.. The amount of theory from computational argumentation used in this article
has been relatively small. Our intention is to create a bridge between formal theories in argumentationand the practical tools in requirements engineering. Now that the initial framework has been developed,
however, it is worth exploring what additional techniques computational argumentation has to offer inmore detail. For instance, in our framework, we do not include the possibility of expressing preferences
between mutually inconsistent arguments. Using the work by Modgil [48], it is possible to provide
explicit arguments for preferences, thus allowing us to make a reasoned choice between two options.
Furthermore, it would be interesting to investigate the link between RationalGRL, arguments and argumentation frameworks about goal models, and formal argumentation dialogues from the literature.
Black et al. [49] have already shown that discussions can be captured as such dialogues, and it would
be interesting to look which types of arguments or argument schemes correspond to their different movetypes in design discussions.

13

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

2
3
4
5
6
7
8
9
10
11
12
14
15
16
17
18
19
20
21
22
23
24
25

Belief revision.. An interesting avenue for further investigation is the theoretical foundation of RationalGRL. Since it is one of our main goals to develop a framework that can be used by practitioners, wedeveloped a formalism that is geared towards implementation using algorithms and a compact propositional logic. However, there is a long strand of research in Artificial Intelligence focusing on developing
postulates that characterize how an agent can revise its knowledge base in a rational way [50]. The most
famous postulates are the so-called AGM postulates [51]. It would be very interesting to study whether(a variation of) these rationality postulates can be used to characterize the algorithms we have developedin this article, and more generally, what rationality means in our setting. While there is formal workin Artificial Intelligence on the connections between argumentation and belief revision (see e.g. [50],
there is very little work on applying the combination to requirements engineering. The only work weare aware of that deals with his subject is by Gervasi and Zowghi [52], who use a logical framework forbelief revision to detect inconsistencies in software specifications and then revise those specifications
so that the inconsistencies are removed. They do not explicitly connect their framework to goal models, however, and do not connect their framework to specific argumentation using schemes in the way
RationalGRL does.
Process and tool support.. The current tool is a prototype that implements the RationalGRL framework
in a fairly simple way. That is, by offering the possibility to argue and ask critical questions about a goalmodel, and then export this goal model for further analysis in jUCMNav. Integration of RationalGRL
elements into jUCMNav, or at least creating an import function to import jUCMNav goal models into
the tool would allow us to tap into the large amount of research and development that is being carried

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

46
1
2
3
4
5
6
7
8
9
10
11

M. van Zee et al. / RationalGRL

out with jUCMNav. Furthermore, the tool could be expanded to include new features described above,
such as new argument schemes and reasoning with preferences.
The user evaluation of the tool revealed that in order to implement the tool in realistic settings, we needto incorporate arguments in the goal modeling process in a more collaborative way. Extending the toolfor collaborative online goal modeling, similar to Github is one of the possibilities: since the renaming(i.e. replacement) and deletion (i.e. disabling) of elements are all logged, it is easy for a stakeholder tocontinue working on a model that was made by another stakeholder. In addition, critical questions can be
included for other stakeholders to answer at a later date. As a formal underpinning of this asynchronous
communication between users, it would make sense to capture requirements engineering and software
design processes as dialogues between parties [29, 30], which are natural fit with the question-answer
format employed in the RationalGRL framework.

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

32
33
34
35
36
37
38
39
40
41
42
43

46

4
5
6
7
8
9
10
11
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
29
30

The process of constructing a goal model involves discussions between requirements engineers and agroup of stakeholders. While it is possible to capture part of this discussion process in a goal model, forinstance by specifying alternative solutions for a goal, not all of the arguments can be found back in the
resulting model. This makes it not only more difficult to understand the model, but other stakeholders
may end up having similar discussions throughout the design and development phase as well. Furthermore, the disconnect between goal models and their underlying beliefs and opinions may lead to a poor
understanding of the problem and solution domain.
In order to solve these problems, we present RationalGRL: a framework for integrated goal modelingand argumentation. We extend the well-known goal modeling language GRL with argument schemes
and critical questions that can be used to analyze and guide stakeholders’ discussions about goal models. Furthermore, we provide formal argumentation semantics for the new RationalGRL language. Our
approach, thus, provides a rationalization for the elements of the goal model in terms of underlying arguments, and helps in understanding why parts of the model have been accepted while others have been

44
45

3

28

8.3. Conclusion

30
31

2

12

Empirical validation.. We have performed a coding analysis and found more than 200 occurrencesof arguments and questions. In this study, we performed a simple experiment with 16 participants14
to evaluate the usability and usefulness of RationalGRL compared to other goal modeling languages.
However, what is still lacking is an industrial-strength case study testing extensively whether, and how,the tools and techniques provided by the RationalGRL framework improve early phase requirements
engineering. The complexity of the domain makes focused experiments difficult, but not impossible. For
example, both Murakannaiah et al. [11] and Tang et al. [17] provided a realistic but bounded problem
for their subjects to solve, and similar experiments are imaginable to evaluate RationalGRL: have twogroups solve a goal modeling problem, one using only GRL and one using RationalGRL, and examine how they perform. Naturally, the type of problem will greatly influence the outcome. For a simple
problem which two people have to solve in an hour, RationalGRL will most likely be of little benefit.
However, a more complex problem in which multiple individuals have to work asynchronously might
benefit from the extra tools offered by RationalGRL. Furthermore, the outcome also depends on whichsets of tools and techniques offered by RationalGRL is tested: the development process, the tool, or alist of critical questions to serve as reminders during the goal modeling process.

28
29

1

31
32
33
34
35
36
37
38
39
40
41
42
43
44

14

See page “Empirical study” on www.rationalgrl.com

4546

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

47

rejected. In the introduction, we identified five important requirements for our framework. Below, we
discuss how the RationalGRL framework meets these requirements.
Our list of argument schemes and critical questions in Table 2 was constructed by performing a coding
analysis in which we analyzed 153 pages of transcripts of discussions among designers of a traffic simulator information system. In this way, we ensure that the argumentation techniques capture the actual
discussions of the stakeholders or designers in the early requirements engineering phase (Requirement
1).
The metamodel of the RationalGRL framework in Figure 6 clearly specifies the formal traceability
links elements of GRL goal model and the underlying arguments. (Requirement 2). In addition to thismetamodel, we provide formal semantics for RationalGRL by formalizing the GRL language in propositional logic and rendering arguments about a GRL model as a formal argumentation framework [10].
We, then, formally capture the link between argumentation and goal modeling as a set of algorithms
for applying argument schemes and critical questions about goal models. These formal traceability links
allow us to compute the effect of the arguments and counterarguments proposed in a discussion on a
GRL model (Requirement 3). In other words, we can determine whether the elements of a GRL model
are acceptable given potentially contradictory opinions of stakeholders. Thus, we add a new formal evaluation technique for goal models that allows us to assess the acceptability of elements of a goal model(in addition to their satisfiability [3]).
One of our main goals is to provide means for RE practitioners to capture the underlying argumentsof goal models by using the RationalGRL framework (Requirement 4). To this end, we propose adevelopment process, which consists of developing goal models and posing arguments based on schemesin an integrated way.
Finally, we have implemented the RationalGRL tool, a web-based prototype15 , for modeling argument
schemes and critical questions and for reasoning about goal models with respect to them (Requirement5). We performed a small empirical evaluation with 16 users. The results indicate that while the cognitive overhead of RationalGRL (or goal modeling in general) is high, combining goal modeling withargumentation is perceived as useful. Furthermore, using a formal semantics to compute which arguments and ultimately goal models are acceptable given the stakeholders’ opinions valid argument wasperceived as very useful.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

30

30

31

31

32

References

33
34
35
36
37
38
39
40
41
42
43
44
45
46

32
33

[1] E.S.K. Yu, Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering, in: Proceedings ofthe 3rd IEEE International Symposium on Requirements Engineering, 1997, pp. 226–235. ISBN 0-8186-7740-6. http://dl.acm.org/citation.cfm?id=827255.827807.
[2] E. Kavakli and P. Loucopoulos, Goal Modeling in Requirements Engineering: Analysis and Critique of Current Methods,
in: Information Modeling Methods and Methodologies, J. Krogstie, T.A. Halpin and K. Siau, eds, Idea Group, 2005,
pp. 102–124. ISBN 1-59140-376-6.
[3] D. Amyot, S. Ghanavati, J. Horkoff, G. Mussbacher, L. Peyton and E.S.K. Yu, Evaluating goal models
within the goal-oriented requirement language, International Journal of Intelligent Systems 25 (2010), 841–877.
doi:http://dx.doi.org/10.1002/int.v25:8.
[4] B. Curtis, H. Krasner and N. Iscoe, A field study of the software design process for large systems, Communications of the
ACM 31(11) (1988), 1268–1287.
[5] T.J. Bench-Capon and P.E. Dunne, Argumentation in Artificial Intelligence, Artificial intelligence 171(10–15) (2007),
619–641.

34

15

45

http://www.rationalgrl.com

35
36
37
38
39
40
41
42
43
44
46

48
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL[6] M. van Zee, F. Bex and S. Ghanavati, Rationalization of Goal Models in GRL using Formal Argumentation, in: Proceedings of the 23rd International Requirements Engineering Conference (RE’15), IEEE Press, 2015, pp. 220–225.
http://www.marcvanzee.nl/publications/2015/renext2015_argumentation_for_requirements_engineering2.pdf.
[7] M. van Zee, D. Marosin, S. Ghanavati and F. Bex, RationalGRL: A Framework for Rationalizing Goal Models Using
Argument Diagrams, in: Proceedings of the 35th International Conference on Conceptual Modeling (ER’2016), 2016,
pp. 553–560. http://www.marcvanzee.nl/publications/2016/er2016_rationalgrl.pdf.
[8] D. Walton, C. Reed and F. Macagno, Argumentation Schemes, Cambridge University Press, 2008.
[9] F. Bex, H. Prakken, C. Reed and D. Walton, Towards a Formal Account of Reasoning about Evidence: Argumentation
Schemes and Generalisations, Artificial Intelligence and Law 11(2/3) (2003), 125–165.
[10] P.M. Dung, On the acceptability of arguments and its fundamental role in nonmonotonic reasoning, logic programmingand n-person games, Artificial Intelligence 77(2) (1995), 321–357.
[11] P.K. Murukannaiah, A.K. Kalia, P.R. Telangy and M.P. Singh, Resolving goal conflicts via argumentation-based analysis
of competing hypotheses, in: Proceedings of the 23rd International Requirements Engineering Conference (RE 2015),
IEEE, 2015, pp. 156–165.
[12] W. Kunz and H. Rittel, Issues as elements of information systems, Working Paper, 131, Institute of Urban and Regional
Development, University of California, Berkeley, California, 1970.
[13] J. Conklin and M. Begeman, gIBIS: A Hypertext Tool for Exploratory Policy Discussion, ACM Transactions on OfficeInformation Systems 6(4) (1988), 303–331.
[14] S.B. Shum and N. Hammond, Argumentation-Based Design Rationale: What Use and What Cost?, International Journalof Human-Computer Studies 40(4) (1994), 603–652.
[15] T.P. Moran and J.C. Carroll (eds), Design Rationale, L. Erlbaum Associates, 1996.
[16] K. Atkinson, T. Bench-Capon and P. McBurney, PARMENIDES: Facilitating Deliberation in Democracies, Artificial
Intelligence and Law 14(4) (2006), 261–275. http://dx.doi.org/10.1007/s10506-006-9001-5.
[17] A. Tang, F. Bex, C. Schriek and J.M.E. van der Werf, Improving software design reasoning – A reminder card approach,
Journal of Systems and Software 144 (2018), 22–40.
[18] UCI, Design Prompt: Traffic Signal Simulator, Accessed: 2016-12-27.
[19] L. Chung, B.A. Nixon, E. Yu and J. Mylopoulos, Non-functional requirements in software engineering, Vol. 5, Springer
Science & Business Media, 2012.
[20] J. Saldaña, The coding manual for qualitative researchers, Sage, 2015.
[21] K. Atkinson and T. Bench-Capon, Practical reasoning as presumptive argumentation using action based alternating transition systems, Artificial Intelligence 171(10) (2007), 855–874.
[22] S. Ghanavati, M. van Zee and F. Bex, Argumentation-based Methodology for Goal-oriented Requirements Language(GRL), in: Proceedings of the 10th International iStar Workshop (iStar’17), CEUR Workshop Proceedings, Vol. 1829,
2017, pp. 97–102.
[23] G. Mussbacher and D. Amyot, Goal and scenario modeling, analysis, and transformation with jUCMNav, in: ICSE Companion, 2009, pp. 431–432.
[24] S.J.B. Shum, A.M. Selvin, M. Sierhuis, J. Conklin, C.B. Haley and B. Nuseibeh, Hypermedia support for argumentationbased rationale, in: Rationale management in software engineering, Springer, 2006, pp. 111–132.
[25] M. Razavian, A. Tang, R. Capilla and P. Lago, In two minds: how reflections influence software design thinking, Journalof Software: Evolution and Process 28(6) (2016), 394–426.
[26] C. Reed and G. Rowe, Araucaria: Software for argument analysis, diagramming and representation, International Journal
on Artificial Intelligence Tools 13(04) (2004), 961–979.
[27] T.F. Gordon, Visualizing Carneades argument graphs, Law, Probability & Risk 6(1–4) (2007), 109–117.
[28] D. Falessi, L.C. Briand, G. Cantone, R. Capilla and P. Kruchten, The value of design rationale information, ACM Transactions on Software Engineering and Methodology (TOSEM) 22(3) (2013), 21.
[29] A. Finkelstein and H. Fuks, Multiparty specification, in: ACM SIGSOFT Software Engineering Notes, Vol. 14, ACM,
1989, pp. 185–195.
[30] E. Black, P. McBurney and S. Zschaler, Towards Agent Dialogue as a Tool for Capturing Software Design Discussions,in: Proceedings of the 2nd International Workshop on Theory and Applications of Formal Argumentation, Springer, 2013,
pp. 95–110.
[31] B. Nuseibeh, Weaving together requirements and architectures, Computer 34(3) (2001), 115–119.
[32] E. Gonçalves, M.A. de Oliveira, I. Monteiro, J. Castro and J. Araújo, Understanding what is important in iStar extension
proposals: the viewpoint of researchers, Requirements Engineering (2018), 1–30.
[33] K. Neace, R. Roncace and P. Fomin, Goal model analysis of autonomy requirements for Unmanned Aircraft Systems,
Requirements Engineering 23(4) (2018), 509–555.
[34] S.R. Smith, Constructing and Revising Formal Arguments in Requirements Engineering, Requir. Eng. 2(4) (1997), 199–
216. doi:10.1007/BF02745372.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

49

[35] J. Lockerbie, N.A.M. Maiden, J. Engmann, D. Randall, S. Jones and D. Bush, Exploring the impact of software requirements on system-wide goals: a method using satisfaction arguments and i* goal modelling, Requirements Engineering
17(3) (2012), 227–254.
[36] J. Horkoff and E. Yu, Interactive goal model analysis for early requirements engineering, Requirements Engineering 21(1)(2016), 29–61.
[37] J. Hassine and D. Amyot, A questionnaire-based survey methodology for systematically validating goal-oriented models,Requirements Engineering 21(2) (2016), 285–308.
[38] C.B. Haley, R. Laney, J.D. Moffett and B. Nuseibeh, Security requirements engineering: A framework for representation
and analysis, IEEE Transactions on Software Engineering 34(1) (2008), 133–153.
[39] Y. Yu, V.N. Franqueira, T.T. Tun, R.J. Wieringa and B. Nuseibeh, Automated analysis of security requirements throughrisk-based argumentation, Journal of systems and software 106 (2015), 102–116.
[40] D. Ionita, J.-W. Bullee and R.J. Wieringa, Argumentation-based security requirements elicitation: The next round, in:IEEE 1st workshop on Evolving Security and Privacy Requirements Engineering (ESPRE 2014), IEEE, 2014, pp. 7–12.
[41] Y. Elrakaiby, A. Ferrari, P. Spoletini, S. Gnesi and B. Nuseibeh, Using Argumentation to Explain Ambiguity in Requirements Elicitation Interviews, in: Proceedings of the 25th IEEE International Requirements Engineering Conference (RE2017), IEEE Press, 2017, pp. 51–60. doi:10.1109/RE.2017.27.
[42] A. Van Lamsweerde, Goal-oriented requirements engineering: A guided tour, in: Proceedings of the 5th IEEE International Symposium on Requirements Engineering, 2001, pp. 249–262.
[43] I.J. Jureta, S. Faulkner and P.Y. Schobbens, Clear Justification of Modeling Decisions for Goal-oriented Requirements
Engineering, Requirements Engineering 13(2) (2008), 87–115. doi:10.1007/s00766-007-0056-y.
[44] E. Bagheri and F. Ensan, Consolidating multiple requirement specifications through argumentation, in: Proceedings of the2011 ACM Symposium on Applied Computing, ACM, 2011, pp. 659–666.
[45] I. Mirbel and S. Villata, Enhancing Goal-Based Requirements Consistency: An Argumentation-Based Approach, in: Computational Logic in Multi-Agent Systems - 13th International Workshop, CLIMA XIII, Montpellier, France, August 27-28,
2012. Proceedings, 2012, pp. 110–127.
[46] D. Marosin, M. van Zee and S. Ghanavati, Formalizing and Modeling Enterprise Architecture (EA) Principles with Goaloriented Requirements Language (GRL), in: Proceedings of the 28th International Conference on Advanced Information
System Engineering (CAiSE16), 2016. http://www.marcvanzee.nl/publications/2016/caise2016_eaprinciples.pdf.
[47] S. Ghanavati, Legal-urn framework for legal compliance of business processes, PhD thesis, University of Ottawa, 2013.
[48] S. Modgil, Reasoning about preferences in argumentation frameworks, Artificial Intelligence 173(9) (2009), 901–934.
[49] P. Bellini, R. Mattolini and P. Nesi, Temporal Logics for Real-time System Specification, ACM Comput. Surv. 32(1)(2000), 12–42. doi:10.1145/349194.349197.
[50] M.A. Falappa, G. Kern-Isberner and G.R. Simari, Belief revision and argumentation theory, in: Argumentation in artificial
intelligence, Springer, 2009, pp. 341–360.
[51] C.E. Alchourrón, P. Gärdenfors and D. Makinson, On the logic of theory change: Partial meet contraction and revisionfunctions, The journal of symbolic logic 50(2) (1985), 510–530.
[52] V. Gervasi and D. Zowghi, Reasoning about inconsistencies in natural language requirements, ACM Transactions on
Software Engineering and Methodology (TOSEM) 14(3) (2005), 277–330.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

30

30

31

31

32

32

33

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46

50
1

M. van Zee et al. / RationalGRL

Appendix A. UCI Design Workshop Prompt2
3

2

Design Prompt: Traffic Signal Simulator

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

21

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Requirements
The following broad requirements should be followed when designing this system:

22
23

3
4

Problem Description
For the next two hours, you will be tasked with designing a traffic flow simulation program. Your client
for this project is Professor E, who teaches civil engineering at UCI. One of the courses she teaches has
a section on traffic signal timing, and according to her, this is a particularly challenging subject for her
students. In short, traffic signal timing involves determining the amount of time that each of an intersection’s traffic lights spend being green, yellow, and red, in order to allow cars in to flow through theintersection from each direction in a fluid manner. In the ideal case, the amount of time that people
spend waiting is minimized by the chosen settings for a given intersection’s traffic lights. This can bea very subtle matter: changing the timing at a single intersection by a couple of seconds can have farreaching effects on the traffic in the surrounding areas. There is a great deal of theory on this subject,
but Professor E. has found that her students find the topic quite abstract. She wants to provide themwith some software that they can use to “play” with different traffic signal timing schemes, in different
scenarios. She anticipates that this will allow her students to learn from practice, by seeing first-handsome of the patterns that govern the subject.

19
20

1

20
21
22

(1) Students must be able to create a visual map of an area, laying out roads in a pattern of theirchoosing. The resulting map need not be complex, but should allow for roads of varying length tobe placed, and different arrangements of intersections to be created. Your approach should readily
accommodate at least six intersections, if not more.
(2) Students must be able to describe the behavior of the traffic lights at each of the intersections. It
is up to you to determine what the exact interaction will be, but a variety of sequences and timing
schemes should be allowed. Your approach should also be able to accommodate left-hand turns
protected by left-hand green arrow lights. In addition:

23
24
25
26
27
28
29
30

(a) Combinations of individual signals that would result in crashes should not be allowed.
(b) Every intersection on the map must have traffic lights (there are not any stop signs, overpasses, or other variations). All intersections will be 4-way: there are no “T” intersections,nor one-way roads.
(c) Students must be able to design each intersection with or without the option to have sensors
that detect whether any cars are present in a given lane. The intersection’s lights’ behavior
should be able to change based on the input from these sensors, though the exact behavior ofthis feature is up to you.

31

(3) Based on the map created, and the intersection timing schemes, the students must be able tosimulate traffic flows on the map. The traffic levels should be conveyed visually to the user in areal-time manner, as they emerge in the simulation. The current state of the intersections’ traffic
lights should also be depicted visually, and updated when they change. It is up to you how topresent this information to the students using your program. For example, you may choose to
depict individual cars, or to use a more abstract representation.

40

32
33
34
35
36
37
38
39
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1
2
3
4
5
6
7
8
9
10

51

(4) Students should be able to change the traffic density that enters the map on a given road. For
ex- ample, it should be possible to create a busy road, or a seldom used one, and any variation in
between. How exactly this is declared by the user and depicted by the system is up to you. Broadly,
the tool should be easy to use, and should encourage students to explore multiple alternative
approaches. Students should be able to observe any problems with their map’s timing scheme, alter
it, and see the results of their changes on the traffic patterns. This program is not meant to be anexact, scientific simulation, but aims to simply illustrate the basic effect that traffic signal timing
has on traffic. If you wish, you may assume that you will be able to reuse an existing software
package that provides relevant mathematical functionality such as statistical distributions, random
number generators, and queuing theory.

11
12
13

1
2
3
4
5
6
7
8
9
10
11

You may add additional features and details to the simulation, if you think that they would support
these goals.

12
13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32

32

33

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46

52
1

M. van Zee et al. / RationalGRL

Appendix B. Transcript excerpts

1

2

2

3
4
5
6
7

3

Speaker
0:15:11 (P1)
0:15:34 (P2)
0:15:42 (P1)89
10

0:15:44 (P2)
0:15:45 (P1)1112

0:15:51 (P2)

13
14

Text
Coding
And then, we have a set of actions. Save map, open [20 task (AS2)] Student has tasks “save map”, “openmap", “add intersection", “remove intersection", “addmap, add and remove intersection, roads
road", “add traffic light" [INTRO]
Yeah, road. Intersection, add traffic lights
Well, all intersection should have traffic lights so [21 critical question CQ11 for 20] Is the task “Addtraffic light" useful/relevant?
it’s
Yeah
[22 answer to 21] Not useful, because according to theIt’s, you don’t have to specifically add a traffic
specification all intersections have traffic lights.
light because if you have
[DISABLE]
They needTable 5
Adding tasks, disabling unnecessary task “Add traffic light” (transcript t1 )

15
16
17

20

Speaker
0:22:52 (P1)
0:23:20 (P1)
0:23:41 (P2)

21
22
23
24

0:24:12 (P2)Text
We also have to be able to change the inflow ofcars. How many cars come out in here on the side
So, sets, yeah, car influx.
If you can only control the set amount of influxfrom any side of this sort of random distribution, I
think that is going to be less interesting than when
you can say something like, this road is frequently
travelled.
So setting it per road, I think is something we want

25
27

Text
Yeah. And then two processes,
static, dynamic and they belong to
the goal simulate.

34

38
39
40
41

10
11
12
13
14

18

17
19

[32 critical question CQ12 for 31] Is “Set car influx”
specific enough?

20
21
22
23

[33 answer to 32] No, “Set car influx” becomes “Setcar influx per road” [REPLACE]

24
25
26
27
29

Speaker
0:18:55 (P1)

33

37

9

28

32

36

8

TRO]

29

35

7

16

28

31

6

Coding[31 task (AS2)] Student has task “Set car influx” [IN-

Table 6
Clarifying the name of a task (transcript t1 )

26

30

5

15

18
19

4

0:30:10 (P1)
0:30:12 (P2)
0:30:14 (P3)
0:30:15 (P1)
0:30:18 (P3)

Yeah. But this is- is this an OR oran AND?
That’s and OR
I think it’s an OR
It’s for the data, it’s an OR
Yep

Coding[17 goal (AS3)] System has goal “Simulate” [INTRO][18 task (AS2)] System has tasks “Static simulation”, “Dynamic simulation” [INTRO][20 decomposition (AS5)] Goal “Simulation" AND-decomposes into
"Static simulation" and “Dynamic simulation" [INTRO]

30
31
32
33
34
35

[26 critical question CQ10b for 20] Is the decomposition type of“simulate” correct?
[27 answer to 26] No, it should be an OR decomposition. [REPLACE]

Table 7
Incorrect decomposition type for goal Simulate (transcript t3 )

36
37
38
39
40
41

42

42

43

43

44

44

45

45

46

46

53

M. van Zee et al. / RationalGRL
1
2
3

Respondent
0:10:55.2 (P1)
0:11:00.8 (P2)

4
5
6
7
8
9
10
11
12
13
14

0:18:13.4 (P2)
0:18:18.2 (P1)
0:18:19.8 (P2)
0:18:22.9 (P1)

Text
Maybe developers
Development team, I don’t know. Because that’s- in thiscontext it looks like she’s gonna make the software

Annotation[4 actor (AS0)] Development team
[5 critical question CQ0 for 4] Is actor "development team" relevant?
[6 answer to 5] No, it looks like the professor
will develop the software.

1

I think we can still do developers here. To the system[16 counter argument for 6] According to theYeah?
specification the professor doesn’t actually
Yeah, it isn’t mentioned but, the professor doesdevelop the software.
Yeah, when the system gets stuck they also have to be[inaudible] ok. So development team
Table 8Discussion about the relevance of an actor (transcript t3 )6

Appendix C. From RationalGRL to GRL - Examples from the Tool

2
3
4
5
7
8
9
10
11
12
13
14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32

32

33

Fig. 20. RationalGRL model of Figure 13 modeled in the RationalGRL tool

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46

54

M. van Zee et al. / RationalGRL

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14
15

Fig. 21. Exporting the model Figure 20 to GRL gives the the above model in jUCMNAv

14
15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32

32

33

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45
46

Fig. 22. Adding an argument that attacks multiple GRL elements to Figure 20

45
46

M. van Zee et al. / RationalGRL

55

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29
30

29

Fig. 23. Exporting the model Figure 22 to GRL gives the the above model in jUCMNAv

30

31

31

32

32

33

33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46

56
1

M. van Zee et al. / RationalGRL

Appendix D. Modeling Task - Traffic Controller

2
3
4
5
6
7
8
9

2

A group of three engineers (E1, E2, and E3) is tasked with designing a traffic flow simulation program.
They receive a task specification, focusing on how the simulator will handle the generation of cars in thesimulation. Below is an excerpt discussing the early requirements of the system. You are asked to model
this discussion in as much detail as possible in the RationalGRL tool (http://www.rationalgrl.com), using
all the tools RationalGRL puts at your disposal (GRL elements, critical questions, arguments).
As the RationalGRL prototype does not yet have a save functionality, please save a screenshot of yourfinal model.

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

1
3
4
5
6
7
8
9
10

Person Transcript
E1
Let’s start by adding the actor "Traffic Simulator". Do you think we need to add more
actors?
E2
I don’t think so. Let’s start with the softgoals and derive the main goals and tasks from that.
E3
The task description states that the simulator should be easy to use.
E2
I’m not sure that we should include that. It seems to me this is redundant since any UIshould be easy to use.
E1
No I disagree, for some UI’s it is more important than others, and the fact that they mention
it explicitly in the task description means we should probably add it anyway.
E3
I agree, let’s keep it in, it seems necessary.
E1
Ok so we have one softgoal ’easy to use’. Anything else?
E2
Here it say the simulation should be realistic, and the design should be simple. I guess those
are two softgoals as well.
E3
Ok sounds good. So one goal of the simulation is to Generate cars. Shall we just add thatas a goal?
E1
Yes let’s do that.
E2
I think we then have two main tasks for that goal: The simulator should be able to create
new cars in the simulation, and it should be able to wrap the cars when they go out of thescreen.
E3
So Generate cars AND-decomposes into those two tasks?
E1
I don’t think so actually. I think it is a XOR-decomposition. The simulation either creates
new cars or wrap them when they are being reused.
E2
Hmm makes sense. But then I think we should rename Wrap cars to Keep same cars.
E3
Yes that is better, then Create new cars and Keep same cars are the two alternatives for thegoal Generate cars.
E1
Hmm what do you think about the contribution links? Should we add any?
E2
Well I think if we create new cars, the simulation will be more realistic because it becomesless static. At the same time it will probably make the design less simple.
E3
Yes so create new cars contributes positively to the realistic design, and negatively to simple
design?
E2
Hmm now I think about it, actually I think think creating new cars doesn’t have much effecton the realism of the simulation.I don’t think the user will notice the difference.
E1
Why not? If you create new cars it changes the flow of the traffic, so I think the user willdefinitely notice this.
E2
Okay well, ok maybe. Yes I think you are right. Let’s keep the contribution link in then.

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

M. van Zee et al. / RationalGRL
1

D.1. Example RationalGRL models made by participants

57
1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17
18

17

Fig. 24. Example model 1

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32

32

33

33

34

34

35

35

36

Fig. 25. Example model 2

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46

58

M. van Zee et al. / RationalGRL

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

11

11

12

12

13

13

14

14

15

15

16

16

17

17

18

18

19

19

20

20

21

21

22

22

23

23

24

24

25

25

26

26

27

27

28

28

29

29

30

30

31

31

32
33

Fig. 26. Example model 3

32
33

34

34

35

35

36

36

37

37

38

38

39

39

40

40

41

41

42

42

43

43

44

44

45

45

46

46