=Paper=
{{Paper
|id=Vol-1829/iStar17_paper_8
|storemode=property
|title=Eliciting Goals and Softgoals - How to Perceive the Intentionality at the Beginning of the Journey
|pdfUrl=https://ceur-ws.org/Vol-1829/iStar17_paper_8.pdf
|volume=Vol-1829
|authors=Antonio De Padua A. Oliveira,Julio Cesar Leite,Luiz Marcio Cysneiros,Wellington Gabriel Sampaio Da Silva
|dblpUrl=https://dblp.org/rec/conf/istar/OliveiraLCS17
}}
==Eliciting Goals and Softgoals - How to Perceive the Intentionality at the Beginning of the Journey==
https://ceur-ws.org/Vol-1829/iStar17_paper_8.pdf
Eliciting Goals and Softgoals - How to Perceive the
Intentionality at the Beginning of the Journey
Antonio de Padua Albuquerque Oliveira 1, Julio Cesar Sampaio do Prado Leite 2,
Luiz Marcio Cysneiros 3, Wellington Gabriel Sampaio da Silva 1
1 Universidade do Estado do Rio de Janeiro – UERJ
Rua São Francisco Xavier, 524 - 6 andar - Maracanã - Rio de Janeiro, Brazil
2 Pontifícia Universidade Católica do Rio de Janeiro – PUC-Rio
Departamento de Informática, Rua Marques de São Vicente 225 – Rio de Janeiro, Brazil
3
York University, School of Information Technology, Toronto, Canada
padua@ime.uerj.br - julio@inf.puc-rio.br - cysneiro@yorku.ca - wellgabrielss@gmail.com
Abstract: Software requirements activity, in the organizational context, is about
addressing the business information problem; discover the needs for improving the
situation and consequently specify the software requirements. Goal-Oriented
Requirements Engineering (GORE), aims to better understand the information
problem by looking at organizational actors’ intentionality (goals and softgoals) first.
Eliciting goals and softgoals within an organizational context is a difficult task: since,
among other things, it demands skills and time. This paper describes one strategy for
eliciting goals and softgoals that still relies on software engineers’ skills and time, but
it simplifies the process. We propose the use of a software tool to support a systematic
process to mitigate the chances for goals to be missed regardless of the experience
and skills of the software engineers involved in the project.
Keywords: Goals Elicitation, GORE, Goal-Oriented Requirements Engineering,
Requirements Engineering, MAS, Multi-Agent Systems, iStar, ERi*c Method.
1. Introduction
The goal concept has come to play a critical role in Requirements Engineering. In
Requirements Engineering, goals are considered a significant construct. Various
researchers consider GORE one of the best ways to produce quality software [12]
[13]. When referring to intentionality, we believe that goal modeling has a key role.
Our strategy uses goals, both hard goals and softgoals, in the same way used by the
iStar Framework [11] and the NFR Framework [2]. In order to avoid freestyle text in
goal naming, which allows a goal to be represented as a function or an action, we
adopted pre-defined syntactic frames that have the purpose of driving the
requirements engineers to represent stakeholder’s intentionality. We have developed a
tool to support goal elicitation in the context of previous work [6]. In this work, we
present the tool and a strategy to apply it to elicit both hard and softgoals.
This paper uses “the toll road control system” (TRC System) [4] [8] [9] [10] to
illustrate the proposed strategy. Section 2 describes the AGFL (Actor Goals from
Lexicon) strategy concepts using the AGFL tool prepared to facilitate the job, its
concepts, and it shows, in a simple way, the central ideas of the AGFL strategy for
perceiving the intentionality and how the process is carried out. An in-vitro
experimentation run by UERJ students is portraited. Section 3 concludes stressing the
continuity of the requirements process.
2. AGFL Strategy Concepts
The AGFL Strategy provides activities to guide goals and softgoals elicitation.
Figures and examples illustrated in this Section were extracted from an in-vitro
experiment conducted with undergraduate students. They were divided into 4 groups
of 3 students for preparing this experiment work of modeling TRC System.
The first activity of the strategy is “A - Build Lexicon”. The strategy adopts the
Language Extended Lexicon (LEL) [5] as an anchor, building on LEL´s strength,
which is to facilitate the comprehension of contextual terminology while providing
semantics associated with the vocabulary. LEL (Figure 1) captures the application
vocabulary elements and classifies (classification) them as either a subject (someone
who does the action Fig.1-a), an object (something that receives the action Fig.1-b), a
verb (the action Fig.1-c) or a state (a result of the action Fig.1-d). Each symbol
(Name) will contain one or more sentences written with minimum vocabulary to
express the meaning of the term being depicted (Notion). Each symbol will contain
one or more sentences specifying the “Behavioral Response” associated with this
symbol. Behavioral responses express the connotation of the symbol and can be
understood as actions that will occur due to the existence of this symbol. The LEL is
supported by a Tool [1]. Figure 1 (a, b, c, d) is a partial description of the TRC LEL.
Figure 1 – Example of four types of LEL symbols - Toll Road System
The lexicon is of fundamental importance to understand the vocabulary. It does
help the requirements engineer (RE) with the context knowledge and capture
semantics from the application language in use. Eliciting behavioral responses for
each symbol plays a special role since behavioral responses will drive the second
activity of our process (B - Extract Goals).
The activity “B - Extract Goals” requires that the RE recognizes goals and
softgoals and organize them by actors.
For recognizing goals, we build on Eric Yu´s observation: “A goal is a condition
or state of affairs in the world that an actor would like to achieve” [11], the strategy
basic idea is: “actions change states and states are goals”1. This concept is used in
Actor Goals from Lexicon – AGFL [6]. The AGFL considers the kinds of actions
revealed by LEL and performed inside the selected context.
Behavioral Responses (BRs) in LEL symbols mention actions which happen in the
organizational context. Two kinds of actions can be observed: concrete actions and
flexible actions. A concrete action changes one state into another, and a flexible
action adds a quality attribute to a state.
Oliveira [7] states that “A concrete action either occurs inside or outside the
Software System, and it also has to bring any concrete result, that is there was a state
change (buy, pay, sell, hire, calculate, and plan are examples of concrete actions)
looking at it from the RE point of view”. Oliveira [7] defines flexible action as a
complement to a concrete action, by bringing a quality characteristic to a given state.
Hence, if there is an action, it will be either concrete or flexible. Oliveira qualified the
term flexible based on the same interpretation used to define “softgoals” [3]. Flexible
actions lack precision, and the execution of the action may depend on interpretation
of the agent performing the action (analyze, evaluate, check, control, verify, and
validate are examples of flexible actions). Since actions change states, identifying the
motivation (why?) behind each action is the key point in AGFL:
When one concrete action is found ➔ the action will define a goal.
When one flexible action is found ➔ the action will define a softgoal.
This activity (B - Extract Goals) is connected to the C&L Tool [1] for picking all
BRs (actions) expressed in the LEL for defining the kind of each one as concrete or
flexible. The example (in activity A) has eight BRs (four concrete actions and four
flexible actions). The first action: “Receives authorization for traveling” is a concrete
action because it results in a concrete free pass while the second one: “Hopes to have
a good trip on the road” is considered flexible because it describes a quality.
Figure 2 shows one example portraying the classifying actions. Usually, on the
screen, we use the field RATIONALE to describe the flexible actions justification.
1
In our context states are interpreted as “desired states”.
Figure 2 – Screen of AGFL Tool for receiving BRs from C&L Tool
For defining goal elements (exemplified in Figure 3), the RE must select for each
BR that denotes a concrete action one LEL symbol element (subject or object) and fill
in one verb in a passive voice. Furthermore, if the current actor (see “AUTHORIZED
DRIVER”) depends on another actor (“operator”) to achieve the goal, RE must indicate
this by adding “ ” a new line, defining a second actor’s goal. We call this case a
reflexive goal when one actor has a goal but depends on another actor for the goal
achievement.
Figure 3 – The screen of the task “Define Goal Elements”.
Figure 3 also shows that the RE selected ROAD as the first element, filled
liberated (the verb) as the second element and picked operator as the second actor.
This means that AUTHORIZED DRIVER depends on the operator for a goal “ROAD BE liberated”.
This means that operator also has the reflexive goal “ROAD BE liberated”.
Figure 4 – The screen of the task “Define Softgoal Elements”.
Figure 4 shows the OBJECT TOLL PLAZA containing two flexible actions. (a) the RE
filled honest (the TYPE) as first element and selected payment (the TOPIC) as the
second element. The RE also associated “honest [payment]” with “toll BE paid” by driver. (b)
the RE filled quality (the TYPE) as the first element and selected road (the TOPIC) as
the second element and also RE associated “quality [road]” with “road BE maintained” by
administration.
The activity “C - Refine Goals”, requires that the RE organizes goals and softgoals
as a list sorted in chronological order. The RE should recognize when one goal comes
before another one. Long-time goals should be placed at the end of the list. The
method proposes two activities to refine the actor’s goals: merge goals (concrete and
softgoals) by actor and set them in chronological order. Chronological order means
long term goals first (the most abstract before and the less abstract after). This order is
important on modeling according to the ERi*c method [7]
Figure 5 – The Report of Refined Goals.
For example, explaining Figure 5, ADMINISTRATION goals chain in chronological order
is: toll BE charged is important for toll BE paid which is required for toll BE
computed, and toll BE computed is necessary for road BE maintained, and so on.
Figure 5 shows the final list of AGFL of Toll Road System goals. The final report
shows two new elements: “DEPENDER” and “DEPENDEE”. DEPENDER is the first actor, the
LEL subject of the actions, and DEPENDEE is the second actor who appears in the
elicitation process as an actor from whom the subject (“DEPENDER”) depends on to
achieve one goal. This idea of “DEPENDER” and “DEPENDEE” is the same used by iStar
Framework models.
3. Conclusions
The aim of this work is to propose a strategy to help the RE in the intentionality
dimension of the elicitation process.
The AGFL presented in this work is an extension of the first step of the ERi*c
Method [7]. The ERi*c Method uses the following composition for the handling the
requirements process: elicitation, modeling and analysis. Elicitation means
understanding the contextual knowledge and discovering the software requirements.
Modeling means describing requirements. Analysis means verifying and validating
the produced models. Consequently, next steps of the system development project are
specifying requirements and building models.
For modeling goals and softgoals before the application of iStar Models, the ERi*c
Method uses a diagram language similar to state charts that are a simpler view of iStar
SR model, to represent chains of goals and softgoals (states) relationships. These
diagrams are called “Intentionality Panels” [7], and they should be drawn separated
from each other, to control the iStar scalability problem. The idea of separation is
based on SDsituations - Strategic Dependency Situations [7] concept. An SDsituation
can be characterized as part of the business unit. In order to do that, the RE identifies
goals and softgoals arrangements that are connected in a less complicated way, using
the criterion defined in the process [7]. We described a process to tackle the
intentional dimension of the requirements elicitation activity by supporting the RE
during the mission of perceiving the intentionality (goals and softgoals) of an
organizational context of the software, preparing a list of candidate goals and
softgoals using a systematic process supported by a software tool called AGFL.
The AGFL Tool was developed using PHP, Javascript and MySQL, it has almost
2000 lines of code and required a 9 man-months effort. AGFL Tool will be available
on the i* wiki. Future work is aimed at integrating the AGFL and IP Diagram tools.
Our contribution relies on proposing a set of heuristics supported by a tool to help the
discovery of goal and softgoals.
References
1. Cenários e Léxicos - PUC-Rio - Disponível em: http://pes.inf.puc-rio.br/cel/. Acessed: 2016/Oct.
2. Chung, L.; Nixon, B.; Yu, E.; Mylopoulos, J.; Non-Functional Requirements in Software Engineering
– Kluwer Academic Publishers 2000 – Massachusetts, USA.
3. Cysneiros, L. M. and Yu, Eric “Non-Functional Requirements Elicitation” in Perspective in Software
Requirements, Kluwer Academics Publishers 2003.
4. http://ec.europa.eu/transport/road/policy/road_charging/charging_tolls_en.htm. accessed: 2008-Nov
5. Leite, Julio C. S. P.; Franco, Ana P. M.; A Client Strategy for Conceptual Model Acquisition;
Proceedings of the International Symposium on Requirements Engineering, IEEE Computer Society
Press, San Diego (1993), pp. 243-246.
6. Oliveira, A. Padua; Leite, J. C. S. P.; Cysneiros, L. M.; Cappelli, C.; “Eliciting Multi-Agents Systems
Intentionality: From Language Extended Lexicon to i* Models”, Proceedings of the XXVI
International Conference of the Chilean Computer Science Society. Los Alamitos: IEEE Computer
Society Press, 2007. v. 16. p. 40-49.
7. Oliveira, A. Padua; Leite, Julio C. S. P.; Cysneiros, L. M.; “ERi*c Method - Intentional Requirements
Engineering”; The XI Workshop on RE; Barcelona, Spain - July/2008.
8. “The TOLLROADSnews” a http://www.tollroadsnews.com/archives - accessed: Nov. 12th, 2008.
9. Wikipedia http://en.wikipedia.org/wiki/Toll_road - accessed: Nov. 12th, 2008.
10. https://en.wikipedia.org/wiki/New_Jersey_Turnpike], [Highway Information Services Division
(December 31, 2013)], [https://www.transcore.com/tolling-systems]
11. Yu, E. Modelling Strategic Relationships for Process Reengineering. PhD Thesis, Graduate
Department of Computer Science, University of Toronto, Toronto, Canada, 1995, pp. 124.
12. van Lamsweerde, Axel. "Goal-oriented requirements enginering: a roundtrip from research to practice
[enginering read engineering]." Requirements Engineering Conference, 2004. Proceedings. 12th
IEEE International. IEEE, 2004.
13. Rifaut, Andre, and Eric Dubois. "Using goal-oriented requirements engineering for improving the
quality of iso/iec 15504 based compliance assessment frameworks." International Requirements
Engineering, 2008. RE'08. 16th IEEE. IEEE, 2008.