Multi-Criteria Decision-Making Approach for Selection of Requirements Elicitation Techniques based on the Best-Worst Method

During requirements elicitation stage, requirements engineers gather system requirements and drive stakeholders to convey needs and desired software functionality. The elicitation techniques used to acquire software requirements significantly impact the quality of elicited requirements. Several elicitation techniques have been proposed for the Requirement Engineering (RE) process; however, these techniques are rarely used in reality due to a lack of empirical and relative appraisals to assist software team members in deciding on the most appropriate technique. Requirement engineers encounter difficulty in deciding the suitable elicitation technique to adopt for a certain software project. This difficulty is due to a lack of knowledge regarding the available elicitation techniques, their efficacy, and how appropriate they are for a certain project. According to the literature, requirements engineering processes benefit from the use of Multi-Criteria Decision-Making (MCDM) approaches within particular contexts. An optimal structure is constitutionally presented within the area of the requirements engineering process; hence, the demonstration of a robust decision-making method in the requirements engineering process should motivate a higher level of satisfaction with software projects developed in this way. This study proposes an approach for using the MCDM method in the requirements engineering process. The study contains a model for investigating the selection of an appropriate elicitation technique based on a decision-making method, namely, the Best-Worst Method (BWM). The findings of the proposed model demonstrate the BWM’s power in solving complex decision problems involving several criteria and alternatives. Keywords—Requirements elicitation; elicitation techniques; decision support methods; Best-Worst Method; BWM


