Explaining the Goal Argumentation
Method
By A.J.Jansen
Introduction
This paper (Jureta I., 2006a) describes a method to model the arguments and choices made in the
Requirement Engineering (RE) processes for Information Systems (IS). The method is called the Goal
Argumentation Method (GAM) for justifying goal modeling decisions.
The representation of requirements for IS is usually done by goal models such as I-Star Strategic
Relationship (SR) diagram. These goal models describe the desired and undesired behaviors within
the IS. However, it is difficult to extract the reasoning, which led to these models, from the models
themselves. This generates the risk that the goal models are altered after several phases, either
because:



a stakeholder does not know why another stakeholder has made a certain modeling decision,
a stakeholder does not recall the reason for a certain modeling decision
or the reasons for making a certain modeling decision are lost over time.
<?For this the researchers conclude important information, the reasoning which leads to certain
choices, is missing in the RE process and should be added in a structured form.?> GAM provides this
structured form. Possible benefits of such a method are: each element in a goal diagram can be
related to a set of arguments, the justification process can be analyzed and validated and when new
information becomes available, changes in the goal diagram can be easier to understand (Jureta I.,
2006a).
Alternatives
Problem
Analysis
Evaluation
Problem
Statement
Problem Setting
Alternative
Justification
Diagram
Change
Decision
Figure 1: GAM reasoning loop
Generic speaking, GAM creates an argumentation model during the process of the creation of the
goal model. To do this, GAM uses a reasoning loop (figure 1), which starts with a problem statement something the IS should resolve. Then the problem statement is analyzed and several alternative
solutions are offered. These are evaluated at the hand of arguments, which give a justification of the
alternatives. Arguments are marked as pros and cons for the argument. When a full argumentation is
in place, a decision can be made on which alternative is the best to solve the problem statement. The
chosen alternative is then added to the goal model in the form, required by the model’s syntaxes.
From the mentioned arguments, new problem statements can be derived, which in place have
alternative solutions, etcetera. The results from this reasoning loop are displayed in a GAM
reasoning diagram (Jureta I., 2006a).
GAM can be used in three ways called light, normal and advanced. In the light version, the goal
diagram and the reasoning diagram are both constructed and can be shown next to each other. In
the normal mode, the contents of the GAM reasoning diagram are directly related to the contents of
the goal diagram by construction a dialectical tree. Finally the advanced mode was created to allow
tool support to be provided for automated recording and analysis of arguments for goal modeling
decisions. In this mode, a mapping is defined, which translates between a goal diagram and a
dialectical tree (Jureta I., 2006a).
This paper is written by Ivan J. Jureta, Stéphan Faulkner and Pierre-Yves Schobbens, all staff at the
University of Namur, Belgium at the time of writing. This University is currently not on the Shanghai
500 ranking of best universities (Center for World-Class Universities of Shanghai Jiao Tong University,
2012). The main writer Ivan J. Jureta is an associate Professor with his research focus on method
engineering and automation and a total of 456 citations on Google Scholar. The second writer is
associate professor Stépahn Faulkner, with a research focus on requirement engineering and 338
citations on Microsoft Academic Search. The last writer is professor Pierre-Yves Schobbens with a
research focus on requirement engineering and model driven engineering. The professor has 1999
citations on Google Scholar.
An Illustration of the Use of GAM
To illustrate the use of the GAM method, a simple example is provided. In this case, a professor
wants to build a service, in which he offers the lectures, that he and his department gives, online.
This is in case students are ill and through this have to miss a lecture. However, this should not cost
too much, since budget cuts also hit the university. Concerning this, some requirement choices need
to be made. A visual output from the GAM reasoning loop, used in this process in light mode, is
provided in figure 2. The method starts with a main problem statement defined as a goal. Goal: give
students opportunity to follow lectures, if they are ill, in a cost effective way. Now the problem
should be analyzed. From this analysis at least two alternatives should be provided. These are stated
as: Alternative 1: film the lectures and put these online; Alternative two: record lectures and post the
audio together with the slides online. These alternatives are then evaluated and arguments are
provided, which gives a justification of the alternatives. These arguments should be stated in the
form: ArgX+/-, in which the plus and minus give an indication whether the argument is positive or
negative for the alternative. In an argument, it is possible to fit in a counter argument, to make the
argument lose power. All the arguments provided under the alternatives are now used to make a
decision between the alternatives. One alternative is chosen and more problem statements are
derived from the arguments and justification of the chosen alternative. These problem statements
will follow the same reasoning loop, just like the problem statements derived after this, etcetera,
until no problem statements can be derived anymore.
PS1: Sick students should be able to view
lectures in a cost effective way online.
1.Alt1: Film lectures.
1.Alt2: Audio record lectures.
1.Alt1Arg1+: Good quality
lectures for students.
1.Alt2Arg1-: Less quality but
together with slides it is sufficient.
1.Alt1Arg2-: Relatively expensive
equipement needed.
1.Alt2Arg2+: Audio device is
relatively cheap.
1.Alt1Arg3-: Difficult to arrange
due bureaucracy at University.
1.Alt2Arg3+: Audio device is easy to
acquire.
1.Alt2Arg4+: Some lecturers already
has positive experience with audio
devices.
1.Alt2Arg5+: Audio is easier to put
online.
1.Alt2Arg6+: Audio recording
requires little skill.
1.Just2: Alt2 is preferred to Alt 1
by the stakeholders, because
they consider it to require less
effort and less budget.
PS2: Which audio device
should be acquired?
…
PS3: The use of the device
should be promoted.
…
PS4: Web space should be available
for the audio recordings
PS5: Lectures should acquire
skills on how to record audio.
PS6: Shouldn’t there be a
budget estimate that would
take into account user
friendliness and effort in use?
…
…
Figure 2: GAM reasoning loop output in light mode
In figure 3 an example of the output of the GAM reasoning loop in a normal and advanced mode is
provided. In this figure the same output is shown in a dialectical tree with well-formed formulas. In
appendix A, a template for this dialectical tree is provided.
Depend(student, provide(course_website(lecturer))
do(post_on_website(lecturer))
provide(lectures(lecturer))
provide(audiorecording(lecturer))
optimize(easy_to_use(lecturer))
do(audiorecording(lecturer))
achieve(lectures_online(lecturer))
…
do(aquire_audiorecording_skills(lecturer))
Figure 3: GAM reasoning loop output in normal and advanced mode
The next step in the method is the creation of an SR diagram. A basic example of such an SR diagram
for this case is provided in figure 4. This I-Star SR diagram provides the relations between the system
goals, soft goals, tasks, resources and actors. This specific diagram is made in the syntaxes of a Tropos
goal diagram (Castroa J. K. M., 2002). Although this example should be extended when the output of
the reasoning loop is expanded, it gives a clear view on output of the GAM.
When the normal or advanced version of GAM is used opposed to the light version, a dialectical tree
should be provided. Such a dialectical tree consists out of all the arguments mentioned in the
example, ordered in such a way, that all relations between arguments, problem statements and
justifications are put in such a way, that is easily translatable to the I-Star SR diagram. These are then
put in an 'achieve', 'optimize', 'do' or 'provide' form. In the advanced version this dialectical tree can
be translated into code that is useful for tools.
PS1
Lecturer
1.Alt2Arg4:
Easy to use defice
1.Alt2Arg1: Record
Audio
+
PS5
Acquire skills on how to
record audio
1.Alt2Arg6:
Audio records
PS1 provide
lecture online
1.Alt2Arg1:
Lectures
1.Alt2Arg5:
Post on website
PS4
Course website
Student
Figure 4: I-star strategic relationship model
Process Delivery Diagram
To gain deeper insight in this method, a Process Delivery Diagram (PDD) is constructed in this paper
and can be seen in figure 5. A PDD is a diagram containing an activity overview on the left side and an
overview of the deliverables on the right side. The activities are explained in the Activity Table. All
the deliverables are explained in the Concept Table (van de Weerd I., 2009).
An important side note to be placed is, that the PDD presented here is based on the Advanced Mode
of GAM and thus the PDD is more extensive and complicated then if it would be based on the Light
Mode or the Normal Mode.
In table 1 the Activity Table is shown. In this table all the actions, used on the process side, are
explained. The process side is the left side of the PDD.
Finally, in table 2 the Concept Table is shown. In this table all the used concepts, used on the right
side, are shown.
SITUATIONAL PROBLEM
CASE
1
Problem setting
based on
0..*
Set Problem
PROBLEM STATEMENT
1
1
1
Create a dialectical tree for the
problem statement
Stakeholder
DIALECTICAL TREE
1
solves
1..*
Add alternatives to the dialectial
tree Stakeholder
ALTERNATIVE
1..*
1
Values
1..*
Evaluate
ARGUMENT
Add arguments to the dialectical
tree
1..*
Description
Support value
Label the dialectical trees
LABEL
[More undefeated
trees exist]
1
c
[else]
DIALECTICAL TREE MAP
Stakeholder
DEFEATED
UNDEFEATED
results in
1
1
1
JUSTIFIED
DIALECTICALTREE
Accept justified alternative
Stakeholder
1
Is rewritten to
Diagram change
1
Write intermediary language
code for the undefeated tree
INTERMEDIARY
LANGUAGE CODE
OUTPUT
1
generates
1
Generate the associated I-Star SR
diagram
Stakeholder
[more problems
occured during the
process]
Figure 5
[else]
I-STAR STRATEGIC RELATION
DIAGRAM
1
1..*
REQUIREMENT
1..*
Activity
1. Problem setting
Sub-Activity
1.1 Set problem
1.2 Create a
dialectical tree for
each problem
2. Add alternatives
to the problem
settings
3. Evaluate
3.1 Add arguments to
dialectical tree
3.2 Label the
dialectical trees
4. Accept justified
alternative
5. Diagram change
Table 1: Activity table
5.1 Write an
intermediary
language code for the
undefeated tree
5.2 Generate the
associated I-Star SR
diagram
Description
The stakeholder generates one or more
PROBLEM STATEMENTs. This is done by
describing the problem in a specific case based
domain. Because of the cyclical way in which
the model works, over time, new (sub) problem
statements can be added. This will be defined
in the PROBLEM STATEMENT as well (Jereta I.,
2006b).
The stakeholder creates a DIALECTICAL TREE
for every presented PROBLEM STATEMENT.
These DIALECTICAL TREEs are all presented in
the DIALECTICAL TREE MAP.
In this process one or more alternative
solutions to the problem are created by the
stakeholder, called ALTERNATIVEs.
The stakeholder adds ARGUMENTs to an
ALTERNATIVE, which can either support or not
support this ALTERNATIVE. This is done in the
notation of the dialectical tree.
All DIALECTICAL TREEs are connected and
labeled by the stakeholder either with a D
(defeated) or a U (undefeated). <?The former
means that the ARGUMENTs of that
ALTERNATIVE is weaker and the latter
ALTERNATIVE is chosen above the former.?>
<?The best ALTERNATIVE is accepted by the
stakeholder. A JUSTIFIED DIALECTICAL TREE
is separated from the DIALECTICAL TREE MAP
or added, which<what?> contains only the
justified ALTERNATIVE and resulting
outcomes?>
From the JUSTIFIED DIALECTICAL TREE an
INTERMEDIARY LANGUAGE CODE OUTPUT is
generated by the stakeholder.
The I-STAR STRATEGIC RELATIONSHIP
DIAGRAM is created or changed based on the
INTERMEDIARY LANGUAGE CODE by the
system.
Concept
SITUATIONAL
PROBLEM CASE
PROBLEM STATEMENT
ALTERNATIVE
DIALECTICAL TREE
ARGUMENT
LABEL
DEFEATED
UNDEFEATED
DIALECTICAL TREE
MAP
JUSTIFIED
DIALECTICAL TREE
INTERMEDIARY
LANGUAGE CODE
OUTPUT
I-STAR STRATEGIC
RELATIONSHIP
DIAGRAM
REQUIREMENT
Table 2: Concept Table
Description
The situational problem is the context, in which the problem occurs.
Eventual problem statements are created based on the problem case
(Jereta I., 2006b).
<?A problem statement defines the objectives to be reached,
demands to be satisfied, problems to be solved, issues to be resolved
or generally speaking anything that one wants to be achieved?>
(Jereta I., 2006b).
A suggestion, proposal or idea about the resolution of the stated
problems (Jereta I., 2006b).
A dialectical tree is a formal way of notating arguments, in which the
argumentation process includes defeasible rules, which are
represented by well-formed formulas (Jereta I., 2006b).
An argument contains a description and a support indication,
whether or not it contributes to the alternative. (Jereta I., 2006b).
A label is the result of the argumentations structure of a dialectical
tree. This result is given in D (defeated) and U (undefeated).
This is a label that shows that an certain argument is bettered by
another (Jereta I., 2006b)
This is a label that shows that a certain argument is not (yet)
bettered by another argument. (Jereta I., 2006b)
A dialectical tree map is an overview of one or more dialectical trees,
which are related in a manner<? that an overview of all defeated and
undefeated < in a manner that an overview of all defeated and
undefeated what? > ?> (Jereta I., 2006b)
The result of the argumentations structure gives one dialectical tree
that is victorious above all other and thus used to produce the i-star
strategic relationship diagram (Jereta I., 2006b).
Intermediary language code output is the output of the rewritten
dialectical tree <?to code?>, from which an i-star strategic
relationship diagram can be generated (Jereta I., 2006b).
The I-Star SR Diagram in this context is a diagram, conducted in the
requirement-driven Tropos notation (Castroa J., 2002), which
describes the requirements and their independencies for a certain
system (Jereta I., 2006b).
Related Literature
The Goal Argumentation Method uses concepts from earlier researches. The general idea of that the
argumentation should be captured during the process of RE starts with a large multiple case study,
which shows that lack of this is one of the reasons for large IT project failures (Curtis B., 1988). The
researchers first searched for a widely accepted method for RE. This was found in the Tropos
(Castroa J. K. M., 2002) methodology of RE. This method provides a strongly goal model driven
approach of RE (Fuxman A., 2004). Next to this more model driven method, a way was needed to
translate the model into a form that could be translated into code. Abstract logical models of
arguments, used in artificial intelligence (Chesñevar C.I., 2000) and a mathematical approach of
defeasible reasoning based on arguments (Simari G., 1992), were used to describe the requirement
model in a way that this could be translated to code. The way, in which this was done, was
influenced by the way, in which the formal specification languages (Dardenne A, 1993)were used to
translate goal models to formalized text. A framework for the argumentation integration into the RE
methods was provided by the reasoning loop model (Lourdas P., 2000), which was an altered little.
Although no direct research was conducted to compare GAM against other RE methods, we will give
a quick comparison. First, we place the GAM in a framework. A RE method should have at least three
dimensions: the specification dimension, the representation dimension and the argumentation
dimension (Pohl, 1994). The first dimension should specify the necessary requirements, the second
dimension should represent these in the total picture and the last should visualize the argumentation
based on the first two dimensions. The GAM uses all of the three dimensions. If we look at an
alternative for GAM <?an example is the use?> of a methodology with which to audit personal data
protection, using Requirements Engineering and based on CobiT (Martínez M., 2010). This method
was developed for the RE of systems, which need a high measure of security and are specifically
adjusted to the Spanish law. This method seems more specific compared to the more general GAM.
Although this method has in common that focus lays on a goal model approach, there is little
possibility to record reasoning and guide the reasoning process, for which can be concluded that the
third dimension is not implemented sufficiently. Another method to compare GAM with is the KAOS
method (Darimont R., 1997). This method seems strong in the first two dimension of the framework
from K.Pohl (1994) and provides good integration in a RE tool called GRAIL, however it misses the
third argumentation dimension. Even though there has been no extensive research on the subject, a
quick comparison with some literature confirms what was already mentioned in the main paper:
most RE methods lack a good method to integrate the argumentation dimension, something GAM
does provide.
In the paper itself (Jureta I., 2006a) a case example is provided, which is based on the Meeting
Scheduler Problem (Van Lamsweerde A., 1993) in which a RE approach to create a meeting scheduler
system is provided. This case is in the paper by Jureta (2006) improved with the third dimension by
using and explaining the GAM. A more extensive case study is done by I. Jureta et al. in Clear
Justification of Modeling Decisions for Goal-Oriented Requirements Engineering, (2006b) which is a
more extensive version of the first paper and describes the problem in more depth.
Bibliography
Castroa J., K. M. (2002). Towards Requirement-Driven Information Systemens Engineering: The
Tropos Project. Information Systems 27, 365-389.
Castroa J., K. M. (2002). Towards requirements-driven information systems engineering: the Tropos
project. Information Systems 27, 365–389.
Center for World-Class Universities of Shanghai Jiao Tong University. (2012). Academic Ranking of
World Universities - 2012. Opgeroepen op 2 14, 2013, van shanghairanking.com:
http://www.shanghairanking.com/ARWU2012.html
Chesñevar C.I., M. A. (2000). Logical Models of Arguments. ACM Computer Serveys 32, 32-41.
Curtis B., K. H. (1988). A Field Study of the Software Design Process for Large Systems.
Communications of the ACM, 1268-1287.
Dardenne A, v. L. (1993). Goal-directed requirements acquisition. Science of Computer Programming
volume 20, 3-50.
Darimont R., D. E. (1997). GRAIL/KAOS: An Environment for Goal Driven Requirement Engineering.
ICSE '97 Proceedings of the 19th international conference on Software engineering (pp. 612613). New York: ACM Inc.
Fuxman A., L. L. (2004). Specifying and analyzing early requirements in Tropos. Requirement
Engeneering, 2, 132-150.
Jereta I., F. S. (2006b). Justifying Goal Models. Requirements Engineering, 14th IEEE International
Conference (pp. 119 - 128). Minneapolis/St. Paul, MN: IEEE.
Jureta I., F. S. (2006a). Justifying Goal Models. Requirements Engineering, 14th IEEE International
Conference (pp. 119-128). Minneapolis: IEEE.
Lourdas P., a. L. (2000). A Generic Model for Reflective Design. ACM Transactions on Software
Engineering and Methodology, Vol. 9, 199-237.
Martínez M., L. J.-M. (2010). A Personal Data Audit Method through Requirements Engineering.
Computer Standards & Interfaces, 166–178.
Pohl, K. (1994). The Three Dimensions of Requirement Engineering: A Framework and its
Applications. Information Systems, 9, 243-258.
Simari G., a. L. (1992). A mathematical treatment of defeasible reasoning and its implementation.
Artificial Intelligence 53, 125-157.
Van de Weerd I., B. S. (2009). Meta-Modeling for Situational Analysis and Design Methods.
Information Science Reference (pp. 3-22). New York: IGI Global.
Van Lamsweerde A., D. R. (1993). The Meeting Scheduler Problem: Preliminary Definition. Rio de
Janeiro: Universitat Catholique de Louvain.
Appendix A: Dialectical Tree Template
Achieve ( goal (
Optimize ( goal (
Depend( Actor,
¬
Actor ) )
Do ( action (
Provide ( data (
This template provides a format on how to build a dialectical tree with labeled well-formed formulas
as described in Jureta et al. (2006). The columns represent choices that can be made, the rows
represent the choices. A choice can be empty, meaning that it is not necessary to implement
something here. The choices or parts of choices represented in gray are fixed, meaning that they
represent a certain operator in the dialectical tree diagram. The parts of choices represented in blue
are domain independent representations which have to be specified to the certain case in which they
will be used. For example goal can be provide_lectures_online.
Another important thing to take into account is that although this template provides all the possible
options of a dialectical tree, the following rule needs to be followed: An well-formed formula is
connected to one or more other well-formed formulas through branches (cell 1,2 and 6,2).
Comments:
I corrected some mistakes in the paper and restructured a couple of sentences. Some other
improvements can still be made. A couple of commas can still be added, but since the English
language is not that strict about them, I didn’t add them. Wherever you see a “<?_?>”, it means that
the sentence is structured in a confusing way. It is hard to understand the meaning of it. I would
suggest restructuring those sentences.
Concerning the content itself, I think that it is well written and well defined. The structure of the
whole paper is proper. Elements are properly described. You can find more information on that
matter in the separate ‘review’ document.