INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1

Proposed framework of Goal-Oriented

Requirement Engineering w.r.t its various
Approaches
Usman Anwar

Abstract: Requirement Engineering (RE) is well known used in industries in software development now-a-days because RE is concerned with
identifying the customer needs and translate these needs into the system requirements. But for a successful software project RE is not only the key but
there is another key factor that is Goal-Oriented Requirement Engineering (GORE). Most of the software project leads to failure because of un-known
goals of system. The term goal is increasingly used in requirement engineering GORE is basically identification of system goals and transfer of those
goals into requirements. GORE presents an approach of goals for RE processes. This paper presents the various RE processes along with the Goals
their attributes, different levels, benefits and various GORE Techniques and framework with respect to GORE Techniques.

Index Terms: Requirement Engineering, Goals, Goal types, Goal-Oriented Requirement Engineering, GORE methods, GORE framework, Agents.

——————————  ——————————

1 INTRODUCTION

R equirement Engineering is a part of software engineering.

It plays an important role in the development of software
products, usually comprises of some phases that is used  Elicitation:
in the overall development. RE comprises of various process The process helps in gathering the requirements. So the
and standards involved in it. The process reflects that the requirements and assumption that are gathered are
requirement engineering means to define, analyze, maintain recognized and further evaluated [1], [2]. Also some of the
and to document the customer and system needs. It is very models are recognized to meet the requirements objectives.
important in software development because gathering the
good requirements is a very challenging task in the  Analysis and Negotiation:
requirement engineering many projects leads towards failure Process in which replacement of the requirements and
due to un-complete and ambiguous requirements. Problems assumptions takes place risks are to be analyzed along with
faced by the software organizations are Poor customer the requirements that are gathered in elicitation process also
satisfaction, cost overruns, errors, and time schedule [1].
involves requirement prioritization, risk assessment and skill
The Requirements Engineering Specialist Group (RESG) of
shortage [1]. Provide stakeholders the rationale to choose the
the British Computer Society defines requirements
best alternative.
engineering as “a key activity in the development of software
systems and is concerned with the identification of the goals of
stakeholders and their elaboration into precise statements of  Specification:
desired services and behavior” [1]. The several process The process in which further specifying the analyzed
involved in the requirement engineering are: Existing requirements are to be take place. Some of the requirements
information and Standards, Elicitation, Analysis, and assumption are formulated and elaborated precisely also
Negotiation, Specification, Validation, and Management. involves requirement definition and requirement maintenance
During development following phases are helpful. Further [1].
these processes can be descripted as:
 Existing Information and Standards:  Validation and Management:
In this process stakeholders and system are to be identified. The process in which we come to know that the requirements
Also Issues related to the current system also elaborated are build and specified is equal to the expected output after
along with Objectives of goals of system are also recognized development involves in managing and validating Incomplete,
[1], [2]. ambiguous and Inconsistent [1].

———————————————— No doubt that there are different ways of gathering

 Usman Anwar currently pursuing Master’s degree
program in Software Engineering in University Of Lahore,
Pakistan, PH- +92-3237416678. E-mail:
usmananwar0001@gmail.com.
requirements and various organizations have established their
own. Difficulties always arise during RE processes and it is
worth considering that there is a gap between theories and
what is happening in practice that is in real-life [1]. The main
measure of the success of a software system is the degree to
which it meets its purpose. Therefore, identifying this purpose

IJSTR©2019
INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1
must be one of the main activities in the development of
software systems [2], [3].
Analysis
Elicitation Validation
and Specification
Negotiate
Existing
Information and Requirement Management
Standards
Fig 1: Requirement Engineering Processes
2 GOALS
2.1 Overview of Goals
Goals are the objective the system should able to achieve [4].
We have seen that goals have long been focused and plays a
key role in requirement engineering. Goal concerns with
“Outcomes to be achieved by the system” or “Objective
system should achieve” [3]. So in the requirements goals
plays very important role to maintain the software by achieving
the certain goals.
Goals basically concerned with following:
 Why
 What
 How
