A Comparative Systematic Analysis of Stakeholder’s Identification Methods in Requirements Elicitation

[Context and Motivation] Before eliciting and gathering requirements for a software project, it is considered pivotal to know about concerned stakeholders. It becomes hard to elicit the actual system requirements without identifying relevant stakeholders, leading the software project to failure. Despite the paramount importance of stakeholder identification in requirement elicitation, it has been given less attention in the software engineering literature. [Method] For this purpose, we conducted a thorough Systematic Literature Review (SLR) on stakeholder identification (SI) and its methods in requirement elicitation. However, previously, a literature study on SI in the requirement elicitation was conducted. We found that no one has proposed any standard or baseline research method for stakeholder identification, stakeholder assessment, and stakeholder interaction up to date according to our knowledge. It provides an opportunity to update the current SLR on SI in requirements elicitation from 2011 till 2021 to search for a baseline methodology for the SI. For this purpose, we explored the existing literature research that involves the SI methods in requirements elicitation. [Principle Ideas/Results] Furthermore, we identify and capture seventeen research methodologies for SI, eight key stakeholders interaction methods, and ten stakeholders assessment methods in requirement elicitation. To further enhance the stakeholder identification process, we additionally identify pivotal information such as different potential stakeholder categories, stakeholder assessments methods, and stakeholder interaction methods. Also, based on the proposed SLR, we find out the existing gaps and new opportunities for SI methods in the requirement elicitation. [Contribution] These SI methodologies help requirements engineers and practitioners identify key stakeholders and efficiently improve the requirements quality. Moreover, this research study helps identify the effective practices used for the traditional and CrowdRE SI, recover consequences that can affect the effectiveness of SI, and recommend advisable SI practices to be employed in the future. This research study would help the software researchers and developers efficiently and accurately identify correct and concerned stakeholders to improve end-user satisfaction instead of considering it a self-evident task.


I. INTRODUCTION
Requirements engineering (RE) is a process in which the most diverse set of product demands from distant The associate editor coordinating the review of this manuscript and approving it for publication was Mario Luca Bernardi.
stakeholders are gathered that are considered by the practitioners for software development. These two reasons make requirements engineering complex and critical [1]. RE consists of five main phases: elicitation of requirements, analysis of requirements, specification of requirements, validation of requirements, and requirement change management. Whereas each requirements activity is executed separately, it should perform or separated sequentially [2], [3]. A ''requirement'' is a necessary attribute in a system or statement that identifies a system's capability, characteristic, or quality factor that has a value and utility to a user [4], [5].In the first phase of requirement engineering, we focus on identifying the concerns of stakeholders [6]- [8]. The requirements elicitation is an activity within requirements engineering that is concerned with discovering the needs of stakeholders for software development, either from scratch or evolution [9]- [12]. We need to consider stakeholders' concerns before starting the elicitation phase. A stakeholder in an organization is any group or individual who can affect or is affected by achieving the organization's objectives [13]- [16]. It is evident in the literature that before finalizing, stakeholders first analyze its influence on the project/system [17], [18].
SI in requirement elicitation is poorly handled and valued in software projects. One possible reason might be the process is viewed as a self-evident task in which the direct users and the development team are the only stakeholders. Also, there is a debate and confusion that software vendors usually forget or do not consider indirect stakeholders for the software applications. Therefore, it is mandatory and pivotal to properly and on-time identify all the concerned stakeholders to improve the quality of software applications and achieve higher user satisfaction [153]. It's believed that Stakeholder Identification might be substituted with opinions or knowledge from other more accessible sources of information [19], [20], [29]- [31]. To date, most of the researchers identify stakeholders with the traditional approaches/techniques, such as focus groups, interviews, and snowballing [32], [38]. The quality of the elicitation of requirements, particularly the software requirements themselves, is directly dependent on the completeness and correctness of the identified stakeholders [13], [34]- [36]. Adequate, accurate, and on-time recognition of stakeholders is vital in software requirement engineering. However, the most critical issue in requirement engineering is to ensure that all the relevant stakeholders are identified and captured accurately. Moreover, in light of this issue, it is also being seen that when multiple vital stakeholders do efforts for the same goal, they probably face contradiction in such situations; that's why requirements may be vague and cannot be acquired by the appropriate stakeholders. Therefore, the accurate stakeholder with its desired nature must be accomplished before starting requirement elicitation [150]. In Contrast, it has received rare attention in the requirements engineering literature compared to other aspects, like user involvement in software development and scenario-based process prioritization [37].
Furthermore, properly identifying stakeholders is the first step to bind the system interest and correctly defines the problem of concerns [14], [19]. Therefore, the identification of stakeholders is of paramount importance to reduce the uncertainty of the validity of a system to be developed [12], [20], [21]. In other words, SI has a pivotal impact on requirements quality [19], [22], [46]. Despite the importance of SI in requirements elicitation, it has been given less attention in software engineering literature [23], [24]. However, Pacheco and Garcia conducted a detailed SLR (Systematic Literature Review) study on SI methods in requirement elicitation. In their proposed SLR study, the authors claimed that to date there is no such method exists to identify stakeholders for requirements elicitations. Recently, software researchers have given more importance to the requirements elicitation phase, while some researchers have proposed methods for SI. It motivates us to update the current SLR for the SI to provide an opportunity to the requirements analysts and development team to improve the overall software quality by identifying concerned stakeholders at the beginning of the project [25], [26], and [28]. In this research work, we extended the four main research questions (the status of SI in RE, effective practices for SI, consequences due to incorrect identification of stakeholders, and advisable approaches for performing SI) from Pacheco and Garcia [19] SLR to identify baseline methods for SI by exploring the literature from 2011 till 2020. Therefore, we explored the existing literature research involving the SI methods and identified additional 42 pivotal research papers that discuss and contribute to stakeholder identification. By critically analyzing these research papers, we were able to recover and capture seventeen methods for SI in Requirement Elicitation and updated the research questions of the original SLR to give a better and comprehensive overview of SI to the researchers and software developers. Furthermore, we find the existing gaps and new opportunities for the SI methods in the requirement elicitation.
Section 2 represents related work to the proposed SLR, Section 3 describe the proposed research methodology, Section 4 represents the results and analysis, which comes against the proposed research study, Section 5 discuss the findings from the SLR, and Section 6 concludes the research paper on SI and discusses the future work.

