Keywords

1 Introduction

Requirements engineering (RE) deals with eliciting the high-level goals that the system to be developed, should achieve, refining these goals at fine grained level, documenting these goals in software requirement specification, and finally operationalizing them in order to fulfill the end user requirements.

Goal Oriented Requirements Engineering (GORE) emphasizes that requirements should not only address the question of “What” but they question of “Why” and “How” should also be focused in requirements engineering.

In recent years, the GORE has gained a dramatic popularity in the domain of requirements engineering both in industry and academia. The main reason behind is the lack of adequacy of the traditional approaches, especially in case when the requirements are more and more complex. The main deficiency of these approaches is that they treat requirements in terms of the processes that need to be implemented and data that need to be manipulated by the required system and they fail to address the basic rational behind the requirements. Various GORE oriented frameworks have been proposed in literature, for example KAOS, GBRAM, AGORA, NFR, i*, Tropos and GRL etc.

In requirement engineering process, goals play a major role. They show they objective in a given environment that need to be achieved by the required system through interaction of different agents [1]. Goals lead towards the requirements that need to be implemented in order to achieve that goal [5].

They help to conclude about the requirements completeness, i.e. if a goal is achieved then we can say that the requirement is completed. They provide the base for the requirements, the requirements exist to achieve some goal, in this scenario the requirements may change but overall goal may remain the same. In simple words, goals derive the requirements in similar way, design derive the programming code.

In this context GORE deals with elicitation, elaboration, structuring, specification, analysis, negotiation, documentation and modification of requirements by using the goals [2]. Thus, goral-oriented requirements engineering represents an explicit relation between the goals and the derived requirements [3].

However, despite many plus points, GORE is still an active research area [3], requiring plenty of work to be done to overcome the inherent issues e.g. goal elicitation, goal refinement and analysis, obstacle analysis etc.

A major problem, the requirements engineers face is to deal with the management of various inconsistencies that result from the acquisition, specification and evolution of goals elicited from multiple sources [5]. Goals can conflict with each other [4]. Resolving these conflicts in goals at one stage or other is the essential step towards developing successful software, which may otherwise lead towards failure or greater cost to resolve them at later stages.

This research work is an endeavor to review different types of these conflicts and the solutions available in industry and academia to resolve these conflicts. We will discuss the limitations and strengths of each method as well. Finally, we will try to present an optimized solution for resolving these conflicts at requirements level.

2 Related Work

Lot of work has already been done in literature in the domain of goals-oriented requirements engineering, especially for resolving the goal conflicts [e.g. 6,7,8,9]. For the sake of this research work, we have studied various state-of-the-art frameworks and methods support further our research work. Here we present a precise introduction of few:

Jureta et al. in [10] present a novel framework (called Techne) to model the requirements. The framework provides a comprehensive way to model the preferences and optionality of the requirements. In the said framework the requirements are modeled formally by using graphical structure and the preferences are introduced to finally decide upon the conflict and the solution. A preference in the graphical structure is a binary relation.

Techne’s framework, however, is a qualitative approach, does not having the numerical weights. Also, it does not provide any specific formula or algorithm to find the solution of various requirement issues, nor does it accommodate the precedence links. Figure 1(a) shows the conflicts between two requirements q(p3) and g(q3) where the preference method is used to show the preference given to g(q3) over q(p3) in Fig. 1(b).

Fig. 1.
figure 1

(a) Conflict between q(p3) and g(q3) (b) g(q3) is srtictly preferred to q(p3)

In [11] Harkoff et al. propose a qualitative and interactive approach for goal oriented and agent-oriented models. Their proposed solution allows the modeler to accommodate the domain knowledge, not captured in the models, with evaluation procedure. Due to its interactive nature, the proposed model suggests the satisfaction of a soft goal or its denial by depending on the human judgment (Table 1).

Table 1. Steps performed in [11]