The use of these concerns are basically involves the system
definition as “ why a certain system should be needed
based upon the previous situations, it also says that what
are the system feature and functionalities that satisfies
this criteria, also focuses on how the system should be
constructed based upon why and what criteria”. Goals are
basically all functional and non-functional requirements which
a system should fulfills. In the functional requirement the goals
concern about “the service or the functions to be
provided.” Whereas in non-functional requirements the goals
concerns about “quality of services” such as safety,
security, accuracy, reliability and performance as well [3].
So there is need to focus on the user goals first then come up
with some of the analysis and cases to satisfy them. No doubt
that goals are much stable then the processes [4], [6].
Goals also formulated with different types of levels of
Abstractions as discussed below:
1. Highest Level.
2. High Level.
3. Low Level.
Moreover these level of abstraction can be classified in the
form of the figure as given in the Fig 2.
IJSTR©2019
Highest Level Goal Levels High Level
(Survival of (Objectives)
Enterprise)
Low Level
(Technicality)
Fig 2: Goal Levels of Abstraction
In Fig 2. Different level of abstraction is introduced. As Goals
are found at different levels. Highest Level (concern with
survival of the Enterprise and organization), High Level
(explains the strategic concerns also at the organization Level),
such as “provide cash service everywhere” in ATM system,
whereas Low Level (Provide technical concerns and also
design specific), such as “card kept on wrong password 3
times” in ATM system [4].
Goals also provide the basic information of understanding,
evaluating and resolving of conflicts arises in multiple
requirements. Goal identification [4] is also very important
and challenging task now-a-days that is commonly seen in the
organization and various software industries as gathering the
goals is not an easy and simple thing. Sometimes it also take
too much time in identifying the correct goals. Goals can be
identified from various sources, some of them discussed below
[4]:
 Analysis of current system is an important source.
 Searching Keywords from previous documents.
 From interview with stakeholders.
Goals can also be classified by their attributes. As these
attributes are used to make some important decisions the
following of goals attributes are Names, Specifications, Utility,
Feasibility and Priority [6]. Goal links are another concept that
are used to ensure the traceability among of the goals. Some
of the goal links are [6]:
1. Inter-goal contribution links:
This goal link captures the positive as well as negative
contribution of one goal to the other goal.
2. Coverage links:
For the achievement of the goals this goal link is specified
by considering pre, post and trigger condition.
3. Operationalization links:
To evaluate and explore the goals from the given scenario.
4. Responsibility links:
Relates the goal and their responsible agent sub-models.
5. Wish links:
Link consists of assigning the specific goal to the specific
agent to avoid the conflicts among goals.
2
INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1
2.2 Types of Goals
Goals consists of three types that is defined below [6], [7]:
1. Achievement goals.
2. Soft goals.
3. Maintenance goals.
Achievement goals concerned with (it is fulfilled when the
specific target goal is accomplished), whereas soft goals
concerned with (goal that does not have any clear boundary to
accomplished) soft goals basically involves non-functional
requirements. Last goal is Maintenance goals (goal consists of
condition to remain constant).
2.3 Decomposition of Goals
In previous section 2.1 we discuss that goals basically
concerns with functional and non-functional requirements. As
GORE consists of goals and each goal is divided into sub-
goals [3].
GORE consists of the following concept of decomposition of
goals decomposition of goals involves AND/OR refinement.
1. AND Refinement:
AND refinement consist of satisfying all sub goals is enough to
satisfy the parent goal [3]. We explain this AND refinement
through the following figure 3.
Fig 3: AND refinement of Book Order Module
In Fig 3 it is discussed that in Book Order Module there are
four goals (Books Received, Books Delivered, Books Available
and Book sent) further there are sub goals of Books
Available(Books Ordered, Books Acquired) reflects that to fulfill
the Books Available goal there is need both of the sub-goals to
be fulfilled first. AND refinement also used in the KAOS
approach in GORE.
2. OR Refinement:
OR refinement consists of consist of at least one goal is
sufficient for satisfying the parent goal [3]. OR refinement
related to the goal. Now we explain the concept of OR
refinement in figure 4.
IJSTR©2019
Fig 4: OR refinement of Book Order Module
In Fig 4 it is further discussed that in order to satisfy the
Receipt sent goal the further sub-goals (Printed Receipt,
Electronic Receipt) as one of the sub-goal need to be
accomplished. One sub-goal is sufficient for the Receipt
send (parent goal).
3 GOAL ORIENTED REQUIREMENT ENGINEERING (GORE)
3.1 Overview of GORE
In previous section 2.1 we discuss about goals in detail. Now
in this section we discuss about GORE ant its main concepts.
In Section 1 we focus on various activities/process involves in
requirement engineering. Goal oriented requirement
engineering (GORE) concern with using goals with
respect to the RE Activities. No Doubt that the goal-oriented
requirement engineering is very broad and manly used for
identification of goals. GORE also deals with identifying the
user needs and system goals. GORE is concerned with the
use of goals in various activities of requirement engineering [6]
above activities mention in section 1. GORE uses the goals to
elicit, negotiate, analyze and specify the requirements [13]. In
this paper I have also compare the following traditional RE
with GORE.
3.2 Traditional Approach to GORE Approach:
In recent years it has been seen that there are many issues in
building a complex system because traditional technique just
focus on translating needs to the systems requirements. Also
main focus is on the functionality rather than identifying goals.
Traditional technique mainly focus on modeling and
specification [5]. Traditional requirements engineering
research takes start from the initial requirements statements,
which express customer’s wishes about what the system
should do. It ignores to focus on why the system should do,
which is the focus of Goal-Oriented RE [5]. But GORE
concerns with identifying the system goals and also the user
needs in the requirement. Non-functional requirements are
also in general left outside of requirements specifications.
Additionally, traditional modeling and analysis techniques do
not allow alternative system configurations where more or less
functionality is automated or different assignments of
responsibility are explored, etc. to be represented and
3
INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1