II. RELATED WORK
In this section, we discuss the important related work for stakeholder identification. The detailed literature study is elaborated in Table 1 also explained below to elicit the proposed approach in the research paper and identify the stakeholders-related activities performed in the paper. Table 1 is comprised of three columns; the ''Authors'' column describes the author names who proposed the SI approach. Column ''proposed approach'' explains an abstract introduction to the SI method proposed by the authors. At the same time, the last column explains the SI activities performed or covered in the proposed approach. The detailed literature study builds a sound background in the field of SI.
Stakeholder Identification in requirement elicitation is poorly handled and valued in software projects. While one wouldn't collect all the relevant requirements until and unless you have not identified the relevant and exact stakeholders, because of that, if one's get any ambiguities in the elicitation process, then it would be very hard to accomplish VOLUME 10, 2022 your project according to its desired outcomes as requirement elicitation is the benchmark and foremost step of software engineering [152]. Pacheco and Garcia [19] conducted a systematic literature review on stakeholder identification, but their study limits a few aspects. For example, they could not identify baseline stakeholder identification methods, stakeholder assessment approaches, and baseline stakeholders interaction methodologies. Furthermore, their proposed study did not cover any knowledge or findings on crowd-based requirements engineering. Also, Hujainah et al. [116] conducted a detailed systematic literature review, which mainly focuses on requirements prioritization. They identified that current prioritization approaches are limited in identifying key stakeholders for requirements prioritization tasks. Also, Limaylla et al. [154] discuss that requirements identification and prioritization are the core concept of software quality. They proposed a semi-automatic multiple-criteria process that can ensure the appropriate prioritization of requirements and decrease stakeholder participation, but still, there is a tiny lack of considering indirect requirements (Functional or Non-Functional requirements), and for that, we need to focus on the identification of indirect stakeholders [154]. Additionally, Coughlan et al. [83] conducted a closed systematic review of 593 different stakeholders and filtered, ordered, and sorted out the stakeholders based on a four-dimensional framework which is consisted of: Type, Mediator, Class, and behavior of stakeholders to efficiently identify requirements.
Sadiq and Jain [33] claim that previously goal-based requirements engineering approaches, such as goal-oriented requirement elicitation process (GOREP), knowledge acquisition for automated specification (KAOS), attributed goaloriented requirement analysis (AGORA), and goal-oriented idea generation (GOIG), couldn't support Stakeholder Identification. In light of this, they proposed a stakeholder identification approach that consists of several steps: stakeholder specification types, stakeholder specification roles, a fuzzybased approach to select and classify stakeholders, and stakeholder inquiry or analysis. Zaharia and Hodorogea [7] proposed an automated approach to identify research stakeholders using information retrieval methodologies over a set of research papers containing the same keywords. For this purpose, they employ the JADE (Java Agent Development Framework) approach installed on relevant nodes and will assess the users of this framework to automate the process. Such an approach can also be utilized and modified to identify key stakeholders for engineering requirements. Similarly, Miles [71] proposed a stakeholder identification approach that identifies and prioritizes stakeholders for a software project based on his interest, relationship nature, the base of their Legitimacy, nature of duty or responsibility, risk nature, and power nature. Salado and Nilchiani [20] proposed a brainstorming based approach in which the system will ask certain questions to identify concerned stakeholders, such as Why: Why you have this system?, How: How does this system make a response?, Where: Where does this system work?, and What: What does the system do? to better identify key stakeholders. Ballejos and Montagna [22] proposed an interview-based approach that identifies key stakeholders by identifying stakeholder type, stakeholder role, stakeholder selection, establishing links between the stakeholders, and finally analyzing the influence of each stakeholder on the software project. Recently, Lim and Finkelstein [10] proposed an automated StakeRare approach to identify potential stakeholders, which works as 1. Initially, stakeholders will be identified by a requirements engineer, 2. Then the identified stakeholders will recommend further relevant stakeholders, 3. By this, a network of stakeholders will be established, 4. Finally, the proposed method will prioritize stakeholders and their roles as an output. While more recently, Khan et al. [5] proposed an automated approach to identify key stakeholders and their corresponding contributions in the social media platform (Reddit forum) by analyzing their user names.
In summary, before starting the requirements elicitation phase, stakeholders from different backgrounds, areas, experiences, understandings, and viewpoints need to be precisely identified to effectively and efficiently define their requirements. The relevant stakeholders can influence the outcome of the system/project. These concerned stakeholders have their needs and expectations based on their understanding, viewpoints, and experiences. The software system requires to fulfill these expectations and requirements [17], [20], [58]. For this purpose, we conducted a detailed literature study on stakeholder identification to identify baseline stakeholder identification methods, stakeholder assessment approaches, and interaction strategies between stakeholders and can help in stakeholder management and requirement elicitation. Reference [7], [18], [58]. An abstract view of the literature study is shown in Table 1.

III. PROPOSED RESEARCH METHODOLOGY
There is a quite difference between Systematic literature review (SLR) and conventional literature review, such as, SLR is a study in which we have to answer specific research questions. In SLR, the main goal is to answer what we have to do and how it will be achieved in the best way, along with the proofs and shreds of evidence [122]. Compared to the conventional literature review, the SLR provides a unique procedure and results, including literature evaluation of a problem, future research directions, and highlighting current limitations [35], [39], [40], [146]. Thus, in comparison with the conventional and traditional methodologies, SLR is alternative literature [26], [41], [42].
This research study is concluded as a preliminary review, and that review by itself is a secondary study. The literature review or secondary research will be meaningful in further researching or identifying any deficiency in the current research. To see the impact of SI in RE on software quality, as discussed in section 1, we become motivated to see the implications of SI in RE, how it can be improved and how it has been performed. Furthermore, we also followed the guidelines proposed by Babra Kitchenham, where they have developed different guidelines for conducting a systematic literature review, which was first presented in 2007 [43]. Latterly, they updated the SLR guidelines in 2013 by introducing the quasi gold standard technique, which we have also adopted and followed in our current research approach. We can highlight the main drawbacks in requirements engineering and software engineering using these guidelines while conducting the SLR study. Following these guidelines, we have taken the following steps. While the detailed research methodology for the proposed SLR is depicted in Figure 1. The Figure is self-explanatory, and each step is depicted in the Figure 1 is explained thoroughly in the below steps.

A. IDENTIFY THE NEED FOR SYSTEMATIC LITERATURE REVIEW
According to the department of defense (DOD), RE is the phase of software development that consists of different life-cycle processes dedicated to the identification of user needs, investigation of requirements, requirement documentation, validation of the software requirements, and all of the concerned processes which support its activities [33].
The different activities in requirement engineering are elicitation, analysis, specification, and requirement validation [13], [44]. Our targeted activity in this research paper is requirements elicitation because it is pivotal to identify key and relevant stakeholders to properly, in-time, and correctly gather end-user requirements that lead within budget and in-time completion of software projects or applications. In the requirements elicitation phase, we gathered requirements from different sources, such as systems and the concerned stakeholders. Therefore, through this research study, we try to minimize this effect by focusing on the requirements elicitation phase. For this purpose, before starting the software requirement elicitation phase, stakeholders from different backgrounds, areas, experiences, understandings, and viewpoints need to define their requirements effectively and efficiently. Moreover, the relevant stakeholders can influence the outcome of the system/project [34]. These concerned stakeholders have their needs and expectations from the system based on their understandings, viewpoints, and experiences [4]. The software system requires to fulfill these expectations and requirements [34], [46]. The stakeholders' study and identification are the pivotal sources to know how to maintain the concerned stakeholders in a rapidly changeable and inconsistent environment [47]- [49]. The SI is a difficult and challenging phase of the requirements elicitation for the practitioners and researchers [35], [50]- [53]. The researchers and practitioners have done much work on SI and their interests, but as per the literature study, the researchers called it a self-evident task or an adoptive process [26]. To fill the gap, it is required to update the original SLR and conduct a new detailed systematic literature review to explore existing standard or baseline SI methods and provide empirical and theoretical evidence regarding this issue. Therefore, to update the SLR in requirement elicitation by exploring and identifying the research shreds of evidence for SI methods/Approaches. Additionally, we will incorporate other aspects of software quality that can be beneficial for software practitioners to improve the software quality.

B. FORMULATE REVIEW RESEARCH QUESTIONS
With the help of the proposed systematic methodology, we have highlighted those aspects through which we could improve the quality of software products regarding SI in RE. Furthermore, we summarized evidence intending to find baseline research methods for SI. For this purpose, we thoroughly evaluated and analyzed different research papers in the proposed system literature review to answer the below research questions: RQ1-How are stakeholders identified in the literature, and do any baseline SI methods exist? RQ2-What key stakeholder assessment and interaction methods exist in the SLR?

RQ3
-What activities or practices should be considered when designing a SI method for traditional and Crow-dRE methodology? RQ4-Does incorrect SI affect requirement elicitations and software projects? For this research study, the proposed research questions are inspired by Pacheco and Garcia [19] approach to identify existing approaches for stakeholder identification and other relevant information, such as stakeholder communication methods, stakeholders assessments, effective practices for SI, and consequences of incorrect SI, to help requirements engineers in improving the overall performance of software applications by achieving high user satisfaction.

C. SEARCH STRATEGY
We used an automated search strategy by collecting all of its shreds of evidence from the online databases/sources, as shown in Figure 1. We derived different keywords to answer the four research questions, such as stakeholder, identification, method, and requirements elicitation. The possible Synonyms for the derived keywords are:

1) SEARCH STRINGS
To accomplish our search study, we developed some research strings to identify research papers for SI. Searching databases are the libraries where we search desired research papers using different search strings. Table 2 shows the results of  Furthermore, we have conducted a pilot study to ensure the accuracy of the search strings. The pilot study has a pivotal role in searching research papers, due to which we can smoothly evaluate our search strings and get the actual results. In Table 3, we show the results of different search strings, which we have tried before finalizing the original search string.
A representation of our pilot study from different search engines, such as IEEE, Science Direct, ACM, and Springer, is depicted in Table 3. There are two types of results against each search engine. The first row represents the results of the trial search string, while the second row represents the actual search string's results. The result shows that we collected many research papers with the trial string, although several research papers were considered inappropriate, such as identified from irrelevant research domains. In contrast, the search results with the actual search string are mentioned in the second row of Table 3, where the most relevant and related research papers are identified against the targeted research topic, resulting in fewer research papers relevant to the SLR domain.

2) SEARCH ENGINES
To execute the search results for the proposed SLR, we identify some popular search engines that help recover and capture pivotal research papers in the domain of SI, such as ACM, IEEE, Springer, and Science Direct (SD), as shown in Figure 1. To explore the recent work published on SI, we applied the search strategy to the aforementioned databases to find the research papers (both journal and conference). Furthermore, each search result was checked and validated for a secondary review. We applied all the four search strings of the derived keywords mentioned above.

3) TIME PERIOD
For the search string, we have covered the duration of eleven years from 2011 to 2021, and the reason is that we found a research gap in the original SLR, indicating that there is a need to update the original SLR [19] to identify a baseline methodology for the SI and other relevant information.

4) ANCILLARY SEARCH PROCEDURES
Snowballing is a technique to search relevant research papers from the primary study where we focus on a preliminary study references list or academia. We ask one concerned SI expert to tell about another relevant research study that is worth considering as a relevant study in the proposed SLR. Snowballing refers to identifying new papers based on those citing the research papers being examined in the process [54], [55]. Similarly, we have used primary references of our study to identify and capture relevant literature if it is missed in our search string results.

5) SEARCH PROCESS EVALUATION
Quasi Gold standard is used to evaluate the research findings. As mentioned before, we have used the snowballing technique to identify and capture relevant research papers to evaluate and analyze our research in line with some known research papers, where the result of the quasi gold standard was above 80%. Initially, 13 (articles were identified  randomly, of which eleven research papers were relevant. Table 4 listed the research papers that came as a result of the random search before finalizing the search string for the proposed SLR.
Both primary and secondary pieces of evidence were used when finding the accuracy of search strings and found relevant results upon extracted search strings.

D. INCLUSION
We have included all the relevant studies of the search result in our proposed SLR. According to the SLR topic (Stakeholder identification), we tried several search strings to get the most suitable and relevant results according to the SLR topic (Stakeholder identification). After getting several hundred research papers, as shown in Table. We included only those papers in the proposed SLR, which fulfill our inclusion criteria. The inclusion criteria's for the proposed SLR is as follows: • Precisely covered any of the research questions or synonyms in the targeted study.

E. EXCLUSION
We excluded all the irrelevant publications to ensure the accuracy of our search results, such as: • Slides (not accepted in research references).
• Laboratories/Workshops. • Viewpoints, Opinions/Storytelling. • Those research papers do not have any evidence or empirical analysis.
• Research papers other than the English language Furthermore, the paper selection for the proposed SLR was performed iteratively, as shown in Table. First, we identified 1487 research papers from the four distant research engines using the developed search string. After applying the exclusion criteria over the selected papers in the first iteration, we reduced the size of the research papers to 99. Thirdly, while reading the title, abstract, or sometimes full text of the research paper, we further reduce the size of the research papers to 58, amongst which 54 papers are included for the proposed SLR, amongst which 15 research papers were identified using the snowballing method that belongs to other research databases or more specifically journals, such as, PAKJET, international journal of business and social research, Ingenta connect, MDPI, IET, Wiley, and google scholar. Furthermore, four research papers are discarded from the SLR because of irrelevancy to the SLR goal. While the remaining 41 papers are still considered relevant as the potential references for the research approach because these papers still pose some relevancy to the proposed SLR, as shown in Figure 1. Furthermore, we additionally found 45 research papers about stakeholder identification, but these papers were already included in the Pacheco and Garcia [19] SLR. Most of these research papers are published between 2000 to 2010. Therefore, we did not include these research studies as a primary source for evaluation and identification of stakeholder's related information but as secondary studies source, as depicted in Figure 1. Secondly, it is considered pivotal as researchers and software engineers will find up-to-date and comprehensive literature about stakeholder identification together. In a nutshell, we shortlisted 54 research papers that are thoroughly and comprehensively analyzed to identify relevant stakeholder identification data and update the existing literature and research questions.  Table 6, shows the results of the quality assessments for the research papers included in the SLR, which is derived by evaluating each research paper in the proposed SLR for SI. By analyzing, we found that one research paper was categorized as poor because it didn't cover any of the research questions about SI. Three research papers were partially accepted because there was a lack of benefit to our presented research. Altogether, we rejected these four research papers from our search study. In comparison, the remaining 54 research papers fully satisfy the SLR objectives and research questions, hence included for the SLR study to identify useful information for the stakeholders. The percentage of the 54 research papers is identified based on the formula (No. of research paper/total No. of research papers * 100).

G. QUALITY ASSESSMENT
The quality checklist for the proposed SLR comprises three questions, which need to be answered for each research paper included in the SLR study. For this purpose, we applied these three questions to the proposed literature study one by one and answered each question for each research paper included in the SLR study. Q1. Is the aim of the research sufficiently explained? Q2. Is the presented approach clearly explained? Q3. What is the acceptance quality rate based on the findings for a paper? To evaluate the quality of the included research papers in the proposed SLR, we adopted scoring criteria, such as if explained = 1, if partial = 0.5, and if not relevant = 0. The scoring criteria are 0 to 1, for which 1 is assigned to excellent or most relevant research papers in the SLR, 0.5 is assigned to partial or moderate research papers, which includes only those that possess certain relevancy to the goals. In contrast, ''0'' is assigned to the research papers that do not correspond to the SLR research questions and are rejected. The sample of research paper assessment in the proposed SLR is shown in Table 7. Based on this assessment, we rejected four research papers that failed to answer the quality questions.

H. DATA EXTRACTION
The data extraction process is conducted with MS Word, MS Excel, and Zotero software's to record all the data and references about the proposed SLR study in this research paper. We categorized the research papers' findings using these existing data extractions software and updated the existing SLR for the SI in requirements elicitation.

I. STUDY SELECTION CRITERIA
Initially, using our search criteria, we found 1487 research papers from the different online research databases, which need to be filtered based on title, keywords, and abstract, as shown in the Table 8 and the detailed pictorial representation are shown in Figure 1. While, in the second row and second column of Table 8, we shortlisted research papers based on the title, keywords, abstract, and introduction. In the 3rd review, we finalized 48 research papers that satisfy the research questions and objectives of the SLR. Finally, four research papers were rejected after filtering it with the quality checklist, and 54 research papers were finalized and were selected for further process of the proposed SLR.

IV. RESULTS
After critically reviewing and analyzing a large number of research papers, only 54 research papers were selected that discuss the target topic of SI in requirement elicitation by executing our protocols. We can now complete our synthesis and analysis phases. A large number of analyzed data is not validated; therefore, we couldn't add its implication in requirement elicitation yet. In the below sections, we discuss the results obtained by analyzing the distant research papers selected for the proposed SLR on SI.

A. NATURE OF RESEARCH STUDIES
The reviewed studies are classified according to the Kitchenham protocols [43] and the proposed SLR research method. We followed a simple strategy to categorize the research papers identified for the SLR. For this purpose, we classify the research papers into the below categories such as: • Empirical, such as research papers directly relevant to the SLR topic, experimental, or preliminary work on the said topic.
• Theoretical or conceptual studies are secondary research studies known from some other sources. Furthermore, Figure 2 shows that 95% of the research papers included in our SLR study are categorized as empirical while fewer studies (5) are identified as theoretical.

B. PUBLICATION YEAR OF SEARCH ARTICLES
In total, we selected 54 research papers for stakeholder identification from the literature, which are in between the years 2011 to 2021. In contrast, four research papers selected for this study are from 2004, 2006, 2007, and 2008, respectively. These research papers are considered critical and pivotal for the SI, but unfortunately, they were missed in the previous SLR [19] that was conducted in 2011. In Figure 3, the most research paper published in a year on SI is 2021, which is 10 research papers. It shows the growing interest of researchers in stakeholder identification and its importance with the emergence of social media platforms where direct and indirect stakeholders frequently contribute requirements-related information. Another aspect behind the increased publication may be due to the awareness of its importance or parallel with general publications on SI in requirement elicitation. Also, the second most publication published in a year on stakeholder identification is 2020, i.e., 8 research papers. It is because of a rising trend towards the utilization of web-based software applications, such as web forums, recommendation systems and wikis, to collect, elicit, model, validate and prioritize software requirements from a large number of potential stakeholders and the emerging market of the mobile applications whose users are distributed geographically around the globe. Therefore, it is pivotal to adopt stakeholders identification and prioritization methods, listen to the needs and requirements of the potential stakeholders, and improve the overall quality and user satisfaction. Furthermore, from 2013 to 2017, we also see an encouraging publication numbers, where different research authors highlighted the importance of stakeholder identification for the project's successful completion. However, since 2011, the SI still needs much attention from the RE research community because we identified only seventeen research papers that precisely describe the proposed SI approaches. Furthermore, according to our knowledge, there is still a lack of efficiency and effectiveness in identifying stakeholders where the existing SI methodologies further need improvements and validations, specifically for the crowd requirements engineering. It is also captured in the literature that the current approaches of SI are vague when it comes to the prioritization and characterization of stakeholders [23], [33], [61].
Additionally, to report the precise picture of literature regarding SI in requirement elicitation, we have gathered pieces of evidence against each research question, that what techniques or methods exists in the literature on SI in RE (RQ1); What key stakeholders assessment and interaction methods exits in the literature (RQ2); what activities and practices should be used when designing SI method for traditional and CrowdRE methodologies (RQ3), and what are the implications of incorrect SI on requirements and software system (RQ4). In the below sub-sections, we elaborated the research questions based on the literature study.

C. STAKEHOLDER IDENTIFICATION TECHNIQUES
Answering to the RQ1, in the previous SLR [19], authors could not identify and capture the standard or baseline methodologies or techniques for the SI in requirement elicitation. In contrast, we were able to identify and capture seventeen SI methods using the proposed SLR study, as explained in Table 9. The Column ''Method'' shows the proposed name of the SI approach in the research paper included in the SLR. Column ''Method description'' offers an overview of the proposed SI method, techniques used and explains the VOLUME 10, 2022   flow of the proposed SI methodology. The column ''Paper Reference'' shows the authors' names who propose the SI method and its corresponding research paper link.

1) ADDITIONAL DETAILS ON TECHNIQUES OF SI
We elaborated some additional interesting information about the proposed SLR compared to the SLR study of Pacheco & Garcia [19]. They have identified seven research papers that exclusively defined the stakeholder. In comparison, we have identified 17 additional research papers that focus on the SI, as shown in Table 10. Furthermore, in their SLR [19], they identified 23 research papers that focus on the interaction of stakeholders. While we additionally identified 11 more research papers that exclusively focus on the interaction of stakeholders. Finally, we find 13 new research papers in the proposed SLR that focus on the assessment of stakeholders compared to the previous SLR [19]. The details of the proposed updated literature study compared to the previous SLR study are depicted in the Table 10. Also, describe below: Studies that exclusively describe • stakeholders (17 (new) + 7 (old) = 24 (Total)) Studies focusing on the interaction • between stakeholders (11 + 23 = 34) Studies that include assessment of stakeholders (13 + 10 = 23) Furthermore, for RQ-1, we identify and capture seventeen baseline or standard SI methods in RE. The authors claim in their original SLR that no method exists for identifying stakeholders [19] to date. In contrast, we have found VOLUME 10, 2022 seventeen methods/techniques for SI in requirement elicitation using the proposed SLR study. The proposed SI approaches names, their detailed explanation, and the following structure is discussed in Table 11. Table 10 provides details on the different aspects of SI in requirements elicitations. In the first row, we summarize those research papers that precisely describe stakeholders, focusing on whom and who the stakeholders are. Also, identified and captured the different names and roles that have been assigned to the stakeholders in distant research papers in the literature study. In the second row of Table 10, the distant authors interpreted that interaction between stakeholders has a vital role while identifying stakeholders in their research papers. It would be beneficial if we mentioned interaction between stakeholders [151]. While in the last row of Table 10, many research authors addressed that the assessment of stakeholders is also pivotal in the identification phase because precise assessment of system stakeholders leads to accurate requirement extraction. In the below sections, each finegrained stakeholder identification findings are explained in detail.

