Exploring the Critical Benefits and Challenges of Social Network Site-Based Requirement Elicitation in Saudi Arabia

Abstract

The digital transformation and proliferation of social network sites (SNSs) have created new opportunities to consider digital sources to support the development of software systems. Social network sites (SNSs), such as Twitter and Facebook, can be major sources used during the process of requirement elicitation to identify and extract users’ requirements. The primary objective of SNS-based requirement elicitation is to overcome the limitations of the traditional requirement elicitation methods. However, these valued resources for requirement elicitation are yet to be fully exploited. Software products might not fulfill users’ needs owing to the numerous challenges in processing the data effectively. This study aims to explore the actual use, benefits, and challenges of SNS-based requirement elicitation. Twenty-five practitioners in the software companies in Saudi Arabia were interviewed, and thematic analysis was conducted on the interview data. With the application of the TOE model, five critical benefits and nine challenges were identified and classified into technological, organizational, and environmental contexts. The findings of this study offer valuable implications for researchers and practitioners by providing fine-grained details about the adoption of SNS-based requirement elicitation that could eventually facilitate its implementation effectively.

1. Introduction

Requirement elicitation, a major determinant of successful information system development, is among the most critical requirement engineering activities [1]. The process of capturing, searching, and acquiring requirements from potential sources is referred to as requirement elicitation [2]. Requirement elicitation is a sociotechnical, human-centered endeavor in which extensive communication with various software stakeholders (customers, end-users, domain experts, project owners, etc.) is necessary to define their requirements and communicate them to software development teams. Traditional requirement elicitation techniques are primarily conducted through interviews or surveys with software users, where relevant details are used to increase the understanding of user requirements [1]. However, they suffer from several key issues, such as a lack of user involvement in requirement-gathering sessions through interviews or focus groups [3,4]. In addition, user analysis methods have reached their limits as software with numerous dispersed users is becoming more common. Thus, ambiguity in user analysis methods may have a negative effect on the quality of software requirements [5]. Moreover, traditional elicitation techniques cannot consider the increasing number of users worldwide. In addition, it is frequently time-consuming and insufficiently scalable for handling rapidly expanding datasets [6].

Social network sites (SNSs) can be a major source for identifying and extracting user requirements. This approach is known as SNS-based requirements engineering [7], in which platforms like Twitter [8] and Facebook [9] are used to extract requirements. The primary objective of SNS-based requirement elicitation is to overcome the limitations of the traditional requirement elicitation methods. The existing accounts have shown that the use of SNSs for requirement engineering purposes has several advantages that include satisfying the requirements for a quick time-to-market [9], providing an inexpensive approach to software development [9], increasing requirement quality by obtaining feedback from large groups of users [10,11], tracking the opinions of main users who can be affected by the success or failure of a software project [12], and increasing users’ involvement in developing software systems [13].

In addition, SNS-based requirement elicitation is suitable for new software paradigms, such as software ecosystems and mobile computing, where traditional requirement elicitation techniques provide insufficient support [9]. According to the authors of [14], SNS-based requirement elicitation is expected to improve requirement elicitation quality, inclusivity, and even financial feasibility.

A recent survey by the authors of [15] involving 101 developers found that most developers (97%) agreed that user feedback provides them with a better understanding of user needs and increases awareness of usability issues [15]. While 80% of the developers often used feedback to identify bugs, 68% identified new feature requests. Although SNSs can be a major source that can be used successfully to extract and identify user requirements [7], valued resources for requirement elicitation are yet to be exploited, and software products might not fulfill users’ needs owing to the numerous challenges in processing the data effectively [6,16].

Research on this topic is in its nascent stages. The studies on SNS-based requirement elicitation are rare [6,7]. The majority of research concentrated on alternative digital sources for requirement elicitation, such as app reviews [17] and forums [18]. Most importantly, studies on SNS-based requirement elicitation have generally used a systematic literature review methodology [19,20]. To the best of our knowledge, there is a lack of the use of SNS-based requirement elicitation, and the benefits and challenges hindering its usage must be addressed. Therefore, this study aimed to fill these gaps by exploring the current practice of SNS-based requirement elicitation and the potential benefits and challenges that affect the adoption of SNS-based requirement elicitation in Saudi Arabia.

Moreover, we investigated the technological, organizational, and environmental TOE framework [21]. The selection of the TOE constructs was based on sufficient evidence of their widely recognized significance in earlier studies in several areas. For instance, it was applied to investigate technology adoption in cloud computing services [22], social commerce [23], and blockchain [24]. The TOE framework is a popular tool for analyzing the challenges and benefits associated with adopting new technologies from the organization’s perspective. The TOE, according to the authors of [21], offers both benefits and challenges for technological innovation. The TOE framework depicts technological challenges like security. Organizational challenges like insufficient skills are included in the organizational perspective. Environmental challenges look at the difficulties presented by the setting in which the organization offers necessities like rules.

This study uses the qualitative research approach to address the research questions; RQ-1 What is the current practice of SNS-based requirement elicitation in the software industry? RQ-2 What are the key benefits of SNS-based requirement elicitation? RQ-3 What are potential challenges faced during the implementation?”. Data were gathered from participants (N = 25) who worked for technology organizations through in-depth interviews. Additionally, the thematic analysis method was used to analyze the gathered data.

The remainder of this paper is organized as follows. Section 2 covers the background and relevant studies of SNS-based requirement elicitation. Section 3 presents the research methodology, data collection technique, and data analysis approach. Section 4 presents the analysis, and Section 5 provides a discussion of the results and its implications. Finally, the conclusions are presented in Section 6.

2. Background

2.1. SNS-Based Requirement Elicitation

Conventionally, requirement elicitation is a stakeholder-driven process. Practitioners extract requirements in the domain knowledge from stakeholders qualitatively through certain techniques such as interviews, questionnaires, focus group discussions, or workshops. However, the emergence of the term big data, characterized by an increasingly growing multi-sourced amount of data in volume, value, variety, velocity, and veracity, along with an ongoing digital revolution, has created new sources to consider for requirement elicitation. Utilizing this online feedback data from various digital sources to elicit users’ requirements in tandem with the traditional techniques facilitates the development of software systems or enhances the quality of ones that already exist [6].

A review of the literature shows that different definitions have been proposed to describe the use of online feedback in requirement elicitation. Existing studies mostly referred to four terms, including Crowd-based Requirements Engineering, Data-Driven Requirement Elicitation, Online User Feedback Requirements Engineering, and Social Computing for Software Engineering. The first term, Crowd-based Requirements Engineering (CrowdRE), has been defined as “eliciting requirements from explicit user feedback from crowd users (e.g., app reviews and data from social media) by applying various techniques based on machine learning and natural language processing” [6] (p. 2).

Data-Driven Requirement Elicitation (DDRE) is the second term used to describe the utilization of online feedback in requirement elicitation. The term refers to mining users’ requirements from online feedback sources that include online and app reviews, microblogs, mailing lists, discussion forums, user feedback and arguments, and usage and system log reports [11,19].

The third term is Online User Feedback Requirements Engineering, in which requirements information is identified through users’ feedback on different online channels, including social media, app stores, and discussion venues. The voice of the users has been commonly used in the requirements engineering literature to describe this type of feedback [18].

The fourth term is Social Computing for Software Engineering, which is used to focus on the social aspects among stakeholders in the systems development process. It refers to the use of various social computing techniques such as email, blog/microblog, wiki, tag, feeds, social networking, crowdsourcing, dashboards, and instant messaging to facilitate interaction among stakeholders when conducting requirement engineering activities [25].

