Mathematical Problems in Engineering
Volume 2020 (2020), Article ID 2156023, 13 pages
https://doi.org/10.1155/2020/2156023

Research Article

Attributes-Based Decision Making for Selection of Requirement Elicitation Techniques Using the Analytic Network Process

Jinyu Li,¹ Asif Ullah,² Jun Li,¹ Shah Nazir,² Habib Ullah Khan,³ Hanif Ur Rehman,⁴ and Amin Ul Haq⁵

¹School of Electronic and Information Engineering, Lanzhou Jiaotong University, Lanzhou 730070, China
²Department of Computer Science, University of Swabi, Swabi, Pakistan
³Department of Accounting & Information Systems College of Business & Economics Qatar, Qatar University, Doha, Qatar
⁴Department of Computer Science, Abdul Wali Khan University Mardan, Mardan, Pakistan
⁵School of Computer Science and Engineering, University of Electronic Science and Technology of China, Chengdu 611731, China

Correspondence should be addressed to Jinyu Li; jinyuli078@163.com

Received 12 May 2020; Revised 24 July 2020; Accepted 7 August 2020; Published 8 September 2020

Guest Editor: Erkan Celik

Copyright © 2020 Jinyu Li et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The publication of this article was funded by Qatar National Library.

Abstract.

Requirement engineering is the first phase of software engineering. In requirement engineering, the first phase is requirement elicitation (RE), which is the most critical and error-prone activity. In this phase, the requirements are extracted from various sources; after extraction, they are analyzed and documented for a specific purpose of software development. In RE, process requirements from stakeholders are gathered, upon which the entire software product failure and success are dependent. In order to accomplish the goal of requirement elicitation, various techniques are used. However, the selection of these techniques is a very challenging task, as one technique may suit a situation but may not be suited for other situations. Besides this, project attributes such as documentation culture of organization, degree of relationship among stakeholders, and familiarity to domain also have a great impact on the process of technique selection. The reason is that there is no empirical value of the techniques that provide help in techniques selection to analyze the basis software project attributes. This study proposed the analytic network process, which is one of the multicriteria decision making processes for the elicitation technique selection process with respect to criterion attributes of project. The motivation toward the use of the ANP approach for the selection of requirement selection technique is that there are dependencies existing among attributes of the project elements. So, the ANP approach is capable of dealing with such situations where dependencies and complexity occur. Results of the proposed study demonstrate that the technique helps in complex situations where decision making is difficult based on the alternatives.

1. Introduction

The most important phase in developing software is requirement engineering, which combines different tasks of the developing system in order to gather requirements, taking into account the requirements of multiple stakeholders who have variations. RE is a complicated, practical, social, and intellectual process, which produces the software system requirements [1, 2]. Requirement gathering is known as the most complicated process and requires a lot of skills for the software development [3]. Instead of this, inappropriate requirement elicitation leads the software development process to failure and late product delivery. The main objective of the elicitation technique(s), used to elicit requirements, is to discover many possible issues in the process requirement gathering, which, in turn, facilitates obtaining appropriate software product for stakeholders, which can fulfill their requirements [4]. In industry, different techniques are used to collect most adequate requirements of a specific software project. However, the most suitable technique selection requires in-depth knowledge of the problem domain, techniques available, and requirement sources (domain experts, organization, market, users, and customers) from where requirement collection is carried out. However, there does not exist one single elicitation technique that works best to solve all kinds of problems. Therefore, techniques used for requirement elicitation are categorized into four various types: cognitive techniques, group techniques, traditional techniques, and contextual techniques [5]. Similarly, lack of knowledge regarding attributes, the most appropriate technique selection, is a challenging task for a particular software. There exist a lot of elicitation techniques for requirement gathering, but among them, some techniques are appropriate to use in some specific condition, while others are not that much suitable to use. [6]. In the same way, there is a need of a technique through which one might be able to elicit the most appropriate requirements for a specific problem based on some attributes. The other techniques work for different situations; however, no such technique is available, which best fits in situation when there is complexity and the decision is based on attributes.

This research first identifies software project attributes. Then, ANP method is used, which is a multicriteria decision making (MCDM) approach. ANP is used for the elicitation technique selection on the basis of project attributes specified. The ANP method provides a model that is used to determine the comparative importance of the software project attributes selected and how a particular technique could be applied with respect to each attribute. It can improve the chances of dependable results, and requirement engineers can help in the process of techniques selection in order to gather requirements. The ANP works well where there are dependencies, and feedback is needed among the elements of the network. The proposed research main contributions are as follows:

(i)To identify the software project attributes for requirement elicitation technique(ii)To identify the relative significance of the attributes with respect to the project(iii)To use multicriteria decision making approach for the selection of requirement elicitation technique

This research work will help the analyst in decision making with full comprehension of both upside and downside (trade-off analysis) of techniques regarding attributes. This research provides a base that will certainly help requirement engineers in the selection of appropriate technique.

The paper organization is given as follows: Section 2 presents related work. Section 3 presents the methodology of ANP for the conduction of the proposed research, attributes for technique selection and elicitation techniques, expert opinion for weights derivation, and experimental work. Section 4 presents results and discussion. Section 5 contains the conclusion of the paper.

2. Related Work