a: POTENTIAL STAKEHOLDERS
In the original SLR [19], the authors had identified two categories for potential stakeholders. In contrast, we additionally identified 3rd category of the potential stakeholders that is different from the other two identified categories of the stakeholders in the literature. In Table 11, we have elaborated on the distant stakeholders identified in the literature study. Table 11 indicates that in the previous SLR study [19], the authors created only two subcategories for potential stakeholders. In contrast, we identified three subcategories of potential stakeholders, user, developer, and legislator, relevant to the development team and customer, as elaborated in Table 10. These stakeholders are identified from the literature while critically analyzing different research papers included in the literature study.

b: INTERACTION BETWEEN STAKEHOLDERS
Interaction is a link/communication between two or more stakeholders for discussing, solving, and analyzing any requirements-related activity, and it is considered pivotal while performing the stakeholder identification process [123]. Table 12 shows the different interaction classes between stakeholders identified using the proposed literature study compared to the previous SLR. In the first row, we reported research papers that show a diagrammatic view to show the internal phenomenon of organization stakeholders in their proposed methodologies. Also, we compare the new research studies identified compared to the previously captured research studies. We were able to identify one additional research paper compared to the previously identified 14 research papers, such as (14+1 = 15). Thus, we now have 15 research papers focusing on stakeholder interaction by displaying the proposed process graphically. Furthermore, we identified and captured six additional research papers that precisely described making interactions, selecting key stakeholders, and observing all the relevant stakeholders theoretically to the already identified eight research studies in the previous SLR [19], as shown in Table 12, row 2, column 3. It is the second category of additional details; we mainly focus on the theoretical view of the interaction between stakeholders. Those research studies in which the author explains the interaction between the stakeholders or between stakeholders and organizations are a diagrammatic representation. Those studies that elaborate this interaction in a theoretical or summary form are a theoretical representation.
For RQ2, unlike the previous SLR study [19], we go one step deeper and critically analyze the research papers in the proposed SLR that focuses on stakeholder interactions to identify widespread or most frequent stakeholders interactions methods. The details of stakeholder interactions methodologies are shown in Table 13. The column ''interaction method'' indicates methods or concepts used to provide interactions between the stakeholders. Column ''Proposed method description'' shows the consolidated abstract of the proposed approaches, and the column ''reference paper'' shows the corresponding research paper reference in the proposed research paper. As shown in Table 13, the researchers have proposed multiple approaches to assess potential stakeholders, such as Win-win methodology, debate, discussion, social network, communication, discussion, etc. It is concluded from Table 13 that Win-win methodology, debate & discussion, and social network are identified as the most frequently used approaches to achieve interaction between the potential stakeholders successfully. However, it is still challenging to identify procedures for interacting between the potential stakeholders for open-source or market-driven software development because of the large number of potential stakeholders involved in the discussion over a considerable time. We only identified one research paper [64] that proposed stakeholder identification and interaction method for open source software development, which needs further exploration and research.