I. INTRODUCTION
In Software Engineering (SE), the software requirements are the services that the software provides to customers to satisfy their needs. Additionally, the software requirements are constraints on its functionality [1]. Requirements engineering is the process of analyzing and determining these software services and constraints. Often, a focused investigation takes place as a pre-step at the RE stage. The focused investigation seeks to answer general queries, such as: does the software contribute to the goals of the company? Is the implementation plan appropriate considering the budget and schedule [1]? RE activities are introduced at the initial phase of the Software Development Life Cycle (SDLS), which allows the development team to draw a clear view of the functionalities and benefits that the system could provide.
The process of RE consists of activities such as communicating with software stakeholders to discover requirements (elicitation), creating a specification document based on the discovered requirements, and validating the requirements against the stakeholders' needs [2]. The requirements elicitation activity allows developers to better understand the stakeholders' needs and how they can benefit from using the new system. This is achieved by working with both stakeholders and developers in order to analyze the problem domain and the current limitations, along with the services and work activities that stakeholders needs.
However, gathering requirements from stakeholders is a difficult task due to system stakeholders' lack of knowledge about what they want. In addition, developers may have a lack of stakeholders' domain, which might lead to a misunderstanding regarding what customers need during the elicitation process. Furthermore, several stakeholders might emphasize the same requirements in different ways, which may result in requirements conflicts. Despite the dynamic environment of the analysis stage, new customers will bring about changes to the project's initial requirements and the addition of new requirements. Also, political and environmental issues might affect the system requirements and the requirements gathering process.
Generally, the activities in the requirements elicitation process include requirements finding and understanding, requirements categorisation, requirements ranking, and requirements documentation. The requirements elicitation process is based on several iterations with ongoing feedback between these activities. There are several requirements elicitation techniques that can be used to assist developers in discovering and gathering the system requirements, which results in delivering satisfactory software to stakeholders [3]. Increasing the number of requirements elicitation techniques makes it difficult for the development team to select the most appropriate technique for a certain software project. Several challenges accompany the selection of the appropriate elicitation technique, such as the type of software methodology, developers experience, customer knowledge, and available technologies. There is no elicitation technique that is appropriate for all projects; however, each software project has its circumstances that affect the selection of an appropriate requirements elicitation technique. The selection of an elicitation technique might be affected by various criteria that influence the software project, making it important for the development team to be aware of this. These criteria include, for example, the diversity of customers and their availability, and customers' skills and experiences. This paper investigates the incorporation of a MCDM-specifically, the BWM-into requirement elicitation activity in order to select the appropriate requirement elicitation technique. The BWM framework consists of a set of elicitation techniques that serve as alternatives that are weighted against each other with respect to several criteria that influence the software project. Each elicitation technique is evaluated with respect to these criteria, and the final selection is made based on the overall weight of all techniques. This paper is organized as follows: Section 2 describes the work related to this research topic. Section 3 introduces the BWM method. Sections 4 describes the proposed criteria and alternatives. Section 5 shows the BWM structure in the requirement elicitation process. Section 6 presents the results and discussion. Finally, Section 7 offers a conclusion and suggests possible future work II. RELATED WORK Tiwari and Rathore sought to enhance the requirement elicitation process by introducing an approach in order to choose a subset of requirement elicitation methods [4]. The authors identified several criteria with respect to three dimensions-namely, the people, the project, and the software process development-and constructed the three p matrix for the three dimensions and their relationship with the elicitation methods. The selection decision is made based on the analyst's experience and the three p matrix mapping mechanism [4]. Ribeiro et al. [5] introduced a method for determining the acceptability and effectiveness of a web collaborative tool whose primary goal is to gather requirements from stakeholders. As a development tool, the six thinking hats technique and gamification were applied. The primary objective of this research is to strengthen stakeholder collaboration by discussing findings and their impacts [5]. The requirements elicitation activity can be viewed from a behavioral and social perspective, which requires equally collaborative communication by all stakeholders. Chakraborty et al. [6] introduced a model based on a conceptualized method in order to provide a road map for the requirements elicitation activity. In their model, the authors addressed interaction dynamics between future system users and requirements engineers. Their study is focused on the four states, and it highlights potential variables that are likely to cause movement from one stage to the next [6].
A prototype was suggested by Vijayan and Raju to be used for requirement elicitation in order to avoid system errors caused by a lack of communication between users and requirements engineers [7]. Domain knowledge acquisition, system understanding, requirements elicitation, prototype validation, and requirements stabilization are the five processes in this prototype method. Such a method is appropriate for small to medium-sized projects, but it adds to the project's cost and time is also required to build a prototype model of the project. Requirements ambiguity has a negative influence on several significant factors, such as quality and cost [8]. There are difficulties in defining the complete and correct requirements in the early stages. Thus, having a prototype model of how the system should look can assist customers in understanding the system's layout and structure. Poorly stated requirements, according to Jain and Ingle [9], are due to inconsistencies in the choosing of requirements elicitation techniques, the amount of information, and missing requirements on standard security solutions. Mulla and Girase [10] stated that eliciting requirements is a difficult undertaking, particularly in large software projects with a wealth of details and several stakeholders with various perspectives. Moreover, Zhang et al. [11] suggested that a lack of requirements elicitation activity is the main cause of software project failure besides inadequate project scope.
The significance of the human factor at the requirements elicitation stage has been studied by different researchers [12], [13], [14], [15], [16], [17], [18]. For example, Fuentes et al. [12] presented a comprehensive Unified Modeling Language (UML) schemata for social issues, providing patterns in order to reconcile stakeholder conflicts. In addition, it is believed that the elicitation process should involve any factor that might impact the developed system or its use in terms of meeting the customers' needs [12]. Dragicevic and Celar [13] presented a method for requirement elicitation, documentation, and validation called MeDoV. Even-driven process (EPC) and UML activity diagrams were used to model requirements. The high acceptance of EPC by business users made it the preferred method of the authors. Additionally, the authors introduced the adoption of the MoDeV framework for requirement engineering [13].
Yousuf et al. [19] proposed a method for selecting appropriate elicitation techniques based on a variety of parameters, including system and requirements type, stakeholder involvement, schedule, and team skills and experience. Abbasi et al. [20] compared the strength of several requirement elicitation methods and requirement tools with respect to numerous factors. In addition, the authors addressed the disadvantages of using a single requirement elicitation technique. Factors such as project environment and stakeholder characteristics were specified by Anwar and Razali [21] as requiring consideration in order to develop a step-by-step strategy to decide the best requirements elicitation techniques for a specific project. Furthermore, Hickey and Davis' [22] mathematical model of requirement elicitation discussed what requirements engineers need to consider during requirement elicitation activity, how to select the appropriate elicitation techniques, and how to enhance the likelihood that the system will fulfill stakeholders' needs.
Darwish et al. [23] investigated the selection of requirements elicitation techniques based on an artificial neural network (ANN) model in order to minimize human engagement in the selection stage. The introduced model can recommend appropriate techniques for gathering information. In addition, the model depends on a set of features representing past requirement elicitation scenarios, such as project complexity.
Li et al. [24] studied the selection of requirement elicitation techniques based on the Analytic Network Process (ANP). The ANP has the ability to structure complex decision problems in a network containing several criteria that affect the selection of elicitation techniques. The authors identified 14 criteria, such as stakeholder availability, reusable requirements availability, project schedule constraints, financial constraints, stakeholder relationship, stakeholder diversity, existing system maintenance, etc. [24]. techniques as alternatives: interview, surveys, task analysis, introspection, questionnaire, and document analysis [24].

