An Approach for Selecting the Suitable Requirement Elicitation Technique

: Requirements elicitation is an initial phase in software development. In this phase, requirements engineers gather the requirements of the software under development from users, stakeholders and customers. The techniques used for gathering requirements have a big influence on the quality of requirements and the success of project. Many requirements elicitation techniques (RET) such as: interview, prototype and observation can be used for requirements gathering process. However, one technique is not suitable for all different projects. Usually requirement engineers select the RET based on personal preferences and assumptions such as; this is the only technique which they know. However, this subjective decision can result in using inappropriate RET. Using unsuitable RET may decrease the quality of elicited requirements. Even though researchers have proposed many techniques for elicitation, one of the challenging issues is to choose the suitable RET for specific situations. The purpose of this paper is to help requirement engineers to choose suitable RET. To do that firstly, we identify factors that affect in selecting RET. Secondly, an approach to select suitable RET is proposed. Thirdly, a prototype is developed to help requirements engineers and to ease the process of selectingelicitation technique. Lastly, experts evaluate the proposed approach and the prototype.


Introduction
In this information and technology age, the software demand is growing day by day. Requirements engineering, an initial phase of software development, plays a vital role in the development of quality software. Requirements elicitation is the most important and initial phase in requirements engineering. The accomplishment of software relies on the satisfaction of its users and the user satisfaction largely depends on the process of requirements elicitation (Nisar et. al, 2015).
There are five phases in Requirements Engineering (RE) process: requirements elicitation, requirements analysis, requirements specification, requirements validation and requirements management. The aim of requirements elicitation is to capture and discover stakeholder needs to identify what features the software system should have. Preparation, execution and analysis are required for each session of elicitation (Carrizo et. al, 2014). The activities during the preparation of elicitation session are: understanding application domain; identifying the sources of requirements; analyzing the stakeholders; selecting requirements elicitation techniques; and eliciting requirements. In this work, we focus on the activity of selecting requirements elicitation techniques. Requirements elicitation is not an easy task andit involvesa lot of human activity. Errors in this phase can affect the following phases of software development (Shah & Petal, 2014) and (Hussain et al. 2016). According to Khan et. al. (2014), most of the software projects have not been successful, 31% of the projects have been cancelled while 53% of projects have faced challenges such as cost overrun, budget overrun or content deficiencies. Only 16% of the projects have been successful. About 50% of all software projects fail because the final product does not meet the user expectations and demands. One of the reasons is poorly defined requirements. It seems that a lot of the delivered software does not fully meet the end userexpectation. Poorly defined system requirements are largely caused by ineffective collection of requirements. It is not important how many techniques employed but how these techniques are fit to capture the needs of stakeholders (Bangor et. al, 2008).
One of the challenging issues in requirement elicitation is selecting requirement elicitation techniques for specific situations. A number of factors influence the process of selection RET (Tiwari &Rathore, 2017). Project degree of criticalness, project size, project complexity (Darwish et. al, 2016), and number of stakeholdersare examples of the factors that influence the selection of suitable technique. If there are many stakeholders involved in the process of elicitation, for example, a questionnaire is more suitable than interview because by using online questionnaire, we can reach large number of people.
Requirement engineers are expected to employ good appropriate technique(s) that fit to the current situation in order to get the quality requirements. According to Hickey & Davis (2003), requirement engineers, who have extensive experience in requirement elicitation, have the ability to select the right elicitation techniques, but the majority of the requirement engineers have less experience. So it is difficult for requirement engineers to choose the right techniques in the right situation. Requirement engineers select the technique based on personal preferences such as: this is the only technique which they know them (Hassim (2017), Hussain et al., (2017), Darwish et. al (2016) and Brooke (1996), which results in low quality requirements (Hassim, 2017).
In this work, we help requirement engineers to choose suitable RET. Firstly, we identify factors that affect selecting RET. Secondly, an approach to select suitable RET is proposed. Thirdly, a prototype is developed to help requirements engineers and to ease the process of elicitation technique selection. Experts are invited to evaluate the approach and the prototype. This paper is structured as follows. Section 2 presents related works. Section 3 introduces the proposed approach. Section 4 presents some results, discussions and evaluations. Section 5 concludes the work.

Background and Related Works
Requirements Elicitation (RE) is the process of gathering the requirements of the software underdevelopment from stakeholders. It is an important and initial phase in software development life cycle. In requirements elicitation process, requirements engineers or analysts collect the requirements of the system from users, customers or stakeholders in order to identify the functionality of the system (Elijah et. al, 2017). It is strongly agreed that a good requirement elicitation process leads to good quality requirements and project success, while poor quality elicitation can lead to project failure Hassim (2017)  Although the previous research works propose different methods and hypothesis to tackle the problem of selecting the right requirement elicitation technique, the problem still exists and the requirement engineer or system analysts are not practicing the approaches that researchers proposed for selecting requirement elicitation techniques.This project focuses on 14 requirements elicitation techniques (RET) and 19 factors that affect the selection of RET. Based on these factors, an approach is proposed to help requirements engineers to choose the suitable elicitation technique. A prototype, based on the proposed approach,isdeveloped to ease the process of selecting RET. This prototype is helpful in requirements engineering phase. It can be used only for selecting suitable requirements elicitation technique. Other requirements elicitation activities such as: recording requirements are not included in this project.

The Proposed Approach
The proposed approach, as in Figure 1, is based on: factors that influence the requirement elicitation selection techniques, identified from literature, suitability matrix and criteria of mapping the factors to suggest the suitable technique. Suitability matrix table is a table that contains the requirement elicitation techniques and factors that influence the selection of RET.

Factors for selecting RET
Nineteen factors that influence the selection of requirement elicitation techniques are selected from the literature. The factors are categorized into four main factors: Elicitor, stakeholder, project and elicitation process. Each main factor contains several sub factors.

Figure1.Overview of the proposed approach
The elicitor, or requirements engineer, is one of factors that has influence the selection of requirement elicitation techniques.The first sub factor, elicitation experience, indicates number of earlier projects in which the elicitor has carried out elicitation activities. The second sub factor, familiarity with domain, indicates number of previous projects in the domain executed by the elicitor. Stakeholders can be users, customers, sponsors or even developers. For the project factor, the characteristics of the project are important for deciding which elicitation technique is suitable.Elicitation process includes the factors that are related to the achievement of the elicitation. We consider two sub factors in this category: time constraint and process time.

Suitability Matrix Table
Our first priority is to extract empirical evidences and expert opinions from the literature, but we observe that the available empirical evidence and expert recommendations are very limited. (Carrizo et. al, 2014) identify that there is shortage of empirical evidences so they used expert opinion and empirical evidences available plus their own experience to highlight the suitability of requirement elicitation techniques. (Carrizo et. al, 2014) discusses in details the suitability of techniques based on elicitor such as: elicitor experience, stakeholder such as: stakeholder availability, location, number of individuals in the process and elicitation process such as time of elicitation (start, middle or end of elicitation). However, they do not focus on the project characteristics that also influence the selection of requirement elicitation techniques such as project size, project, project complexity, requirement volatility and so on. Table 1 shows the suitability of the requirement elicitation techniques from the literature. We examine how different requirement elicitation techniques are suitable based onthese factors using the recommendations from the literature. The requirements elicitation technique is suitable (+), not suitable(X) or no influence (-) according to specific factor. Suitable (√): means the technique is recommended for such conditions and it is better to use this technique. Not suitable (x) means the technique is not recommended for specified condition and it may result wrong result compared to other available techniques. No influence (-) means it is not clear whether this technique is suitable for the situation or not. In Table 1, we show only one factor Elicitor due to space limitations.

Mapping Criteria
After identifying the factors that influence the selection requirement elicitation techniques, one of the main objectives of this work is to map the influencing factors and requirement elicitation techniques. Criteria isused to select the top requirement elicitation techniques that best suit the specified project environment. In order to map the factors and requirement elicitation technique, we take the following steps: First, store the suitability matrix in MYQL database. Second, capture the user input(for example: project size: large, number of stakeholders: 5, etc) through the prototype. Third, read the suitability of requirement elicitation techniques (based on user input) from the database. Fourth, count the suitability score for each technique and select the techniques with the maximum three values. To see how the proposed prototype works, follow this link: http://rets.tilmaamesoft.com.

Results And Discussion
Questionnaire and prototype are usedas tool to conduct the experts review on the proposed approach. They are distributed to requirement engineering experts through online. We got responses from five experts.The evaluation focuses on two aspects. First one is to examine the reliability of the proposed criteria. Experts are asked to give their opinion if the proposed approachis suggesting the suitable requirement elicitation technique for their projects after using the prototype online. 80% of experts, state that the proposed criteria suggest the suitable requirement elicitation technique for their projects, while 20% of respondents disagree. We also evaluate how the experts agree on the considered factors in the project and they strongly agree in average of 63%. Secondly, we evaluate the usability of the proposed criteria. We used system usability scale (SUS) by Brooke (1996). After applying SUS score rules to our scenario, we got 71.5 and it is acceptablesince it is above 70.

Conclusion
This work addresses the issue of selecting the suitable requirements elicitation technique for gathering software requirements. From literature, we identify factors to be considered to select the suitable requirement elicitation techniques. Also, we identify recommendations on how requirement elicitation technique is preferable over others considering the influencing factors. A prototype is developed to automate the proposed criteria. Experts have evaluated the reliability criteria and the usability of the prototype. One of the limitations of this study is that we only consider some factors. There are more factors that could be considered in future. We also recommend to develop a framework that does not only focus on selecting RETs but also ease the process of selecting techniques and tools used in different stages of software development life cycle.