c: ASSESSMENT OF STAKEHOLDERS
In Table 14, we reported fourteen research studies that have been identified in the literature, which assess the stakeholders based on their importance (dominance or importance). In contrast, the authors did not report this category in the original SLR study [19]. Also, eight research papers have been additionally identified in the literature study that has performed stakeholder assessments based on the priority interest in the project (stakeholder skills or stakeholder potentials) in comparison to the original SLR study [19].
We need to assess the stakeholders because there is a possibility that we identify many stakeholders for a specific project, which might not be possible to access every stakeholder due to the time and cost constraints [13]. Therefore, we require procedures or methodologies that can be used to assess and prioritize different stakeholders to have a positive impact on the software project. In this section, we focus on the experiences of the expert for the SI purpose. In assessing stakeholders, we assess the stakeholders from different studies according to their priorities and how they mark stakeholder influence on an organization project. In Table 14, we reported research studies that precisely define the skills and assessment of stakeholders in their proposed methodologies. In Table 14, we summarized the results obtained from the proposed SLR against RQ2, where we additionally identified eight research papers (shown in 2nd row of Table 13) that mentioned the skills of stakeholders in the project, compared to the already identified four research studies in the original SLR study [19]. Furthermore, in the second category, the previous SLR study did not report research studies about the importance of stakeholders. At the same time, we can identify fourteen research studies that identify stakeholders based on their significance in the project. The results are summarized as follows: • Stakeholder list according to their importance. (14+ 0 = 14) • Priority Interest in the project (Skills). (8+4 = 12) We identified two categories of stakeholders. One category is different from the stakeholders' categories identified in the original SLR findings [19], such as stakeholders' priority interests in the project and stakeholder list according to their importance. When comparing to the original SLR [19], we identified one new category for stakeholders assessment from the proposed literature, for which different authors of the research papers assess the stakeholders based on their interest in the project/system. The details of the stakeholder's assessments are shown in Table 14.
For RQ2, we critically analyze the research papers in the proposed SLR that focuses on stakeholder assessment to identify widespread or most frequent stakeholders assessment and evaluation methods. The details of stakeholder assessments methodologies are shown in Table 15. The column ''assessment approach'' indicates methods used to assess potential stakeholders. Column ''Proposed method description'' shows the consolidated abstract of the proposed approach, and the column ''reference paper'' shows the corresponding research paper reference in the SLR. As shown in Table 15, the researchers have proposed multiple approaches to assess potential stakeholders, such as comparative analysis, pairwise comparison, social network, fuzzy methods, discussion, etc. It is concluded from the Table 15 that Pair-wise comparison (AHP) and social network methodologies are identified as the most frequently used approaches to assess potential stakeholders. However, it is still challenging to identify and evaluate potential stakeholders for open-source or market-driven software development. We only identified one research paper [64] that proposed stakeholder identification and assessment method for open source software development, which further exploration is needed.

D. POSSIBLE EFFECTIVE PRACTICES AND CHALLENGES TO IDENTIFY STAKEHOLDERS FOR TRADITIONAL AND CROWD-BASED SOFTWARE APPLICATIONS
According to our knowledge, the previous SLR [19] on stakeholder identification is outdated because the authors VOLUME 10, 2022  did not register or report any research papers that explicitly discuss a baseline SI methodology. Therefore, it is required to update the SLR study on stakeholder identification to capture and recover the latest research practices and approaches for the changing nature of software applications. For RQ3, this section elaborates on two aspects of stakeholders identification; first, we update the existing SLR by identifying effective and efficient research approaches for performing SI for traditional software development methods, which need to be updated with the latest research articles. Secondly, we highlighted the effective practices and challenges in identifying potential stakeholders for market-based or crowd-based software applications, which remains a hot research area these days. Each aspect is elaborated in detail as follow:

1) UPDATE EXISTING LITERATURE WITH UPDATED RESEARCH PAPERS FOR TRADITIONAL SOFTWARE DEVELOPMENT
We identify and capture the relevant updated research articles that discuss the effective practices and methodologies for SI. The research papers captured for the effective SI practices were distributed, across the three categories, such as identifying and consulting all likely sources of requirements [29], [41], [46], [85], [108], identifying user classes and their characteristics [4], [13], [31], [34], [38], [45], [56], [58], [83], and [87]- [89], and identify & consult with the stakeholders of the system [13], [28], [36], [37], [43], [59], [61]. In line with the original SLR [19], our results are also classified in the following three practices with updated research articles, as shown in Table 16. The details are elaborated below: • We were able to identify five additional research papers compared to the original SLR study [19] for the category of identification and consultation of all relevant sources of requirements, as shown in the second row of Table 16. Now in total, we have ten research papers identified for this category, such as (5 + 5 = 10), where the 5 presents the reference of the previous SLR [19] and the remaining five refers to the updated proposed SLR study.
• Similarly, we identified six additional research papers compared to the original SLR study [19] for the category of identified user classes and their characteristics, as shown in the third row of Table 16. In total, we have 12 research papers identified for this category, such as (6 + 6 = 12), where the first six presents the reference of the previous SLR [19] and the remaining six refer to the updated proposed SLR study.
• Also, we were able to identify six additional research papers compared to the original SLR study [19] for the category identify and consult with the system's stakeholders, as shown in the fourth row of Table 16. In total, we have eleven research papers identified for this category, such as (5 + 6 = 11), where the five presents the reference of the previous SLR [19] and the six refers to the updated proposed SLR study. Our focus in this research study is to identify and capture effective, pivotal, and suitable practices for conducting the SI process in the requirements elicitation phase of requirements engineering. Similar to the original SLR [19], we also identified three main categories of these practices for SI but with updated research papers references. In the first category, we need to identify all the relevant sources of requirements. We need to identify user classes and their features/qualities in the second category. While in the 3rd category, we need to identify stakeholders that seek information about the software system. The details of different research methods identified from the literature about the effective practices for SI are shown in Table 16.

2) EFFECTIVE PRACTICES AND CHALLENGES IN IDENTIFYING POTENTIAL STAKEHOLDERS FOR CROWD-BASED SOFTWARE APPLICATIONS
For RQ3, the previous SLR [19] mainly focuses on research papers describing research approaches for stakeholder identification for in-house software development. Recently, due to the emergence of social media platforms, such as user forums, app stores, Facebook, Twitter, etc., potential stakeholders more actively participate in these social media platforms and frequently contribute requirements-related information in user reviews for the market-driven software applications [5], [133]. Such information is of pivotal importance for the requirements and software engineers to make informed decision-making to improve the quality of software applications under discussion by considering the crowd-users opinions, issues, new features reported in the end-user reviews [132], [138]. To timely gather such requirements-related information, we need to track the potential stakeholders in these social media platforms and the traditional in-house stakeholders to take informed requirements and software decisions. Therefore, we need crowd-based stakeholder identification, analysis, and prioritization approaches to take advantage of a large pool of stakeholders distributed geographically around the globe for market-driven software applications. By critically analyzing research papers in the proposed SLR, we find only a few (6) research papers [5], [64], [68], [139], [141], [151] that focus on identifying key stakeholders who frequently contribute requirements-related information in the social media platforms about market-based software applications. The one possible reason for identifying fewer research papers is that CrowdRE is still an emerging research area that needs theoretical and conceptual exploration. However, we reported specific recommendations for identifying, analyzing, and prioritizing stakeholders for gathering requirements for markdriven software applications by critically analyzing existing literature and our understanding of the Crowd-based requirements engineering.

3) KNOW THE PURPOSE OF IDENTIFYING STAKEHOLDERS
In CrowdRE, we simultaneously perform multiple requirements engineering activities, such as identifying and capturing functional requirements, new features, emergent requirements, non-functional requirements, and issues. Therefore, we need to identify the purpose of identifying and capturing critical stakeholders in the social media platform to perform specific requirements engineering activities. Furthermore, we need to specify or limit the time for determining the CrowdRE activities in social media because crowd-users continuously submit a large number of end-user comments over a period that might affect the performance of stakeholders 30998 VOLUME 10, 2022 identification method due to the presence of irrelevant or outdated data.