III. THE BEST WORST METHOD
The best-worst method (BWM), introduced by Rezaei [25], is a new approach that, since its presentation, has stood out for researchers from different disciplines. Its ease of use, the more modest number of comparisons, and the steadier judgments, in contrast with comparable techniques such as the Analytic Hierarchy Process (AHP) and ANP, have made the BWM a trustworthy and attractive approach. The BWM can assist decision makers in deciding criteria weights by distinguishing the best (i.e., generally positive or generally significant) and the worst (i.e., least significant) criteria. Moreover, pairwise comparisons are then completed based on each of the two criteria (i.e., best and worst) and other criteria. After that, the criteria weights are dictated by tackling a minimax problem. Despite prioritization in BWM being demonstrated to be sensible, it can be enhanced to catch the decision makers' uncertainty. Two vectors of comparison (best-to-other criteria and other criteria-to-worst) are equally significant in the BWM. In addition, the decision maker's confidence in the best-toothers and others-to-worst judgments are treated as equally significant. Moreover, the BWM expects decision makers to be completely sure about the best and worst criteria, along with the corresponding pairwise comparisons [26]. The decisionmakers use the AHP fundamental scale introduced by Saaty [27] to obtain their judgments. Extreme importance Similar to the AHP and the ANP, the BWM uses pairwise comparisons, yet the BWM is a more effective method in some ways than the AHP and the ANP, which has made it more common lately. For example, the BWM requires fewer pairwise comparisons than the AHP. Furthermore, the BWM involves less complex pairwise comparisons as, in the BWM, decision makers only need to fill the up part of the pairwise comparison with no need to use the reciprocal of the 1-9 scale, which makes it easier for the decision makers to measure.
Several researchers have investigated incorporating the BWM into software development. For example, Aljuhani and Alhubaishy [28] adopted the BWM in Mobile-D development, identifying nine insertion points that can benefit from the adoption of the BWM in order to reconcile conflicting perspectives among the team members. Furthermore, Alhubaishy and Aljuhani [29] investigated the use of the BWM in cloud computing in order to manage resource allocation and prioritize several tasks.