The study in [20] focused on social network sites (SNS-based feedback) in requirement engineering (RE), in which they investigated “how requirements engineering (RE) activities (requirement elicitation, prioritization, and negotiation) are conducted using social network sites (e.g., Facebook and Twitter)”. Within this context, our comprehensive review shows that there is an intimate connection between these definitions, and no key differences exist among them. Therefore, all relevant existing studies that employed these terms and definitions were included in our review. We propose the use of the term SNS-based requirement elicitation to investigate the process of utilizing social network sites (SNSs), particularly excluding all other online feedback sources, to identify, gather, and document stakeholders’ requirements. Our focus is on investigating how the distinctive features of SNSs are used during the software development process to extract users’ online feedback during the activity of requirement elicitation only. The following section presents the related work.

2.2. Related Work

Many recent studies have addressed the critical benefits and challenges encountered during requirement elicitation from SNSs, online reviews, and blogs.

Ref. [9] proposed a social network service-based requirement engineering process that considers the variety and commonality of the requirements when eliciting them from social network platforms. A controlled experiment was conducted on a sample of users’ opinions extracted from Facebook and Twitter. Two teams participated in the experiment, during which one team elicited user requirements using traditional requirement elicitation methods (interview and online survey), and the other team used an SNS-based requirement engineering process. Data gathered from both teams was tested to investigate the efficiency and effectiveness of the proposed SNS-based requirement engineering process. The findings of the experiment confirmed the efficiency and effectiveness of the proposed process in eliciting users’ requirements. The authors outlined the main advantages of their approach, which included a quicker time to market, fewer labour-intensive tasks, and higher productivity and quality.

The work of ref. [26] focused on how SNSs allow the participation of end users in the requirement engineering activities (elicitation, prioritization, and negotiation). The authors developed a generic SNS-based RE approach, which was validated through three exploratory studies. The findings supported the efficiency of the proposed approach in identifying users’ needs. As for the elicitation activity, their results found that the proposed SNS-based RE approach showed increased stakeholder involvement.

Ref. [19] conducted a systematic literature review (SLR) to explore the state-of-the-art of data-driven requirement elicitation and identify key challenges. Their findings revealed a set of requirement elicitation techniques and identified four groups of challenges. General challenges include information overload, lack of successful cases in the industry, the need for additional processes, requirement volatility, conflicting requirements, inaccurate results, and lack of metrics for effort estimation. The authors also identified nine challenges associated with natural language-based techniques: the unstructured nature of natural language, inability to obtain feedback providers’ identity information, same requirements with different words, same requirements with different perspectives, different data sources and algorithms that might affect the result, high human effort to create a training set, sarcastic sentences, platform structure, and lack of attention for analysis on multiple time dimensions. The challenges of privacy, security, and monitoring needed to fit the changes have been reported as difficulties with using data-based techniques. The study also reported difficulties in eliciting requirements by combining usage data and feedback.

Recently, ref. [14] interviewed 52 requirements software engineers to investigate the potential challenges encountered in software crowdsourcing requirements engineering. The findings presented 20 challenges and solutions grouped into seven categories. Four challenges were associated with requirement engineering activities. First, gathering software crowdsourcing requirements is considered time-consuming. Second, respondents reported difficulties in obtaining quality requirements. Third, software crowdsourcing-based requirements necessitate the recruitment of a greater number of experts and resources. Lack of confidentiality (privacy) and communication issues was the fourth challenge.

Many calls in the engineering literature have raised the concern of users refraining from providing online feedback, which may result in missing key user needs during requirement engineering. In an attempt to provide certain insights into this issue, ref. [18] surveyed software users regarding their feedback and presenting habits mainly through three channels: app reviews, forums, and social media. Their results showed significant demographic differences among feedback-givers and identified different motivations for their engagement. When identifying the reasons for not providing online feedback, users stated the three most common reasons: searching for existing answers, looking for an alternative app, and thinking problem resolution would be time-consuming. The study reported other less frequent reasons, such as users’ desire to stay anonymous, their preference for not sharing software issues on social media, and not creating an account. Interestingly, the findings showed that users were not aware that their feedback would influence software improvements and that their cultural differences affected their feedback attitudes.

Ref. [10] investigated the landscape of crowd-based requirement engineering and identified key challenges. The authors concluded that Crowd requirement engineering provides promising opportunities for practitioners to elicit user feedback, particularly for quality and feature improvements. Their findings highlighted a set of critical challenges that were divided into four groups. First, crowd motivation, wherein users tend not to share their opinions or experiences, is a major challenge affecting the quality of feedback. Second, user privacy and personalization stood out as obstacles in requirement engineering. The analysis of feedback was the third most challenging task in Crowd requirement engineering. The lack of successful applications in the industry was another challenge for Crowd requirement engineering.

Ref. [20] conducted an SLR to identify studies that utilized SNSs as a means for requirements engineering activities. These findings suggest that SNSs can be a significant source for extracting and identifying user requirements. While previous studies used SNSs to support all requirement engineering activities, SNSs have been used extensively, particularly for requirement elicitation. The findings revealed the use of various social networking platforms, including Facebook, Twitter, Reddit, products, and VLC forums, to satisfy user requirements. The authors identified three main approaches used in existing studies to utilize SNSs for requirement elicitation: manual, semiautomatic, and automatic. Furthermore, to address the fourth research question, the authors divided the challenges that occurred during SNS-based requirement elicitation into four main categories: opinion trustworthiness, data preprocessing, opinion classification, and interpretation.

Against this background, three distinctive gaps characterize the literature. First, existing studies that utilize online feedback from SNSs for requirement elicitation purposes are still in their early stages, and they primarily focus on crowdsourcing platforms, such as the App Store, Google Play, and Microsoft Store. Other crowdsourcing platforms, such as SNSs, have not yet been fully exploited. Second, most existing studies have focused on the technical challenges associated with its implementation. The benefits and other challenges of the adoption of SNS-based requirement elicitation have received minimal attention in previous studies. Third, most of the research to date has adopted systematic literature review (SLR) as the methodological approach in their investigation.

Table 1. Summary of the related work.

Reference	Research Aim	Methodology	Key Findings
[9]	Propose a social network service-based requirement engineering process to elicit user requirements from Facebook and Twitter platforms.	Experimental design	Current state of SNSs requirement elicitation: Semi-automated approach Benefits: The findings confirmed the effectiveness of the proposed approach in terms of a quicker time to market, fewer labor-intensive tasks, and higher productivity and quality.
[26]	Investigate how SNSs allow the participation of end users in the requirement engineering activities (elicitation, prioritization, and negotiation).	Exploratory approach	Current state of SNSs requirement elicitation: Semi-automated Benefits: The findings supported the efficiency of the proposed approach in identifying users’ needs and increasing stakeholder involvement.
[19]	To explore the state-of-the-art of data-driven requirement elicitation and identify key challenges.	Systematic literature review (SLR)	Challenges: Their findings revealed a set of general challenges, challenges associated with natural language-based techniques, and difficulties with using data-based techniques
[14]	To investigate the potential challenges encountered in software crowdsourcing requirements engineering.	Interviews	Challenges: The findings presented 20 challenges and solutions grouped into seven categories.
[18]	To find out the key reasons for users refraining from providing online feedback and how this impacts the process of requirement engineering	Survey	Challenges: Their results pointed out the most common reasons that prevented users from providing online feedback, which contributed to missing key user needs during requirement engineering.
[10]	To investigate the landscape of crowd-based requirement engineering and identify key challenges.	Exploratory approach	Challenges: Highlighted a set of critical challenges (crowd motivation, user privacy and personalization, analysis of feedback, lack of successful application in the industry)
[20]	To identify studies that utilized SNSs as a means for requirements engineering activities.	Systematic literature review (SLR)	Benefits: SNSs have been used extensively, particularly for requirement elicitation. Challenges: Identified challenges that occurred during SNS-based requirement elicitation (opinion trustworthiness, data preprocessing, opinion classification, and interpretation).

