DOI:10.32604/cmc.2021.013263
| Computers, Materials & Continua DOI:10.32604/cmc.2021.013263 | |
| Review |
Economical Requirements Elicitation Techniques During COVID-19: A Systematic Literature Review
1Department of Software Engineering, National University of Modern Languages, Islamabad, Pakistan
2Department of Software Engineering, College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia
*Corresponding Author: Tauqeer ul Amin. Email: tauqeer.ulamin@gmail.com
Received: 30 August 2020; Accepted: 02 January 2021
Abstract: Requirements elicitation is a fundamental phase of software development in which an analyst discovers the needs of different stakeholders and transforms them into requirements. This phase is cost- and time-intensive, and a project may fail if there are excessive costs and schedule overruns. COVID-19 has affected the software industry by reducing interactions between developers and customers. Such a lack of interaction is a key reason for the failure of software projects. Projects can also fail when customers do not know precisely what they want. Furthermore, selecting the unsuitable elicitation technique can also cause project failure. The present study, therefore, aimed to identify which requirements elicitation technique is the most cost-effective for large-scale projects when time to market is a critical issue or when the customer is not available. To that end, we conducted a systematic literature review on requirements elicitation techniques. Most primary studies identified introspection as the best technique, followed by survey and brainstorming. This finding suggests that introspection should be the first choice of elicitation technique, especially when the customer is not available or the project has strict time and cost constraints. Moreover, introspection should also be used as the starting point in the elicitation process of a large-scale project, and all known requirements should be elicited using this technique.
Keywords: COVID-19; software engineering; requirements engineering; requirements elicitation; introspection; project failure; SLR on elicitation techniques; large-scale projects; economical elicitation techniques; cost-effective; time constraints
Despite a long tradition of requirements engineering research, some issues remain regarding requirements engineering and software projects. The present study focused on the elicitation of requirements, which is the first step in the requirements engineering process. The purpose of requirements elicitation is to determine stakeholders’ needs and wants [1,2]. Previous studies have examined various elicitation methods, including their advantages and disadvantages [3,4]. Interestingly, 60% of the projects considered in the Standish Group Report were not completed on time and therefore failed [5]. In addition to time constraints, several other risk factors associated with requirements elicitation can cause software project failure [6,7]. Furthermore, such risk factors can give rise to inaccurate resource allocation [8]. Similarly, when a product’s time to market is crucial, selecting the inappropriate requirements elicitation technique can also cause software project failure [9,10].
Customers and software development organizations always seek out cost-effective systems. However, this has become incredibly challenging during the COVID-19 pandemic. As a result of COVID-19, customers cannot directly interact with system analysts during the elicitation process. This lack of interaction has become another cause for the failure of recent software projects. Likewise, customers might not specify or fail to include essential features, based on the presumption that such features are apparent [11]. This type of issue becomes more severe if the customer wants the product to be ready in a relatively short period of time [12]. Introspection is a technique in which system analysts use their experience to determine what users need from the system. It has been suggested that this technique should only be used if the analyst has domain knowledge about the system and is familiar with the structure of the organization’s business processes [13].
This study conducted a systematic literature review to investigate the cost-effectiveness of various requirements elicitation techniques. The findings can help identify the best technique to use when the customer is unavailable or unable to provide requirements. During the pilot study for the review, we observed that researchers have recommended various time-saving elicitation techniques. The main idea is to measure the cost-effectiveness of requirements elicitation techniques that can be used when a product’s time to market is short. Below, we briefly define the main requirements elicitation techniques discussed in this review.
• Prototyping is used when the customer is uncertain about the requirements or when early feedback is needed [14,15]. The prototype can be a throwaway, in that it may be used only for validation purposes, or it can be evolutionary, in that it may be used as part of the actual system.
• In the interview technique, a system analyst asks stakeholders questions and documents the responses [1]. Interview questions can be open- or closed-ended, depending on the situation [10]. The interviewee has more control during a close-ended interview than in an open-ended one.
• Introspection is a technique where analysts determine requirements based on their own thoughts, beliefs, and experiences [16]. A prerequisite for this technique is that the system analysts must have domain knowledge and awareness of the organization’s business processes.
• Brainstorming is a group technique in which stakeholders from different domains share ideas openly and rapidly [17]. It is mostly used at the start of the elicitation process and has two phases: the generation phase, where ideas are generated, and the evolution phase, where they are discussed.
• A focus group is a team of diverse stakeholders with different skill sets, usually led by a moderator to identify high-level features of the product [17]. A focus group is like a group interview from which qualitative data can be obtained more quickly.
• In joint application development (JAD), different stakeholder representatives meet under the supervision of an unbiased facilitator. The members can include system analysts, customers, developers, and architects [18].
• When using observation, an analyst observes users in their natural environment. Observation can be active, where analysts ask questions, or passive, where user interactions are under observation [19].
• Ethnography is used when system analysts want to communicate with various stakeholders to identify problems that might lead to insufficient requirements. Here, the observer inhabits the user’s environment to obtain thorough observations [18,20].
• Scenarios refer to the sequence of interactions between the user and the system. Scenarios cover not only the normal flow of events but also exceptions [18,21]. A scenario can help determine which functional requirements should be included in the system [22].
The rest of this paper is organized as follows. Section 2 discusses the related work while Section 3 describes the method. Section 4 presents the results and discussion while Section 5 focuses on validity issues. Lastly, Section 6 concludes with the study’s implications and directions for future research.
While many studies have investigated requirements elicitation, only a few have considered technique selection under the condition of time constraints. Examining several techniques and their uses, Coulin et al. [23] highlighted eight core techniques and their alternatives, including interview, group work, ethnography, prototyping, goal-based approach, scenarios, and viewpoints. The authors found that most requirements elicitation activities should be performed in conjunction with each other and found interviews, group workshops, observation, goals, and scenarios the most commonly used techniques. By contrast, the authors suggested using introspection when the user has no previous experience and the analyst has in-depth domain knowledge.
Mishra et al. [10] developed the Situational Requirement Method System (SRMS), which helps users select the appropriate elicitation method for a given situation. This research suggested that if only a few hours are available, then role-playing should be employed; if there are two to three days, the workshop technique should be used, provided the customer is experienced. The authors further noted that if customers are experienced and can articulate their needs, workshops and brainstorming can be beneficial; otherwise, ethnography or interviews are recommended. If a meeting is possible between both teams, then brainstorming and workshop are effective. If the budget is limited, storytelling or storyboarding can be used. A prototype can be used if the user experience is critical. For complex projects, the authors recommended using multiple techniques simultaneously to elicit the maximum number of requirements.
Kiran et al. [24] examined various requirements elicitation techniques that are used to build open-source applications. These techniques include groupware tools, web surveys, interviews, introspection, and analysis. It is suggested that if a stakeholder is not available, scenario is the best option; meanwhile, a web survey is recommended if a large number of responders need to be reached. Interviews should be used when complex data are under investigation. Similarly, analysis is recommended when it is necessary to improve an existing system or substitute it with an alternative system.. The use of introspection is recommended when requirements are already known to the analyst. The authors also suggested using introspection when the customer is not available for elicitation sessions.
Garg et al. [25] divided elicitation techniques into direct and indirect approaches. The direct approach is used to improve knowledge about the problem under discussion. Interviews, case studies, and prototyping are the most common examples of this approach. Meanwhile, if information is scattered, the indirect approach is suggested; the most common examples of this approach are questionnaires and document analysis. This study also considered techniques such as task analysis, interviews, introspection, protocol analysis, and scenarios. In task analysis, a high-level task is divided into subtasks that the user performs to accomplish the high-level task. Interview is an effective way to gather a significant amount of data. During introspection, the analyst develops requirements based on what the system should have. Garg et al. [25] further found that introspection can be effective when an analyst is familiar with the domain and knows the user’s business processes. The authors further reported that scenarios could facilitate a better understanding of the system due to interactions between user and system.
To our knowledge, no prior study has investigated the cost-effectiveness of requirements elicitation techniques where the product’s time to market is limited. Therefore, we aimed to assess the cost-effectiveness of different requirements elicitation techniques when the product’s time to market is limited or when the customer is not available or does not the requirements.
This study employed a systematic literature review [26], which is a well-defined approach for identifying, assessing, and interpreting all available studies in a field of interest [23,27]. This study followed Kitchenham’s guidelines to assess the cost-effectiveness of different requirements elicitation techniques.
Fig. 1 shows the eight phases of the study method: the need for systematic literature review, research question formulation, search strategy, study selection, inclusion/exclusion criteria, quality assessment procedure, data extraction, and data composition.
Figure 1: Research method
3.1 The Need for a Systematic Literature Review
One main reason for the failure of software projects is an inability to collect complete, correct, and unambiguous requirements [6,28,29]. Such issues can be caused by a lack of user involvement, incomplete requirements, inconsistent requirements, or changes in requirements. Various elicitation techniques are discussed in the literature, such as interview, introspection, questionnaire/survey, JAD/RAD, focus group, observation, laddering, and card sorting. Selection of an inappropriate elicitation technique may lead to project failure [9]. A systematic literature review is thus required to summarize the findings of existing studies of elicitation techniques and to determine their cost-effectiveness.
3.2 Defining the Research Question
During the pilot study, we noticed that several studies had already compared different elicitation techniques. However, we did not find any that aimed to determine the cost-effectiveness of different elicitation techniques when the product’s time to market is a key issue. Therefore, this review aimed to answer the following research question: Which requirements elicitation technique is cost-effective for large scale projects in which time to market is the key issue?
To answer the research question, the following keywords were used to construct a search string: Requirements, elicitation, software, and cost-effective. The search string formulated on the basis of these keywords was as follows:
Requirements AND (elicitation OR gathering OR acquiring) AND software AND “cost effective”
We also used synonyms of the keywords to expand the search query.
3.3 Defining the Search Strategy
Kitchenham [26,27] recommended using different electronic databases when performing a systematic literature review. We therefore used the following:
• ACM Digital Library
• IEEE Digital Library
• Science Direct
• Springer Link
• Others
Additional electronic databases were consulted but not included due to availability issues. We performed trial searches using a search string constructed through a combination of different keywords.
As suggested by Kitchenham, the selection criteria were determined as part of the protocol definition. We reviewed the titles, keywords, and abstracts of the extracted articles to determine their relevance. The full article was read to check its soundness and to obtain essential data. It was also necessary to examine the selected studies to check for similar articles. If there were similar publications from different databases, only the most recent ones were considered.
3.5 Inclusion and Exclusion Criteria
In systematic literature reviews, inclusion and exclusion criteria are used to select the primary studies. This study adopted the following inclusion criteria:
• Studies that discussed the cost-effectiveness of software requirements elicitation techniques
• Book chapters, conference papers, and journal papers
• Articles related to the software engineering domain
• Articles that answered the research question
• Articles that were free or openly accessible in Pakistan
• Articles published between 2000 and 2020
The following material was excluded because of irrelevance:
• Articles written in a language other than English
• Slides, personal opinions, magazine reports, news articles, and web pages
3.6 Quality Assessment Procedures
Aside from the above mentioned inclusion/exclusion criteria, it was also necessary to gauge the quality of the selected studies to minimize researcher bias and maximize internal and external validity [26]. Our quality assessment criteria were constructed following Davis et al. [4]. Appendix A shows the quality assessment form used in this study.
Data extraction concerns the useful information that was extracted from the selected studies. Appendix B provides the data-extraction form used to record publication-related information. This fulfilled the quality-assessment criteria listed in Appendix A.
The results retrieved from the selected studies were compiled and put into tabular form for better visualization.
The search string execution and data extraction were performed between February 2020 and May 2020. Fig. 2 shows the workflow for data collection. To address the research question, 4,751 articles from different electronic databases were identified based on the criteria specified in Section 3.4.
Figure 2: Search strategy
We read the titles and abstracts of the selected articles, and out of the 4,751 articles, 408 were selected in the initial scan. After further filtering that involved reading the full articles, 88 papers were selected. Then, of those 88 articles, 38 were discarded based on the quality criteria mentioned in Section 3.6. Tab. 1 summarizes the articles extracted for this study.
Table 1: List of extracted results
Fifty studies were selected based on the quality assessment criteria. Tab. 2 lists the articles used to perform the systematic literature review.
Table 2: Selected research articles
All key findings from the articles were put into a form, as shown in Appendix C. Tab. 3 presents the key data from some of the studies. Only broad data were extracted and stored in the form.
Table 3: Selected articles with features and comments
Here, we present studies that discussed the cost-effectiveness of requirements elicitation techniques when the product’s time to market was the key issue. From the 50 selected studies, 15 requirements elicitation techniques were identified. The selection criteria are explained in Section 3.4. Tab. 4 shows that 62% of the selected studies recommended introspection, 34% recommended questionnaires, 24% recommended brainstorming, and 24% recommended interviews.
Table 4: Elicitation techniques and their cost-effectiveness under time constraints
Fig. 3 shows the usage percentage of each elicitation technique, where it is clear that the most-used elicitation technique is introspection when cost-effectiveness and time constraints are key issues. The results indicate the following. First, introspection is the leading elicitation technique used when customers want early system deployment to meet their business needs. Second, introspection may help the developer organization release the software early when the critical issue is limited time to market. Third, if the customer is not available or cannot explain the required characteristics, introspection should be used. Fourth, introspection should be used as the starting point in the elicitation process for a large-scale project, and all known requirements should be specified using this technique. In this way, the project team can reduce time spent on the elicitation process, thereby reducing the time and cost of the whole project.
Figure 3: Usage percentage of elicitation techniques
This research highlights the fact that we know little about introspection; it is one of the least-researched techniques for software requirements elicitation. Only 50 related studies were identified between 2000 and 2020 using the selection and quality criteria discussed previously. Several studies have concluded that multiple requirements elicitation techniques should be used to obtain the requirements for a given software project.
This study was performed systematically, as described in Section 3. Articles were selected based on the search strategy and quality assessment criteria discussed previously. Yet, there is still a chance we could have missed important studies since extracting articles using the search terms in titles, keywords, and abstracts is not assured. However, we used multiple databases, which reduces the likelihood of missing relevant articles. Aside from this issue, another issue is that results may be different in the future owing to the continually expanding nature of electronic databases. Finally, our results have yet to be verified through an experimental study.
Business needs are evolving rapidly, and businesses want to deploy cost-effective software systems in the shortest possible time. At the same time, many software systems have struggled to fulfil their aims for various reasons. One reason for this failure is related to requirements engineering. Software products can meet customers’ requirements if sufficient resources are available for the requirements engineering process. Among all the phases of this process, requirements elicitation is the most critical. Here, customer requirements are determined in a way that can result in a successful project. Many elicitation techniques, and their pros and cons, are examined in the literature, including interview, survey, observation, introspection, task analysis, group work, and prototyping. Among these elicitation techniques, introspection is the least-addressed technique and therefore needs further exploration. This study, therefore, used a systematic literature review to investigate the cost-effectiveness of elicitation techniques when time constraints are the primary concern.
A comprehensive literature review was undertaken to ensure maximum validity. We collected 4,751 articles from multiple electronic databases based on our established selection criteria. Following the inclusion/exclusion and quality-assessment processes, 50 articles were selected to answer the research question. Then, after a detailed analysis of the selected studies, 15 requirements elicitation techniques were identified. We assigned each elicitation technique a number depending on its frequency in the extracted studies. The proportions of these selected studies were also calculated for ranking. Based on this ranking, we concluded that introspection may be a cost-effective option when a product’s time to market is a key issue, followed by survey, brainstorming, interview, and joint application development.
Efforts have been made to identify a cost-effective elicitation technique during the COVID-19 pandemic, especially when a product’s time to market is limited. This study could help analysts and managers take advantage of introspection in situations where there is limited time to develop a cost-effective system. In addition, for large-scale software, a project team can significantly reduce elicitation time and cost by using introspection for known domain areas. This study also revealed that introspection could be used at the start of the elicitation process. Using introspection in the early stage of a software project could help to minimize the time and cost of the software development process.
In future research, we plan to establish a framework to identify the system areas and functionalities in which introspection can or cannot be effectively employed. We also intend to conduct experimental studies to validate our findings.
Funding Statement: The authors extend their appreciation to the Deanship of Scientific Research at King Saud University for funding this work through research group no. RG-1441-490.
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
1. K. Pohl. (2010). “Eliciting requirements,” in Requirements Engineering: Fundamentals, Principles and Techniques, 1st ed., New York: Springer Publishing Company, Incorporated, pp. 19–31. [Google Scholar]
2. A. M. Davis. (2005). “Requirements elicitation,” in Just Enough Requirements Management: Where Software Development Meets Marketing, USA: Dorset House Publishing Co., Inc., pp. 40–61. [Google Scholar]
3. R. S. Pressman. (2010). “Requirements Engineering,” in Software Engineering: A Practioners Approach, 9 ed., USA: Mcgraw Hill, pp. 82–111. [Google Scholar]
4. A. Davis, O. Dieste, A. Hickey, N. Juristo and A. M. Moreno. (2006). “Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review,” in 14th IEEE Int. Requirements Engineering Conference, Minneapolis, USA, pp. 179–188. [Google Scholar]
5. The chaos report. (2015). [Online]. Available: https://www.standishgroup.com/. (Accessed 16 May 2020). [Google Scholar]
6. B. Shahzad, K. Awan, M. I. Lali and W. Aslam. (2017). “Identification of patterns in failure of software projects,” Journal of Information Science and Engineering, vol. 33, no. 6, pp. 1465–1479. [Google Scholar]
7. B. Lawrence, K. Wiegers and C. Ebert. (2001). “The top risk of requirements engineering,” IEEE Software, vol. 18, no. 6, pp. 62–63. [Google Scholar]
8. S. Tahir, B. Shahzad, S. T. Bakhsh and M. Basheri. (2020). “Developing relationship among risk factors and project factors for large scale healthcare applications,” Journal of Medical Imaging and Health Informatics, vol. 10, no. 10, pp. 2439–2445. [Google Scholar]
9. S. Kausar, S. Tariq, S. Riaz and A. Khanum. (2010). “Guidelines for the selection of elicitation techniques,” in 6th Int. Conf. on Emerging Technologies, Islamabad, Pakistan, pp. 265–269. [Google Scholar]
10. D. Mishra, S. Aydin, A. Mishra and S. Ostrovska. (2018). “Knowledge management in requirement elicitation: Situational methods view,” Computer Standards and Interfaces, vol. 56, pp. 49–61. [Google Scholar]
11. B. Berenbach, D. J. Paulish, J. Kazmeier and A. Rudorfer. (2009). “Eliciting requirements,” in Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Education, pp. 39–70. [Google Scholar]
12. S. T. Bakhsh, B. Shahzad and S. Tahir. (2017). “Risk management approaches for large scale software development,” Journal of Information Science and Engineering, vol. 33, no. 6, pp. 1547–1560. [Google Scholar]
13. A. Aurum and C. Wohlin. (2005). “Requirements elicitation: A survey of techniques, approaches,” in Engineering and Managing software Requirements. Berlin, London: Springer, pp. 19–41. [Google Scholar]
14. B. Nuseibeh and S. Easterbrook. (2000). “Requirements engineering: A roadmap,” in Proc. of the Conf. on the Future of Software Engineering, New York, USA, pp. 35–46. [Google Scholar]
15. T. Tuunanen. (2003). “A new perspective on requirements elicitation methods,” Journal of Information Technology Theory and Application, vol. 5, no. 3, pp. 45–72. [Google Scholar]
16. P. Sharmila and R. Umarani. (2011). “A walkthrough of requirement elicitation techniques,” International Journal of Engineering Research and Applications, vol. 1, no. 4, pp. 1583–1586. [Google Scholar]
17. S. G. Nilofar Mulla. (2012). “Comparison of various elicitation techniques and requirement prioritisation techniques,” International Journal of Engineering Research & Technology, vol. 1, no. 3, pp. 1–8. [Google Scholar]
18. S. Tiwari, S. S. Rathore and A. Gupta. (2012). “Selecting requirement elicitation techniques for software projects,” in 2012 CSI Sixth Int. Conf. on Software Engineering, Madhay Pradesh, India, pp. 1–10. [Google Scholar]
19. G. Dimitrakopoulos, L. Uden, I. Varlamis, G. Dimitrakopoulos, L. Uden et al. (2020). , “User requirements and preferences for ITS,” in The Future of Intelligent Transport Systems. Netherlands: Elsevier Science, pp. 43–62. [Google Scholar]
20. Z. Zhang. (2007). “Effective requirements development–-A comparison of requirements elicitation techniques,” in Software Quality Management, UK: British Computer Society, pp. 225–240. [Google Scholar]
21. M. Usman, N. Majeed and K. Shahzad. (2013). “Evaluation of efficient requirement engineering techniques in agile software development,” International Journal of Computer Applications, vol. 83, no. 3, pp. 24–29. [Google Scholar]
22. I. Sommerville. (2011). “Requirements engineering,” in Software Engineering, 9th ed., India: Pearson, pp. 82–111. [Google Scholar]
23. C. Coulin and D. Zowghi. (2005). “Requirements elicitation: A survey of techniques approaches,” Engineering and Managing Software Requirements, Berlin: Springer, pp. 19–46. [Google Scholar]
24. H. M. Kiran and Z. Ali. (2018). “Requirement elicitation techniques for open source systems: A review,” International Journal of Advanced Computer Science and Applications, vol. 9, no. 1, pp. 330–334. [Google Scholar]
25. N. Garg, P. Agarwal and S. Khan. (2015). “Recent advancements in requirement elicitation and prioritization techniques,” in Int. Conf. on Advances in Computer Engineering and Applications 2015, Ghaziabad, India, pp. 237–240. [Google Scholar]
26. B. Kitchenham. (2004). “Procedures for performing systematic reviews,” Joint Technical Report, Computer Science Department, 2004, Keele University (TR/ SE-0401) and National ICT Australia Ltd. (0400011T.1), UK. [Google Scholar]
27. B. Kitchenham and S. Charters. (2007). “Guidelines for performing systematic literature reviews in software engineering,” in Software Engineering Group, Keele University: School of Computer Science and Mathematics, pp. 1–57. [Google Scholar]
28. B. Shahzad and A. M. Said. (2014). “Identification and quantitative analysis of project success factors for large scale projects,” International Journal of Knowledge Society Research, vol. 5, no. 1, pp. 83–95. [Google Scholar]
29. B. Shahzad, A. M. Abdullatif, N. Ikram and A. Mashkoor. (2017). “Build software or buy: A study on developing large scale software,” IEEE Access, vol. 5, pp. 24262–24274. [Google Scholar]
30. J. M. Fernandes and R. J. Machado. (2015). “RequirementsElicitation,” in Requirements in Engineering Projects, Switzerland: Springer, pp. 85–117. [Google Scholar]
31. N. M. Salleh and P. N. E. Nohuddin. (2019). “Optimization of software requirement process: An integrated conceptual model of lean six sigma and requirement planning,” International Review of Applied Sciences and Engineering, vol. 10, no. 2, pp. 125–133. [Google Scholar]
32. S. A. Fricker, R. Grau and A. Zwingli. (2015). “Requirements engineering: Best practice,” In: S. A. Fricker, C. Thümmler, A. Gavras (Eds.) Requirements Engineering for Digital Health, pp. 25–46, Cham: Springer International Publishing. [Google Scholar]
33. A. Ullah, S. Nazir and S. Shahzad. (2018). “Trade-off analysis among elicitation techniques using simple additive weighting method,” in Advances in Intelligent Systems and Computing. Switzerland: Springer International Publishing, pp. 498–514. [Google Scholar]
34. M. Volk, N. Falk-Andersson and U. Sedlar. (2015). “How to elicit, analyse and validate requirements for a digital health solution,” In: S. A. Fricker, C. Thümmler, A. Gavras (Eds.) Requirements Engineering for Digital Health, pp. 155–188, Cham: Springer International Publishing. [Google Scholar]
35. A. Kanwal. (2019). “Requirements engineering: Elicitation techniques,” International Journal of Scientific & Engineering Research, vol. 10, no. 6, pp. 154–162. [Google Scholar]
36. R. Singh. (2014). “Comparative analysis of requirement elicitation technique,” International Journal of Current Research, vol. 6, no. 10, pp. 9135–9137. [Google Scholar]
37. Aleryani. (2018). “The impact of the user experience (UX) on the quality of the requirements elicitation,” International Journal of Digital Information and Wireless Communications, vol. 10, pp. 1–9. [Google Scholar]
38. T. Dirgahayu, N. Setiani and Z. Zukhri. (2014). “Information requirements engineering for specific content management systems,” in ICOS, 2014–-2014 IEEE Conf. on Open Systems, Subang, Malaysia, pp. 54–59. [Google Scholar]
39. R. Singh. (2013). “Role of requirement engineering processes in software development,” International Journal of Advanced Research in Management and Social Sciences, vol. 3, no. 5, pp. 1–6. [Google Scholar]
40. S. Sharma and S. K. Pandey. (2013). “Revisiting requirements elicitation techniques,” International Journal of Computer Applications, vol. 75, no. 12, pp. 35–39. [Google Scholar]
41. S. Tiwari and S. S. Rathore. (2017). “A methodology for the selection of requirement elicitation techniques,” . [Online]. Available: https://arxiv.org/abs/1709.08481. [Google Scholar]
42. T. Rehman, M. N. A. Khan and N. Riaz. (2013). “Analysis of requirement engineering processes, tools/techniques and methodologies,” International Journal of Information Technology and Computer Science, vol. 5, no. 3, pp. 40–48. [Google Scholar]
43. M. Batra and A. Bhatnagar. (2017). “An experimental survey to find application specific elicitation technique,” in Int. Conf. on Computing for Sustainable Global Development, India, pp. 1201–1204. [Google Scholar]
44. A. Ejaz, A. Khalid, S. Ahmed and M. C. A. Daud. (2016). “Effectiveness of requirements elicitation techniques in software engineering process: A comparative study based on time, cost, performance, usability and scalability of various techniques,” International Journal of Management, Information Technology and Engineering, vol. 4, no. 5, pp. 23–28. [Google Scholar]
45. N. Sabahat, F. Iqbal, F. Azam and M. Y. Javed. (2010). “An iterative approach for global requirements elicitation: A case study analysis,” in Int. Conf. on Electronics and Information Engineering, Kyoto, Japan, pp. 361–366. [Google Scholar]
46. P. Delatorre and A. Salguero. (2016). “Training to capture software requirements by role playing,” in Proc. of the Fourth Int. Conf. on Technological Ecosystems for Enhancing Multiculturality, Salamanca, Spain, pp. 811–818. [Google Scholar]
47. R. R. Dube and S. K. Dixit. (2010). “Process-oriented complete requirement engineering cycle for generic projects,” in Pro. of the Int. Conf. and Workshop on Emerging Trends in Technology, Mumbai, India, pp. 194–197. [Google Scholar]
48. M. Tariq, S. Farhan, H. Tauseef and M. A. Fahiem. (2015). “A comparative analysis of elicitation techniques for eesign of smart requirements using situational characteristics,” International Journal of Multidisciplinary Sciences and Engineering, vol. 6, pp. 8. [Google Scholar]
49. S. A. K. Gahyyur, S. Arif and Q. Khan. (2010). “Requirements engineering processes, tools/technologies, & methodologies,” International Journal of Reviews in Computing, ISSN: 2076–3328, vol. 2, pp. 41–56. [Google Scholar]
50. M. Yousuf and M. Asghar. (2015). “Comparison of various requirements elicitation technique,” International Journal of Computer Applications, vol. 116, no. 4, pp. 8–15. [Google Scholar]
51. R. Kaur and T. Singh. (2010). “Analysis and need of requirements engineering,” International Journal of Computer Applications, vol. 7, no. 14, pp. 27–32. [Google Scholar]
52. M. Arif and S. Sarwar. (2015). “Identification of requirements using goal oriented requirements elicitation process,” International Journal of Computer Applications, vol. 120, no. 15, pp. 17–21. [Google Scholar]
53. S. Hansen, N. Berente and K. Lyytinen. (2009). “Requirements in the 21st century: Current practice and emerging trends,” in Design Requirements Engineering: A Ten-Year Perspective, Berlin, Heidelberg, Germany: Springer Berlin, pp. 44–87. [Google Scholar]
54. J. T. Catanio. (2006). “Requirements analysis: A review,” in Advances in Systems, Computing Sciences and Software Engineering–-Proc. of SCSS, Dordrecht, Netherland, pp. 411–418. [Google Scholar]
55. H. J. Heydt and R. S. Alessi. (2002). “Tools for requirements discovery, creation and elicitationa,” INCOSE Int. Symp, vol. 12, no. 1, pp. 554–564. [Google Scholar]
56. W. J. Lloyd, M. B. Rosson and J. D. Arthur. (2002). “Effectiveness of elicitation techniques in distributed requirements engineering,” in Proc. IEEE Joint Int. Conf. on Requirements Engineering, Essen, Germany, pp. 311–318. [Google Scholar]
57. S. Khan, A. B. Dulloo and M. Verma. (2014). “Systematic review of requirement elicitation techniques,” International Journal of Information and Computation Technology, vol. 4, no. 2, pp. 133–138. [Google Scholar]
58. S. Sharma and S. K. Pandey. (2014). “Requirements elicitation: Issues and challenges,” in Int. Conf. on Computing for Sustainable Global Development (INDIAComUSA, pp. 151–155. [Google Scholar]
59. K. Yozgyur. (2014). “A proposal for a requirements elicitation tool to increase stakeholder involvement,” in 2014 IEEE 5th Int. Conf. on Software Engineering and Service Science, Beijing, China, pp. 145–148. [Google Scholar]
60. T. Iqbal and M. Suaib. (2014). “Requirement elicitation technique: A review paper,” International Journal of Computer & Mathematical Sciences, vol. 3, no. 9, pp. 1–6. [Google Scholar]
61. S. Wellsandt, K. A. Hribernik and K. D. Thoben. (2014). “Qualitative comparison of requirements elicitation techniques that are used to collect feedback information about product use,” Procedia CIRP, vol. 21, pp. 212–217. [Google Scholar]
62. D. Carrizo. (2016). “Comparison of research and practice regarding what we mean by ‘the right software requirements elicitation technique,” in 2016 10th Int. Conf. on the Quality of Information and Communications Technology, Lisbon, Portugal, pp. 79–82. [Google Scholar]
63. E. Joseph. (2017). “Survey on requirement elicitation techniques: It’s effect on software engineering,” International Journal of Innovative Research in Computer and Communication Engineering, vol. 5, pp. 9201–9215. [Google Scholar]
64. J. Horkoff, J. Ersare, J. Kahler, T. D. Jörundsson and I. Hammouda. (2018). “Efficiency and effectiveness of requirements elicitation techniques for children,” in 2018 IEEE 26th Int. Requirements Engineering Conference, Alberta, Canada, pp. 194–204. [Google Scholar]
65. H. Dar, M. I. Lali, H. Ashraf, M. Ramzan, T. Amjad et al. (2018). , “A systematic study on software requirements elicitation techniques and its challenges in mobile application development,” IEEE Access, vol. 6, pp. 63859–63867. [Google Scholar]
66. C. Pacheco, I. García and M. Reyes. (2018). “Requirements elicitation techniques: A systematic literature review based on the maturity of the techniques,” IET Software, vol. 12, no. 4, pp. 365–378. [Google Scholar]
67. O. Okesola, K. Okokpujie, R. Goddy-Worlu, A. Ogunbanwo and O. Iheanetu. (2019). “Qualitative comparisons of elicitation techniques in requirement engineering,” ARPN Journal of Engineering and Applied Sciences, vol. 14, no. 2, pp. 565–570. [Google Scholar]
68. A. Iqbal, I. A. Khan and S. Jan. (2019). “A review and comparison of the traditional collaborative and online collaborative techniques for software requirement elicitation,” in 2019 2nd Int. Conf. on Advancements in Computational Sciences, Lahore, Pakistan, pp. 1–8. [Google Scholar]
69. A. A. H. Alzahrani. (2020). “Analyzing the factors impacting the choice of the fact-finding technique for requirements elicitation,” International Journal on Information Technologies & Security, vol. 12, no. 1, pp. 15–36. [Google Scholar]
70. S. Rueda, J. I. Panach and D. Distante. (2020). “Requirements elicitation methods based on interviews in comparison: A family of experiments,” Information and Software Technology, vol. 126, pp. 1–19. [Google Scholar]
71. S. Besrour, L. Bin Ab Rahim and P. D. D. Dominic. (2014). “Assessment and evaluation of requirements elicitation techniques using analysis determination requirements framework,” in 2014 Int. Conf. on Computer and Information Sciences, London, pp. 1–6. [Google Scholar]
Appendix A
Appendix B
Appendix C
 | This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. |