Several approaches are adopted by researchers for elicitation techniques used in industry and stated in literature. The applicability of these approaches is dependent on the requirement types gathered, the environment of the project, and features of the target technique. There are limited guidelines for requirement engineers to support them in the selection of most appropriate technique to gather proper requirements. It has been evidenced from the literature that criteria for the assessment and comparing related work are based on disciplines in which proposal is applicable, scope which the proposal intends to achieve, information type upon which proposal is based, number of elicitation techniques covered, kinds of elicitation process contextual elements accounted for, specification of the contextual attribute values, and evolving ability of the proposal. The elicitation session preparation involves understanding of the domain of application by elaborating policy, organizational and social aspects, and system development constraints, identification of requirement sources, stakeholder analysis, technique selection, tools used for requirements, and requirement elicitation from users [6]. In actual practice, when a particular software system’s analysts start gathering requirements, they usually use one technique only, which is interview, for information gathering; besides that, analysts are possibly familiar with numerous techniques [7]. People are using different techniques taken from other disciplines like linguistics, sociology, anthropology, and cognitive psychology [8], and techniques used by knowledge engineering [9], and now software engineering. Most of the software developers are not aware of these techniques for optimization of their elicited requirements. This is thought out to be a breach between practice and theory [10].

Most of the researchers tried their best to propose techniques for optimization of the selection process [3, 11–13]. But, still, the existing efforts do not provide any empirical exploration and complete assessment regarding relative significance of various selection issues and their supporting strength for each and every technique. Researchers such as Ghanbar et al. [14] introduced an approach of eliciting requirements. In this approach, online serious games are applied for gathering requirements in situations, in which stakeholders of software systems are dispersed. By using empirical evaluation, the effectiveness and validity of the approached were checked and hence, much more encouraging results are produced. Burnay et al. [15] proposed a method of “Elicitation Topic Map” (ETM) to facilitate analysts to prepare interviews. Ribeiro et al. [16] presented an approach in order to verify the acceptance and effectiveness of a tool that is web collaborative, whose main purpose is stakeholders gathering in order to gather requirements. The tool development approach is Six Thinking Hats Method and gamification. The main aim of this work is to improve stakeholder’s collaboration by discussing results and implications. Ruf et al. [17] reported the elicitation of Mobile Financial Advisory Service (mFAS) requirements for the purpose of its design by validating and instantiating the Requirement Data Model (RDMod). A selection of multimethod approach is done for attaining this goal, focus groups and the review of literature.

Yousaf and Asger [5] provided different elicitation techniques comparison for requirements. They introduced top to bottom survey of various techniques, their strengths, and weaknesses. Chakraborty et al. [18] proposed technique for the process of eliciting requirements based on conceptualized approach, which emphasizes dynamics of interactions between requirement engineer and future system user. The multifaceted, collaborative perspective of requirement elicitation is repeated by them, and guidelines that are well enough to explain this collaboration are provided. This collaborative activity success depends upon group ability in building up a share frame of reference and furthermore, to work collectively. Most of the empirical research studies are conducted in recent years. However, most of the empirical researches conducted are dependent on experiments in laboratory in which students mainly focus on techniques effects of requirement elicitation on the final product of elicitation process. [19]. The authors [20] define a Methodology for Requirement Engineering Techniques Selection (MRETS); requirement engineering is facilitated by this approach to choose adequate technique for a particular project with respect to requirements. The MRETS proceeds towards the selection of techniques from the given three perspectives as follows: (1) A connection setup between attributes of both techniques and projects. (2) Based on evaluation schema, detailed analysis is carried out by using clustering. (3) Useful tools have been provided by the objective function to select RE techniques. The process of RE is of multidisciplinary nature; in a specific situation, a technique could be perfect, but it may not in another. Table 1 shows the summary of the techniques and approaches used.

Table 1: Techniques and approaches used for requirement elicitation.

Reference
Technique
Description

[6]
Survey of requirement elicitation techniques, approaches, and tools
Significant aspects of tools, techniques, and approaches are covered along with the trends, issues, and challenges in the field

[8]
Roadmap of requirement engineering
This research work provides an overview about requirement engineering (RE) of the software systems. It defines the core areas of RE practice and points out some main issues of open research for the future.

[9]
Techniques of knowledge elicitation
The main reason of this survey is (1) knowledge elicitation techniques identification and the related bibliographic information, (2) techniques organization into categories based on methodological resemblance, and (3) summarizing techniques strengths, weaknesses, and suggested applications.

[10]
Elicitation technique selection: how do experts do it?
This study provides in-depth interviews results conducted from some of the world’s most experienced analysts. The results produced show how the selection is carried out for elicitation techniques based on a variety of situational assessments.

[11]
Framework for matching requirement engineering techniques
This paper proposed a framework in which the typical requirement engineering techniques are characterized, which in turn provides a base for the selection of most adequate techniques at the time when the project starts and at the time of identifying a change in nature of the project or experiencing difficulties in describing a appropriate set of requirements.

[12]
Framework for selection of requirement elicitation techniques
In this paper, a framework is introduced; this framework helps analysts select the most suitable elicitation technique that is fit for the elicitation session, the project environment, and problem domain. After applying this framework, it provides a priority list of elicitation techniques that best suits the project.

[14]
Utilizing online serious games to facilitate distributed requirement elicitation
This paper proposed a new approach, i.e., online serious games, in order to gather requirements from the stakeholders distributed. Empirical study was conducted in this approach to evaluate the feasibility and find the effectiveness. The results produced by this approach were good enough and helped out less experienced analysts gather higher number of requirements. The results produced also recognized that this approach provides simple and easy way to individuals that are technically less experienced and allows them to contribute in requirement elicitation.

[15]
A theoretical and empirical study of topic importance in requirement engineering elicitation interviews
This study proposed the elicitation topic map (ETM), which helps engineers formulate interviews. ETM shows topics in the form of diagrams; these diagrams are then discussed in interviews and represents how likely to discuss these topics spontaneously by the stakeholders. If a topic to be discussed spontaneously, it is less likely, then suggestions to engineers are that they might wish to make questions on it just before the interview. ETM was shaped through empirical and theoretical research.

[16]
Gamifying requirement elicitation
This study examines that how much web collaborative tools are useful and accepted, in which development was done by using approach of the six thinking hats method and gamification to get dispersed stakeholders altogether. The document discusses the implication and results in order to improve collaboration among stakeholders.

