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

requirements and various organizations have established their
 Usman Anwar currently pursuing Master’s degree own. Difficulties always arise during RE processes and it is
program in Software Engineering in University Of Lahore, worth considering that there is a gap between theories and
Pakistan, PH- +92-3237416678. E-mail:
usmananwar0001@gmail.com. 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]. Highest Level Goal Levels High Level
(Survival of (Objectives)
Enterprise)
Analysis
Elicitation Validation
and Specification Low Level
Negotiate
(Technicality)

Existing Fig 2: Goal Levels of Abstraction

Information and Requirement Management
Standards
In Fig 2. Different level of abstraction is introduced. As Goals
are found at different levels. Highest Level (concern with
Fig 1: Requirement Engineering Processes 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,
2 GOALS whereas Low Level (Provide technical concerns and also
design specific), such as “card kept on wrong password 3
times” in ATM system [4].
2.1 Overview of Goals
Goals are the objective the system should able to achieve [4]. Goals also provide the basic information of understanding,
We have seen that goals have long been focused and plays a evaluating and resolving of conflicts arises in multiple
requirements. Goal identification [4] is also very important
key role in requirement engineering. Goal concerns with
and challenging task now-a-days that is commonly seen in the
“Outcomes to be achieved by the system” or “Objective organization and various software industries as gathering the
system should achieve” [3]. So in the requirements goals goals is not an easy and simple thing. Sometimes it also take
plays very important role to maintain the software by achieving too much time in identifying the correct goals. Goals can be
the certain goals. identified from various sources, some of them discussed below
Goals basically concerned with following: [4]:
 Analysis of current system is an important source.
 Why
 What  Searching Keywords from previous documents.
 How  From interview with stakeholders.
The use of these concerns are basically involves the system
definition as “ why a certain system should be needed Goals can also be classified by their attributes. As these
based upon the previous situations, it also says that what attributes are used to make some important decisions the
following of goals attributes are Names, Specifications, Utility,
are the system feature and functionalities that satisfies
Feasibility and Priority [6]. Goal links are another concept that
this criteria, also focuses on how the system should be are used to ensure the traceability among of the goals. Some
constructed based upon why and what criteria”. Goals are of the goal links are [6]:
basically all functional and non-functional requirements which
a system should fulfills. In the functional requirement the goals 1. Inter-goal contribution links:
concern about “the service or the functions to be This goal link captures the positive as well as negative
provided.” Whereas in non-functional requirements the goals contribution of one goal to the other goal.
concerns about “quality of services” such as safety,
2. Coverage links:
security, accuracy, reliability and performance as well [3].
So there is need to focus on the user goals first then come up For the achievement of the goals this goal link is specified
with some of the analysis and cases to satisfy them. No doubt by considering pre, post and trigger condition.
that goals are much stable then the processes [4], [6]. 3. Operationalization links:

Goals also formulated with different types of levels of To evaluate and explore the goals from the given scenario.
Abstractions as discussed below: 4. Responsibility links:
Relates the goal and their responsible agent sub-models.
1. Highest Level.
5. Wish links:
2. High Level.
Link consists of assigning the specific goal to the specific
3. Low Level.
agent to avoid the conflicts among goals.
Moreover these level of abstraction can be classified in the
form of the figure as given in the Fig 2.

2
IJSTR©2019
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).
Fig 4: OR refinement of Book Order Module
2.3 Decomposition of Goals
In previous section 2.1 we discuss that goals basically
concerns with functional and non-functional requirements. As In Fig 4 it is further discussed that in order to satisfy the
GORE consists of goals and each goal is divided into sub-
goals [3].
Receipt sent goal the further sub-goals (Printed Receipt,
Electronic Receipt) as one of the sub-goal need to be
GORE consists of the following concept of decomposition of accomplished. One sub-goal is sufficient for the Receipt
goals decomposition of goals involves AND/OR refinement. send (parent goal).

1. AND Refinement: 3 GOAL ORIENTED REQUIREMENT ENGINEERING (GORE)

AND refinement consist of satisfying all sub goals is enough to 3.1 Overview of GORE
satisfy the parent goal [3]. We explain this AND refinement
through the following figure 3. 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.

Fig 3: AND refinement of Book Order Module 3.2 Traditional Approach to GORE Approach:

In recent years it has been seen that there are many issues in
In Fig 3 it is discussed that in Book Order Module there are building a complex system because traditional technique just
four goals (Books Received, Books Delivered, Books Available focus on translating needs to the systems requirements. Also
and Book sent) further there are sub goals of Books main focus is on the functionality rather than identifying goals.
Available(Books Ordered, Books Acquired) reflects that to fulfill Traditional technique mainly focus on modeling and
the Books Available goal there is need both of the sub-goals to
specification [5]. Traditional requirements engineering
be fulfilled first. AND refinement also used in the KAOS
approach in GORE. 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,
2. OR Refinement: which is the focus of Goal-Oriented RE [5]. But GORE
concerns with identifying the system goals and also the user
OR refinement consists of consist of at least one goal is needs in the requirement. Non-functional requirements are
sufficient for satisfying the parent goal [3]. OR refinement also in general left outside of requirements specifications.
related to the goal. Now we explain the concept of OR Additionally, traditional modeling and analysis techniques do
refinement in figure 4. 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
IJSTR©2019
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  Responsibility Model.
explaining requirements to stakeholder is not a major  Object Model.
issue.  Operational Model.
2. Mechanism for structuring:
Goal model elaborates (diagram that are used to deal with
GORE provides a valid criteria or mechanism for goals) basically example are AND/OR graph as discussed in
structuring of the complex requirement, so that it can be Fig. 3 and 4, Responsibility model elaborates (achieving goals
readable and easily understandable. with the help of Agent) basic entities in this model are
3. Completeness and Irrelevant Requirements: “Agents”, Object model elaborates (establishing constraint and
linking the application) basic entities involves in this model are
Provides the criteria for the completeness of requirements “Objects”, Finally Operational model illustrates (describing the
specification and to avoid irrelevant requirements so it can behavior of the agents that have to accomplish their needs).
be easily modifiable.

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

The NFR Framework mainly consists of dealing, concentrating

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

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