provides a summary of the related work.

2.3. The TOE Framework

The most common theory of IT adoption at the organizational level is the Technology, Organization, and Environment (TOE) framework, as shown in Figure 1 [21].

• Technological context describes both the internal and external technologies relevant to the firm. This includes current practices and equipment internal to the firm.
• Organizational context refers to descriptive measures about the organization, such as scope, size, and managerial structure.
• Environmental context is the arena in which a firm conducts its business—its industry, competitors, and dealings with the government.

Both the benefits and challenges of innovative technology are presented by the TOE [27]. The TOE framework [21] has been widely used to study the benefits and challenges associated with technology adoption. For example, the work of [22] employed the TOE model to examine the factors affecting the adoption of cloud computing services in a developing country. Another study was conducted by [23] in which the TOE model was used to investigate the factors influencing small-and medium-sized enterprises’ adoption of social commerce. In the logistics sector, the TOE model was applied by [24] to identify challenges relevant to the adoption of blockchain technology. Therefore, the TOE framework is well suited in this study for exploring and categorizing the benefits as well as the challenges that affect the adoption of SNS-based requirement elicitation.

3. Research Methodology

This study adopts a qualitative approach to explore the nature of SNS-based requirement elicitation and investigate its associated benefits and challenges. The qualitative approach views facts as a subjective reality connected to individual differences rather than an objective reality; it enables a deeper understanding of SNS-based requirement elicitation by investigating participants’ experiences, attitudes, and beliefs in greater detail [28]. The primary advantage of applying a qualitative approach in this study is that it facilitates the generation of the case study rather than merely a list of numerical data [29]. This section will provide an overview of the research objectives and questions, participants selection, and data collection, validation, and analysis procedures.

3.1. Participant Selection

In order to ensure that the collected data is relevant, that the findings can be generalized to other countries, and to understand different perspectives on the requirement elicitation process, all participants were carefully selected to meet the specific criteria related to this study’s objectives. For this study, the selection criteria for participants are as follows:

• Be working at leading software companies;
• Hold international professional certificates in the field;
• Have working experience of at least 1–3 years in the software industry;
• Hold different roles at different organizational levels.

Accordingly, we interviewed 25 participants over the period of eight months (from January to August 2023). The sample consists of 52% male and 48% female participants, as shown in Figure 2.

The educational level of the participants varied and included (64%) a Bachelor’s degree, (28%) a Master’s degree, and (8%) a PhD degree (Figure 3).

The majority of the respondents (52%) fell under the age group of 25–34 years, followed by the age group of 35–44 years (32%) and 45–54 years (12%), and 4% of the participants were among the age group of 18–24 years (Figure 4).

The participants worked at leading software companies, such as Pwc, THIQAH, IIBA, and governmental agencies, on different types of software development projects in different fields (Educational, FinTech, Governmental public services, IT, and consultancy). Figure 5 shows the participants’ experience range in the software industry. A total of 32% of the participants had work experience between 4 and 6 years, 28% had more than ten years of experience in the software industry, 16% had between 7 and 10 years, and 16% had 1–3 years of experience. Only 8% had less than a year of experience.

We conducted interviews with participants occupying various positions at different organizational levels, as shown in Figure 6.

Participants also had professional certifications in various areas of the field, as shown in

Table 2. List of professional certifications held by participants.

Name of Professional Certification	Number of Participants
Certified Business Analysis Professional (CBAP)	4
The Entry Certificate in Business Analysis (ECBA)	4
Certified Scrum Product Owner (CSPO)	3
Certified ScrumMaster (CSM)	3
Professional in Business Analysis (PMI-PBA)	3
The Open Group Architecture Framework (TOGAF)	3
Certified Data Management Professionals (CDMP)	2
Professional Scrum Product Owner (PSPO)	2
Certification of Capability in Business Analysis (CCBA)	1
Certified Tester Foundation Level For software testers (CTFL)	1
Control Objectives for Information and Related Technology (COBIT 5)	1
DevOps certifications	1
Information Technology Infrastructure Library (ITIL)	1
PMI Risk Management Professional (PMI-RMP)	1
Professional Scrum Master (PSM)	1
Project Management Professional (PMI-PMP)	1
Scrum Fundamentals Certification (SFC)	1
The Agile Analysis Certification (AAC)	1
Total	34

.

3.2. Data Collection

In this study, in-depth interviews with participants (N = 25) from different technical companies were used to collect data. Participation was voluntary. We conducted one-on-one interviews with participants. The interview questions covered various topics on the current practice of SNS-based requirement elicitation in the software industry, including the activities, types of SNS-based requirement elicitation, benefits, and potential challenges faced during the implementation of SNS-based requirement elicitation, as shown in

Table 3. List of the interview questions.

Interview Questions
How often do you or your organization utilize social networking sites (SNSs) for requirements elicitation purposes?
Describe the specific SNSs platforms used for requirements elicitation.
What are the types of requirements commonly gathered from SNSs?
Provide examples of specific projects or instances where SNSs-based requirements elicitation was implemented successfully?
What are the main benefits you have experienced when using SNSs for requirements elicitation?
Describe the specific domains where SNSs-based requirements elicitation is more commonly adopted or has shown greater benefits?
Explain the specific activities or techniques that are commonly applied during SNSs-based requirements elicitation?
Based on your experience, what are the best practices or recommendations for effectively utilizing the requirements elicitation from SNS?
What are the key challenges that need to be addressed for wider adoption and successful implementation of SNSs-based requirements elicitation?
How do you deal with these challenges?
How do these challenges impact the process of requirement elicitation?
How do you perceive the future potential of SNSs-based requirements elicitation in the software industry?

. All interviews were conducted with the presence of two interviewers; one posed the questions while the other took notes and asked clarifying questions.

Every interview took around 45 to 90 min and was conducted in English. Due to the geographical variations, the interviews were conducted virtually via Skype and Zoom. The internal recording feature on both platforms was used to capture the interviews in order to guarantee the data’s quality and correctness.

3.3. Data Analysis