[21]
Requirement elicitation techniques selection
The study was conducted in knowledge-based systems based on previous works, evaluating and building upon their efforts, and extended the knowledge-based approach by considering taxonomy of project characteristics. It has mainly bridged the gap to provide necessary support for the analyst by taxonomy of the software project types. The method proposed provides support in terms of selection of appropriate elicitation technique and knowledge base related to it. The method evaluation is done through a case study and prototype to check its effectiveness and feasibility.

[22]
Review of techniques of requirement elicitation
This paper presented elicitation techniques understanding and how to use them in applications of real time. The implementation of these techniques of requirement gathering provides base to know clearly requirements of the stakeholders and also helps developers better understand the requirements of the developing system.

[23]
Requirement elicitation problems
This paper presented problem types classification that requirement elicitation process faces. To derive this classification, a literature analysis has been carried out. Papers reporting on techniques for improving requirement elicitation practice were examined for the problem the technique was designed to address. The classification contains the most prominent or recent techniques for solving the problems. The requirement engineer is allowed by the classification to be sensitive on the rise of the problems and the educator to structure delivery of requirement elicitation training.

[24]
Assessment of requirement elicitation tools and techniques
This paper provides the understanding of requirement elicitation tools and techniques. The paper also presented the comparison of elicitation techniques and software requirement tools in a summarized form, and this comparison is based on different parameters.

[25]
Requirement elicitation framework
This study proposed a framework of requirement elicitation, which starts with an organization’s business process model and builds the system’s CRUD matrix. This matrix actually provides all possible relationships between entities and functions of the system in order to gather complete requirements of the system.

[26]
Analysis of elicitation techniques for design of smart requirements
This paper presented elicitation techniques comparison in detail, along with its characteristics as well as situational characteristics. The main aim of comparative analysis is to support analyst for selection of suitable requirement elicitation technique on the basis of different situational characteristics. The model presented will be quite helpful to automate the process of technique selection for elicitation.

[18]
An exploration into the process of requirement elicitation
In this study for RE, an integrative process model is presented. The suggestion comes from the study’s finding that there are four collaborative states from which RE is composed. This research explains these four states, and important factors are identified, which tend to trigger transitions from one state to another.

[19]
Review and aggregation of empirical studies on elicitation techniques
This research has provided empirical studies results on the techniques used for elicitation, and empirical evidence has been provided after the results aggregated. The methodology chosen for surveying was systematic review, whereas comparative analysis method is adopted for aggregation because the applicability of meta-analysis techniques is not possible. In review, identification of 564 publications is done from ACM DL databases, IE EEXPLORE, SCOPUS, and Google. In this research, 26 publications are selected, and then data is extracted from them. The 30 empirical studies are found in the selected publications. These studies were designed to test 43 elicitation techniques and 50 different response variables. The study got 100 separate results from the experiments. The 17 pieces of knowledge are generated by the aggregation about sorting, laddering, protocol analysis, and interviewing elicitation techniques. In this research, the gathered knowledge provides guidelines set.

3. ANP Approach for the Selection of Elicitation Technique

Multicriteria decision support system (MCDSS) is used to facilitate the issues arise from daily life. Due to the usefulness of multicriteria based decision support system, researchers are trying to devise machine learning algorithms to provide an intelligent decision making alternative [27–29]. Decision support systems (DSS) are used in a variety of applications and domains for solving or assisting the decision maker to take a more appropriate decision, and these can be exploited in almost all domains to solve decision problems, such as DSS in Agriculture [30], energy sector [31], waste management, and business [32], [33]. These DSS can help practitioners solve the particular problems in the area domain of real life. Various domains exploit the theories and methods of decision making alternatives from simple to more advanced and intelligent models [34, 35]. DSS is an active area of research where research finds new ways to evaluate multiple criteria and propose intelligent framework for enhancing the potential of decision support systems.

ANP is a MCDM method, which is used to handle the problems when it becomes very difficult to make a decision. In the ANP, the elements are clustered with each other in a group of networks. The cluster consists of different elements and nodes connected to each other via a network. The ANP works well where there are dependencies, and feedback is needed among the elements of the network. The ANP is a suitable tool to handle such a complicated situation. The following sections briefly show the details of the ANP process for the proposed research.

3.1. Analytic Network Process

The main goal of ANP method is to handle the selection of elicitation technique, both inner and outer dependencies among the project environment attributes of the network of nodes. ANP is applicable in different situations such as [36]. The ANP deals in situations when there is complexity among the available alternatives based on some criteria, and the selection is uncertain. No decision is possible on which option should be adopted. So, to overcome such situation, the ANP is the best option to be adopted. The summarized form of the main steps involved in ANP method is given as follows [37]:

(i)The network is composed of various clusters.(ii)A cluster is a combination of nodes.(iii)Weighting scale is relative to the importance of each node within the cluster.(iv)Set up a matrix [A] of n × n.(v)Pairwise comparison is computed among nodes.(vi)Sum the columns of the matrix [A].(vii)Normalize the matrix [A] by dividing the elements in each column by the sum value of that column obtained in original matrix [A]. After normalizing the matrix, [A] averages the rows to get the Eigenvector [24].(viii)To check the consistency, determine a weight sum vector, i.e., {} = [C]{}.(ix)Consistency vector will be obtained by computing dot product of {} and {}, i.e., {Consis} = {}. {}.(x)Determine the average of the elements of {Consis} to get λmax(xi)Find consistency index and consistency ratio by

where n is the number of elements in a matrix by

where RI is a random index.

Table 2 shows the RI presented by Saaty [38].

Table 2: Random consistency index.

Number of elements (N)
Random consistency index (RI)

1
0

2
0

3
0.58

4
0.9

5
1.12

6
1.24

7
1.32

8
1.41