In [12] Giorgini et al. proposed a formal model that helps to reason about the goal models that are developed in agent-oriented development by the use of Tropos. Their model supports the goals adopted in Tropos and helps the requirement engineer to overcome the qualitative relationships and inconsistencies among conflicting goals. Formal notations are used to develop the goal graph. As per the proposed model, different goals can add contradictory contributions to the same goals.

Figure 2 shows the set of formal notations and their meaning in the graph.

Fig. 2.
figure 2

Formal notations used in [12]

According to the authors, a conflict occurs when satisfying different goals have opposite effect for the same goal. For instance, if the graph contains , which means that if G1 is satisfied then G will be satisfied, on the other hand if the same graph contains , which means if G2 is satisfied then G will be denied. Now in this situation if both G1 and G2 are satisfied then we will call it a conflicting situation. In this case it becomes necessary to keep record of the satisfiability and deniability of all the goals to make the decision about accepting or denying a goal.

In [5] Alex et al. propose two types of inconsistencies arising during the phase of requirement elicitation. They propose an integrated framework to explore the relationships between these inconsistencies. They propose two formal techniques for detecting divergences: (1) Regressing Negated Assertions and (2) Using Divergence Patterns.

Figure 3 shows the conflict management integrated in the process of requirements elaboration. Authors also suggest various heuristics to help the engineer to detect the divergences without applying the necessary formal techniques each time.

Fig. 3.
figure 3

Goal driven RE: conflict management

In the end, authors suggest different strategies to solve the divergences. Each of these strategies matches to a specific resolution operator class:

2.1 Assertion Transformation

In this strategy authors group all operators to manipulate (Crete, Delete and modify) the goal assertions, the techniques in this group include avoiding boundary condition, Goal restoration, Conflict anticipation, Goal weakening, Alternative goal refinement and Divergence resolution heuristics.

2.2 Object Transformation

In this strategy authors group all operators which manipulate (create, delete, or modify) the object types, the techniques in this group include Object refinement and Agent refinement.

3 Critical Analysis

Each of the approach discussed so far has its own plus points and limitations. In this section we present a detailed comparison of various approaches we have discussed in Sect. 3. The approaches were compared on the basis of the criteria discussed in Table 2:

Table 2. Evaluation criteria

Now using the above criteria all the discussed approaches were analyzed. Table 3 shows the result of the evaluation.

Table 3. Comparison

As indicated in Table 3 that no approach uses full quantitative and algorithmic way to resolve the conflicts. Based on these conclusions we have proposed a method to resolve the conflict among the participant goals. The approach uses the weighted method, and mathematical formulae to resolve the conflicts.

4 Proposed Solution

In this research work we have proposed a quantitative method to resolve the conflict among the participant goals. The approach is based on the input by the stakeholders, it uses the weighted method to prioritize the goals, and the goal having maximum preference is the one getting more attention (e.g. by giving resources) to resolve the conflict. The proposed method consists of four steps (Fig. 4).

Fig. 4.
figure 4

Proposed process flow

4.1 Goals Identification

At this stage we identify the goals participating in a conflict. They goals may pertain to the stakeholders from multiple domains of the system.

4.2 Identify the Stakeholders

In this step, we identify the stakeholders, affected by the conflict. These stakeholders will be participating to resolve the conflict. Note that the number of stakeholders accepting or denying a goal will also impact the acceptance/rejection of the goal.

4.3 Weight the Goals

In this step, each of the stakeholder, weight each goal. Weights are given to the goals on scale from 1 to 5, where the value “1” means that achieving the goal is necessary and value “5” means that the goal is optional. The weights are assigned by the stakeholders as per their requirement to complete the tasks.

4.4 Select Criticality Value

At this stage, we select the goal which scores maximum value. This means that full attention will be given to this goal and the other goal can be compromised in terms of resources etc.

Now, to weight each goal, each stakeholder will assign the goal a value from 1 to 5, the average of the weighted value will determine the critical goal. This can be summarized in following formula.

C(Gi) = (∑(Weights)/no. of stakeholders) + S