The data was analyzed using thematic analysis. Three rounds of analysis were conducted following [30]’s five steps iteratively, starting with familiarization with data, generation of initial codes, searching for themes, reviewing themes, defining and naming themes, and producing the final report. The purpose of thematic analysis is to find themes, that is, significant or intriguing patterns in the data, and then utilize these themes to discuss the research or present a point. Familiarization with data: with the permission of the participants, the interviews were audio-recorded while maintaining their private information. The researchers utilized a recording app on Zoom(6.0.11 (39959) and Skype (8.129.0.202) to audio-record the interview sessions. After the interview was completed, a summary meeting was conducted to provide the participants with the opportunity to ask questions, offer comments, and add any material not covered during the interview session. Interview transcripts and interview-related notes comprised the evaluated materials. To verify that the transcriptions accurately captured the interviewees’ remarks, the researcher compared them to mobile application recordings multiple times before performing any necessary edits. Generating the initial codes: we coded each piece of data related to the research questions. We employed open coding; that is, we created and adjusted the codes while going through the coding process rather than using preset codes. Subsequently, we compared our codes, discussed them, and made changes before proceeding to the remaining transcripts. We created new codes progressively and occasionally changed those that were already present. We did this by hand, using pens and highlighters to check the physical copies of the transcripts. Search for themes: when examining the codes in these transcripts that were related. The classification and coding of the themes are displayed in

Table A1. Sample of the themes, their codes, and themes frequencies.

Types of Challenges	Themes	Description	Examples	Theme Frequency, n
Organizational Challenges	Local governmental legalizations	The governmental local laws, regulations, codes of practice, or guidance that directly impact the SNS-based requirement elicitation process.	In one of my projects in which I used SNS, I was restricted with some local governmental legalisations (p. 13)	7
	Lack of adequate skills	Refers to the lack of the necessary knowledge, resources, or skills for conducting business analytics tasks.	Unfortunately many practitioners ignore the use of SNSs which can be considered as a fertile environment for requirement elicitation (p. 10)	8
	Project Delay	Refers to events or conducts that may; - extend the planned project deadline or - disrupt delivery of goals.	The search on social media was time-consuming, and I personally preferred to meet the users directly and elicit their needs (p. 6)	5
Technical Challenges	Natural Language (NL) Issues	Difficulties in managing the extraction, storage, and processing of data from (SNSs) for requirement elicitation purposes.	The problems associated with NL techniques are real barriers for conducting SNS-based RE (p. 12) from my experience, I know that most of the data on social media is important; however, it is still raw data that has not been processed or structured in a ready-to-use form for requirement elicitation. I know that 98% of the data on social media is unprocessed data that is not going to be useful for RE. It [data] must be cleaned and filtered to use them properly; however, I cannot do that. (p. 5)	12
	Lack of technical support	The necessary technical resources, expertise, services, and infrastructure to assist practitioners in resolving issues that may arise during SNS-based requirement elicitation.	I highly recommend appointing a dedicated social media team to gather comments and convert them into business needs and then IT systems requirements (p. 7)	6
	Privacy Issues	Concerns regarding potential misuse of users’ private information	Users’ privacy is one of the sensitive issues that I must consider during SNS-based RE (p. 9)	5
	Security Issues	This refers to potential risks or vulnerabilities that could cause damage to businesses, systems, or data.	On several occasions, I was not able to access or gather content on SNS platforms for security purposes, mainly to protect users’ accounts or devices from being controlled by other parties. (p. 10)	2
General Challenges	Lack of Stakeholder s’ involvement	Missing users’ voices who are expected to actively contribute to the development and enhancement of the software services.	Continuous communication with users until all requirements are elicited is very difficult on SNS because users are not so involved in the process (p. 10)	5
	Lack of Quality requirements	Missing quality requirements attribute/s as defined by IIBA-BABOK that include the following criteria: - Unambiguous - Testable - Concise - Understandable - Feasible - Atomic - Prioritized - Consistent - Complete	Compared to the traditional methods, I usually get less quality requirement from SNSs (p. 8) It is challenging to elicit requirements from SNS where you have to be very careful with users’ cultural issues (p. 11)	21

(Appendix A). At the end of this step, all codes fit one or more themes. Codes were then organized into broader themes that appeared to indicate something specific to this research question. Review themes: in this stage, the concepts identified in Step 3 were reviewed, modified, and developed. The themes are coherent, logical, and distinct. This was performed quickly by utilizing the ‘cut and paste’ function using a program such as Microsoft Excel. Defining and Naming Themes: the goal of the last iteration was to “identify the ‘essence’ of each theme” [30]. What were the themes attempting to indicate? If there are sub-themes, how do they relate to and interact with the main theme? Finally, a final report was presented.

3.4. Result Validation

A validation process was conducted to ensure the credibility and accuracy of the results. Sharing the analyzed results with participants and seeking their feedback or clarifications helps validate the findings and enhance the trustworthiness of the research outcomes. We sent emails to every interviewee, inviting them to the feedback session. The presentation was attended by fifteen people, most of whom were the individuals we interviewed. Using excerpts from anonymous interviews, we presented our key findings. During the discussion, participants confirmed our findings, and we received no feedback for corrections.

4. Results

The results of our search are shown in this section. The current practice of SNS-based requirement elicitation is presented in Section 4.1, benefits are shown in Section 4.2, and challenges are discussed in Section 4.3.

4.1. The Current Practice of SNS-Based Requirement Elicitation in the Software Industry

This section presents an answer to the first research question, “What is the current practice of SNS-based requirement elicitation in the software industry?”. Most of the participants (16) confirmed their use of SNSs for requirement elicitation purposes. The use of SNSs was considered a contemporary essential requirement elicitation tool due to the participative features provided by SNSs, diversified and persistent content, and innovative ideas found on these platforms.

Let me tell you, I have more than ten years of experience, the use of SNSs for requirements elicitation today is not an option but it is rather a necessity regardless of the field or the type of system/application. The features offered by SNSs make them a valuable source for requirement elicitation (p. 1)

The customer-centric approach was found to be the driving incentive for practitioners to adopt SNS-based requirement elicitation. Respondents explained that the customer-centric approach requires them to find various channels beyond the traditional requirement elicitation methods to hear users’ voices on as wide a base as possible.

I tend to use SNSs because as you know requirements elicitation is the most important stage among other stages of requirement’s lifecycle, during which users’ feedback significantly matters, it’s all about users and their needs (p. 12)

Participants revealed that the utilization of SNSs has most frequently been for conducting various requirement elicitation activities.

SNSs helped me a lot during preparations and evaluation activities (p. 9)

Several participants described the selection of the SNS platform as part of elicitation preparation activities. A variety of SNSs were used by the participants, including Twitter (X now), Facebook, LinkedIn, Microsoft Teams, WhatsApp, Instagram, Telegram, YouTube, and TikTok. As explained by participants, the selection of a particular platform to elicit requirements is determined by several factors, such as the business need, the nature of the problem, and the most visited SNS platform by users.

We need to decide on the platform first. Usually we use Twitter to read customers feedback because it is the most widely used SNS (p. 3)

I directly go to LinkedIn and Facebook (p. 8)

I use a selection of SNSs including; WhatsApp, Instagram, X, Telegram, depending on where my users can be found (p. 11)

As a business consultant, I usually select the platform based on the problem/need, but in most of the projects I worked on I tend to check Twitter and Telegram more often (p. 19)

Practitioners sought to elicit functional, non-functional, and business requirements from SNSs. Analyzing users’ posts, comments, discussions, reviews, and ratings, all informed the requirement elicitation process. Alternatively, analyzing entities’ official accounts or pages on SNSs can be used to examine users’ feedback or comments towards the systems/services. Respondents also mentioned the usefulness of SNSs in identifying market requirements by monitoring trends, hashtags, and discussions, which revealed market gaps and opportunities. As described by the participants, SNSs are like a gate for them to conduct market studies for certain projects and products, such as designing job recruitment platforms.

I use SNSs to elicit functional requirements by analyzing users’ feedback and reviews (p. 12)

I used YouTube to learn about the architecture of new software, and these videos help me to identify the nonfunctional requirements (p. 5)

Some participants mentioned that their use of SNSs was not intended mainly for requirement elicitation purposes. Rather, SNSs were used to test users’ reactions or feedback when a new feature or system is released for improvement purposes or to identify the current system’s problems. For example, a participant shared a successful case in using SNSs effectively to improve an Enterprise Resource Planning (ERP) system for a manufacturing company. The SNS platform played an important communication tool that brought all involved parties (business owners, system developers, and end users) together, which facilitated the precise diagnosis of the current system’s problems in a flexible manner and enabled solution evaluation to increase the value of the suggested solution.

As a business developer, I really enjoyed this experience, the development team was able to conduct solution evaluation and share recommendations through WhatsApp with other stakeholders who were given the opportunity to participate and express their opinions freely, which enhanced the value of the proposed solution. (p. 12)

The data showed that practitioners used a variety of techniques to gather requirements from SNS, including e-surveys, virtual meetings, e-polls, user behavior analysis, and social analysis. Participants indicated the use of the manual approach extensively to extract online feedback from SNSs and the automated techniques to a narrow extent.

We create specific Twitter accounts to ask the users directly or post a survey about their needs (p. 2)

We have specific departments in our companies that are responsible for collecting and analyzing the online feedback from SNS using specific technologies to handle big data, such as Data analysis tool, IBM Watson, JIRA/Figma/Google analytics/Firebase, Sigma and data mining as well as in-house technologies developed by our companies. (p. 1)

Participants also used SNSs to confirm the elicitation results. They stressed the importance of this step in order to avoid requirement volatility and conflicting requirements.

the requirements obtained from SNS should be compared with other requirements to check its consistency with other requirements on SNS or from other traditional sources, I mean applying the three types of elicitation collaborative, research, and experiments (p. 5)

In sharing the successful implementation of SNS-based requirement elicitation, participants outlined specific types of projects such as IT development projects, e-government systems and services, designing digital products, FinTech projects, and designing e-postpaid payment services such as Tabby and Tamara.

However, nine interviewees mentioned that they do not tend to utilize SNSs for requirement elicitation purposes. Participants shared two key reasons behind eliminating SNSs as a rich source for RE. Security purposes was the first reason stated by participants, especially with governmental projects that require a high level of confidentiality.

I don’t usually rely on SNS for RE, because of the nature of my work, I work on governmental projects in which a high level of confidentiality is required (p. 14)

The second reason for not using SNS-based requirement elicitation is that practitioners believed that the requirements and targeted users do not exist on SN platforms. This reason was found to be associated with participants when referring to emerging fields/systems they were working on and when expressing their personal perception and belief toward SNS.

Due to the novelty of the field, I’m not expecting to find much feedback or requirements from SNS (p. 25)

Sometimes, I fail to find sufficient feedback on SNS, particularly with new systems that have never been developed, or with confidential/governmental projects. In such cases I do not use SNS at all (p. 5)

Because I personally do not believe that I can find reliable precise requirements on SNSs (p. 24)

4.2. The Benefits of SNS-Based Requirement Elicitation Adoption

An answer to the second research question is given in this section: “What are the key benefits of SNS-based requirement elicitation?”. The second round of analysis focused on identifying key benefits participants experienced when extracting requirements from SNS. Five themes emerged from the data analysis, which were classified using the TOE model, as shown in

Table 4. The classification of key benefits of SNS-based requirement elicitation.

TOE Context	Themes
Technological benefits	Time-saving
Organizational benefits	Cost reduction Corporate agility
Environmental benefits	Increased stakeholders’ involvement Improved quality of requirements

.

Frequency analysis was conducted to identify the most popular benefits mentioned by the participants (Figure 7). The most repeated benefits of SNS-based requirement elicitation were improved stakeholders’ involvement, cost reduction, time-saving, corporate agility, and improved quality of requirements, respectively.

The section below presents the analysis of each theme in more detail.

4.2.1. Technological Benefits

The first context of the TOE framework is technological and focuses on how the structure, quality, and characteristics of requirements can affect the process of adopting SNS-based requirement elicitation. Two themes comprised this context: time-saving and improved quality of requirements.

Theme-1: Time-saving

Participants mentioned that SNSs helped in reducing the time needed for requirement elicitation. Participants referred to the features and functionalities of SNS platforms that enhanced instant communication and enabled virtual collaboration with key stakeholders, which expedited the extraction of requirements and reduced time-to-market.

When using the traditional techniques, I need time to prepare for workshops and brain storming sessions, and I need to arrange for a suitable time and place for everyone. On the other hand, when using SNSs, there is no such requirements (p. 1)

4.2.2. Organizational Benefits

The organizational dimension is the second context of the TOE framework that includes the organizational attributes of the SNS-based requirement elicitation, such as cost reduction and corporate agility.

Theme-2: Cost reduction

Cost reduction is found to be the second significant benefit valued by participants in utilizing SNSs for requirement elicitation. Respondents compared traditional methods used for requirement elicitation, which require face-to-face meetings, with SNS-based requirement elicitation, which can be held virtually, to show how the latter reduces the associated costs significantly. Using the automated techniques to extract users’ feedback is another cost-effective way of SNS-based requirement elicitation described by participants. Some respondents also mentioned crowdsourcing fostered by SNSs as a means for achieving optimized resource utilization, which ultimately reduces cost through collaborative ideation.

I consider SNSs as a cost-effective approach (p. 13)

If I use SNSs correctly and target the right audience, I can easily capture what I need without incurring high costs (p. 1)

Theme-3: Corporate agility

Corporate agility emerged as another benefit of embracing SNSs for requirement elicitation. Participants’ responses showed three repeatedly occurring elements offered by SNSs to achieve corporate agility: customer-centric approach, flexibility, and responsiveness.

I think if companies adopt SNS effectively, they will have a customer-centric focus that enables them to respond to the constantly changing users’ demands, introduce new features/services, and exceptionally meet users’ needs; in other words, achieve corporate agility (p. 1)

4.2.3. Environmental Benefits

The Environmental benefits are mentioned in the third context of the TOE framework. It represents all external parties of the organization in this study’s context, as well as increased stakeholders’ involvement.

Theme-4: Increased stakeholders’ involvement

The most significant benefit of SNS-based requirement elicitation mentioned by the participants was users’ involvement. The participants explained how SNSs enabled a direct and dynamic engagement with stakeholders and broadened their reach and accessibility to a wider and diverse user base. Respondents referred to the multiplicity and authenticity of users’ needs, feedback, and experiences, which were found on SNSs as enriching to the requirement elicitation process. Many participants described the ubiquitous presence of SNSs as a facilitating factor of deeper users’ involvement across diverse demographics and geographic locations. For participants, this particular feature of SNSs enabled them to respond to a representative wider pool of users’ needs.

SNSs link me with countless users at any time, everywhere. As a business analyst, I require the users’ feedback, views, problems as they appear naturally in their normal everyday conversations, without any embellishment, favoritism, or any other influences (p. 1)

SNS platforms inform us with what is actually happening on the ground, enabling us to know what the users’ needs really are (p. 2)

Some participants described SNSs as a rich source of innovative ideas that can be harnessed for systems improvements.

In general, SNS is a very important source for innovative and out of the box ideas that can be suggested by anyone regardless of his or her educational level or background (p. 1)

Theme-5: Improved quality of requirements

The lowest significant benefit mentioned by participants was obtaining quality requirements. Some interviewees considered SNSs as a source of obtaining quality requirements. The capabilities of SNS platforms that allowed real-time feedback and communication and collaborative and interactive user participation were seen by participants as contributing to the production of quality requirements.

Due to the great features of SNSs, I elicited good quality requirements in several projects (p. 13)

4.3. The Challenges of SNS-Based Requirement Elicitation Adoption

This section presents an answer to the third research question, “What are all potential challenges faced during the implementation of SNS-based requirement elicitation?”. The third round of analysis focused on identifying all types of challenges faced by participants when extracting requirements from SNS. Nine themes were identified from that data analysis, as shown in Table A1 in Appendix A, which presents the themes and their description, examples, and themes frequencies. The TOE model was then used to categorize these themes (

Table 5. The classification of the key challenges of SNS-based requirement elicitation.

TOE Context	Themes
Technological challenges	Natural Language data Time-consuming Privacy issues Security issues
Organizational challenges	Lack of technical support Lack of adequate skills
Environmental challenges	Local governmental legalization Lack of stakeholders’ involvement Lack of quality requirements

).

Frequency analysis was conducted to identify the most common challenges that emerged from participants’ responses. Figure 8 presents the frequencies of the various challenges mentioned by participants. Lack of quality requirements was the most important challenge for participants during SNS-based RE, followed by Natural Language (NL) issues. The next important challenges were a lack of adequate skills, local governmental legalization, a lack of technical support, project delay, privacy issues, a lack of stakeholder involvement, and security issues, respectively. The section below presents the analysis of each theme in more detail.

4.3.1. Technological Challenges

The first context of the TOE framework is technological and focuses on how the structure, quality, and characteristics of requirements can affect the process of adopting SNS-based requirement elicitation. Five themes comprised this context: Natural Language data, Lack of quality requirements, Project Delay, Privacy, and Security issues.

Theme-1: Natural Language (NL) Issues

Technical issues related to NL techniques and big data were the second major challenge for most practitioners, who indicated that they often find it difficult to gather and analyze the huge amount of data extracted from SNSs. Furthermore, as described by participants, the application of NL techniques to extract requirements from SNSs holds its own limitations. The unstructured nature of data and the diversity found in user opinions, which are usually expressed in informal languages and dialects, limit the extraction and analysis of user needs. Therefore, the inability of practitioners to manage the extraction, storage, and processing of data from SNSs to make it useful for requirement elicitation was a key challenge for SNS-based requirement elicitation.

It is really difficult to collect and dig deep into big data and extract users’ needs. (p. 3)

Even if we apply NL technique, there is still a risk of missing key users’ needs. On social media, we have users from different backgrounds who express their needs, usually informally, with various dialects, or implicitly, which is hard for the machine to pick it. not every requirement collected by machine learning (ML) techniques is acceptable. In most cases, there would be certain missing information, unrelated issues, repeated feedbacks by the same user, and ignored implicit requirements. This is why I need a human, someone who understands well what is needed, can penetrate deep inside the extracted data, elicit requirements correctly, and connect it to the organizations’ vision and mission. (p. 1)

Theme-2: Project delay

Another significant challenge that emerged from the data relates to the perception of participants that the use of SNSs for requirement elicitation is time-consuming, which would extend the project duration and disrupt the delivery of the project’s outcomes. This personal belief that participants hold affects their tendency toward applying SNS-based requirement elicitation.

I personally think SNSs are waste of time, I spend hours on them and cannot find complete requirements I think if SNS platforms were used to extract requirements, we as a team would miss the projects deadline (p. 3)

Theme-3: Privacy issues

Users’ privacy emerged as an obstacle to conducting SNS-based requirement elicitation. During the SNS-based requirement elicitation, practitioners were feeling constrained as they needed to be cautious about not violating users’ privacy when extracting requirements. As explained by many participants, business owners are legally obligated to protect users’ sensitive information from being misused, which in turn limits access to the content on SNS.

Certain software is developed for private companies that are not permitted to gather or share any information through social media for privacy issues (p. 8)

Theme-4: Security issues

Security concerns were mentioned by participants as barriers to conducting SNS-based requirement elicitation, especially with governmental projects that require a high level of security. Participants’ responses showed their inability to access or gather content on SNS platforms for security purposes, mainly to protect users’ accounts or devices from being controlled by others.

I worked on governmental projects, and it was difficult to conduct SNS-RE because of issues related to security (p. 4)

4.3.2. Organizational Challenges

The second context of the TOE framework is the organizational dimensions, which include organizational attributes such as a lack of technical support and a lack of adequate skills. These attributes can facilitate or hinder the adoption of SNS-based requirement elicitation.

Theme-5: Lack of adequate skills

Lack of adequate skills was another important challenge mentioned by participants repeatedly. Participants described their peers and business owners in some cases as having insufficient knowledge or understanding of the necessary information, resources, or skills needed for conducting business analytics tasks and techniques, which in turn prevented the opportunities of optimal utilization of SNS’s potential for requirement elicitation.

In my opinion, the real issue is with certain colleagues who lack an understanding of their role and responsibilities. They think that the job of a business analysts is to gather requirements only, without considering its effects on the business processes and other project’s components (p. 3)

I usually face some issues with business owners that affected requirement elicitation activities. For example, the lack of understanding of what is business analytics, the flawed expectations of software developers’ responsibilities, and the lack of awareness of the legal aspects involved in the RE process are major obstacles in dealing with business owners (p. 9)

Theme-6: Lack of technical support

Lack of technical support created additional barriers to the use of SNS-based requirement elicitation. Participants expressed their need for assistance in terms of the technical resources, expertise, and infrastructure and emphasized the improvement of engaging other departments and experts in conducting SNS-based requirement elicitation efficiently. Some respondents felt isolated as there was no technical support to guide and support the technological side involved during SNS-based RE.

As I told you earlier, it is a daunting task to dig in big data or use automated approach for RE as a business analyst alone, the process is very complicated and requires cooperation from other departments and experts such as data engineering or data scientists. They have the required tools and techniques for this task, I urgently need technical support (p. 2)

4.3.3. Environmental Challenges

The Environmental challenges are mentioned in the third context of the TOE framework. It represents all external parties of the organization in this context: a lack of stakeholders’ involvement and local governmental legalization.

Theme-7: Lack of Stakeholder involvement

Another concern described by the participants was the ‘missing key user voices’ on SNSs. Participants described the frustration they felt knowing that thousands of users avoid sharing their positive experiences or opinions about a service or application on SNSs. The negative feedback and complaints from users usually exceed their positive feedback, which prevents a holistic view of their experiences. For participants, it was difficult to create a continuous communication flow with those missing key user voices to identify their needs and make the necessary service/system improvements.

It’s frustrating to know that thousands of users avoid sharing their positive experiences or opinions about a service or an application on SNSs. I think users’ negative feedback and complaints usually exceed positive feedback, which prevents a holistic view of their experiences. So, for me these are missing user voices (p. 1)

Theme-8: Lack of quality requirements

This challenge was the most important one among other challenges. By quality requirements, participants were referring to the list of characteristics for good requirements being violated by missing all or some of the criteria. Participants revealed that requirements obtained from SNSs are mostly unreliable because of the fake and repeated feedback and the unreliable user experiences since users’ identities and ages are missing. Incomplete requirements elicited from SNSs were also reported as a concern, particularly with novel or highly confidential IT projects, because of the insufficient data available on SNSs to be used for requirement elicitation. Another concerning issue for participants was eliciting culturally acceptable requirements from SNS. Many participants explained that SNS users have different cultural backgrounds and usually express their needs according to their culture, which makes them cautious when approaching SNSs for requirement elicitation.

It’s really difficult to elicit reliable accurate requirements (p. 19)

There are many social media content or comments that are inappropriate to our culture, thus, I need to be careful in extracting and interpreting these needs (p. 6)

Theme-9: Local governmental legalizations

Local governmental legalization was found to be an obstacle to developing regulation-compliant software when adopting SNS-based requirement elicitation. Participants described how challenging it was for them to elicit SNS-based requirements that were compliant with the legal regulations governing their activities. It was even harder to deal with conflicting legalization between two or more governmental entities, which prevented the requirements from being extracted efficiently.

It was difficult in some projects to develop regulation-compliant software. Local government legalization places significant constraints on RE activities. I have to make sure that elicited requirements are compliant with the legal regulations. I worked on projects during which I faced conflicting legalizations, particularly between two or more governmental entities, which prevented the requirements from being extracted efficiently (p. 7)

Overall, we found the critical benefits and challenges affecting the organizational adoption of SNS-based requirement elicitation, as shown in Figure 9.

5. Discussion

This section discusses the findings and provides a comparison with earlier research. We also discuss how this has implications for research and practice.

• RQ1: What is the current practice of SNS-based requirement elicitation in the software industry?

Based on the data analysis, most software developers interviewed in this study use SNS-based requirement elicitation, with a small percentage not using it. This study discovered two reasons why software developers are still using the traditional approach to gather requirements rather than implementing SNS-based requirement elicitation. The most important reason mentioned is that they believe the requirements and the target stakeholders are not available on the SNSs. The second reason is that they work on projects involving sensitive software, such as governmental software, which requires strong security assistance. A likely explanation for not providing online feedback is that stakeholders would rather find an alternative online solution instead of providing their feedback or opinions on SNS. As found by [31], stakeholders avoid providing online feedback and attempt to download alternative software because they think it would take too long to solve their problem.

Software developers do not currently consider SNSs as a primary source of requirement elicitation; rather, it is considered a secondary source to support the requirement elicitation process. This finding aligns with that of [7]. This tendency may be attributed to a lack of technical support, as found in this study. Collective efforts and better communication between software developers and other parties are required for efficient SNS-based requirement elicitation.

The study discovered that the following five steps are used in performing SNS-based requirement elicitation manually: (1) choosing the SNS platform that the target stakeholders use the most; (2) extracting requirements from SNSs manually (search, read, and ask the stakeholders); (3) processing the extracted requirements before using them to prevent repetitive and incomplete requirements; (4) verifying the elicitation requirements that elicit from SNSs by displaying it on the target stakeholders; and (5) compiling the requirements that elicit from SNSs with the requirements that elicit from traditional approach (survey, interview).

Numerous research [9,26] have indicated that manual approaches are utilized to extract user requirements from SNSs and have been successful. A small software development organization conducted its requirement elicitation using the manual approach since it addresses the organization’s knowledge and skill constraints, budgetary constraints, and time constraints [7].

• RQ2: What are the key benefits of SNS-based requirement elicitation?

The 25 participants identified a total of five key benefits. The TOE framework was used to categorize these benefits into three contexts: technological, organizational, and environmental.

Technological Benefits: (1) Time-saving: This benefit is mentioned nine times by participants. One of the frequently highlighted advantages of requirements obtained from SNSs that have been covered in prior research when using the automatic or semi-automatic approach is time savings [9].

Organizational Benefits: (2) Cost reduction: This benefit is mentioned ten times by participants. The most significant benefit, according to several recent studies on extracting requirements from SNSs is cost reduction [9,14]. (3) Corporate agility: This benefit is mentioned six times by participants. This finding is unique to the context of this study as it has not been previously confirmed by other studies in the literature.

Environmental Benefits: (4) Increased stakeholder involvement: Participants mentioned this benefit 12 times. Stakeholders’ involvement has been one of the commonly mentioned benefits of SNS-based requirement elicitation discussed in the previous studies [13]. (5) Improved quality requirements: This benefit is mentioned five times and is similar to that reported in recent studies [10,11,14] with respect to gathering feedback from large numbers of users of SNSs.

• RQ3: What are all potential challenges faced during the implementation of SNS-based requirement elicitation?

Existing research on online feedback requirement elicitation has primarily focused on crowdsourcing platforms as potential sources of requirement elicitation. SNSs have received minimal attention from previous studies as valuable sources for extracting requirements. Furthermore, describing the technological challenges associated with online feedback requirement elicitation was substantially more prevalent compared to other types of challenges. Our results indicate that the current SNS-based requirement elicitation holds great potential in eliciting requirements, and this process comes with a wide range of challenges in its respective context.

The participants identified a total of 9 challenges that were specifically indicated as the most critical, citing their significant impact on the adoption of the SNS-based requirement elicitation. The categorization of these challenges based on the TOE framework into three contexts, technological, organizational, and environmental, provided a broader view of its application. For instance, participants discussed the challenge of (1) Natural Language (NL) 12 times, highlighting the difficulties in two major respects. First, SNS users utilize natural and unstructured language to express their opinions. Second, the data generated on SNSs is huge, which makes it difficult for analysts to find valuable requirements. This contrasts with traditional elicitation methods, which provide more precise information in controlled settings during formal interviews or structured surveys and, thus, reduce the possibility of misinterpreted requirements. Technical opinion mining and natural language processing (NLP) techniques ought to be combined to address these kinds of problems when dealing with data on SNSs [6,7]. In this respect, practitioners would need additional efforts or skills to obtain requirements from machine-generated data such as SNSs. Much research is needed to develop advanced methods that would be able to infer quality requirements. Both techniques for inferring requirements and validating their practicality, especially for SNS-based requirement elicitation, are still lacking. This challenge, though, is addressed in prior studies as the primary challenge when obtaining data from users’ online feedback [20].

(2) Project Delay: This challenge is mentioned five times by the respondents. This study found that most respondents prefer to directly conduct traditional techniques to stakeholders to save time. This challenge has been addressed in many previous studies [14]. This challenge could be attributed to the fact that online feedback comes from widely dispersed stakeholders with varying amounts and levels of written natural language, making it time-consuming to manually extract software requirements [10]. Traditional methods often involve scheduled meetings or workshops where all relevant stakeholders are engaged simultaneously, making the process more time-efficient. The automatic derivation of requirements from online user feedback is a possible solution, and it has been the focus of extensive research [10]. (3) Privacy Issues pose a significant challenge and have been mentioned five times. Unlike the case with traditional requirement elicitation, stakeholders do not want to reveal their identity for a review they wrote on SNS platforms, as their feedback about software is visible to others. However, this may involve legal issues, thus limiting the effective application of SNS-based requirement elicitation. This result is consistent with previous studies that found usage data, which represents user behavior, can be sensitive information. Similarly, prior studies found that stakeholder privacy affects the adoption of SNS-based requirement elicitation [10,14,19]. This finding suggests that policy regulators for SNSs need to improve the disclosure of information in order to protect users’ privacy and facilitate a smooth application of SNS-based requirement elicitation. (4) Security Issues: This challenge is mentioned two times. Software developers obtain requirements by monitoring stakeholder feedback on SNSs, which is allowed by stakeholders but could be affected by other parties gaining control of their accounts or devices. Their accounts could be hacked for illegal purposes. For a more effective application of SNS-based requirement elicitation, practitioners need to find ways to monitor users’ needs efficiently, safely, and legally. This finding is consistent with a prior study [19].

The technology challenges identified in this study could be a result of the application of manual techniques to extract user requirements from SNS. To overcome technical challenges, a semi-automatic requirement elicitation should be adopted, which uses both manual and automatic techniques, such as NLP and ML, as indicated in previous studies [9,32]. More research is needed in this respect to identify the level of automation and the combining mechanism between two data types that are required to obtain quality requirements from SNSs. In addition, software developers may lack expertise or interest in the challenges that need to be solved for efficient SNS-based requirement elicitation. In addition, software developers may be reluctant to use new automatic techniques. This highlights the need for collaboration between software developers and other experts, such as data analysts, to find an effective approach to implement SNS-based requirement elicitation and minimize technical challenges. Organizations, on the other hand, should prioritize the protection of stakeholders’ accounts or devices from unauthorized control by third parties through SNSs to enhance privacy measures and improve the disclosure of information.

Organizational Challenges: (5) Lack of adequate skills: This challenge is mentioned eight times. This challenge is addressed in previous studies [14]. The business owner and the software developers are not encouraging and supporting the eliciting requirements from SNSs because they might not be completely aware of its benefits. In addition, they might not have sufficient knowledge and skills to obtain the software requirements that have the qualities of SNSs. (6) Lack of Technical Support: This challenge is mentioned six times. Software developers who do not have sufficient skills to implement technical processes such as data mining and natural language processing (NLP) face obstacles in obtaining quality requirements from SNSs. These techniques are the most used techniques to obtain requirements from SNSs [6]. This challenge is highlighted in prior studies [10,19,20]. Therefore, more effort is required by software developers in collaboration with other departments and experts to consider applying automated and semi-automated approaches and explore the associated benefits. This would add flexibility to SNS-based requirement elicitation, thus facilitating the combination of more than the elicitation approach, according to the nature of the project.

All organizational challenges, including Lack of adequate skills and lack of technical support, have a significant impact on the effective adoption of SNS-based requirement elicitation. However, if careful attention is paid to these issues, they can be easily controlled.

Environmental Challenges: (7) Lack of stakeholder involvement: This challenge is mentioned five times. The stakeholders are not motivated to give their online feedback, especially positive feedback. The challenge could be because stakeholders are not aware that their feedback would influence software improvements. This challenge is reported as a major challenge affecting the quality requirements [10,18]. Therefore, software developers should plan to promote user involvement by leveraging the sense of accomplishment users experience after identifying and reporting issues. When the suggested modifications are implemented, impact users become more motivated. In addition, software developers should improve communication with stakeholders by discussing their feedback, software problems, and potential solutions, with deeper attention to feedback issues. (8) Local governmental legalization: This challenge is mentioned seven times. Stakeholder feedback and local government legalization conflict have made it challenging to successfully extract requirements from SNSs. This challenge was not noted by many participants, and it was not included in any prior studies. This finding might be the result of it happening infrequently because everyone is aware of the laws passed by the local government. (9) Lack of quality requirements: This challenge is mentioned 21 times. This challenge means any deficit in SNS’s users’ feedback toward a service/system that results in deviating requirements from conforming to one or more of the good requirements of quality criterion that include Unambiguous, Testable, Clear, Correct, Feasible, Atomic, Necessary, Consistent, and Complete. This challenge is discussed in a prior study [10,14].

5.1. Implication for Research

The findings of this study have a number of important theoretical implications:

• The study added new knowledge to the requirement elicitation literature by exploring the actual use, benefits, and challenges of SNS-based requirement elicitation by directly interviewing software developers, a previously unexplored area.
• By applying a different methodological lens than the commonly used systematic literature review (SLR) methodology, the study offered a more specific and nuanced exploration of the subject.
• To the best of our knowledge, this study is among the first to identify the factors influencing software organizations’ adoption of SNS-based requirement elicitation. The utilization of the Technology, Organization, and Environment model (TOE) served as the theoretical foundation for this study. It was possible to integrate the most critical benefits and challenges from each of the three TOE framework dimensions—technology, organization, and environment that were most faced by software developers when they performed SNS-based requirement elicitation.
• This study is among the first studies to offer strong empirical evidence in support of software organizations using SNS-based requirement elicitation.
• This study reported many SNS-based requirement elicitation benefits and challenges, several of which were not found in previous studies, such as corporate agility.
• Most challenges, for instance, also have benefits. It is beneficial to involve stakeholders more in the SNSs in order to gather requirements. Requirement elicitation, however, usually becomes a challenging task when developers have to deal with large amounts of data.
• The findings of this study bring a level of specificity to the broad definitions found in the literature by focusing on the use of a specific online feedback source (SNS) during a particular requirement engineering activity (requirement elicitation). Thus, the discrete specifications and categorizations provide a deeper understanding of the intricacies of SNS-based requirement elicitation.

5.2. Implication for Practice

The participants described various technical, organizational, and environmental benefits and challenges regarding the implementation of SNS-based requirement elicitation; the results of this study present useful, practical implications for software developers, organization owners, and project managers. These include the following:

• Based on the findings from this study, developers should consider SNSs as primary sources of requirements with careful consideration of the limitations that emerged from this study.
• The manual steps identified from this study when conducting SNS-based requirement elicitation offer practical insights for practitioners to improve the efficiency and effectiveness of the projects. Practitioners could modify or incorporate additional steps that can be used as guidance assisting in resource allocation and timelines required for successful implementation.
• The categorization of benefits and challenges stemming from this study serves as a practical roadmap for developers to anticipate the positive outcomes and complexities associated with the adoption of SNS-based requirement elicitation. Realizing these specifications, practitioners would be better acquainted with the key aspects contributing to the effective implementation of the SNS-based requirement elicitation.
• This study found that software developers adopt a manual technique to extract requirements from SNSs despite all previous studies recommending automated and semi-automated approaches. This tendency may be attributed to the lack of academic-industry collaborations.
• We found that SNS-based requirement elicitation was a significant source of functional requirements. This may be because stakeholders only express their needs and are mostly unaware of nonfunctional requirements.

6. Conclusions and Future Research

This study aimed to explore the actual use, benefits, and challenges of the adoption of SNS-based requirement elicitation in Saudi Arabia. By applying a different methodological lens than the commonly used systematic literature review (SLR) methodology, we interviewed 25 practitioners in the software development industry to offer a more specific and nuanced exploration of the subject. Although the use of SNS-based requirement elicitation in the software development industry is still in its infancy, the findings confirmed its potential as a significantly valuable resource for extracting requirements, especially for functional requirements. The study also sheds light on the reasons behind some developers avoiding the use of SNSs for requirement elicitation, offering a critical perspective on the current tendencies and attitudes toward the adoption of SNS-based requirement elicitation. By investigating the current practice of SNS-based requirement elicitation, the findings revealed that software developers extract requirements from SNSs manually, contrasting the previous studies’ recommendations about the use of automated and semi-automated approaches.

With the application of the TOE framework, we identified five benefits and nine challenges of SNS-based requirement elicitation and classified them into three distinct viewpoints, namely technological, organizational, and environmental. The benefits found from this study supported some findings from previous research and introduced advantages that have not been reported by previous studies, such as corporate agility. Further, the identified challenges from this study involve more than simply the widely discussed technical challenges in the literature.

This empirical investigation was conducted in the context of SNSs within the software industry in Saudi Arabia on a relatively small sample size. Although our participants worked at leading software companies and had a wide range of experience in software development, future studies may expand their investigation into other online feedback sources, such as the App Store, on a larger sample and in broader contexts. Furthermore, while the qualitative data provided a comprehensive understanding of SNS-based requirement elicitation, future investigations may consider adopting quantitative methods to statistically measure the effectiveness of the practices and impacts of the challenges found in this study for the SNS-based requirement elicitation. According to this study, participants paid greater attention to technological challenges than to the other two contexts. This indicates a gap in the environmental and organizational challenges that will negatively affect and heighten opposition to the adoption of this technology in the SNS-based requirement elicitation. Thus, additional study is needed from an environmental and organizational viewpoint.