9
1.45

10
1.49

11
1.51

12
1.48

13
1.56

14
1.57

15
1.59

CR value should always be smaller than 0.1; else, the process of calculating the CR should be revised so that the value becomes less than 0.1:

(i)The combination of Eigenvectors of the matrices will provide super matrix. Unweighted super matrix is a matrix if the value obtained from column sum is bigger than one. In order to obtain the value of sum of the column less than or equal to one, unweighted super matrix will be normalized.(ii)The weighted matrix will be obtained after normalizing unweighted matrix.(iii)Furthermore, the transformation of super matrix into limit matrix will be carried out.(iv)The limit matrix obtained provides help to select the most appropriate alternative.

The steps involved in ANP technique along with the process of calculations are shown in Figure 1.

Figure 1: Steps of the process of the ANP.

3.2. Attributes for Technique Selection and Elicitation Techniques

Project environment attributes greatly affect technique selection for elicitation process. A technique for elicitation may be fit for an attribute but may be not for the rest. E.g:- if stakeholders are easily available, then interview is a good technique that can be applied, but if the analysts find them hard to be available, then he/she cannot use this technique. Industry practices, interviews conducted from domain experts, and large amount of literature reviews have been observed for the identification of attributes of software project environment that are highly influential on the technique selection process [38–40]. These attributes are given as follows:

(1)Availability of Key Stakeholders (ASTK)(2)Availability of Reusable Requirements (RQ)(3)Computer Literacy (CL)(4)Degree of Financial Constraints (FCO)(5)Degree of Project Schedule Constraints (SCO)(6)Degree of Relationship among Stakeholders (RSTK)(7)Diversity of Stakeholders (DSSK)(8)Documentation Culture of Organization (DOC)(9)Familiarity to Domain (FD)(10)Interactive Nature of Prospective System (INT)(11)Maintenance of Existing System (MES)(12)People per Session (PS)(13)Relation between Analyst and Client (RAC)(14)User’s Expressiveness (EXP)

Requirement elicitation is collaborative and human oriented activity where knowledge from other fields is also used widely such as management science, psychology, and sociology. The most crucial task for a requirement engineer in the process of developing software is a suitable technique selection. In process of requirement gathering, various techniques are used to elicit requirements. But there is no such technique that works well to cover all the aspects of the software project. The literature [5, 24, 26] and industry report many techniques that are used for requirement gathering. But this research mainly focuses on techniques that are most widely used such as (i) Document Analysis (DA), (ii) Interview (IV), (iii) Introspection (IS), (iv) Questionnaire (QN), (v) Survey (SV), and (vi) Task Analysis (TA).

In this study, the process of technique selection to gather requirements is based on attributes of the software project environment. ANP comprises three key components, i.e., (1) Goal, (2) Criteria, and (3) Alternatives. The algorithm presented Saaty’s scale, which actually describes the fundamental scales for the judgements and represents the importance of elements among themselves. Table 3 also shows the importance of one element from the other.

Table 3: Saaty’s scale of judgment for the elements.

Definition
Explanation
Intensity of values

Equal importance
Two factors contribute equally to the objective.
1

Somewhat more important
Experience and judgment slightly favor one over the other.
3

Much more important
Experience and judgment strongly favor one over the other.
5

Very much more important
Experience and judgment very strongly favor one over the other. Its importance is demonstrated in practice.
7

Absolutely more important
The evidence favoring one over the other is of the highest possible validity.
9

Intermediate values
When compromise is needed.
2,4,6,8

Figure 2 represents techniques and attributes using ANP.

Figure 2: Representation of techniques and attributes using the ANP.

3.3. Derivation of Weights from Expert’s Opinion

In this study, ANP method is applied to the proposed model by in which comparisons are carried out in two phases. These comparisons are performed in such way that first attributes comparisons are done among themselves with respect to techniques and then comparisons among techniques with respect to attributes. Domain experts (Employee) of various software houses are the source from where data are collected. Questionnaire was used as a data collection tool, distributed among 25 experts. At the start, domain experts were first briefed about techniques used for requirement elicitation and project attributes. After the discussions, the experts came with the idea of using these techniques that are mostly used for requirement gathering and software development. Questions related to the techniques and their attributes were given to the experts. These questions have covered all techniques mentioned along with the attributes for facilitating requirement gathering. The experts assigned weights to attributes of project environment and to techniques used for elicitation that lead to a balanced agreement on each attribute and technique with respect to weight. To eliminate the variations that occurred in the opinions extracted from experts, a normalized geometric mean on opinions of experts is applied. In this research, traditional techniques are considered, that is, Document Analysis (DA), Interview (IV), Questionnaire (QN), Introspection (IS), Survey (SV), and Task Analysis (TA). These techniques were chosen to validate results and they pushed into matrix of n × n. The relative weights of the afore mentioned techniques are shown as Tij, where “i” is for the row’s representation in the matrix and “j” is for columns. If in the matrix relative weights assigned to any two techniques are the same, then the values of Tij = 1 and Tji = 1. Then in position where Tij is compared with the Tji which will definitely be a diagonal value, value “1” will be placed in that position. As shown in the given matrix below, “1” is inserted in DA11, IV22, IS33, QN44, SV55, and TA66:

After deciding weights for different parameters, the step by step ANP method to select an elicitation technique with respect to Attributes of project environment is as follows. Techniques comparison with respect to attribute SCO is as given in Table 4.

Table 4: Techniques comparison with respect to attribute SCO.

DA
IV
IS
QN
SV
TA

DA
1
0.2
2
3
3
0.5

IV
5
1
5
7
7
5

IS
0.5
0.2
1
0.5
0.5
0.33

QN
0.33
0.14
2
1
0.5
0.33

SV
0.33
0.14
2
2
1
0.33

TA
2
0.2
3
3
3
1