4) IDENTIFY AND MINE USEFUL REQUIREMENTS ENGINEERING REPOSITORIES
In CrowdRE, mainly information for requirements and software engineers came from various social media platforms, such as Twitter, user forums (Reddit, etc.), app stores, issue tracking systems, or specialized crowdsourcing platforms (Amazon Mechanical Turk (AMT)) [133]. Therefore, we need to identify or select the CrowdRE platforms where stakeholders mainly interact with each other. After identifying the social media platforms, we need to collect or mine requirements-related information (new features, issues, non-functional requirements, etc.) and their available corresponding met-data (stakeholders name, email, user name, etc.) registered by the various stakeholders in the selected platforms using existing API or other freely available extensions, such as PRAW. 1

5) IDENTIFY SIMILAR STAKEHOLDERS IN THE SOCIAL MEDIA
In CrowdRE, a few hundred thousand end-users contribute software and requirements-related information in the social media platforms [5], which need to be analyzed to identify similar stakeholders to reach the key contributors. Also, it is common in social media platforms where crowd-users assign different nicknames to themselves in the same social media platform or various social media platforms [138]. The nickname is a self-selected name derived from the original name, for example, Alikhan for Ali Khan. Additionally, sometimes crowd-users use a combination of names, nicknames, or emails, such as aalikhan, alikhan501, or alikhan50111, etc. We can resolve this issue by pre-processing the meta-data collected in the previous step, which contains the stakeholder's name, email, user name, etc. For this purpose, we extract the email string by removing the email domain; for example, test501@yahoo.com is converted to test501. Next, the email text is further cleaned by removing punctuations and number if there is any. Next, get the crowd-user name associated with the email and remove the middle name if there is any. Next, we use text similarity algorithms, natural language toolkit, and unsupervised learning algorithms, such as KMean, genetic KMean, etc. to identify similar stakeholders in the social media platforms [149]. Finally, we can identify similar stakeholders if slightly different end-users names have similar email login names.

6) CLUSTERING STAKEHOLDERS AND CREATING INTERACTIONS BETWEEN STAKEHOLDERS
In CrowdRE, many crowd-users submit feedback against the software application under discussion, which is identified either as a new feature, issue, emergent requirement, or nonfunctional requirement. There is a possibility that distant end-users recorded the same new software features, issues, 1 https://praw.readthedocs.io/en/latest emergent requirements, or non-functional requirements in the social media platform. We can identify similar-minded stakeholders in the social media platform and cluster them into similar stakeholders groups using machine learning and natural language processing techniques if they have reported on similar issues, new features, or non-functional requirements in the social media platform. Furthermore, we can use argumentation theory to create a stakeholder interaction graph or tree between the crowd-users in the social media platforms [138], [153] . The stakeholders who participated in the social media platform are represented as nodes in the argumentation graph and are connected through edges if they are involved in discussing similar features, issues, or non-functional requirements. For example, in the Reddit user forum, crowd-users submit ten to a hundred arguments in response to their immediate parent comment [64]. Such representation of stakeholders in the social media platforms helps resolve conflicts that arrive during the ongoing conversation over the requirements-related information.

7) IDENTIFY STAKEHOLDER PRIORITIES IN THE SOCIAL MEDIA PLATFORMS
We can identify the stakeholder influence in argumentation networks by identifying the number of feedback provided by each stakeholder in the social media platform using natural language processing techniques [5], [64]. For this, we can identify the number of comments submitted by each end-user in the social media platform and add this score as a weight on the edges. Next, we can employ weighted abstract argumentation [140] semantics to identify the most influential stakeholders in the network. Identification of key stakeholders in CrowdRE is of pivotal importance to timely and efficiently accommodating crucial requirements-related information in the software application timely and efficiently.

E. IMPLICATIONS OF INCORRECT STAKEHOLDER IDENTIFICATION ON SOFTWARE REQUIREMENTS
For RQ4, to complete a software project, it is important to identify your actual stakeholders and how much each stakeholder influences the project. In contrast, if you misidentify the potential stakeholder for the software project, pivotal and crucial distant stakeholder opinions are left out when designing and developing the project plan. Furthermore, incorrectly identifying key stakeholders can have long-term consequences on a software project, as the potential stakeholders are devalued or ignored and will expect to be ignored or devalued in the future. One possible remedy to resolve this issue is to list the diverse people or different organizations that might impact or impact the software project. On the way, there might be some interesting and supervising potential stakeholders identified, such as the Wife of CEOs, analysts, or media directly or indirectly interacting with the software system. Later, we discard or remove stakeholders not relevant to the software product initially identified as relevant and important stakeholders.  Also, we develop and write the software requirements specification (SRS) document based on the software requirements gathered and analyzed from the system stakeholders. Ultimately, if the actual system stakeholders were unidentified, the SRS document would not represent actual system requirements. Therefore, the software project fails, i.e., not satisfying the customer's needs and requirements. For this purpose, we need to analyze the Software Requirement Specification Quality (SRSQ), which is all about correctness, completeness, and consistency of the requirement specification, where IEEE standard 830 precisely discussed this scenario that it must be a part of SRS document [55]. Similarly, the software requirements collected from the wrong stakeholders might lead to incorrect requirements (Correctness). Furthermore, if the unconcerned stakeholders or participants are identified, this might result in incomplete requirements, resulting in project failure and affecting the software requirements specification [6], [23], [46], [56]. Whereas, All the ISO/IEC 25000, ISO 25010, and ISO 9126 have mentioned the significance of these functionalities (Correctness, completeness, and consistency) as pivotal modules for software quality [56]- [58], [128]. Many research approaches now emphasize the importance of correctly identifying stakeholders for the software project. We identified and captured the relevant research articles in the proposed SLR study that discusses the possible implications of incorrect SI for software projects. Unlike the previous approach [19], the research papers captured for the incorrect SI are distributed across the two categories, system failures, and cost time & resources, as shown in Table 17.
• We identify eight research papers in the proposed SLR, unlike the previous SLR study [19], for the category of system failure, as shown in the second row of Table 17, whose fail to identify any research paper that emphasizes the implication of incorrect stakeholder's identification.
In total, we have eight research papers identified for this category, such as (8 + 0 = 8), where the eight presents the reference of the proposed updated SLR. The zero refers to the previous SLR study, as they were unable to identify research papers for this category, which is considered a pivotal category for the success of software systems [56], [57].
• Similarly, we identified four additional research papers compared to the original SLR study [19] for the category of cost time resources, as shown in the third row of Table 17. In total, we have four research papers identified for this category, such as (4 + 0 = 4), where the four represents the reference of the proposed updated SLR [19]. The zero refers to the previous SLR study, as they were unable to identify research papers for this category, which is also considered an important category for the success of software systems [14]. In summary, there were no categories and research papers identified for the implications of incorrect SI in the original SLR [19]. In contrast, identifying and capturing irrelevant stakeholders can impact the requirement specification regarding correctness, completeness, and consistency [124]. Our proposed SLR identified two main categories for incorrect SI consequences: system failure and cost times resources, as shown in Table 17.