Where C(Gi) = criticality of goal i.

S = Number of stakeholders.

In next section we have presented a case study to further elaborate the idea.

5 Case Study

Here we present an example to further elaborate the idea. We have considered two goals (G1 and G2) and 3 stake holders. Both of the goals are in conflict with each other, Goals G1 allows the user to retrieve the (information) items in any file format, whereas the goals G2 at the same time conflicts G1 by emphasizing to not to support the file conversion in case if the user wants the data item in different format.

We will use the proposed model to resolve these conflicting goals and based on the formula will select one goal to implement.

Step by Step we will follow all the phases of the proposed model:

5.1 Identify Goals

Here we have identified two goals:

G1 = “The option X allows the user to retrieve information items in any file format”.

G2 = “File conversion should not be supported”.

5.2 Identify Stakeholders

For the sake of this case study we have identified three stakeholders, Tom, John and Eliza. All of these stakeholders will be participating in goal conflict resolution mechanism. Note that in actual scenario each stakeholder has its own requirements and priorities regarding a specific goal.

5.3 Weight Goals

All of these stakeholders will prioritize each goal based on their understanding and domain knowledge.

Tables 4 and 5 show the weights given by each stakeholder to both of the goals.

Table 4. Values assigned by stakeholders to G1
Table 5. Values assigned by stakeholders to G2

5.4 Select Goal

As discussed in the proposed solution section, in this phase we will use the empirical formula to conclude about the acceptance/rejection of a particular goal, for this purpose the weights assigned by stakeholders in step 3 will be used.

Now calculating the criticality value for G1:

C(G1) = (∑(Weights)/no. of stakeholders) + S

C(G1) = ((4 + 3 + 4)/3) + 3

C(G1) = (11/3) + 3

C(G1) = 3.67 + 3

C(G1) = 6.67

Calculating criticality value for G2:

C(G2) = (∑(Weights)/no. of stakeholders) + S

C(G2) = ((4 + 4 + 2)/3) + 3

C(G2) = (10/3) + 3

C(G2) = 3.34 + 3

C(G2) = 6.34

Now as the C(G1) > C(G2) so we conclude that preference will be given to G1 and to resolve the conflict decisions will be made in favor of goal G1. Note that if the number of stakeholders in all the conflicting goals is same the “S” factor will be useless and can be ignored.

6 Critical Review of Proposed Solution

The proposed solution tries to formalize the conflict resolution mechanism by introducing the weighted method. Weights in the proposed solution are assigned by the stakeholders. Although model tries to formalize the decisions but on the other hand the model includes some uncertainty (the “S” factor) in case when the requirements are not clear to stakeholders or in case when the project is a new application.

The proposed solution has been analyzed on the basis of the criteria given in Sect. 4. Table 6 shows the comparison of the proposed solution with others approaches discussed in Sect. 3.

Table 6. Comparison of proposed solution with other approaches

As shown in Table 6, the proposed solution provides (as compared with the other approaches) more algorithms based quantitative approach to resolve the conflicts, thus providing us more formal way to deal with conflicting goals.

7 Conclusion

In this paper, we have presented an algorithm based quantitative approach to resolve the conflicts among diverging goals during requirements analysis phase in context of goal-oriented requirements engineering. A thorough literature review of the state-of-the-art approaches was performed in this respect to find out the limitations and deficiencies of already existing models. On the basis of these deficiencies then, a new model was proposed.

Efforts were made in the proposed model to overcome the deficiencies in already existing approaches. A critical analysis based on the comparison of the proposed solution with already existing approaches was also presented in order to justify it. Finally, the model was explained with the help of case study.

8 Future Work

For future, we have planned to refine the criteria based on the implementation of the proposed model in various projects. Efforts will be made to minimize the interaction of stakeholder (the “S” factor) in the model in order to avoid biased ness. This will help further to precise the goals conflict resolution mechanism. Plans are also there to provide the automated support for the proposed solution.