Total
9.17
1.88
15
16.50
15
7.50

The process of normalization of original matrix as shown in Table 4 is carried out and is given in Table 5.

Table 5: Original matrix normalization process.

DA
IV
IS
QN
SV
TA

DA

IV

IS

QN

SV

TA

Table 6 is extracted as a result of Table 5 and is said to be a normalized table if we calculate the sum of all columns in Table 4 and the result obtained is equal to 1. Now, to calculate Eigenvalues, the procedure that followed is to find the row sum of Table 5 which will be then divided by the total numbers of column in Table 6. The consistency ratio (CR) is calculated by the formula given in equation (2).

Table 6: Normalized matrix.

DA
IV
IS
QN
SV
TA

DA
0.11
0.11
0.13
0.18
0.20
0.07

IV
0.55
0.53
0.33
0.42
0.47
0.67

IS
0.05
0.11
0.07
0.03
0.03
0.04

QN
0.04
0.07
0.13
0.06
0.03
0.04

SV
0.04
0.07
0.13
0.12
0.07
0.04

TA
0.22
0.11
0.20
0.18
0.20
0.13

CR = 0.085.

The same processes of comparisons have been done for the rest of the attributes.

Comparison of attributes with respect to Interview is shown in Table 7.

Table 7: Comparison of attributes with respect to interview.

MES
CL
RQ
INT
ASTK
FCO
SCO
FD
RAC
EXP
RSTK
DSSK
DOC
PPS
EV

MES
1
1/3
3
3
1/3
1/3
1/2
1/3
1/3
1/3
1/2
3
3
2
0.051

CL
3
1
4
3
1/3
1/3
2
1/3
1/3
1/2
1/3
3
3
3
0.069

RQ
1/3
1/4
1
2
1/3
1/3
1/3
1/3
1/3
1/3
1/3
3
2
1/2
0.035

INT
1/3
1/3
1/2
1
1/3
1/3
1/3
1/3
1/3
1/3
1/3
3
1/2
1/2
0.029

ASTK
3
3
3
3
1
1/2
2
3
1/2
3
1/3
3
3
3
0.104

FCO
3
3
3
3
2
1
2
3
1/3
3
2
3
3
3
0.125

SCO
2
1/2
3
3
1/2
1/2
1
1/2
1/2
1/2
1/3
3
3
2
0.061

FD
3
3
3
3
1/3
1/3
2
1
1/3
3
1/3
3
3
3
0.087

RAC
3
3
3
3
2
3
2
3
1
2
2
4
3
3
0.148

EXP
3
2
3
3
1/3
1/3
2
1/3
1/2
1
1/3
3
3
3
0.075

RSTK
2
3
3
3
3
1/2
3
3
1/2
3
1
3
3
3
0.122

DSSK
1/3
1/3
1/3
1/3
1/3
1/3
1/3
1/3
1/4
1/3
1/3
1
1/2
1/3
0.022

DOC
1/3
1/3
1/2
2
1/3
1/3
1/3
1/3
1/3
1/3
1/3
2
1
1/3
0.030

PPS
1/2
1/3
2
2
1/3
1/3
1/2
1/3
1/3
1/3
1/3
3
3
1
0.042

CR = 0.0939269.

The same processes of comparisons have been done for the rest of the requirement elicitation techniques.

4. Results and Discussion

The proper requirement elicitation is one of the core issues in the software development process. To gather most appropriate requirements of the problem domain elicitation technique selection is also very important and difficult task. The reason is that an elicitation technique might be suitable for use in one situation which results in suitable requirement gathering but it may not be suitable to use in other situations. On the other hand, technique selection process is greatly affected by project attributes of the software system due to the reason that there is no observed value of the techniques to assist the analyst in the process of technique selection. The ANP method is applied which is of the MCDM approach for the appropriate selection of technique to elicit requirements on the basis of software project attributes. In this study, the first step that was taken is the development of a network structure. This network structure was designed in such way that it consists of goal, criteria, and alternatives associated with criteria. The proposed research, results, and discussion section are shown in the following sections:

4.1. Weighted Super Matrix

A weighted super matrix is a matrix in which total sum of all the columns must be equal to or less than “1”; otherwise the matrix will be normalized to get weighted matrix. Table 8 shows weighted super matrix.

Table 8: Weighted super matrix.

SCO
MES
RAC
RQ
RSTK
DOC
INT
FCO
FD
ASTK
EXP
CL
DSSK
PS
IV
SV
QN
TA
DA
IS

SCO
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.06
0.03
0.07
0.09
0.12
0.09

MES
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.05
0.05
0.10
0.11
0.07
0.08

RAC
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.15
0.15
0.06
0.07
0.04
0.18

RQ
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.04
0.10
0.05
0.10
0.10
0.04

RSTK
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.12
0.10
0.04
0.07
0.04
0.14

DOC
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.03
0.10
0.04
0.04
0.21
0.03

INT
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.03
0.04
0.04
0.16
0.08
0.02

FCO
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.13
0.03
0.03
0.04
0.06
0.03

FD
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.09
0.09
0.12
0.14
0.12
0.11

ASTK
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.10
0.08
0.14
0.05
0.04
0.09

EXP
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.08
0.08
0.03
0.04
0.04
0.09

CL
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.07
0.06
0.14
0.03
0.03
0.05

DSSK
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.02
0.03
0.04
0.03
0.03
0.02

PS
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.04
0.07
0.11
0.03
0.02
0.03

IV
0.49
0.24
0.36
0.15
0.20
0.15
0.16
0.37
0.22
0.34
0.35
0.40
0.14
0.43
0.00
0.00
0.00
0.00
0.00
0.00

SV
0.08
0.08
0.07
0.24
0.26
0.23
0.23
0.25
0.09
0.14
0.15
0.20
0.13
0.20
0.00
0.00
0.00
0.00
0.00
0.00

