By A.J.Jansen

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
Statement
Problem
Analysis
Evaluation
Alternative
Justification
Problem Setting
Decision
Diagram
Change
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.
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, he and his department gives, online 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 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 then are evaluated and arguments are provided which give 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.Alt1Arg1+: Good quality lectures for students.
1.Alt1Arg2-: Relatively expensive equipement needed.
1.Alt1Arg3-: Difficult to arrange due bureaucracy at University.
1.Alt2: Audio record lectures.
1.Alt2Arg1-: Less quality but together with slides it is sufficient.
1.Alt2Arg2+: Audio device is relatively cheap.
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.
Figure 2: GAM reasoning loop output in light mode
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?
In figure 3 an example of the output of the GAM reasoning loop in 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)) do(audiorecording(lecturer)) optimize(easy_to_use(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 and 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 which is useful for tools.
PS1
Lecturer
1.Alt2Arg1: Record
Audio
PS1 provide lecture online
1.Alt2Arg4:
Easy to use defice
+
1.Alt2Arg6:
Audio records
1.Alt2Arg5:
Post on website
PS5
Acquire skills on how to record audio
1.Alt2Arg1:
Lectures
Student
Figure 4: I-star strategic relationship model
PS4
Course website

To gain deeper insight in this method a Process Delivery Diagram (PDD) is constructed in this paper as 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 when it would be based on the
Light Mode and 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.

Problem setting
Set Problem
Create a dialectical tree for the problem statement
Stakeholder
Add alternatives to the dialectial tree
Stakeholder
Evaluate
Add arguments to the dialectical tree
Label the dialectical trees
[More undefeated trees exist]
[else] Stakeholder
Accept justified alternative
Stakeholder
Diagram change
Write intermediary language code for the undefeated tree
Generate the associated I-Star SR diagram
Stakeholder
Figure 5
[more problems occured during the process]
[else]
SITUATIONAL PROBLEM
CASE
1
0..* based on
PROBLEM STATEMENT
1
1 solves
1..*
ALTERNATIVE
1
Values
1..*
ARGUMENT
Description
Support value
1..*
1..*
1
DIALECTICAL TREE
1
1..*
DEFEATED
LABEL c
1
DIALECTICAL TREE MAP
1
UNDEFEATED
1 results in
1
JUSTIFIED
DIALECTICALTREE
1
Is rewritten to
1
INTERMEDIARY
LANGUAGE CODE
OUTPUT
1
1 generates
I-STAR STRATEGIC RELATION
DIAGRAM
1 1..*
REQUIREMENT

Activity
1. Problem setting
2. Add alternatives to the problem settings
3. Evaluate
4. Accept justified alternative
5. Diagram change
Sub-Activity
1.1 Set problem
1.2 Create a dialectical tree for each problem
3.1 Add arguments to dialectical tree
3.2 Label the dialectical trees
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 the model works over time new (sub) problem statements can be added which will be defined in the
PROBLEM STATEMENT as well (Jereta I.,
2006b).
The stakeholder a DIALECTICAL TREE for the presented PROBLEM STATEMENTs. 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 the ARGUMENTs of that ALTERNATIVE is weaker and the latter ALTERNATIVE is chosen above the former.
The best ALTERNATIVE is accepted by the stakeholder and a JUSTIFIED DIALECTICAL
TREE separated from the DIALECTICAL TREE
MAP or added which 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.
Table 1: Activity table

Concept
SITUATIONAL
PROBLEM CASE
PROBLEM STATEMENT A problem statement defines objectives to be reached, demands to be satisfied, problems to be solved issues to be achieved of generally speaking anything that one wants to be achieved (Jereta I., 2006b).
ALTERNATIVE
DIALECTICAL TREE
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).
ARGUMENT
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).
LABEL
DEFEATED
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)
UNDEFEATED
DIALECTICAL TREE
MAP
JUSTIFIED
DIALECTICAL TREE
This is a label that shows that an 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 (Jereta I., 2006b)
The result of the argumentations structure gives one dialectical tree which is victorious above all other and thus used to produce the istar strategic relationship diagram (Jereta I., 2006b).
INTERMEDIARY
LANGUAGE CODE
OUTPUT
I-STAR STRATEGIC
RELATIONSHIP
DIAGRAM
REQUIREMENT
Table 2: Concept Table
Intermediary language code ouput 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).

The Goal Argumentation Method uses concepts from earlier researches. The general idea that 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 which 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 this could be translated to code. The way this was done is influenced by the way
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 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 to 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 is 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 possible 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 already was 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 in 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 bij 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 en describes the problem in more depth.

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. 612-
613). 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.

Depend( Actor , ¬
Achieve ( goal (
Optimize ( goal (
Do ( action (
Provide ( data (
Actor ) )
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).