A. Steps of BWM
As stated by Rezaei [25], the BWM consists of five main steps, which are as follows: Step 1. The decision criteria {c 1 , c 2 , ..., c n } that impact the proposed solutions or alternatives are specified.
Step 2. The best and the worst criteria are specified by the decision makers without making a comparison at this step.
Step 3. A series of judgments of the other criteria are made with respect to the best criterion, based on the proposed fundamental scale in table I and what the outcome vector would be [25]: Where a Bj reflects the comparison of criterion j with respect to the best criterion B.
Step 4. A series of judgments are made on the worst criterion in relation to the other criteria based on the proposed fundamental scale in table I and what the outcome vector would be [25]: Where a 1W reflects the comparison of criterion j with respect to the worst criterion W.
Step 5. The criteria optimum weights w * 1 , w * 2 , ..., w * n are identified, and it is the weight where, we have w B /w j = a Bj and w j /w w = a jw for each pair of w B /w j and w j /w w [25]. Also, in order to determine the solution, the maximum absolute differences w B wj − a Bj and wj ww − a jw should be minimized to be to satisfy these conditions for all j as stated by [25]. This leads to the following problem: Thus, problem 1 has been transferred to the next problem: We obtain the ideal weights and ξ * by solving problem 2.
www.ijacsa.thesai.org Moreover, the consistency ratio is obtained based on the following problem: Where the consistency index depends on the number of criteria included in the decision problem as shown in [25]. While the consistency ratio value should be < 0.10 as the comparisons would otherwise be considered inconsistent. The BWM steps are visually represented in Fig. 1.

IV. PROPOSED CRITERIA FOR SELECTING PROCESS
Technique selection for the elicitation process is greatly affected by project environment criteria (attributes). It may be appropriate to use one technique for eliciting requirements with respect to one attribute, but not for the rest of them. Identifying the factors that influence the selection process is essential for choosing the right elicitation technique. To show their inter-dependencies, these criteria are compared with each other and compared in relation to each alternative or elicitation technique. Criteria are used to compare the elicitation techniques, allowing for a better understanding of how the selection process is affected by each criterion. Therefore, to select a suitable elicitation technique, this paper proposes nine criteria, which are taken from [24], [30], [18], and [31]. It is valuable to address how different studies use the same methodology with different criteria. The studied criteria are as follows: Similar to the ANP and AHP, the BWM structure for selecting the appropriate elicitation technique consists of three levels. The first level explains the goal of the adoption of the BWM, which in this paper is selecting the best elicitation technique. The second level describes the selection criteria, which are introduced in the previous section. The third level contains the alternatives, which are the elicitation techniques that are evaluated against each other in order to select the most appropriate one with respect to various attributes. Eliciting requirements can be done using a variety of methods; however, in this paper, six traditional elicitation techniques are selected to evaluate in the BWM model. These techniques are [20], [24], [32]:

A. BWM Model Evaluation Based on Expert's Opinion
In this paper, the main objective is to investigate the adoption of the BWM for selecting the appropriate requirement elicitation technique during software project development. The chosen research methodology is the case study methodology, which is described in [11]. In this regard, two research questions are raised in order to better focus the case study: 1) how can the BWM help in selecting the appropriate requirement elicitation technique, and 2) how can the BWM affect the team members' communication and productivity? The units of analysis for the proposed study are derived from these questions. Evaluating and selecting are two units of analysis that are appropriate to use, as well as the experts' opinion of the BWM in selecting the suitable elicitation technique.
Criteria that affect the selection of elicitation techniques were identified as a first step in BWM evaluation in order to highlight the BWM's abilities and benefits. The source of the collected data was 27 domain experts, and the data collection tool was a questionnaire distributed among these experts. The experts were asked to evaluate the proposed criteria in order to weight each criterion in the model. By following the BWM steps, the experts first determined the best criterion and made a pairwise comparison to specify the weight of the best chosen criterion over all of the other criteria, as shown in Table II. The pairwise comparison in Table II can be read as follows: the ASTK criterion is 4,9,8,4,8,5,4 and 5 times more important than the AUCD, RQ, ACT, AR, FCO, DSTK, UCM and EXP criteria, respectively. In other words, the ASTK should be given preference over the EXP criterion, for example, as it is 5 times more important.
Then, the experts made judgments based on the pairwise comparison among all of the other criteria over the worst selected criterion. In table III FCO should be given preference over RQ, for example, but the judgement between the two criteria indicates that there is a weak level of preference of FCO over RQ, as FCO is only 2 times as important as RQ. In addition, ASTK is given preference over RQ as it is 9 times more important, which means that there is an extreme preference for ASTK over RQ.