QN
0.06
0.06
0.05
0.08
0.05
0.11
0.12
0.17
0.10
0.12
0.12
0.16
0.36
0.14
0.00
0.00
0.00
0.00
0.00
0.00

TA
0.17
0.42
0.21
0.12
0.05
0.06
0.38
0.10
0.36
0.07
0.05
0.05
0.05
0.05
0.00
0.00
0.00
0.00
0.00
0.00

DA
0.13
0.15
0.17
0.37
0.05
0.40
0.07
0.07
0.16
0.05
0.06
0.07
0.24
0.07
0.00
0.00
0.00
0.00
0.00
0.00

IS
0.06
0.05
0.14
0.04
0.38
0.05
0.05
0.04
0.06
0.28
0.28
0.11
0.07
0.11
0.00
0.00
0.00
0.00
0.00
0.00

4.2. Limit Matrix

The values in the weighted super matrix are raised to the power until the rows in the weighted super matrix become the same and stable. The matrix obtained as a result of this process of the weighted super matrix is called the limit matrix. The limit matrix is the summarized form of all the pairwise comparison matrices. The limit matrix as shown in Table 9 contains the priorities of all the elements which help the requirement engineer select a suitable technique with respect to project environment attributes.

Table 9: Limit matrix.

SCO
MES
RAC
RQ
RSTK
DOC
INT
FCO
FD
ASTK
EXP
CL
DSSK
PS
IV
SV
QN
TA
DA
IS

SCO
0.0681
0.0689
0.0688
0.0689
0.0681
0.0688
0.0695
0.0688
0.0682
0.0688
0.0695
0.0681
0.0681
0.0688
0
0
0
0
0
0

MES
0.0655
0.0661
0.0661
0.0661
0.0655
0.0661
0.0668
0.0661
0.0655
0.0661
0.0668
0.0655
0.0654
0.0661

0
0
0
0
0

RAC
0.1062
0.1073
0.1073
0.1073
0.1062
0.1073
0.1084
0.1073
0.1062
0.1073
0.1083
0.1062
0.1062
0.1073
0
0
0
0
0
0

RQ
0.0624
0.0630
0.0630
0.0630
0.0624
0.0630
0.0637
0.0630
0.0624
0.0630
0.0636
0.0624
0.0623
0.0630
0
0
0
0
0
0

RSTK
0.0854
0.0863
0.0862
0.0863
0.0854
0.0862
0.0871
0.0862
0.0854
0.0862
0.0871
0.0854
0.0853
0.0862
0
0
0
0
0
0

DOC
0.0648
0.0654
0.0654
0.0654
0.0648
0.0654
0.0661
0.0654
0.0648
0.0654
0.0660
0.0647
0.0647
0.0654
0
0
0
0
0
0

INT
0.0550
0.0556
0.0556
0.0556
0.0550
0.0556
0.0562
0.0556
0.0551
0.0556
0.0561
0.0550
0.0550
0.0556
0
0
0
0
0
0

FCO
0.0581
0.0587
0.0587
0.0587
0.0581
0.0587
0.0593
0.0587
0.0581
0.0587
0.0592
0.0581
0.0580
0.0587
0
0
0
0
0
0

FD
0.0993
0.1003
0.1003
0.1003
0.0993
0.1003
0.1013
0.1003
0.0993
0.1002
0.1012
0.0992
0.0992
0.1003
0
0
0
0
0
0

ASTK
0.0764
0.0772
0.0771
0.0772
0.0764
0.0771
0.0779
0.0771
0.0764
0.0771
0.0779
0.0764
0.0763
0.0771
0
0
0
0
0
0

EXP
0.0575
0.0581
0.0581
0.0581
0.0575
0.0581
0.0587
0.0581
0.0575
0.0580
0.0586
0.0575
0.0574
0.058
0
0
0
0
0
0

CL
0.0558
0.0564
0.0564
0.0564
0.0558
0.0564
0.0570
0.0564
0.0558
0.0564
0.0569
0.0558
0.0558
0.0564
0
0
0
0
0
0

DSSK
0.0240
0.0243
0.0243
0.0243
0.0240
0.0243
0.0245
0.0243
0.0240
0.0243
0.0245
0.0240
0.0240
0.0243
0
0
0
0
0
0

PS
0.0425
0.0430
0.0429
0.0430
0.0425
0.0429
0.0434
0.0429
0.0425
0.0429
0.0434
0.0425
0.0425
0.0429
0
0
0
0
0
0

IV
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.2683
0.2687
0.2678
0.2686
0.2684
0.2682

SV
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.1499
0.1501
0.1496
0.1500
0.1499
0.1498

QN
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.0966
0.0968
0.0965
0.0967
0.0967
0.0966

TA
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.1553
0.1556
0.1551
0.1555
0.1554
0.1553

DA
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.1350
0.1352
0.1348
0.1352
0.1351
0.1350

IS
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.1226
0.1228
0.1224
0.1227
0.1227
0.1226

The final output (weights) is visually represented in Figure 3. It is very clear from Figure 3 that” Interview (IV)” is the most suitable technique to be selected, then the second number “Task Analysis (TA)”, then third “Survey (SV)”, fourth “Document Analysis (DA)”, fifth “Introspection (IS)”, and the last one is “Questionnaire (QN)”. Hence, the result generated shows that the technique is the best among the others. So on the basis of attributes of software environment this selection of elicitation technique has been done. These results for IV were obtained based on the weights assigned and the calculation process of pair-wise comparison. The process of pair-wise comparisons is shown from Tables 4–7, and the final calculation of summary matrix is shown in Table 8, and limit matrix in Table 9. From these calculations, it is concluded to select the best option among alternatives. The selected technique is well applicable and reliable for its selection purpose.