F. CAPTURED RECOMMENDED PRACTICES FOR STAKEHOLDERS IDENTIFICATION
The involvement of relevant stakeholders guarantees to complete the software system successfully [125]. We couldn't extract appropriate requirements until we identify relevant stakeholders for the software system, and it can then lead to the quality system [57], [63], [66], [117], [118]. Thus, SI is as important as the other phases and activities for developing a software project or system. Using the proposed SLR study, we were able to identify additionally four advisable practices in the literature for future research, discussed as follows: • It is identified that although distant SI methodologies have been identified in the literature using the proposed SLR study, still, the validation of the developed approaches for the SI is needed. Furthermore, a comparative study is required to compare their efficiency and effectiveness in actual software projects, such as how much time and resources they will require to effectively capture and identify the relevant stakeholders for the software development project.
• To precisely understand the stakeholders' relationship in an organization, we still need to research the different perceptions, such as what aspects stakeholders consider to be involved in and what must be a mandatory situation for SI.
• Additionally, we need to develop automated SI approaches to automatically identify relevant stakeholders for a specific in-house software domain or marketdriven software development. For example, we need to identify distant stakeholders for a market-driven software application, such as, Mobile applications whose stakeholders are distributed geographically in the world.
• We can adapt the existing state-of-the-art stakeholder identification tools that help improve stakeholder management, which enhances the quality of the software system by incorporating all stakeholder identification steps. For this purpose, researchers have developed some stakeholder management tools, such as Mindtoolshttps://www.mindtools.com/pages/article/newPPM_ 07.htm 2 and simply stakeholders. 3 Such stakeholder identification and management can be utilized in the future to enhance and automate the process. We identified four additional issues that need improvement in the SI process. SI is considered a pivotal activity in the software engineering literature for the access of software projects. Using the proposed literature study and the original SLR [19], we identified that these issues need to be highlighted for future improvements. In the field of requirement elicitation, the concept of SI is vitally Impactful. Moreover, it can enhance the quality of software products by identifying concerned stakeholders before starting a software project, and that's how we would be able to gather the desired requirements and avoid overlapping in requirements that can lead to successful project completion [126]. Furthermore, it will enable us to create a quality software requirement specification document, which would be free of incompleteness, inconsistency, and appropriateness.
A proper selection of stakeholders avoids requirement overlapping and can guarantee the organizational desires more rationally. Also, we would have an appropriate list of stakeholders and familiars, while the key stakeholder will not omit. The pros of proper SI are evident in several works of literature [43], [119].

V. DISCUSSION
This detailed literature study aims to capture and identify the importance of stakeholder identification for an effective and productive requirements elicitation activity. Requirements gathering and elicitation activity is the first phase of the software development life cycle [47], [134]. It is a prerequisite to the other software development phases (design, implementation, testing, and maintenance). In other cases, it can cause solid system failure if one can miss proper elicitation of requirements [142], [143]. Therefore, this literature study highlights the importance of suitable and correct stakeholder identification methods, best stakeholder interactions practices, and best stakeholder assessments and prioritization techniques to help requirements engineers and software developers efficiently and precisely understand the software requirements, business domain, and operating environment. Many research papers included in the proposed literature study support this claim. To develop a user-friendly and successful software application, one needs to capture and identify correct requirements that satisfy the need of end-users [135], for which we need to recover and identify correct and relevant stakeholder's [10], [33], [54], [62], [67]- [69], [110].
Furthermore, it is challenging for larger and market-based software applications to correctly and efficiently identify key stakeholders [5], [64]. For example, a rising trend towards the utilization of web-based software applications, such as web forums, recommendation systems and wikis to collect, elicit, model, validate and prioritize software requirements from a large number of potential stakeholders. On the other hand 24,730 direct distant stakeholders were identified who contributed 34,982 issues against 562 open-source software applications [151]. Such a large number of end-users needs to be prioritized to reach and identify key stakeholders who are frequently contributing requirements-related information in the social media platforms against the open-source software applications.. Also, agile software development adopted by large organizations, such as telecom and automotive, to develop software applications encounters the challenges of many stakeholders, different teams, multiple projects, and various features, making it challenging to coordinate between development teams and stakeholders involved [155]. Similarly, software vendors organization faces severe stakeholder identification challenges when dealing with collaborative software, such as Microsoft Dynamics CRM [148]. In contrast, they have more than thousands of customers who interact directly with the software, a few hundred potential partners, and many other indirect stakeholders affected directly or indirectly by the software application. It is still challenging and critical for such collaborative software to identify key stakeholders because of the large number of stakeholders involved and open interfaces [148]. Recently, a headline was made in US 2020, when an indirect end-user Robert Williams is wrongly identified by a facial recognition application and arrested as wanted criminal [153]. Therefore, it is pivotal to identify indirect stakeholders called outside of organization stakeholders that are not direct system users but are affected by the system in different ways [156]. The Crow-dRE paradigm and approaches can be utilized to reach outside organization stakeholders. Furthermore, domain-specific stakeholders can be identified from professional social media networks, such as LinkedIn, Xing, Conferences, or Twitter, using surveys, NLP toolkit, or machine and deep learning approaches.
Therefore, keeping in view the importance of the key stakeholder's identification for the requirements engineering and requirements elicitation in general, we conducted a systematic literature review, which aims to identify best practices and research approaches that focus on key stakeholder identification, stakeholder interaction and assessment. For this purpose, we identify seventeen pivotal stakeholder identification approaches and best practices used in the literature elaborated in their corresponding research papers. The best practices for stakeholder identification adopted from the literature are building a social network of stakeholders, classification and prioritization of stakeholders based on their influence on the software projects, conducting interviews and focus group activities with the stakeholders, stakeholders role, communications skills, interest and concerns, influences, and interpersonal skills. These are the most mentioned practices in the literature used for correctly identifying key stakeholders incorporated by the researchers in their proposed research methodologies. Also, we identify research papers and their corresponding research approaches in the proposed SLR study, which focus on stakeholder's assessment to improve and enhance the quality of gathered requirements by identifying correct and suitable stakeholders. For this, we recovered ten frequently used best practices for stakeholders assessments to efficiently and correctly identify stakeholders to gather quality requirements. Amongst the identified practices, Pair-wise comparison (AHP) and social network methodologies are recovered as the most frequently used approaches to assessing potential stakeholders to collect requirements efficiently.
Similarly, stakeholder interaction is graded as a pivotal part of stakeholder identification in the literature. For this, we identified and captured eight best practices and frequently used approaches for stakeholder interaction and communication to improve the quality of gathered requirements and improve the overall quality of the software application under development. Among the eight captured best practices, the win-win methodology, debate & discussion, and social network are the most frequently used approaches to achieve interaction between potential stakeholders successfully. We concluded that effective interaction between the stakeholders leads to satisfactory requirements elicitations, minimizes ambiguities between the stakeholders over requirements gathering, and overcomes conflicts, which is a mandatory activity in requirements engineering, particularly crowd requirements engineering where few hundred endusers are interacting with the software application directly or indirectly. It is recommended in the literature to have an effective interaction between the stakeholders; it is required that concerned stakeholders must possess better and more effective communication skills when performing requirement elicitation activities.
Therefore, it is pivotal first to identify and prioritize the identified stakeholders because not all the identified stakeholders are equally important to elicit requirements [136]. For this purpose, we can classify or divide the identified stakeholders into different stakeholder groups, such as criticalstakeholders, major-stakeholders, normal-stakeholders, and minor-stakeholders. One possible solution is to cluster many potential stakeholders for the mobile and web-based applications into smaller groups that can be easily managed and analyzed by introducing un-supervising clustering techniques, such as Genetic K-means, Kmeans, etc. [149]. Furthermore, it is mandatory to consider cultural and sociotechnical factors when identifying indirect system stakeholders for marketbased software applications, i.e., face recognition systems, etc., that are currently overlooked, which might have serious consequences [153]. For this purpose, we need to borrow methods and techniques from social sciences, such as soft system methodology that explore complex social human affairs with an extensive picture analysis. Similarly, to improve requirement prioritization and stakeholder identification for software product lines and market-based applications development, one can employ natural language processing and machine learning algorithms to automate the process and reduce the large number of direct and indirect stakeholders involved in requirements engineering activities [154]. Another challenge in the literature review study is that end-users identified for the requirements-related activities do not participate more often when they interact or collaborate to complete certain activities. For this purpose, the gamification approach can improve the overall quality of software applications by efficiently and accurately identifying stakeholders needs and requirements by improving communications, collaboration, participation, and commitment and minimizing conflicts between the stakeholders [147]. Additionally, it is mandatory to assess and evaluate the stakeholders identified for the requirements elicitation activities to ensure that best suited and relevant stakeholders have been shortlisted for the software application to achieve user satisfaction and improve software quality. Recently, researchers have proposed a goal-question-Metric approach to identify potential stakeholders by defining certain goals, generating certain questions for how to reach the goals, and then using some metrics to answer the questions [152]. Similarly, constructing an undirected graph network of stakeholders where nodes represent potential stakeholders and edges represents collaboration on the submitted requirements [151].
Furthermore, in the proposed research approach, we mainly emphasize the identification of potential stakeholders to develop the right software system, which satisfies the needs of the stakeholders. For this purpose, we identify an additional category of pivotal potential stakeholders that includes legislators, regulators, external consultants, project managers, sales representatives, executive chairperson, digital directors, and potential owners. Our research approach is to identify maximum potential stakeholders to cover a large pool of distant software users that might interact directly or indirectly with the software application. Also, there might be more categories and types of stakeholders depending on the nature of the software application. The approach should first identify maximum stakeholders, while some might be discarded later when prioritizing the potential stakeholders to remove the redundancy. Moreover, the researchers emphasize that correct stakeholder identification and its relevant role in the software are important for eliciting effective and corrective requirements [136]. It is necessary to select or shortlist stakeholders that can contribute their knowledge, which improves the quality of requirements [65], [67]. For this purpose, one can adopt both qualitative and quantitative approaches to recover the useful and pivotal stakeholder knowledge to improve the requirements elicitation activities [151], [152]. One such approach is to identify important and influential stakeholders by employing the analytic network process (ANP) [129] or the Analytic hierarchy process [130] and evaluate them against knowledge, role, influence, interpersonal skills, interest, and relationship [63].
Additionally, we critically analyzed different research papers on stakeholders' identification in the proposed literature study. We found that some researchers have proposed and suggested best practices for stakeholder identification. Utilizing these best practices can enhance the overall requirements gathering process to improve software quality. We categorized the identified research papers and their proposed best practices for stakeholder identification into three groups: identification and consultation of all relevant sources of requirements, identifying user classes and their characteristics, and identifying/consulting with the system's stakeholders. Such information is considered pivotal for successful and quality software applications. Furthermore, we were able to identify the consequences of incorrect stakeholder identification through the proposed SLR study. We debated in our proposed approach if requirements are gathered from wrong or irrelevant stakeholders that might lead to incorrect, ambiguous, and incomplete stakeholder requirements, thus affecting the software requirements specification document, which results in the project failure [144], [145]. For this purpose, we identify two main categories from the literature studies that gathering or eliciting requirements from incorrect or wrong stakeholders can lead to system failure and exceed the development project's cost and time. Finally, we argue that due to the emergence of social media platforms, such as user forums, app stores, Facebook, Twitter, etc., both direct and indirect stakeholders more frequently contribute requirements-related information about market-based and OSS applications in the form of end-user reviews [5], [131], [133], that are considered an important alternative source to the already existing in-house stakeholders. For this purpose, we proposed certain recommendations by adopting the CrowdRE approach by first knowing the purpose of identifying stakeholders, recovering and mining useful crowd requirements repositories, identifying similar stakeholders and clustering them using NLP toolkit and unsupervised learning algorithms, creating interaction between the stakeholders using undirected graph network, and finally prioritize the identified stakeholders into different groups based on their influence, stakeholders role, communications skills, interest and concerns, influences, and interpersonal skills.

