DOI:10.32604/csse.2021.016510
| Computer Systems Science & Engineering DOI:10.32604/csse.2021.016510 | |
| Article |
Crowdsourced Requirements Engineering Challenges and Solutions: A Software Industry Perspective
1Department of Software Engineering, National University of Modern Languages, Islamabad, Pakistan
2Department of Computer Science, National University of Modern Languages, Islamabad, Pakistan
3Department of Computer Science, College of Computer and Information Systems, Umm Al-Qura University, Makkah, Saudi Arabia
4Department of Computer Science, College of Computers and Information Technology, Taif University, PO Box 11099, Taif, Saudi Arabia
5Department of Information Technology, College of Computers and Information Technology, Taif University, Taif, Saudi Arabia
*Corresponding Author: Huma Hayat Khan. Email: hnauman@numl.edu.pk
Received: 04 January 2021; Accepted: 01 March 2021
Abstract: Software crowdsourcing (SW CS) is an evolving software development paradigm, in which crowds of people are asked to solve various problems through an open call (with the encouragement of prizes for the top solutions). Because of its dynamic nature, SW CS has been progressively accepted and adopted in the software industry. However, issues pertinent to the understanding of requirements among crowds of people and requirements engineers are yet to be clarified and explained. If the requirements are not clear to the development team, it has a significant effect on the quality of the software product. This study aims to identify the potential challenges faced by requirements engineers when conducting the SW–CS based requirements engineering (RE) process. Moreover, solutions to overcome these challenges are also identified. Qualitative data analysis is performed on the interview data collected from software industry professionals. Consequently, 20 SW–CS based RE challenges and their subsequent proposed solutions are devised, which are further grouped under seven categories. This study is beneficial for academicians, researchers and practitioners by providing detailed SW–CS based RE challenges and subsequent solutions that could eventually guide them to understand and effectively implement RE in SW CS.
Keywords: Software crowdsourced; requirements engineering; software industry; software development; survey; challenges
The crowdsourcing (CS) concept has arisen from new-fangled collaboration technologies such as social media and Web 2.0. The term CS was invented by Howe and Robison [1], who reported it as a fragment of notions such as mass collaboration, open collaboration and collective intelligence. It is a novel form of effort, in which a ‘crowd’ collaborates and accomplishes software development life cycle tasks (e.g. requirement elicitation and analysis as well as design, coding and testing). This software development paradigm has emerged as an alternative to traditional software development organisations. Despite that the general effect has been ordinary so far, software crowdsourcing (SW CS) has the potential to and will enforce troublesome changes in how software development will be undertaken in the future [2–4].
SW CS is the assignation of a worldwide pool of online developers who can be appointed on-demand to contribute to several types of software development tasks [5–7]. The process is facilitated by platforms that link requesters and online developers. On this platform, the requester disseminates tasks to volunteer online developers, who solve the tasks based on their motivation for reward (e.g., money or respect). The SW CS platform has significant importance because it provides guidelines for managing and coordinating the processes and people in business and at technical levels [5,8]. Moreover, the platform permits requesters to discover talent outside their borders and earn the benefits of cost, quality, time and expertise [3,5,6]. In essence, this reveals that the software development team encounters an extensive user audience, which is referred to as the crowd of people. It is important to involve the crowd to satisfy crowd requirements, which demonstrates the importance of crowdsourcing [9]. Involving an enormous number of users in requirements engineering (RE) has always been challenging with customary RE methods [10,11]; specifically, this is true when RE would include an enormous number of users (a crowd) who are beyond an organisation’s reach [10,12].
Traditional approaches to conducting the RE process typically involve an inadequate number of representatives in requirement-gathering sessions through interviews or focus groups [13]. Conversely, recent RE approaches, which are functional in market-driven RE, permit organisations to directly interact with main stakeholders who employ ad hoc feedback-gathering networks [14]. However, these recent RE approaches miss the prospect of uninterruptedly involving diverse groups of users who share their feedback through a variety of media [12,15,16]. Consequently, it is believed that the software development team cannot consider the varied circumstances of user subgroups when evolving the product [17,18]. So, valued resources for RE continue to be unexploited and software products might not fulfill users’ needs [2,11].
CS-based RE is an umbrella term used for computerised or semi-computerised approaches to elicit and analyse information from a crowd to stem authenticated user requirements [19]. Usually, the crowd is an undefined set of people [5]; however, in the context of CS-based RE, a crowd is usually a large group of current or prospective software users who act together or with the software organisation’s representatives (e.g., product owner or development team) [11]. These users are involved at the run time for requirement elicitation through users’ feedback [20]. CS is considered a promising paradigm for eliciting requirements of a software system in a dynamic, possibly unknown context with a large pool of users [21]. CS-based RE is likely to enhance the quality, inclusiveness and even monetary viability of requirements elicitation. It allows software development teams to receive more updated knowledge about users’ perceptions of the system’s role to fulfil their requirements [9].
Although CS has noteworthy possibilities for RE, there remains scarce knowledge regarding how to set-up a CS-based project to fit the RE task [9]. A study conducted by Ågerfalk et al. [22] also specifies the importance of identifying various challenges that can be faced in SW CS. Further, Ågerfalk et al. [22] reported the importance of giving more attention to RE challenges to effectively implement the SW CS. Given the large effect of the challenges faced in the CS environment, it is difficult to form CS if the quality of elicited requirements is poor or unclear [11]. Therefore, this paper aims to investigate the potential challenges faced by the software development team in conducting SW–CS based RE. In addition, the solutions to overcome these challenges are investigated. The paper is outlined below. In Section 2, the related work is presented and in Section 3, the research method to achieve the research aim is reported. Section 4 discusses the research results, Section 5 provides an overall discussion of the research and Section 6 reports the research limitations. Last, in Section 7, the research is concluded and the future work is described.
It is essential to closely observe the conventional requirements gathering process to report the attributes of a software RE process conducted based on crowdsourcings. The RE process execution involves gathering, analysing, specifying and validating the requirements from stakeholders. In RE, multiple team members repeatedly converse with stakeholders in regard to requirements and continue to do so until a mutual agreement is reached on gathered requirements [23]. This conversation is conducted in formal meetings between the development team and stakeholders, in which secrecy remained until the software’s first version was released [23]. In its conventional mode, RE relates to the system development that principally suits the requirements of its stakeholders (i.e., the financial owner of the system); however, because customers’ (financial owners) eventual objective is that their system eis used by end-users, their instant requirements should be reflected on during RE [24].
In CS-based RE, it is unlikely that requirements for developing a new system or version of an existing system are based on the crowd’s perspective in an open call. A study conducted by Howe [1] first introduced the term CS as ‘any acts a company or institution taking a function once performed by employees, and outsourcing it to an undefined (and generally large) network in the form of an open call’ [23]. In this context, open call signifies that anyone who is interested might participate in the development. This type of process is made possible with the continuance of the internet. Stakeholders are the crowd in the CS environment and thus software development relies on them to gather their needs properly [9]. This indicates that it is time to rethink requirements elicitation to handle the difficulty and scale of the crowd and certify that the requirements are gathered efficiently and precisely [9]. The crowd could be the prospective users of the developed software to encounter their requirements; therefore, it is necessary to consider the crowd through the entirety of the software development process [9].
Several studies attempted to use the abilities of the crowd and end-users to resolve RE problems. It was found that these studies primarily focused on research areas such as requirements-driven social adaptation [20,25], feedback-based RE [26], stakeholders’ discovery [27] and general requirements identification [28]. Zhang et al. [20,25] reported the difficulty of validating software in a dynamic context. According to the researchers, the unpredictability of software’s role in fulfilling its needs in a dynamic context means that validating the software is a complex, difficult and time-consuming task. Ali et al. suggested the concept of social adaptation and social sensing for long-term validation of dissimilar alternatives to changing software. According to the researchers, it is an approach footed on obtaining and analysing users’ awareness of the system’s role in attaining their needs and its quality. The researchers have proposed to use this approach to generate adaptation decisions.
Similarly, research on feedback-based RE has been conducted. Martens et al. [26] discussed users’ feedback. According to Pagano and Maalej, it is important to obtain users’ software feedback to assist the development team in understanding the requirements of its future releases. The researchers suggested the effects of user feedback on RE teams by basing the significance of user feedback on the number of times a mobile application was downloaded. Other research [27] has reported CS from the perspective of stakeholders’ discovery. This research has suggested that it is difficult to identify the stakeholders and their roles, skilfulness and needs for any complex and dynamic system. The study concluded that CS could assist in identifying the relevant stakeholders specified by the analyst. The study argued about the complexity behind identifying the relevant stakeholders and suggested a participatory approach to identify stakeholders. The work appraised stakeholders as a collaborative network. It is reported that by this, analysts who know only a few members would nominate additional members as analysts.
Further, previous literature has specified appropriate requirements identification as another issue. In various software paradigms, users are usually diverse and unpredictable. It becomes costly to rely on an elite set of users for the functionality and quality attributes of the software. CS could assist in tackling the crowd’s capability to comprehend their requirements in a more desirable way. CrowdREquire [28] is a representative case of initiatives in which the notion of CS was supported for requirements elicitation. Existing studies have significantly reported the importance of RE in SW CS; however, they reported the need to give more attention to RE challenges to implement the SW CS effectively. Therefore, this research attempted to address this need by investigating the challenges faced by software development teams to conduct RE in SW CS. Moreover, the study also presents the suggested solutions to overcome these challenges.
Qualitative research was conducted in this study because it is a type of scientific research that answers questions, gathers evidence, yields findings that were not found in advance and generates findings that are relevant outside the study’s immediate limitations. Qualitative research is especially effective in gaining culturally detailed data about the values, opinions, behaviours and social contexts of specific populations [29]. This study uses the ‘in-depth interview’ technique to exploit the characteristics of qualitative research.
In-depth interviewing is a qualitative research technique that encompasses thorough individual interviews with a fewer number of respondents to discover perspectives of a particular idea or situation. In-depth interviews are valuable when comprehensive information is required about a person’s opinion or behaviour or for discovering and discussing novel issues in depth [30]. The in-depth interviews were conducted according to the guide provided by Deterding et al. [30]. The method for conducting an in-depth interview involves the following process: plan, develop instruments, collect data, analyse data and disseminate findings [30]. Further thorough steps are described below.
The in-depth interview plan comprised the following primary tasks. First, stakeholders were identified. The survey invitation was delivered to various software development companies to identify the most relevant stakeholders. The Pakistan software engineering board database was used to select the companies. A total of 12 companies were contacted and six responded to the invitation. These companies exist in all major Pakistani cities; however, the head offices are situated in Islamabad, Lahore and Rawalpindi. The selected software development companies that participated in this study are displayed in Tab. 1.
In total, 73 respondents from the selected companies were willing to participate in the survey. Following this, an appointment was scheduled with the willing respondents to conduct the interview. However, only 50 respondents were interviewed—23 respondents could not give their responses because of their work commitments. In this research, the participating stakeholders (respondents) were requirements engineers (also called business analysts) who worked in crowdsourcing platforms. Once the stakeholders were listed, the interview questions were established. For this research, stakeholders were asked about the challenges they face when conducting CS-based RE and the strategies used to overcome those challenges.
This stage involved developing the interview instrument. Initially, an interview protocol was developed. This protocol contained the guidelines that were followed for each interview to certify uniformity between interviews and thus increase the trustworthiness of the findings. Moreover, an interview guide was generated, which contained the interview questions. The instrument was validated for face validity and content validity through two methods: Average congruency percentage (ACP) and content validity index (CVI). The instrument was validated through four experts who had educational, research and industry background in CS-based RE. All experts were specialised in crowdsourcing and had more than 10 years of industry and academic experience.
In ACP, experts computed the percentage of questions deemed to be relevant. Conversely, CVI calculated the content validity index for the individual item (I-CVI). Experts 1 and 3 found one out of 12 questions irrelevant, which resulted in a 91.66% relevancy rate at their level. However, Experts 2 and 4 rated all questions relevant, which resulted in a 100% relevancy rate at their level. The average value of the experts’ congruency percentage was 95.5%, which was considered valid. For CVI, the four experts were asked to evaluate each question’s content relevancy on a 4-point Likert scale, in which 1 = not relevant, 2 = somewhat relevant, 3 = relevant and 4 = very relevant. To decide the relevancy criteria for each question, the number of experts who gave three or four scores was counted as relevant and one or two scores were considered not relevant. It was found that the majority of questions (Q2, Q5, Q7–Q12) scored an I-CVI value of 1.00 (Q1, Q3–Q4 and Q6 scored an I-CVI value of 0.75). The resultant mean I-CVI value was 0.9, which was considered valid. Moreover, the proportion relevancy of questions was also calculated. It was found that all the experts rated the questions with high proportion relevancy, which resulted in a mean expert proportion of 0.87 (considered high). Based on the results, the face and content validity of the questions asked in the interview session were found to be significantly high, which ensured the quality of the instrument.
At this stage of the in-depth interviewing technique, interviewers were identified and trained. Two final-year research students of a bachelor’s in software engineering programs were trained and involved in the data collection process. Irrespective of the data collectors’ prior experience, comprehensive training was provided over two weeks. The training process comprised an introduction to the evaluation objectives, an analysis of data collection techniques, a detailed analysis of the data collection items and instruments, preparation in the instrument usage, skill-building drills on interpersonal communication and conversation of ethical issues.
3.1.4 Collection of Data via Interview
Interviews were conducted with the 50 stakeholders (respondents). The interviews were conducted in groups with respondents from each participating company. First, interviewees’ consent was taken and re-explained according to the interview’s purpose, interviewees were notified as to why they were selected, and the interview session’s expected duration was indicated. Once the interview was conducted, the interview minutes were summarised in the form of an interview report—a process that was completed for each interview within 2–3 h after the interview session.
The gathered data were transcribed and analysed through grounded theory [31] data coding steps. The steps for data coding are detailed in Fig. 1.
Figure 1: Data coding steps
The data were collected through interviews before being transcribed. Transcription is significant for qualitative research because it assists the researcher in analysing data easily and creating a narrative with the data. The transcription allowed the researchers to find data patterns and save the accuracy of the data. Initial reads were given to the data to achieve understanding regarding data. Once the researchers understood the data, they identified critical segments and assigned codes. Every response was allocated with a letter code, which was next entered into the software. Afterwards, the similar codes were grouped and redundancies were removed. Consequently, themes were generated and categorised according to their similarities. The researchers observed the created codes and identified various patterns, which resulted in themes. These themes are wider than codes. Researchers combined various codes into a unique theme. In this study, the codes represented the challenges and their solutions and the categories represented the various RE phases. Tab. 2 illustrates the detailed list of CS-based challenges and their solutions under the category of various RE phases.
In this section, the detailed result of the identified challenges and suggestions for SW CS are discussed. Moreover, the categories based on similarities and mapping of these challenges to RE phases are explained.
In classical software development, RE is critical; rather, it becomes more decisive in SW–CS based RE. To respond to the complexity of RE in SW CS, this research identified 20 challenges that requirements engineers face when conducting various phases of the RE process. Tab. 2 demonstrates the identified CS-based RE challenges and their suggested solutions for each RE phase. Tab. 2 comprises four columns: RE phase, challenges, challenge categories and suggested solution. In the ‘challenge’ column, each challenge was given an ID, which are referred to in subsequent sections.
As described in Tab. 2, the aforementioned challenges are faced by industry practitioners when conducting the RE process in a crowdsourcing platform. In total, 20 challenges were identified, which were further grouped under seven categories against each RE phase. In addition, the solutions of these challenges were described in detail. Further, the challenges are mapped with four RE activities: requirement elicitation, requirement analysis and design, requirement specification and requirement validation. For example, the activity ‘requirement elicitation’ involves four challenges that respondents most commonly face, and the respondents have suggested the most appropriate solutions overcome these challenges.
It was reported that eight challenges were most faced by requirements engineers when they performed requirement analysis and design:
• difficulty in the effective interpretation of user requirements [c5]
• lack of conformity between the idea and solution [c6]
• lack of face-to-face communication, which results in changing requirements [c7]
• difficulty in user requirements fulfilment [c8]
• difficulty in designing requirements because people give requirements based on their culture and needs [c9]
• designed requirements conflict with user perspectives [c10]
• difficult to prepare, initialise, decompose and aggregate requirements [c11]
• requirements engineers do not have the complete knowledge of the requirements in a CS environment, which leads to difficulty in requirements design [c12].
Subsequently, the respondents provided solutions to overcome these challenges. The respondents noted that, when they performed requirements specification activities, they predominantly encountered five challenges:
• difficult to manage and decide in finalising the requirements of numerous people [c13]
• designing SRS is complex because stakeholders are not on a common ground [c14]
• requires more experts [c15]
• lack of face-to-face communication between requirements engineers and clients [c16]
• difficult to maintain a proper document according to the customer’s needs [c20].
Solutions to overcome these challenges are also described in detail. Last, requirement validation included three common challenges:
• lack of quality assurance [c17]
• difficult to obtain requirements for feedback from numerous people, which invalidates the requirements [c18]
• time-consuming to manage or validate the gathered requirements from the stakeholder [c19].
4.2 Categories of Software–Crowdsourcing Based Requirements Engineering Challenges
The research results (challenges) were analysed thoroughly and grouped into various categories based on their similarity. In particular, there were 20 challenges, in which each challenge pertinent to a specific aspect was grouped under a category. Fig. 2 depicts the categories of the identified RE challenges for SW CS.
Figure 2: Categories of SW–CS-based RE challenges
As demonstrated in Fig. 2, the challenges are mapped in terms of their challenge ID to the seven categories:
• ‘Time-consuming to gather the requirements [c1]’, and ‘time-consuming to manage or validate the gathered requirements from the stakeholder [c19]’ are challenges related to ‘time’.
• ‘Hard to obtain quality work [c2]’, ‘difficulty in user requirements fulfilment [c8]’, ‘lack of quality assurance [c17]’ and ‘difficult to maintain a proper document presented according to the customer’s needs [c20]’, are challenges related to ‘quality work’.
• ‘Difficulty in designing requirements because people give requirements according to their culture and needs [c9]’ and ‘designed requirements conflict with user perspectives [c10]’ are challenges related to ‘culture’.
• ‘Require more experts and resources [c3]’ and ‘requires more experts [c15]’, are categorised under ‘require more experts’ because both relate to the aspect of lacking experts’ comprehensiveness.
• ‘Lack of face-to-face communication, which results in changing requirements [c7]’, ‘designing SRS is complex as stakeholders are not on a common ground [c14]’, ‘lack of face-to-face communication between requirements engineers and clients [c16]’ and ‘lack of confidentiality and communication [c4]’ are challenges related to ‘communication and confidentiality’.
• ‘Lack of conformity between the idea and solution [c6]’ and ‘difficult to obtain requirements for feedback from numerous people, which invalidates the requirements [c18]’ are categorised under ‘conformity’ because both relate to the aspect of lacking conformity between requirements.
• ‘Difficulty in the effective interpretation of user requirements [c5]’, ‘difficult to prepare, initialise, decompose and aggregate requirements [c11]’, ‘requirements engineers do not have the complete knowledge of the requirements in a CS environment, which leads to difficulty in requirements design [c12]’ and ‘difficult to manage and decide in finalising the requirements of numerous people [c13]’ are categorised under ‘requirement understanding based on a lack of CS knowledge’ because the challenges occur from a lack of CS knowledge.
4.3 Mapping the Software–Crowdsourcing Based Challenges with the Requirements Engineering Process
The research findings also generated mapping patterns between the RE process and challenge categories. Tab. 3 explains the identified SW–CS based challenges categories and their occurrence at RE activities.
As demonstrated in Tab. 3, identified challenges grouped under their respective categories occurred at various RE process activities. According to the respondents, challenges regarding ‘time’ were most common when conducting requirement elicitation and requirement validation. Challenges regarding ‘quality work’ appeared to be more profound throughout the RE process. Moreover, challenges regarding ‘more experts required’ commonly occurred when analysing, designing and specifying the requirements. Last, challenges regarding ‘confidence and confidentiality’ are usually faced when requirements engineers were involved in requirements elicitation and analysing, designing and specifying the requirements.
According to the respondents, the challenges regarding ‘conformity’ occurred while the RE team analyses, designs and validates the gathered requirements. Further, the challenges regarding ‘requirement understanding based on a lack of CS knowledge’ were faced by most requirements engineers when they performed requirement analysis, design and specification. To increase an in-depth understanding and visualisation of the findings, Fig. 3 depicts a diagrammatic representation of the most commonly occurring RE challenges in CS at each RE activity.
Figure 3: Commonly occurring challenges in the RE process
The focus group was conducted to validate the research findings (SW–CS based RE challenges and solutions). Jay’s [32] study was followed to conduct a focus group. Fig. 4 depicts the detailed process that was followed to conduct the focus group sessions.
The detailed focus group process consisted of six steps. First, it was necessary to define the focus group’s objective and validate the outcome of this research by comprising CS-based RE challenges and their solutions. The second step involved establishing a timeline. Planning the focus group session began six weeks before the session occurred. Eight senior requirements engineers were contacted, each with at least 10 years of experience, and six consented. Next, formal invitations were delivered. These six experts were serving in the industry as ‘principal software engineer’, ‘software project manager’, ‘senior software developer’ and ‘senior team leads’. It was ensured that all experts had been working in a CS environment. The interview questions were prepared thoroughly (see Tab. 4).
Figure 4: Focus group process
As demonstrated in Tab. 4, the sample questions were asked in the main session of the focus group. The facilitator—a senior researcher— opened the session. First, the facilitator welcomed all participants, reviewed the purpose of the focus group and the aims or objectives of the meeting. The facilitator ensured that everything flowed smoothly in the meeting by establishing the ground rules (e.g. how the session will continue and how the participants can contribute).
The session began with a general open-ended question—‘what do you think about SW–CS based RE?’. It was ensured that all opinions regarding various questions were conveyed and considered. The participants’ comments or feedback regarding the identified CS-based RE challenges and their solutions were recorded. The participants suggested some modifications in regard to the challenges and solutions; consequently, a modified list of CS-based RE challenges and solutions was generated. Tab. 2 displays the CS-based RE challenges and solutions. Other than the suggested modifications, the experts also commented on the study’s comprehensiveness and strengths and weaknesses, as well as the comprehension of the recommended solutions and the barriers that restrict the adoption of the study.
5.1 The Comprehensiveness of the Software–Crowdsourcing based Challenges and Suggested Solutions
All the participants agreed on the study’s comprehensiveness. It was noted that the study could act as a guide for academicians and practitioners working in the domain of CS-based RE. According to Expert 6, categorising challenges and mapping with RE phases would further the reader’s understanding. Further, Expert 4 noted that the detailed solutions against the challenges enhance the study’s comprehensiveness.
According to the participants, the study findings were easy to understand and grasp. The experts reported the authenticity of the identified challenges by mentioning the comments of other session participants. There was a consensus regarding the practicality of the identified challenges and their solutions in a real environment. The experts suggested some modifications to the findings to enhance their understandability (see Tab. 2).
5.3 Barriers Against Adopting the Findings
Interestingly, the participants described various organisational and personal barriers in regard to adopting the study findings. The experts mentioned the problem of mindset in any organisation—organisations could be reluctant to consider these findings when working in CS-based RE. Further, in regard to personal barriers, there could be a lack of understanding or passion in understanding the challenges and their solutions for effective CS-based RE.
In addition, the organisation’s employees may possess a reluctant attitude towards adopting novel things. All these barriers have significance in their context; however, it was concluded that these barriers could be easily managed if careful attention is applied.
There are often multiple validity threats in survey-based studies. One of the difficulties with the survey is that it occasionally had a low response rate and the likelihood of individual biases. Previous literature has reported that thoughts and views obtained through a survey could be prejudiced and dissimilar from the real-world population distribution. Another study limitation regards the instrument (questionnaire) that covered most aspects related to the potential challenges and solutions. The instrument was statistically analysed in terms of face and content validity tests and the results demonstrated the instrument’s authenticity and comprehensiveness. However, it is possible that various significant questions that could have been further explored were overlooked.
The authors gathered qualitative data by conducting interviews with 50 respondents from the software industry who worked in a CS platform. In particular, the interviewees were all requirements engineers. Although their responses were quite comprehensive, the sample size is limited in terms of generalising the results. This limitation was attempted to be overcome through conducting a focus group, which would ideally validate and generalise the list of challenges and solutions. Last, the findings of this research is based on a human–understanding based data extraction strategy, which may have affected the outcome of this research. To address this limitation, experts were involved from both academia and the industry to ensure the contextual insights of the results.
This research study has identified 20 SW–CS based RE challenges and their subsequent proposed solutions through an industrial survey. These challenges were further grouped into seven categories. The authors validated the findings by including eight experts in a focus group session. A total of 12 companies were contacted and six were willing to respond to the invitation. In total, 73 relevant respondents from the selected companies were willing to participate in the survey; however, only 50 respondents were interviewed because of attrition. SW CS exhibited a basic pattern swing in regard to how the software would be established in the future. Consequently, this has lifted numerous issues and RE has become one of the most pressing issues. In this regard, if RE is not properly handled in SW CS, the quality of the software work product will be greatly affected. In response, this study has involved a qualitative data analysis through conducting interviews with software industry professionals. Consequently, 20 SW–CS based RE challenges and their proposed solutions were devised. The factors were categorised under seven categories—time, quality work, culture, more experts required, confidence and confidentiality, conformity and requirement understanding based on lacking CS knowledge. Next, the research findings were validated through a focus group, in which experts evaluated the comprehensiveness of the findings, the strengths and weaknesses of the results and potential barriers against adopting the findings. It is believed that SW CS platforms can be assisted by this research in terms of obtaining a better understanding and gathering of software requirements. Researchers, academicians and practitioners can benefit from this research by utilising the research outcome. Moreover, future research could engage in the following activities:
• using empirical evidence to evaluate the proposed mapping between CS-based RE challenges and strategies to solve them
• using a wider audience to validate whether lists of challenges and solutions are exhaustive.
Acknowledgement: We deeply acknowledge Taif University for Supporting this study through Taif University Researchers Supporting Project number (TURSP-2020/115), Taif University, Taif, Saudi Arabia.
Funding Statement: ‘This research is funded by Taif University, TURSP-2020/115’.
Conflicts of Interest: The author declares that they have no conflicts of interest to report regarding the present study.
 | 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. |