Figure 3: Graphical representation of weights of elicitation techniques.

The managerial implications of the proposed approach are that it can help practitioners in a better way to select the most appropriate elicitation technique among the available techniques. As the approach is based on several attributes as criteria, so it deals with multiple perspectives of a project in a better way and can lead the project to success.

5. Conclusion

In the process of software development, the important thing is requirements, which if gathered properly, then the end product will be according to the need of the user; otherwise, it will be rejected. It means that the development of software system is highly dependent on requirements. For the purpose of eliciting suitable requirements, the most adequate technique selection is required. Hence, selection of suitable technique will gather the most appropriate requirements, which in turn increase productivity and will provide protection to software industry, to clients and system developer from useless efforts, cost, wastage of time, and other resources. The increase in software success ratio and prevention from failure is mainly dependent on elicitation technique selection based on project attributes of software environment. In this research, the method applied for the selection of elicitation technique must be the most suitable one based on attributes of software project environments. ANP, which is one of the MCDM approaches, is very useful to solve decisions, to structure, and to plan problems where multiple criteria are involved.

In this research, the first step was to develop a network structure using ANP method, and the network structure designed is of goal, criteria, and alternatives associated with the criteria. In the network structure goal is to select suitable elicitation technique, criteria are project environment attributes, and alternatives are elicitation techniques. Due to this network structure requirement engineer understanding level becomes increased about elicitation techniques and project environment attributes. After network structure is designed in the next step, the weights are derived from well experienced persons (Experts), who worked in the software industry for years. The experts carried out the pairwise comparison of techniques with respect to attributes and then of attributes with respect to techniques. On the basis of this comparison, calculations have been done, which result in the Eigen values of the techniques and attributes. The consistency ratio was also calculated, which was less than 0.1 and was correct according to the rule. After weighted super and limit matrix were obtained, the limit matrix was actually the summarized form of all the matrices. After all the processes of pair-wise comparisons and calculating weighted and limit matrix, the results show clearly that IV with values 0.2683 and SV with values 0.1499 were the best choices among the available alternatives as they show high ranked values. The final results are obtained through limit matrix, which contains weights and on the basis of these weights, it can be very easy for a requirement engineer to take decision about most suitable technique selection. The proposed research results represent that the method is quite helpful, useful, and appropriate for decision making with respect to requirement elicitation technique selection. In the proposed study, it has been proved that the application of ANP method is very efficient for technique selection with respect to project environment attributes. In future, the proposed work can be extended by using some more efficient techniques like fuzzy ANP, fuzzy logic, roughest, and so on in order to ensure efficient selection of requirement elicitation technique.

Data Availability

No primary data were used to support this study.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Acknowledgments

This work was partially supported by the NSFC project (grant no. 61762058) and the Science and Technology Project of Gansu Province (grant no. 1610RJZA056).

References

N. A. M. Maiden and M. Hare, “Problem domain categories in requirements engineering,” International Journal of Human-Computer Studies, vol. 49, no. 3, pp. 281–304, 1998.

B. Nuseibeh and S. Easterbrook, “Requirements engineering: a roadmap,” in Proceedings of the Conference on the Future of Software Engineering, pp. 35–46, New York, NY, USA, June 2000.

A. M. Hickey and A. M. Davis, “Requirements elicitation and elicitation technique selection: model for two knowledge-intensive software development processes,” in Proceedings of the 36th Annual Hawaii International Conference on System Sciences, p. 10, Big Island, HI, USA, January 2003.

N. Garg, P. Agarwal, and S. Khan, “Recent advancements in requirement elicitation and prioritization techniques,” in Proceedings of the International Conference on Advances in Computer Engineering and Applications, pp. 237–240, Ghaziabad, India, March 2015.

M. Yousuf and M. Asger, “Comparison of various requirements elicitation techniques,” International Journal of Computer Applications, vol. 116, 2015.

D. Zowghi and C. Coulin, “Requirements elicitation: a survey of techniques, approaches, and tools,” In Engineering and Managing Software Requirements, Springer-Verlag, New York, NY, USA, pp. 19–46, 2005.

H. F. Hofmann and F. Lehner, “Requirements engineering as a success factor in software projects,” IEEE Software, vol. 18, no. 4, pp. 58–66, 2001.

B. Nuseibeh and S. M. Easterbrook, “Requirements engineering: a roadmap, the future of software engineering,” in Proceedings of the 22nd International Conference on Software Engineering, ICSE’00, A. C. W. Finkelstein, Ed., IEEE Computer Society Press, Limerick, Ireland, June 2000.

N. J. Cooke, “Varieties of knowledge elicitation techniques,” International Journal of Human-Computer Studies, vol. 41, no. 6, pp. 801–849, 1994.

A. M. Davis and P. Pei Hsia, “Giving voice to requirements engineering,” IEEE Software, vol. 11, no. 2, pp. 12–16, 1994.

A. M. Hickey and A. M. Davis, “Elicitation technique selection: how do experts do it?” in Proceedings of the 11th IEEE International Requirements Engineering Conference, pp. 169–178, Monterey Bay, CA, USA, September 2003.

T. Tsumaki and T. Tamai, “A framework for matching requirements engineering techniques to project characteristics and situation changes,” Situational Requirements Engineering Processes, vol. 44, 2005.

Y. Ayalew, “A framework for requirements elicitation techniques selection,” in Proceedings of the SEDE, pp. 92–97, Los Angeles, CA, USA, July 2006.

H. Ghanbari, J. Similä, and J. Markkula, “Utilizing online serious games to facilitate distributed requirements elicitation,” Journal of Systems and Software, vol. 109, pp. 32–49, 2015.

C. Burnay, I. J. Jureta, and S. Faulkner, “What stakeholders will or will not say: a theoretical and empirical study of topic importance in Requirements Engineering elicitation interviews,” Information Systems, vol. 46, pp. 61–81, 2014.