VI. RESULTS AND DISCUSSION
The aggregated result based on 27 domain experts shows that the ASTK criterion was evaluated as the most significant attribute for selecting the appropriate elicitation technique. The AR criterion was ranked in the second position, followed by EXP and UCM. The AUCD criterion was ranked in the fifth position. ACT and RQ were ranked in the sixth and seventh positions, respectively. FCO was ranked in the eight position, while DSTK was the least important. The overall weights of all criteria are shown in Table IV.
Furthermore, based on the BWM, the IV technique is evaluated as the most appropriate elicitation technique. The results also show that TA is ranked in the second position, followed by the DA technique. Moreover, SV was ranked in the fourth position, followed by QN and IS. The final weights for all techniques are shown in Table V.
The domain experts addressed some benefits they gained from this study. For example, the BWM reconciled conflicting opinions among the team members using a scientific approach. The power of the BWM helps the development team to easily solve complex and unstructured problems. In addition, the structure of the presented method allows every member to participate in the decision process based on his/her experience. This way, a high level of satisfaction among these members is ensured, which might be reflected in the project's quality. The BWM assists in making decisions with respect to several attributes affecting the decision-making process. Moreover, the BWM provides team members or managers with a better   understanding about the most significant criteria to consider when selecting the suitable elicitation technique. The BWM also produces highly consistent findings for the consistency ratio value for each paired comparison. Here, the consistency ratio was 0.08, which is less than the maximum acceptable consistency ratio of 0.10.
These results demonstrate that the BWM can be integrated into requirement elicitation activities, as shown in Table IV and  Table V, thereby validating the method's viability. Regarding the decision model presented here, there is a key issue. At least one team member (such as a project leader) would involve significant BWM training, since it is an integral part of the requirement elicitation activities. The BWM can be applied to impromptu decision crises not covered by the presented model. After all, the cost of integrating the BWM into the requirement elicitation stage is included in this.

VII. CONCLUSION
It is essential to use the most appropriate selection approach in order to elicit relevant requirements. The most appropriate technique will gather the most relevant requirements, increasing productivity and ensuring more successful software projects within the planned budget and schedule. The requirement elicitation activity was contextualized in this paper by applying the BWM decision-making method. In particular, this study concentrates on selecting the appropriate elicitation technique for a certain project with respect to multiple attributes affecting the selection process. The requirements engineering stage is a critical stage in the software life-cycle; therefore, selecting the most suitable requirement elicitation technique is important in order to ensure project success. A total of 27 domain experts participated in this investigation by adopting the BWM for selecting the best elicitation technique. The participants entered their judgments in BWM pairwise comparisons, and the final results were obtained based on the aggregated results of all experts. The BWM results addressed the importance of the ASTK criterion during gathering requirements. The interview was selected as the best elicitation technique based on the BWM results. The research findings showed the power of the BWM for solving complicated problems in less time as compared to similar approaches, such as the AHP and the ANP. The introduced method requires 2n-3 comparisons, while AHP requires n(n-1)/2 comparisons, where n is the number of elements in the model.
The following are some of the advantages of using the model presented in this paper: • A formalized decision-making process is established to help improve the structure and adaptability of the selection of the requirement elicitation technique.
• Based on a scientific approach, it is possible to reconcile different perspectives when selecting the most suitable elicitation technique.
In the future, the BWM can be integrated into other approaches in order to enhance the accuracy of its outputs. For example, it can be integrated with a fuzzy set to provide better results in handling subjective assessments and roughness when evaluating a model's items. Building an automated BWM tool to meet the RE process and its values is another future project that could be undertaken. However, the adoption of a multi-decision support approach at the requirement elicitation stage requires comprehensive knowledge of the problem area, to ensure that the most effective attributes are identified and techniques to avoid intensive computations are put to use.