compared. Goal-Oriented Requirements Engineering (GORE) 4. Detecting conflicts:

attempts to solve these and other important problems [8].
Identify the roots for detecting conflicts among
GORE Approach focus mainly on following activities [6]. requirements because man conflicts arouse from the
stakeholder side and in team members.
 Goal Elicitation.
 Goal Analysis.
3.4 Disadvantages of using GORE
 Goal Refinement and Specification.
 Requirement Management. Some of the GORE disadvantages also given as [5]:

So following tasks w.r.t GORE are explained:  Unless a rigorous automated reason is used with formal
 Elicitation: methods, an abstract model may go unquestioned.
Elicitation w.r.t gore consists of eliciting the goals from the
requirements and use of those goals we elaborate the  Records contain vague intentions without thinking properly
requirement engineering to build the system needs. about the practical applications.
 Analysis:
After the elicitation the goal phase then following goals that 4 GOAL ORIENTED REQUIREMENT ENGINEERING
are elicited are analyzed.
APPROACHES
 Refinement/Specification:
When the certain goals and requirements are analyzed Following some of GORE methods are summarize below [3]
then we specify these goals and make refinement by apply [5] [6] [9] [10]:
AND/OR concept and by introducing the agents in it.
 Requirement Management: 1. KAOS.
In the requirement management phase the refined and 2. i* (Tropos).
specified goals are to be managed by applying the 3. NFR Framework.
management activities. 4. GBRAM.
5. AGBR.
3.3 Role of Agents in GORE
6. GOIG.
7. AGORA.
Agents are the components that plays an important role in the
8. VVA.
GORE such as human, devices, software. Goals are assigned
9. A-BT.
to agent that is responsible for the basic achievement of goals.
As goals are set of constraints, Agents, sub-goals, refinement,
requirements, conflicts, resolution, expectations Agents are 4.1 KAOS:
basic concept that is used in fulfillment of the goals. So goals
are assigned to the single agents. So every goals are KAOS method stands for Knowledge Acquisition in autOmated
decomposes into sub-goals due to the refinement. So the Specification (A. Dardene et al. 1993) or Keep all Objectives
goals are realized by the agent who are responsible for the Satisfied. Basically KAOS is goal-oriented requirement
achievement of the goals. So the refinement of the goal ends engineering approach. The requirements gathered through the
when the agent is able to fulfill or accomplish the sub-goals KAOS methodology can be validated by reviewing them so as
[5], [6]. to build a high quality product by organizing collective reviews
of the KAOS model. Virtual meetings using shared screens on
3.4 Advantages of using GORE distant stakeholder’s locations can also be used. KAOS
methodology is a multi-paradigm of different model and is
There are many advantages of using GORE in RE some of the basically help to obtain requirements by KAOS models. KAOS
advantages are summarized below [4] [5] [6]: is based upon the combination of four models [8] [9] [10].