C. Ribeiro, C. Farinha, J. Pereira, and M. Mira da Silva, “Gamifying requirement elicitation: practical implications and outcomes in improving stakeholders collaboration,” Entertainment Computing, vol. 5, no. 4, pp. 335–345, 2014.

C. Ruf, A. Back, R. Bergmann, and M. Schlegel, “Elicitation of requirements for the design of mobile financial advisory services--instantiation and validation of the requirement data model with a multi-method approach,” in Proceedings of the 2015 48th Hawaii International Conference on System Sciences, pp. 1169–1178, Kauai, HI, USA, January 2015.

S. Chakraborty, S. Sarker, and S. Sarker, “An exploration into the process of requirements elicitation: a grounded approach,” Journal of the Association for Information Systems, vol. 11, no. 1, 2010.

O. Dieste and N. Juristo, “Systematic review and aggregation of empirical studies on elicitation techniques,” IEEE Transactions on Software Engineering, vol. 37, pp. 283–304, 2010.

L. Jiang, A. Eberlein, B. H. Far, and M. Mousavi, “A methodology for the selection of requirements engineering techniques,” Software & Systems Modeling, vol. 7, no. 3, pp. 303–328, 2008.

G. Beshah and M. Kifle, “Requirements elicitation techniques selection based on taxonomy of project type,” HiLCoE Journal of Computer Science and Technology, vol. 1, 2013.

S. Khanâ, A. B. Dulloo, and M. Verma, “Systematic review of requirement elicitation techniques,” International Journal of Information and Computation Technology, vol. 4, no. 2, pp. 133–138, 2014.

B. Davey and K. Parker, “Requirements elicitation problems: a literature analysis,” Issues in Informing Science and Information Technology, vol. 12, pp. 71–82, 2015.

M. A. Abbasi, J. Jabeen, Y. Hafeez, D. Batool, and N. Fareen, “Assessment of requirement elicitation tools and techniques by various parameters,” Software Engineering, vol. 3, pp. 7–11, 2015.

R. Yousef and T. Almarabeh, “An enhanced requirements elicitation framework based on business process models,” Scientific Research and Essays, vol. 10, no. 7, pp. 279–286, 2015.

M. Tariq, S. Farhan, H. Tauseef, and M. A. Fahiem, “A comparative analysis of elicitation techniques for design of smart requirements using situational characteristics,” International Journal of Multidisciplinary Sciences and Engineering, vol. 6, pp. 30–38, 2015.

S. Safdar, S. Zafar, N. Zafar, and N. F. Khan, “Machine learning based decision support systems (DSS) for heart disease diagnosis: a review,” Artificial Intelligence Review, vol. 50, no. 4, pp. 597–623, 2018.

I. Aouadni and A. Rebai, “Decision support system based on genetic algorithm and multi-criteria satisfaction analysis (MUSA) method for measuring job satisfaction,” Annals of Operations Research, vol. 256, no. 1, pp. 3–20, 2017.

M. Jemmali, M. Alharbi, and L. K. B. Melhim, “Intelligent decision-making algorithm for supplier evaluation based on multi-criteria preferences,” in Proceedings of the 2018 1st International Conference on Computer Applications & Information Security (ICCAIS), pp. 1–5, Riyadh, Saudi Arabia, April 2018.

I. Petkovics, J. Simon, P. Á, and Z. Čović, “Selection of unmanned aerial vehicle for precision agriculture with multi-criteria decision making algorithm,” in Proceedings of the 2017 IEEE 15th International Symposium on Intelligent Systems and Informatics (SISY), pp. 000151–000156, Subotica, Serbia, September 2017.

A. Schwenk-Ferrero and A. Andrianov, “Nuclear waste management decision-making support with MCDA,” Science and Technology of Nuclear Installations, vol. 2017, Article ID 9029406, 20 pages, 2017.

C. Fleig, D. Augenstein, and A. Maedche, Designing a Process Mining-Enabled Decision Support System for Business Process Standardization in ERP Implementation Projects, Springer, Cham, Switzerland, 2018.

S. Kheybari, F. M. Rezaie, and H. Farazmand, “Analytic network process: an overview of applications,” Applied Mathematics and Computation, vol. 367, p. 124780, 2020.

L. S. R. Supriadi and L. Sui Pheng, “Knowledge based decision support system (KBDSS),” in Business Continuity Management in Construction Singapore, pp. 155–174, Springer, Singapore, 2018.

A. Alaeddini and K. G. Murty, “DSS (decision support system) for allocating appointment times to calling patients at a medical facility,” in Case Studies in Operations Research: Applications of Optimal Decision Making, K. G. Murty, Ed., pp. 83–109, Springer, New York, NY, USA, 2015.

S. Nazir, S. Anwar, S. A. Khan et al., “Software component selection based on quality criteria using the analytic network process,” in Abstract and Applied Analysis, vol. 2014, 12 pages, 2014.

T. L. Saaty, “Fundamentals of the analytic network process,” in Proceedings of the 5th International Symposium on the Analytic Hierarchy Process, pp. 12–14, Kobe, Japan, August 1999.

Y. Ayalew and A. Masizana-Katongo, “A multi-criteria group decision support approach for requirements elicitation techniques selection,” Asian Journal of Information Technology, vol. 7, pp. 40–52, 2008.

L. C. Ronoh, G. M. Muchiri, and F. Wabwoba, “Factors affecting requirements elicitation for heterogeneous users of information systems,” International Journal of Computer Science Engineering and Technology, vol. 5, no. 3, pp. 35–39, 2015.

D. Carrizo, O. Dieste, and N. Juristo, “Systematizing requirements elicitation technique selection,” Information and Software Technology, vol. 56, no. 6, pp. 644–669, 2014.