Goal Oriented Requirements Engineering: Approaches, Open Problems and Future Research Areas

Abstract

In the recent years, the popularity of goal-oriented requirements engineering approaches has increased dramatically. The main reason for this is the inadequacy of the traditional systems analysis approaches when dealing with more and more complex software systems. In this paper we tried to briefly discuss what GORE (Goal Oriented Requirements Engineering) is, what are the different approaches and the future research areas, which need to be focused.

1. Introduction

At the requirements level, these approaches treat requirements as consisting only of processes and data and do not capture the rationale for the software systems, thus making it difficult to understand requirements with respect to some high-level concerns in the problem domain. Most techniques focus on modelling and specification of the software alone. Therefore, they lack support for reasoning about the composite system comprised of the System-to-be and its environment.

It is important to note that goal-oriented requirements elaboration process ends where most traditional specification techniques would start .Overall GORE focuses on the activities that precede the formulation of software system requirements. The following main activities are normally present in GORE approaches: goal elicitation, goal refinement and various types of goal analysis, and the assignment of responsibility for goals to agents.

2. Evolution of RE and GORE

Over the past ten years, the requirements engineering (RE) community has increasingly expanded its adoption and adaptation of goal-oriented approaches to both functional and non-functional requirements (NFRs). Assessing project stakeholders’ goals early in the software life cycle was recognized as the major step towards achieving a project scope definition with clearly understood and well communicated project goals. Such an assessment relies on the availability of knowledge on the user defined requirements and their effort estimates, priorities, as well as their risk.

This knowledge enables analysts, managers, and software engineers to identify the most significant requirements from the list of initial defined requirements in the project.

3. Concepts and Terminology

Before getting into details let us examine some terminology in goal modelling. Goal-oriented modelling and software requirements engineering have some specific terminology defined here that will be used in the rest of this paper.

3.1. Goal

A goal is an objective the system under consideration should achieve. Goal formulations thus refer to intended properties to be ensured.

Goals may be formulated at different levels of abstraction, ranging from high-level, strategic concerns (such as “serve more passengers” for a train transportation system or “provide ubiquitous cash service” for an ATM network system) to low-level, technical concerns (such as “acceleration command delivered on time” for a train transportation system or “card kept after 3 wrong password entries” for an ATM system).

Goals also cover different types of concerns: functional concerns associated with the services to be provided, and non functional concerns associated with quality of service –such as safety, security, accuracy, performance, and so forth. Three levels of abstraction identified are described in Figure 1

illustration not visible in this excerpt

3.2. Functional vs. Non-Functional

Most software engineers are familiar with the concept of functional requirements (FR). In modeling system requirements, non-functional requirements (NFR) are often just as important, and can make or break a project depending on how well they are satisfied. NFRs are defined as system requirements that are not tied to any particular functionality. Examples of non-functional requirements include system-wide requirements such as performance, accessibility, and security. In this respect, modeling NFRs is relevant to modeling requirements of self-managing systems in that the four aspects cited by IBM of self-configuring, self-optimizing, self-healing, and self-protecting are all in fact non-functional requirements by this definition.

3.3. Hardgoals vs. Softgoals

Goals are distinguished between hard and soft. The distinction between the two is that of measurability. Hardgoals are satisfied when measurable criteria have been achieved. Softgoals however, have no concrete measurable criteria. Their status is thus “fuzzy.” Instead of discussing softgoals in terms of being satisfied, which implies an absolute completeness regarding goal achievement, softgoals are “satisficed.” Similar to the use of the term in domain of decision support systems, the nuance is that a goal has been satisfied to a degree that is “good enough” to accept. The importance in the distinction between hard and soft goals is that NFRs are often represented in terms of softgoals. Moreover, high-level business goals are very “soft” in nature. Therefore, representation and treatment of softgoals is important in design of self-managing systems.

3.4. Tasks vs. Operationalizations

Hardgoals at the lowest level are satisfied via tasks. Processes are a representation of knowledge organized into the design of an action whose results are intended to satisfy or contribute to a goal.

Processes define tasks. The end result of a process is achievement of or toward a goal. Softgoals at the lowest level are satisfied by “operationalizations.” The distinction here is that agents do not necessarily achieve goals by a fixed set of tasks. Agents modify their behavior according to the environment, motivated by achievement of goals assigned to them.10 The specific behavior required to achieve such goals is not known until run-time.

4. Why are goals needed?

There are many reasons why goals are so important in the RE process:

- Achieving requirements completeness is a major RE concern. Goals provide a precise criterion for sufficient completeness of a requirements specification;
the specification is complete with respect to a set of goals if all the goals can be proved to be achieved from the specification and the properties known about the domain considered
- Avoiding irrelevant requirements is another major RE concern. Goals provide a precise criterion for requirements pertinence; a requirement is pertinent with respect to a set of goals in the domain considered if its specification is used in the proof of one goal at least
- Explaining requirements to stakeholders is another important issue. Goals provide the rationale for requirements, in a way similar to design goals in design processes [1][2]. A requirement appears because of some underlying goal which provides a base for it [3][4][5]. More explicitly, a goal refinement tree provides traceability links from high-level strategic objectives to low- level technical requirements. In particular, for business application systems, goals may be used to relate the software-to-be to organizational and business contexts [6]
- Goal refinement provides a natural mechanism for structuring complex requirements documents for increased readability
- Alternative goal refinements. Requirements engineers are faced with many alternatives to be considered during the requirements elaboration process. Our research revealed that alternative goal refinements provide the right level of abstraction at which decision makers can be involved for validating choices being made or suggesting other alternatives overlooked so far. Alternative goal refinements allow alternative system proposals to be explored
- Managing conflicts among multiple viewpoints is another major RE concern [7]. Goals have been recognized to provide the roots for detecting conflicts among requirements and for resolving them eventually
- Separating stable from more volatile information is another important concern for managing requirements evolution. A requirement represents one particular way of achieving some specific goal; the requirement is therefore more likely to evolve, towards another way of achieving that same goal, than the goal itself. The higher level a goal is, the more stable it will be.