1. Rationale for Requirements:  Goal Model

GORE provides a rationale for requirements, so that
explaining requirements to stakeholder is not a major
issue.
2. Mechanism for structuring:
GORE provides a valid criteria or mechanism for
structuring of the complex requirement, so that it can be
readable and easily understandable.
3. Completeness and Irrelevant Requirements:
Provides the criteria for the completeness of requirements
specification and to avoid irrelevant requirements so it can
be easily modifiable.
 Responsibility Model.
 Object Model.
 Operational Model.
Goal model elaborates (diagram that are used to deal with
goals) basically example are AND/OR graph as discussed in
Fig. 3 and 4, Responsibility model elaborates (achieving goals
with the help of Agent) basic entities in this model are
“Agents”, Object model elaborates (establishing constraint and
linking the application) basic entities involves in this model are
“Objects”, Finally Operational model illustrates (describing the
behavior of the agents that have to accomplish their needs).

4
IJSTR©2019
INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1

4.2 i* Tropos: 4.5 VVA

i* is a goal oriented modeling approach used in GORE (E. Yu
1997). It is the basis of Tropos which is agent oriented
development methodology (J. Castro et al. 2003). This method
consists of large framework and the framework mainly consists
of two main concepts: Strategic Dependency Model (SD) that
concerns with capturing the relationship among actors and the
other concept is Strategic Rationale Model (SR) that illustrates
rationale behind the systems [3] [10]. Since i* concerns with
modeling of goals so they can be used as an “Early phase
requirements” as well as “Late phase requirements”.
4.3 NFR FRAMEWORK
VVA is analysis method used in GORE techniques mainly is
Visual Variability Analysis deals with visualizing the
requirements and understanding the requirements in order to
meet the stakeholder’s satisfaction [11].
4.6 A-BT
A-BT is another GORE technique used to manage the
requirements to resolve the problems and issues related to
goals. This method consists of assigning goals to the agents
and the agents realizes it. This method provides a set of plan
to resolve the issues [11].

The NFR Framework mainly consists of dealing, concentrating

and modeling of non-functional requirements (H Kaiya et al
2004). NFR mainly focus on the soft goals. The basic concept
involves in this framework is that it deals with decomposing of
NFR, capturing NFR and also operationalizing the NFR’s [2]
[6]. So it also focus whether the developed product meets its
non-functional requirements or not.
4.4 GBRAM
GBRAM is a goal-oriented approach that stands for Goal-
Based Requirement Analysis and Measurement (A I Anton
1997). This method is used to analyze the requirements [6].
The analysis can be made from given data set or a scenario
because it is analyzed in the textual form this method does not
provide any graphical notation to express agents and goals
[2]. This method can be used in elicitation, analysis and
refinement tasks.
5 PROPOSED FRAMEWORK OF GORE W.R.T GORE
APPROACHES
Here I proposed a framework that is helpful in goal-oriented
requirement engineering to identify the goals and how various
GORE techniques are helpful when applied to various
activities of RE. The proposed framework consists of following
Activities and some GORE methods [2] [3] [5] [6] applied to
each of the activities. No doubt there are many methods but I
have discussed some methods in section 4. This model is
helpful in the software industries and organization as defining
the goals is also a very challenging thing in software
development process. This framework also includes the early
phase that is identifying the stakeholders because
stakeholders are very important part of our project. The
proposed framework is given as in Fig 5:

4.5 AGBR
AGBR is a goal-oriented approach which is basically stands
for Agent-based Goal Refinement (A M Sen 2007) mainly
discuss about eliciting the goals and refining it. So this method
involves stakeholders to elicit the soft goals [8].