VI. CONCLUSION AND FUTURE WORK
We conducted a detailed and comprehensive systematic literature review on SI methods in requirement elicitation. We used Babra Kitchenham guidelines for performing the proposed SLR [120]. Accurately and precisely identifying the relevant stakeholders, its management, and capturing its influence are risky for project success [56]. Accurately identifying stakeholders may lead the project to success, or missing SI can cause the project to fail. According to the original SLR [19], there was no method for SI in requirement elicitation. It was considered a self-evidence task that only users and developers are the only stakeholders. In contrast, it is considered an inheritance activity that varies from project to project.
We updated four main research questions from the previous SLR [19], which we answered in the proposed literature study. The dominant one is that is there any standard or baseline method for SI in RE?. While analyzing different research studies in the proposed SLR, we identified seventeen SI methods and, which are: a novel approach [54], a StakeRare method [10], a GOREP method [33], an intelligent agent-based approach [7], A soft system methodology [27], contextual and behavioral centric approach [20], stakeholder Evaluation/Analysis Process [62], stakeholder Matrix [63], stakeholder analysis influence method [64], research/Stakeholder Model [65], StakeQP [66], design Science Approach [55], systematic approach, Stakeholder selection framework [67], and StakeSoNet [68]. To answer the second research question of our proposed research study, we identified and captured ten effective practices for stakeholder interactions using the proposed SLR. We organized the proposed literature into three inherited and included categories in the proposed SLR. For research question 3, we thoroughly describe guidelines for stakeholders identification for crowd requirements engineering. Also, we additionally identified through the proposed SLR study two causes for the consequences of incorrect SI: project failure, loss of time, and cost. The incorrect identification of stakeholders might cause the software development company and end-users to eradicate the contract due to loss of time and cost [127]. Research question 4 is about the implication of incorrect stakeholder identification on requirements and software projects; we identified several issues or concerns: effectiveness (coverage of stakeholders) and efficiency (time to identify stakeholders) of stakeholders.
This SLR study targets mainly the requirement engineers as they work closely on requirement elicitation activities, such as identifying the main pivotal stakeholders to elicit requirements for the software system. Furthermore, the proposed study will also benefit the software/requirements engineers. Before starting a software project, they need to ensure that correct, relevant, and concerned stakeholders have been identified to ensure the successful completion and deployment of the software project. On the other side, the proposed study will be good for the research community and students researching in this area to find up-to-date research work on stakeholder identification. They can further improve and enhance the research finding on stakeholder identification by exploring the opportunities and gaps derived in this research study.
In the future, we are interested in conducting a detailed and comprehensive study on the seventeen identified research methods to identify and capture the best SI method by conducting experiments both in academia and industry. Furthermore, in the future, we aim to identify important and influential stakeholders by employing the analytic network process (ANP) [129] or the Analytic hierarchy process [130]   and evaluate them against knowledge, role, influence, interpersonal skills, interest, and relationship [63]. Another possible challenge that needs exploration in the future is to recover the conflicting viewpoints between different stakeholders on certain requirements. For this purpose, we can employ argumentation theory, which provides built-in semantics to identify conflict-free stakeholders and their requirements [131], [132]. Also, it is required to propose a research method for the SI that considers all the factors that could help requirements engineers correctly and efficiently identify concerned stakeholders, such as knowledge, role, influence, interpersonal skills, interest, and relationship.
Recently, with the pervasive use of social media and the emergence of big data applications due to the digital transformation of many industries and societies at large, it has become pivotal to consider alternative information sources for requirements elicitation, in addition to traditional stakeholders [133]. It opens a new research direction and challenge to identify major stakeholders in the social media platforms that frequently contributed requirements-related information in the social media platforms, such as app stores, Twitter, and user forums, together with the in-house stakeholders. For this purpose, we need some automated approach to automatically identify key stakeholders in the large pool of online stakeholders that frequently contributed requirements-related information, such as new features, issues, and non-functional requirements [5]. Another possible future direction is identifying potential stakeholders' mental and cognitive strength when identifying and prioritizing requirements engineering tasks [137]. Many essential and perilous requirements-related decisions are taken during the requirements engineering phase. Therefore identifying stakeholders with weak cognitive skills might affect the requirements decision-making.   Table 18 shows the list of research papers that have been selected for the preliminary SLR study. Using the proposed research study, we were able to identify 54 research papers that are relevant to stakeholder identification. The column ''paper title'' represents the main title of the research paper, while the column ''reference no'' means the corresponding reference number in the proposed research paper.

APPENDIX-II
In Table 19 is the list of research papers that have been selected as a secondary source for the proposed SLR study. The identified research papers are closely relevant to the stakeholder identification, but they were already cited and discussed in the previous SLR [19]. We still consider them as an essential source for the research community and software engineers. Furthermore, we compare our research findings with these papers and update the research questions. The column ''paper title'' represents the main title of the research paper, while the column ''reference no'' means the corresponding reference number in the proposed research paper.