4.5 GOIG
GOIG is concerned with requirement Elicitation which mainly
stands for Goal-Oriented Idea Generation (Kazuya Ohshiro
2005) [10]. The purpose of this method is used to elicit the
requirements goals based on idea-generation like eliciting goal
by brainstorming and observation the transform the generated
idea in the form of sub-goals.

4.5 AGORA
AGORA is a goal-oriented approach usually stands for
Attributed Goal-Oriented Requirements Analysis deals with
managing of the requirements provide methods to check
completeness, correctness, Unambiguity and Consistency [3]
[5]. Whereas this method also be used in the analysis phase
to analyze the conflicts among the goals by the analyst or
agent.
Fig 5. GORE Framework w.r.t to its various Approaches

5
IJSTR©2019
INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH, VOL 1, ISSUE 1

6 CONCLUSION Literature Review.”

In this paper we have studied the requirement engineering
their activities and analyze them as requirement engineering is
an important part of software organization. But GORE is also a
very known and good approach to elicit the goals from the
requirement and adobe those goals into the system. No doubt
that Goal-Oriented requirement engineering is very broad era.
In this paper GORE and heir various approaches has been
analyzed descriptively and also a framework is proposed with
respect to its approaches that are helpful in organization to
analyze the problems in software. Many concepts of goals has
been summarized briefly.
[12] Javier Martnez Silva, “Using GORE method for
Requirement Engineering of Planning & Scheduling.”
2016.
[13] Pedro Pignaton Negri, Vitor E. Silva Souza, Giancarlo
Guizzardi, “Towards an Ontology of Goal – Oriented
Requirements.”
[14] Giovanni Giachetti, Beatriz Marin, Lidia Lopez, Xavier Franch,
Oscar Pastor, “Verifying goal – Oriented specifications used in
model – driven development processes.” 2016.

REFERENCES [15] Danilo Filgueira Mendonca, Genaina Nunes Rodrigues, Raian

Ali, Vander Alves, Luciano Baresi, “GODA: A goal – Oriented
requirements engineering framework for runtine dependability
[1] Geshwaree Huzooree, Vimla Devi Ramdoo, “A systematic analysis.” 2016.
study on Requirement Engineering Processes and
Practices in Mauritius.” (International Journals of [16] Jennifer Horkoff, Fatma Basak Aydemir, Evellin Cardoso,
Advanced Research in computer science and software Tong Ali, Luca Piras, “Goal – oriented requirements
Engineering), 2014. engineering: an extended systematic mapping study.”
2019.
[2] SHAISTA PARVEEN, ASIF IMAM, “ANALYSIS OF
DIFFERENT TECHNIQUES OF GORE (GOAL
ORIENTED REQUIREMENT ENGINEERING).”
(International Journals of Advances in Electronics and
Computer Science), 2016.

[3] Jameela Bano, Dr. L. S. S. Reddy, Dr. Hedi Khammari,

“A Significant Research Framework on Goal Oriented
Requirement Engineering.” (International Journal of
Applied Engineering Research), 2018, pp. 9558-9564.

[4] Axel van Lamsweerde, “Goal-Oriented Requirement

Engineering – A Guided Tour” 2001 EEE.

[5] Jameela Bano, Nisar Hundewale, “Goal Oriented

Requirement Engineering – A Review.” 2011, Research
Gate.

[6] Shahzad Akram, Naveed Ikram, “Goal Oriented

Requirement Engineering: A critical study of Techniques.”
(ASIA PACIFIC SOFTWARE ENGINEERING
CONFERENCE), 2006 IEEE.

[7] Annie I. Anton, “Goal Based Requirement Analysis” 1996

IEEE Proceedings of ICRE ’96.

[8] Alexei Lapouchnian, “Goal Oriented Requirement

Engineering: An Overview of the Current Research.”

[9] Mizbah Fatima, “KAOS: A Goal Oriented Requirement

Approach” IJIRST, 2015.

[10] Vera Werneck, Antonio de Padua Oliveria, Julio Cesar

Sampaio do Prado Leite, “Compairing GORE frameworks: I
– Star and KAOS.”

[11] GORE (Goal Oriented Requirement Engineering): A

6
IJSTR©2019