TY - JOUR
AU - Nasir, Mohd Hairul Nizam
AB - 1. Introduction Information Technology Outsourcing (ITO) is the subcontracting of particular services or the use of external resources to undertake IT functions [1]. The volume of ITO is steadily growing. The IT services outsourcing business was of worth $520.74 billion in 2019 and is expected to grow to $937.67 billion by 2027 [2]. Software Development Outsourcing (SDO) is a sort of ITO in which a customer contracts out some or all the software development operations to the vendor (s) [3–6]. For both advanced and developing countries, SDO generates a win-win state [7]. Software development projects are being outsourced to India, Russia, and China by European companies [8]. SDO options include onshoring or domestic outsourcing, nearshoring, offshoring, Distributed Software Development (DSD), and Global Software Development (GSD). SDO offers benefits such as reduced cost, better capabilities, access to cutting-edge technologies, shorter completion times, process enhancement, novelty, risk mitigation, optimum use of internal resources, and institutional deficiencies such as inept management, inexpert staff, and resource scarcity [9–11]. However, a significant portion of SDO initiatives fails to deliver the expected advantages [8, 12–14]. Failures causes are frequently pin down to the Requirements Engineering (RE) process for SDO [8, 15–17]. This is not unexpected, given that RE is the most important stage of the software development life cycle and has a considerable impact on the other software development activities [18, 19]. This is due to the fact that flaws left untreated during the RE phase frequently cascade into subsequent phases. As per findings of a study, insufficient requirements specification causes planning and control challenges [17]. According to previous research, fixing a RE problem later in the software development life cycle can cost up to 100 times more than fixing a coding error [20]. The requirements elicitation, analysis, and negotiating stage, as well as the description, modelling, validation, and management phases, are all challenging and complicated [21–23]. Because the players in the SDO are geographically dispersed, the RE process issues are multiplied [15, 21, 24]. The geographical diffusion of stakeholders has an impact on the RE process’s numerous activities, causing communication, knowledge management, cultural, and coordination issues. Consequently, to attain the projected advantages of the SDO, the issues of the RE process for SDO must be tackled. To tackle the issues, the pertinent RE practices must be discovered for enriching the SDO RE process as a well-specified RE process is vital to the fruitful outsourced software development projects with regard to price, timing, and quality [18]. Considering this, the purpose of this research work is to respond to the following Research Questions (RQs). RQ1: Which are the RE practices, grounded on existing literature, for dealing with the issues of the RE process in the context of SDO? Sommerville and Sawyer have provided an adequate number of RE practices to overcome the problems with the traditional RE approach [22]. To determine empirically which of these RE practices are crucial to tackle the RE process issues for SDO, the second RQ is: RQ2: Which of Sommerville and Sawyer’s proposed RE practices are important for addressing issues with the RE process for SDO? For a thorough and successful research, it is necessary to include the viewpoint of the industry. Hence, the third RQ is: RQ3: Which RE practices do SDO professionals use to address the issues with the RE process for SDO? To know the importance of RE practices for addressing SDO RE process issues, the practices need to be ranked. Therefore, fourth RQ is: RQ4: Which are ranks of the RE practices with respect to importance of the practices for addressing issues of SDO RE process? The remainder of the article is structured as follows: Section 2 covers relevant work, Section 3 describes research methodology, Section 4 presents results and discussion, Section 5 provides ranking of RE practices and Section 6 wraps up the research work. 2. Related work The RE process, for scenarios in which stakeholders are scattered across multiple sites, has been studied from many perspectives in the current literature. One of the perspectives focuses on the issues that arise throughout the RE process. The geographical dispersal of stakeholders has a substantial influence on RE [25]. In such cases, the teams have to confront obstacles during requirement elicitation and negotiation. In the case of GSD, certain issues have an impact on the efficacy of requirements elicitation techniques: i) inadequate scope management, ii) poor comprehension of requirements, and iii) requirements’ volatility. An RE elicitation strategy, in the GSD context, has been developed for addressing such issues [26]. The implications of inadequate RE on outsourced software projects have been explored from the developers’ viewpoint [7]. To achieve this objective, a questionnaire survey was done with 57 developers who have dealt with SDO and have worked for 8 small and medium software companies. Developers must cope with too many requirements’ modifications, reduced designs, extended development stages, and an unanticipated number of deliverables, according to data analysis. In [27], some findings concerning the distributed RE process in the context of GSD have been derived. The dispersed environment has certain distinct characteristics, such as distance between stakeholders, time zone variations, and cultural diversity, all of which have an impact on the RE process. The impact of these issues on the distributed RE process is briefly described in this paper, and it is suggested that a distinct RE process must be developed to accommodate the dispersed environment. Inadequate communication, time zone disparities, diverse cultures, and poor knowledge management all hinder the elicitation of requirements in the context of GSD [28]. A framework named RE-GSD (Requirement Elicitation for Global Software Development) has been suggested to overcome such issues. An industrial perspective report [29] highlights the issues that impact the management of changing requirements in the outsourcing scenario. Finally, the study presents a conceptual framework for RE Systems. Another article about GSD [30] focuses on Requirements Change Management (RCM) and provides a framework to overcome RCM challenges, primarily communication challenges. One more experimental study [16] analyses and tackles requirements management concerns in the case of globally distributed software development projects. The focal point of another research is Requirements Understanding in GSD [31]. Authors aim to discover: i) Various elements which generate problems for Requirements Understanding in the GSD scenario, and ii) Resolutions to cope with those problems. Finding demonstrates that the usage of the NetMeeting web-based technology, which was used to enable requirements communication between two remote sites, improves the dispersed RE process [32]. Multinational initiatives with a huge number of collaborators, user, and developer groups; are differentiated by a wide range of backgrounds and abilities [33]. Data collection and validation during the RE in this diversified context need efficient processing strategies to deal with large amounts of data and for controlling inconsistencies during online data gathering. PBURC (Pattern-Based Unsupervised Requirements Clustering) is a framework that has been developed for this purpose. Another research [34] proposed the usage of MAS (Multi Agent System) architecture to reduce the challenges that occur throughout the distributed RE process, particularly within verification and validation tasks. Exploratory research was done to better understand the complexity inherent during the RE process in the context of GSD projects by examining the case of 24 virtual teams that participated in five-week activities of identifying requirements [18]. When partners are geographically spread, a paradigm called the V model has been developed for generating and choosing requirements for a software release [35]. In another study [36], knowledge transfer and reuse in the global RE perspective are also examined. Distance between partners and cultural differences have an impact on knowledge exchange. Improper reuse in RE is a result of mistrust and protectionism. The findings of an exploratory investigation on the role and relevance of the human moderator during dispersed RE, have also been presented [37]. The 43 most common RE process issues in the SDO scenario have been identified, classified, and prioritized based on their frequency of recurrence [38]. The 25 elements that can influence the offshore SDO RE process have also been discovered and verified [39]. With efficiency and cost reduction in mind, Ahmed and Abdulrahman have investigated the impact of localized decisions, about requirements, on software customization in the DSD scenario [40]. The RCM process for dispersed agile software development has been streamlined using a methodology and a tool [41]. Another study [42] presents 15 issues for quality requirements the in the case of huge DSD agile projects, as well as 13 processes and 9 strategies for dealing with the challenges. In the context of GSD, a well-ordered domain ontology has been recommended to aid the RCM process [43]. For the GSD scenario, the 30 RCM problems have been explored and classified [44]. The 23 elements that lead to an effective RCM for GSD, have been uncovered [45]. In another research work [46], a three-stage technique has been presented to aid the RCM process in the GSD scenario. The elements that facilitate the implementation of appropriate requirements in the GSD scenario, have been discovered and examined [47]. Two frameworks have been suggested and validated to study the significance of project management exclusively for RE and then RCM procedures in the context of GSD [48]. The 218 risks linked with the RE process in GSD scenario, as well as 146 measures to mitigate those risks, have been outlined [49]. A paradigm has been proposed to investigate the impact of geographical, intercultural, and spatial disparities on communication during RCM process in the GSD scenario [50]. Thirteen strategies have been discovered to support efficient communication for requirements elicitation in the context of GSD projects [51]. In GSD scenario, RCM obstacles have been discovered, confirmed, and quantified [52]. A methodology has been designed to evaluate GSD companies’ preparedness for the RCM process in GSD scenario [53]. A two-phase approach for prioritising requirements in the GSD environment, has been presented depending on three criteria: weight, vote, and priority of partners [54]. A model has been created and tested to investigate the impact of fluctuating requirements on the sustainability of GSD initiatives [55]. Based on company scale and location, the success elements that are necessary for successful communication across the requirements elicitation in the GSD scenario have been examined [56]. A mechanism for specifying and validating requirements has been established by generating a requirements graph, particularly in GSD scenario [57]. A block-chain dependent approach has been presented to deal with the requirements discrepancies in GSD context [58]. With regard to business function, scale, and experts’ ability, the 20 obstacles in the context of GSD RE scenario have been identified and confirmed [59]. The 15 problems for RCM in the offshore SDO scenario have been discovered [60]. The 14 problems for reusing requirements in the case of huge agile DSD projects, as well as 10 approaches to solve those problems have been recommended [61]. Focusing on 32 communication problems and 28 RE practices, a paradigm has been presented to tackle communication-related problems for the RE process in GSD scenario [62]. Thus, an examination of recent research reveals the fact that studies just partly resolve the SDO RE issues or partly present the RE practices to tackle SDO RE issues. To our knowledge, no research has ever presented a complete list of RE practices for dealing with the SDO RE process issues. As a result, the focus of this study is to establish an exhaustive list of RE practices to tackle the most prevalent SDO RE process issues that lead to SDO failures. 3. Research methodology The committee for candidature defence has authorized this research work, which is part of my PhD study. This research’s only human-associated subject matter is questionnaire surveys. The verbal agreement of prospective respondents or their corresponding organizations was requested prior to performing the surveys. In this study, no private data has been disclosed or examined in any way. The replies have been stated in a collective way. Individuals’ and organizations’ anonymousness and secrecy have been absolutely secured in this way. To achieve research objectives, employed research methods are: Systematic Literature Review (SLR), questionnaire survey, 50% rule and focus group session. Fig 1 depicts research methodology. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. Steps for identifying RE practices to tackle SDO RE process issues. https://doi.org/10.1371/journal.pone.0269607.g001 Thus, three steps have been performed to meet this research works’ objectives. The sections 3.1, 3.2, 3.3 and 3.4 present introduction to employed methods. 3.1. Systematic literature review The objective of a SLR is to find, examine, and synthesize all available research on a particular research question, subject, or area of focus [63]. Barbara Kitchenham’s technique [64] has been used to conduct the SLR in this study like the previous studies [65, 66]. 3.2. Questionnaire surveys Both questionnaire surveys used in this study have been done utilising a semi-supervised technique, in which the survey’s purpose, questionnaire structure, and numerous questions about the questionnaire are made explicit to respondents prior to survey [67]. Semi-supervised techniques have been employed in this study, either via head-on encounters with participants or via use of the Computer-Assisted Telephone Interviewing (CATI) methodology [68]. During the first survey, some questionnaires were provided and filled out at face-to-face meetings, while others were sent through emails. The Drop-Off/Pick-Up approach [69] was used for the second questionnaire survey. 3.3. The 50% rule The 50 percent rule states that a viewpoint is considered if at least 50 percent of those polled agree with it. The analogous guideline has been applied in other investigations as well [70–72]. 3.4. Focus group session Focus groups are used to collect information about a certain topic chosen by the investigator. Focus groups are meticulously designed debates that allow participants to obtain personal insight into a certain study topic [73]. Focus groups have been used in numerous investigations [74, 75]. 3.5. First questionnaire survey The survey research approach has been used to gather information on significant RE practices for SDO. The first questionnaire survey of the research work is based on Sommerville and Sawyer’s 49 RE practices [22] for six major areas of the RE process: elicitation of requirements, evaluating and negotiating requirements, requirements description, modelling requirements, validating requirements, and maintaining requirements. The survey research approach is seen to be a good way to collect both qualitative and quantitative data [76]. Like Wohlin and Aurum [77], this survey was designed and conducted using the guidelines described in research [78]. A cross-sectional investigation was conducted for this survey. SDO practitioners received 130 surveys in total. Seventy (70) questionnaires were delivered and filled out at face-to-face meetings, while Sixty (60) questions were distributed and filled out over emails. The survey was carried out using either a semi-supervised approach [67], in which respondents were directed during face-to-face sessions, or the CATI technique [79]. In research, the CATI approach is commonly used [80–82]. The term "significant" refers to something that is "important enough to make an impact" [83, 84], therefore, significant RE practices means the RE practices which effect RE process. 3.6. Second questionnaire survey The survey was designed and conducted using the guidelines described in research [78]. A cross-sectional investigation was conducted for this survey. The Drop-off/Pick-up approach was used to distribute 200 questionnaires. Various studies employed Drop-off/Pick-up approach [85, 86]. The survey was carried out using a semi-supervised method [67]. The survey’s goals, professionals’ assumptions, questionnaire style, and respondents’ questions were all clarified using the CATI approach [79]. 3.1. Systematic literature review The objective of a SLR is to find, examine, and synthesize all available research on a particular research question, subject, or area of focus [63]. Barbara Kitchenham’s technique [64] has been used to conduct the SLR in this study like the previous studies [65, 66]. 3.2. Questionnaire surveys Both questionnaire surveys used in this study have been done utilising a semi-supervised technique, in which the survey’s purpose, questionnaire structure, and numerous questions about the questionnaire are made explicit to respondents prior to survey [67]. Semi-supervised techniques have been employed in this study, either via head-on encounters with participants or via use of the Computer-Assisted Telephone Interviewing (CATI) methodology [68]. During the first survey, some questionnaires were provided and filled out at face-to-face meetings, while others were sent through emails. The Drop-Off/Pick-Up approach [69] was used for the second questionnaire survey. 3.3. The 50% rule The 50 percent rule states that a viewpoint is considered if at least 50 percent of those polled agree with it. The analogous guideline has been applied in other investigations as well [70–72]. 3.4. Focus group session Focus groups are used to collect information about a certain topic chosen by the investigator. Focus groups are meticulously designed debates that allow participants to obtain personal insight into a certain study topic [73]. Focus groups have been used in numerous investigations [74, 75]. 3.5. First questionnaire survey The survey research approach has been used to gather information on significant RE practices for SDO. The first questionnaire survey of the research work is based on Sommerville and Sawyer’s 49 RE practices [22] for six major areas of the RE process: elicitation of requirements, evaluating and negotiating requirements, requirements description, modelling requirements, validating requirements, and maintaining requirements. The survey research approach is seen to be a good way to collect both qualitative and quantitative data [76]. Like Wohlin and Aurum [77], this survey was designed and conducted using the guidelines described in research [78]. A cross-sectional investigation was conducted for this survey. SDO practitioners received 130 surveys in total. Seventy (70) questionnaires were delivered and filled out at face-to-face meetings, while Sixty (60) questions were distributed and filled out over emails. The survey was carried out using either a semi-supervised approach [67], in which respondents were directed during face-to-face sessions, or the CATI technique [79]. In research, the CATI approach is commonly used [80–82]. The term "significant" refers to something that is "important enough to make an impact" [83, 84], therefore, significant RE practices means the RE practices which effect RE process. 3.6. Second questionnaire survey The survey was designed and conducted using the guidelines described in research [78]. A cross-sectional investigation was conducted for this survey. The Drop-off/Pick-up approach was used to distribute 200 questionnaires. Various studies employed Drop-off/Pick-up approach [85, 86]. The survey was carried out using a semi-supervised method [67]. The survey’s goals, professionals’ assumptions, questionnaire style, and respondents’ questions were all clarified using the CATI approach [79]. 4. Results and discussion This section summarises the findings of the research analyses by focusing on the three phases outlined in the section of research methodology. The procedure is depicted in Fig 2. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. Data sources for detecting exhaustive list of RE practices. https://doi.org/10.1371/journal.pone.0269607.g002 4.1. Step 1: Identifying RE practices, grounded on existing literature, to tackle the issues of RE process for SDO SLR has been performed in the initial phase of this study. 4.1.1. Systematic literature review. The targeted sources to find relevant studies are IEEE Xplore, ACM, Science Direct, Springer Link & Web of Science. Fig 3 depicts the SLR process. To eliminate bias, two other investigators have been engaged throughout the process, and each phase has been concluded after reaching an agreement. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Studies selection procedure. https://doi.org/10.1371/journal.pone.0269607.g003 After a rigorous review and screening procedure, 117 studies were chosen for extracting data. 4.1.2. The RE practices to tackle SDO RE process issues. The 90 RE practices have been discovered, after a thorough examination of 117 studies, that can be applied to tackle the RE process issues in SDO scenario. The 90 RE practices denoted by the initials REPR1, REPR2, REPR3,…, REPR90 are as follows: REPR1 = Putting in place the necessary infrastructure to support communication and guaranteeing that it is operational [87]; REPR2 = Promoting synchronous communication using chat rooms, phone conversations, and videoconferencing [87]; REPR3 = Adjusting to and comprehending various stakeholders’ cultures [87], means being familiar with a culture’s customs, values, ethos, and local language [5]; REPR4 = Choosing and utilizing a standardized communication language [88]; REPR5 = Concentrating on communication language improvement, such as English language classes [87, 89, 90]; REPR6 = Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]; REPR7 = Creating a ’proximity training center’ in a time zone that is the same or somewhat different from the client’s zone [93]; REPR8 = Attempting to identify natural overlaps in work time [94]; REPR9 = Evaluating a person’s capacity to work ’around the clock’ [94]; REPR10 = Time-shifting (adjusting one’s working time to coincide with the work time of others) to attain time zone closeness, a variety of approaches for this purpose, are: Flextime (functioning on a flexible schedule to allow for overlapping). Overtime (functioning for additional time for overlapping). Telework (functioning for elastic schedules from home for overlapping). Long working days (allowing for work time overlapping at the beginning or finish of the day). Unrestricted working hours (employees decide their own operating time for overlapping and there are no standard work hours) [95]; REPR11 = Providing electronic message "drop in", remote phoning, and artefact distribution capabilities to distant practitioners’ rooms [96]; REPR12 = Enabling professional integration from the outset of the project, such as by holding face-to-face kick-off meetings to create personal interactions [21, 97]; REPR13 = Organizing regular visits to isolated locations in order to foster trust [18, 98, 99]; REPR14 = Encouraging direct contact amongst stakeholders [100]; REPR15 = Assuring that stakeholders are introduced to each other from the start of the project [101]; REPR16 = Facilitating interaction in the client’s original tongue [5]; REPR17 = Advising on the usage of groupware tools [99]; REPR18 = Attempting to convince stakeholders that disclosing concerns or sharing information would have beneficial repercussions rather than adverse effects [94]; REPR19 = Organizing video or teleconferences on day-to-day, weekly, semi-monthly, or monthly basis such that no or a few awkward hours exist for all the partners [98]; REPR20 = Organizing requirements engineering sessions by: Using a human moderator and a rich communication medium that allows data, audios, and videos to be integrated. Making and sticking to an agenda. Identifying appropriate participants and notifying them on time to participate in requirements engineering sessions. Exchanging of reference materials in a timely manner to allow participants ample time to view the essential content. Giving attendees of requirements sessions access to resources (like emails, relevant papers, work artefacts, and so on) containing information on the requirements [21]; REPR21 = Setting up assertive governance at the project manager and team leader levels [102]; REPR22 = Keeping track of the directives in a certain order [102]; REPR23 = Personal and group obligations must be clearly stated and agreed upon [102]; REPR24 = Getting obviously defined and grasped requirements engineering processes [102]; REPR25 = Utilizing email as a communication verification tool because it preserves a written copy of contact [21, 89, 96]; REPR26 = Getting agreements in writing and adequately documented [103]; REPR27 = Creating an organizational structure with clear communication roles [91]; REPR28 = At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]; REPR29 = Partly orchestrating inter-organizational procedures [91]; REPR30 = Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]; REPR31 = Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR32 = Making use of an awareness support system to manage requirements, all partners ought to be able to obtain the following details: Specifications, justifications, and priorities of various requirements. Requirements dependencies, as well as design, code, and testing dependencies. Duties of every member of the team in relation to specific requirement(s) and contact particulars like email address and phone number. The people who took initiatives for the requirements. Issues relating to requirements, issues’ activators, state of issues’ resolution, and judgments made because of issues. Dates, times, and venues of the meetings, as well as the present stakeholders, debated issues and judgments done. Demands for change, change demand activators, state of every change demand, personnel engaged in making judgments, and judgments made [104]; REPR33 = Retaining senior professionals on the team and persuading those professionals to bridge the knowledge gap [105]; REPR34 = Putting in place a centralized communication system [105]; REPR35 = After each meeting, making a report of the proceedings. Any member of the team or moderator ought to outline which issues were presented at the meeting, what decisions were taken about every issue, still open issues, who is responsible for gathering more data, and whose guidance should be solicited in the event of each issue [106]; REPR36 = To use a Requirements Management System (to regulate and follow changes) that has the succeeding characteristics: Searching a list of requirements, extracting individual requirements, and organizing requirements according to certain criteria. Administration of the requirements modification process, assistance for requirements traceability, and development of various forms of requirements reporting. Acceptance of external documents via an interface. Managing several versions of requirements. Aid for carrying out various forms of analyses (e.g., impact analysis, knowing whether a requirement is orphan, status tracking). Limiting access and editing privileges to the list of requirements [29]; REPR37 = Notifying the pertinent partner regarding the change in requirements by: Communication technologies such as telephone, emails, and the internet. Using the system to send out automated notifications [107]; REPR38 = In the event that there are a large number of partners: Designating a person (communication channel) out of each organizational unit or group of requirements sources to collect requirements from that unit or group. The requirements are then transferred to an expert via communication channels, where they might be combined [108]. Obtaining unanimity on requirements employing group elicitation approaches like Brainstorming, JAD, Focus groups, and requirements Workshops [25]. Generating a consolidated requirements document that includes all of the requirements [108]; REPR39 = Adopting the following steps to address cultural challenges: (REPR6) Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]. Advising members of the team to tour other partners’ sites [109]. Organizing cultural training sessions [109]. Offering cross-cultural orientation sessions [109]. Considering stakeholders’ cultural beliefs when determining female responsibilities [109]. Introducing a ’Negotiated Culture,’ a negotiated culture created to respect all partners’ cultural standards [103]. Identifying persons with expertise and familiarity with the customer’s culture to support for requirements discussion and definition [89]. (REPR4) Choosing and utilizing a standardized communication language [88]. (REPR5) Concentrating on communication language improvement, such as English language classes [87, 89, 90]. The project manager or/and experienced team members planning and supervision of all the efforts that are carried out to cope with cultural differences [109]; REPR40 = Presenting the Equality Model (EM) for all partners, in which all partners are treated equally and can discuss each other’s preferences, religion, and social traditions. They can also exchange knowledge and make recommendations based on others’ perspectives and roles [110]; REPR41 = Defining the procedures, techniques, and policies that must be followed [111]; REPR42 = Knowledge exchange [111]; REPR43 = Observance of common hopes [111]; REPR44 = Possessing technological, managerial, and personnel capabilities for satisfying quality standards & meeting deadlines [5]; REPR45 = To inspire non-fluent or less confident partners to participate in the discourse, begin with an informal dialogue [112]; REPR46 = Making use of translation facilities: Utilizing human interpreter [112, 113]. Utilizing real-time machine conversion facilities [113]; REPR47 = Utilizing scales to calculate the mean time it takes for hopes to be met. For example, providing a feature that determines the average time it takes a person or team to react to an email. If the mean time to respond is three days, the sender may anticipate receiving a response within three days [114]; REPR48 = Developing and utilizing a vocabulary and notations for requirements description [88]; REPR49 = Vendor managers can take the following steps to establish collaboration: Establishing team members’ roles and tasks, as well as constructing Organizational Charts that show their roles and obligations [115]. Obtaining and administering the appropriate human resources using Resource Calendar [115]. Appropriate task distribution [115]. (REPR28) At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]. (REPR29) Partly orchestrating inter-organizational procedures [91]. (REPR30) Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]. (REPR31) Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR50 = Achieving partners’ agreement on meeting attendance terms and conditions, as well as fulfilling timelines and obligations [116]; REPR51 = Identifying each team member’s function and suggesting who might interact with whom [16, 117]; REPR52 = In terms of decisions, keep in constant contact with customers by organizing: Meetings in person. Video conferencing [16]; REPR53 = Selecting a teammate that works beyond the typical business hours and responds to questions [118]; REPR54 = Educating on in what manner to: Make use of the available tools. Interact efficiently in a situation where partners are scattered at remote sites [18]; REPR55 = Giving prospective team members training about how to use relevant procedures, as well as associated tools and technology [119]; REPR56 = Performing six general steps for RE, in absence of any standard RE process [20, 120], which are: i) Requirements Elicitation, ii) Requirements Analysis & Negotiations, iii) Specifying Requirements, iv) System Modeling, v) Requirements Validation, and vi) Requirements Management [13, 22, 121]; REPR57 = Adopting procedures that have been discussed and agreed upon [97]; REPR58 = Utilizing tools which can connect with one another [107]; REPR59 = Utilizing the ISO/IEC TR 24766:2009 framework and related data, for evaluating the functionalities of RE tools [122, 123]; REPR60 = Nominating a practitioner as requirements engineer or system analyst who possesses: Domain knowledge or is ready to understand domain and sophisticated elicitation procedures [124]. Capabilities for working in the global context, with remote teams and people from other cultures [124]. Ability to settle problems and operate in unclear and uncertain conditions [124]. Case tools, system modelling, computer languages, requirements management systems, and human-computer interface knowledge [125]. Traits for interaction, socializing, conflict resolution, teamwork as well as individual work, creativity, and adaptability to change [126]; REPR61 = Selecting an appropriate requirements elicitation approach by applying a right procedure [127]; REPR62 = Establishing and adhering to a standardized document format [22]; REPR63 = For structuring the requirements description document, employing IEEE Standard 830–1998 [88]; REPR64 = Developing bare minimum standards to document requirements [88]; REPR65 = By negotiating, positioning the customer and vendor’s goals [119]; REPR66 = Developing a plan for RE and allocating 15 to 30 percent of overall project efforts to RE [128, 129]; REPR67 = Creating metrics for gauging performance [116]; REPR68 = Creating methods to track and report progress [116]; REPR69 = Raising the frequency of RE deliverables to improve progress monitoring and transparency [116]; REPR70 = Locating and gaining access to critical users [119, 130]; REPR71 = Inquiring from known or recognized partners about additional partners, creating partners’ social networks, and then ranking partners based on social network measurements [131]; REPR72 = Forming a Change Control Board (CCB) [102] and incorporating new requirements through an appropriate requirement change management procedure (change assessment and dissemination mechanism) [132–135]; REPR73 = Including actual system operators during RE process [136]; REPR74 = Standardizing requirements description template, by following guidelines of the IEEE Standard 830–1998 [88]; REPR75 = Meeting the criteria described in IEEE Standard 830–1998 in terms of quality [88]; REPR76 = Utilizing Wikis, physically dispersed partners are involved in the exploration of their wants, discussion of relevant issues, requests for additional characteristics, and formation of requirements [137]; REPR77 = Employing asynchronous communication, such as email, so that partners with lower capability have opportunity to grasp and respond to delivered messages [96, 98]. Features such as spell-checking and grammatical correction, as well as language interpretation, should really be incorporated with the email service [90]; REPR78 = Leveraging requirements visualization tools (such as use case and business process diagrams) and social visualization approaches to encourage partners’ participation and improve awareness about requirements [138]; REPR79 = Using Felder-Silverman’s Learning Style Model to choose appropriate groupware tools and strategies to elicit requirements while considering cognitive traits of partners [139]; REPR80 = Utilizing the same collection of tools [97]; REPR81 = Conducting workshops to elicit requirements [140]; REPR82 = Replacing conventional head-on workshops with a peer-to-peer workshop technology [141] which should offer services such as: Direct messaging. Document exchange, inspection, and modification. Negotiations over audio link up. Autonomy (by employing access privileges, a peer sends data to others while simultaneously imposing limits, such as not providing data to specific peers) provision. Intermittency (removal of a peer as a result of network disconnect, which can be purposeful or unintentional) detection [141]; REPR83 = Taking into account Hofstede’s cultural dimensions, for assisting managers in identifying individual and group conduct [109], which are: The distance between the power sources. Collectivism as opposed to individualism. Masculinity as opposed to Femininity. Avoiding uncertainty. Short-term opposed to Long-term adjustment [92, 142]; REPR84 = Encouraging informal contact amongst partners who are dispersed [143]; REPR85 = Making it easier for partners to communicate with one another on a regular basis [144]; REPR86 = Applying a proper requirements traceability method throughout the stages of requirements, design, and implementation [145]; REPR87 = Identifying co-change tendencies to forecast future requirements changes and developing a corresponding policy [146, 147]; REPR88 = Utilizing altered 100 $ method for requirements prioritization [148]; REPR89 = Considering that the client communication and requirements phase accounts for 10 to 25 percent of the overall project effort [149]; REPR90 = Forming the groups in a manner that work overlaps so that employees are aware of the other individuals’ duties [150]. The RQ1 is answered in this way. 4.2. Step 2: Sommerville and Sawyer’s significant RE practices to tackle issues of SDO RE process There is a need to study which of Sommerville & Sawyer’s suggested practices are critical for addressing the RE process issues in the context of SD. 4.2.1. Identification of the significant RE practices for SDO through questionnaire survey. The S1 Appendix presents the questionnaire employed for the survey. (a) Questionnaire format: The closed format questions ask you to rank the advantages of RE techniques for SDO on a scale of one to four. The open-ended questions are designed to find out whether respondents are using any additional RE practices except the ones listed. The questionnaire is split into two sections. The first section’s goal is to gather information on the respondents’ work experience, job kind, and businesses. The second section is for data collection about key RE practices based on their assessed advantages for SDO. Two rounds of pilot study were undertaken to enhance the questionnaire layout. The following are the various types of purported benefits of RE practices [8, 70]: High Perceived Benefits (Hi): If a RE practice is mandated and always utilized, it has a "high perceived benefit". Medium Perceived Benefits (Mi): If a RE practice is not obligatory but is commonly or often utilized, it has “medium perceived advantages”. Low Perceived Benefits (Li): If a RE practice is only employed for a few projects, it has "low perceived benefits". Zero Perceived Benefits (Zi): If a RE practice is never or just seldom employed, it has "zero perceived benefits". (b) Sampling and population: For acquiring a valid sample of respondents, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the participants. These professionals are classified as ’developers, ’managers,’ and ’senior managers,’ [71]. (c) Response rate: As interested professionals have been in constant communication, 45 out of 60 answers have been received by email. The 108(T) replies were chosen for data analysis, from a total of 115 (70+45) responses, grounded on the participant’s company profile, job description, and appropriate experience. Table 1 displays the results of the first questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. Particulars of the 1st questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t001 (d) Criteria for choosing significant RE practices: If at least 50% of respondents believe that a RE practice’s perceived advantages fall into the ’high perceived benefits’ and ’medium perceived benefits’ categories, then that RE practice is considered ’significant’ for resolving RE process issues for outsourced software development projects. An approach comparable to this, has been used successfully in previous investigations [70–72]. 4.2.2. Survey outcomes and selecting the significant RE practices. To determine the significant RE practices, out of the four classes of the RE practices’ perceived benefits, only the RE practices belonging to ’high perceived benefits’ and ’medium perceived benefits’ classes have been regarded based on the definitions of perceived benefits’ classes [8]. The Prominence Level (PL) for every RE practice indicates the percentage of replies in the ’high perceived benefits’ and ’medium perceived benefits’ classes, and is computed as specified in Eq 1: (1) The survey’s findings are reported in S2 Appendix. The findings reveal that the bulk of the RE practices advised by Sommerville and Sawyer are significant for SDO with 43 out of 49 practices (87.76%) meeting the essential criterion. Fig 4 depicts the percentages of practices and significant practices in relation to major RE process steps. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Percentages of the RE practices and significant RE Practices w.r.t phases of RE process. https://doi.org/10.1371/journal.pone.0269607.g004 4.2.3. Significant RE practices to tackle issues of RE process for SDO. Sommerville and Sawyer’s 43 RE practices are significant for addressing the RE process issues for SDO. The 43 RE practices denoted by REPR91, REPR92, REPR93, …, REPR133 are: REPR91 = Evaluate the system’s effectiveness; REPR92 = Recognizing system stakeholders and taking into account their requirements; REPR93 = Sources of information must be recorded; REPR94 = Determining the system’s operational environment; REPR95 = Leveraging business needs to derive the requirements’ elicitation; REPR96 = Search for the specific constraints of domain; REPR97 = Document the justification for the requirements; REPR98 = Use prototyping to understand the uncertain requirements; REPR99 = Use scenarios to elicit requirements; REPR100 = Outline operating procedures; REPR101 = Utilize requirements from comparable systems that have already been created; REPR102 = Outline boundaries in case of each system; REPR103 = When assessing requirements, consider checklists; REPR104 = To help negotiating, employ communication channels; REPR105 = Prepare a strategy for identifying and resolving disputes; REPR106 = Consultation with partners to prioritize requirements; REPR107 = Categorize requirements by employing a multi-dimensional methodology; REPR108 = Evaluate the risks associated with the requirements; REPR109 = Develop and apply templates’ standard to describe requirements; REPR110 = To express requirements adopt basic, uniform, and brief language; REPR111 = Employ diagrams as needed; REPR112 = Other representations for the requirements should also be incorporated to support the natural language specification; REPR113 = Describe requirements numerically wherever possible; REPR114 = Create a model of the system’s surroundings; REPR115 = Sketch the architecture of the proposed system; REPR116 = When modelling a system, utilize structured methodologies; REPR117 = Prepare and utilize a data dictionary; PR118 = Define the linkage between needs of the various partners and system models; REPR119 = Evaluate requirements documentation to check that it adheres to your stated criteria or not; REPR120 = Arranging the requirements evaluations; REPR121 = Evaluating requirements by involving interdisciplinary teams; REPR122 = Creating checklists to validate the requirements; REPR123 = Animating the partners’ needs by utilizing prototypes; REPR124 = Creating a draft version of the user manual; REPR125 = System models’ rephrasing by utilizing native language; REPR126 = Uniquely distinguishing every requirement of the partners; REPR127 = Creating guidelines to help you manage requirements; REPR128 = Establishing policies to trace various partners’ needs; REPR129 = Keeping the traceability guide up to date; REPR130 = Managing partners’ needs by employing database; REPR131 = Creating guidelines to deal with changing needs; REPR132 = Defining the system’s global needs; REPR133 = Determining the needs that are prone to change. The RQ2 is answered in this way. 4.3. Step 3: Identification of the additional RE practices to tackle issues of SDO RE process Another questionnaire survey was employed for identification of the additional RE practices which are adopted by SDO professionals for addressing RE issues. 4.3.1. Questionnaire survey for finding additional SDO RE practices. The S3 Appendix presents the questionnaire employed for the survey. Questionnaire format: The questionnaire is split into two segments. The first segment’s goal is to gather information on the participants’ work experience, job kind, and businesses. The second segment is dedicated for gathering the RE practices used by SDO practitioners to handle the issues they confront. Two rounds of pilot study were undertaken to enhance the questionnaire design. Sampling and population: For acquiring a valid sample of participants, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the respondents. Response rate: There have been a total of 110 replies. The 106 replies were chosen for data analysis from 110 responses grounded on the participant’s corporate profile, job title, appropriate experience, and data reliability. Table 2 includes details about the study’s second questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Particulars of the 2nd questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t002 4.3.2. Consolidation of SDO RE practices. A focus group session was held with the help of two other researchers to develop the finalized listing of additional RE practices. The terminologies have been clarified, and similar RE practices from the literature and the SDO professionals have been merged. 4.3.3. Additional RE practices to tackle the SDO RE process issues. The second questionnaire survey highlighted 14 additional RE practices that may be employed to solve the RE process issues for SDO. REPR134, REPR135, REPR136, …, REPR147 denote 14 RE practices: REPR134 = Motivate employees to utilize Facebook or Twitter as means of communication [Proposed]; REPR135 = Record synchronous communication in form of telephonic calls, Skype conversation and through videoconferencing [Proposed]; REPR136 = Finding and gaining access to all means of requirements which are: System’s end users, managers, executives, supervisors, customers, designers, and maintenance workers. Persons who take part in the business processes’ pursuits. As mentioned by client services, persons who are interested or effected. Client-supplied requirements or the requirements of multiple partners. Challenges that stakeholders encounter. Specialists in the field. Limitations, rules, and criteria that must be adhered to in the specific domain. Existing comparable systems. Consumers of the existing comparable systems. Records pertaining to the target system such as ledger books, bills, invoices, and notifications. Different applications or systems that integrate with the to-be-created system [Proposed]; REPR137 = Prior to actually picking RE tool(s), acquiring experience and knowledge about distinct aspects of the RE tool(s) [Proposed]; REPR138 = If feasible, seeking the advice of subject matter experts [Proposed]; REPR139 = Evaluating the likelihood of interruptions, as partners are dispersed, when estimating the time needed for various operations [Proposed]; REPR140 = Estimating and, if feasible, incorporating Float or Slack Time in the plan [Proposed]; REPR141 = In the event that development is delayed: investing additional time and supplies; OR after discussing with the various partners, decreasing the effort related to RE; OR delegating some of the workload to a separate contractor [Proposed]; REPR142 = Establishing a list of basic criteria that will meet the customer’s demands [Proposed]; REPR143 = Creating a Software Requirements Specification document that everyone agrees on [Proposed]; REPR144 = Just share information, regarding requirements, with those who need to know [Proposed]; REPR145 = Assigning more funds and resources to additional needs [Proposed]; REPR146 = If it is impractical to adopt same operating standards or procedures, the minimal number of same operating standards or procedures should be observed [Proposed]; REPR147 = Notifying the customer as soon as feasible, regarding any requirement(s) that is/are not possible to accomplish [Proposed]. The RQ3 is answered in this way. 4.4. Exhaustive list of RE practices to tackle usually arising SDO RE process issues To address the usually arising issues of RE process in the context of SDO, it can be seen in sections 4.1.2, 4.2.3, and 4.3.3 that: The present literature was used to investigate the 90 RE practices. Sommerville and Sawyer offer 43 RE practices, which are significant, and SDO industry professionals have suggested the 14 more RE practices. As a result, there are 147(90+43+14) RE practices in the full list. Table 3 indicates the specifics. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 3. No. of identified RE practices to tackle SDO RE process issues. https://doi.org/10.1371/journal.pone.0269607.t003 This delivers a cumulative reply to RQ1, RQ2, and RQ3. The proportions of the total 147 RE practices acquired from different sources can be seen in Fig 5. As presented in Fig 5, 61 percent of RE practices were collected from the literature, 29 percent were Sommerville and Sawyer’s significant RE practices, and 10% of RE practices were proposed by SDO industrial professionals. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Percentages of RE practices from various resources. https://doi.org/10.1371/journal.pone.0269607.g005 S4 Appendix comprises of an extensive compilation of 147 RE practices for tackling typical SDO RE process issues. 4.1. Step 1: Identifying RE practices, grounded on existing literature, to tackle the issues of RE process for SDO SLR has been performed in the initial phase of this study. 4.1.1. Systematic literature review. The targeted sources to find relevant studies are IEEE Xplore, ACM, Science Direct, Springer Link & Web of Science. Fig 3 depicts the SLR process. To eliminate bias, two other investigators have been engaged throughout the process, and each phase has been concluded after reaching an agreement. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Studies selection procedure. https://doi.org/10.1371/journal.pone.0269607.g003 After a rigorous review and screening procedure, 117 studies were chosen for extracting data. 4.1.2. The RE practices to tackle SDO RE process issues. The 90 RE practices have been discovered, after a thorough examination of 117 studies, that can be applied to tackle the RE process issues in SDO scenario. The 90 RE practices denoted by the initials REPR1, REPR2, REPR3,…, REPR90 are as follows: REPR1 = Putting in place the necessary infrastructure to support communication and guaranteeing that it is operational [87]; REPR2 = Promoting synchronous communication using chat rooms, phone conversations, and videoconferencing [87]; REPR3 = Adjusting to and comprehending various stakeholders’ cultures [87], means being familiar with a culture’s customs, values, ethos, and local language [5]; REPR4 = Choosing and utilizing a standardized communication language [88]; REPR5 = Concentrating on communication language improvement, such as English language classes [87, 89, 90]; REPR6 = Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]; REPR7 = Creating a ’proximity training center’ in a time zone that is the same or somewhat different from the client’s zone [93]; REPR8 = Attempting to identify natural overlaps in work time [94]; REPR9 = Evaluating a person’s capacity to work ’around the clock’ [94]; REPR10 = Time-shifting (adjusting one’s working time to coincide with the work time of others) to attain time zone closeness, a variety of approaches for this purpose, are: Flextime (functioning on a flexible schedule to allow for overlapping). Overtime (functioning for additional time for overlapping). Telework (functioning for elastic schedules from home for overlapping). Long working days (allowing for work time overlapping at the beginning or finish of the day). Unrestricted working hours (employees decide their own operating time for overlapping and there are no standard work hours) [95]; REPR11 = Providing electronic message "drop in", remote phoning, and artefact distribution capabilities to distant practitioners’ rooms [96]; REPR12 = Enabling professional integration from the outset of the project, such as by holding face-to-face kick-off meetings to create personal interactions [21, 97]; REPR13 = Organizing regular visits to isolated locations in order to foster trust [18, 98, 99]; REPR14 = Encouraging direct contact amongst stakeholders [100]; REPR15 = Assuring that stakeholders are introduced to each other from the start of the project [101]; REPR16 = Facilitating interaction in the client’s original tongue [5]; REPR17 = Advising on the usage of groupware tools [99]; REPR18 = Attempting to convince stakeholders that disclosing concerns or sharing information would have beneficial repercussions rather than adverse effects [94]; REPR19 = Organizing video or teleconferences on day-to-day, weekly, semi-monthly, or monthly basis such that no or a few awkward hours exist for all the partners [98]; REPR20 = Organizing requirements engineering sessions by: Using a human moderator and a rich communication medium that allows data, audios, and videos to be integrated. Making and sticking to an agenda. Identifying appropriate participants and notifying them on time to participate in requirements engineering sessions. Exchanging of reference materials in a timely manner to allow participants ample time to view the essential content. Giving attendees of requirements sessions access to resources (like emails, relevant papers, work artefacts, and so on) containing information on the requirements [21]; REPR21 = Setting up assertive governance at the project manager and team leader levels [102]; REPR22 = Keeping track of the directives in a certain order [102]; REPR23 = Personal and group obligations must be clearly stated and agreed upon [102]; REPR24 = Getting obviously defined and grasped requirements engineering processes [102]; REPR25 = Utilizing email as a communication verification tool because it preserves a written copy of contact [21, 89, 96]; REPR26 = Getting agreements in writing and adequately documented [103]; REPR27 = Creating an organizational structure with clear communication roles [91]; REPR28 = At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]; REPR29 = Partly orchestrating inter-organizational procedures [91]; REPR30 = Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]; REPR31 = Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR32 = Making use of an awareness support system to manage requirements, all partners ought to be able to obtain the following details: Specifications, justifications, and priorities of various requirements. Requirements dependencies, as well as design, code, and testing dependencies. Duties of every member of the team in relation to specific requirement(s) and contact particulars like email address and phone number. The people who took initiatives for the requirements. Issues relating to requirements, issues’ activators, state of issues’ resolution, and judgments made because of issues. Dates, times, and venues of the meetings, as well as the present stakeholders, debated issues and judgments done. Demands for change, change demand activators, state of every change demand, personnel engaged in making judgments, and judgments made [104]; REPR33 = Retaining senior professionals on the team and persuading those professionals to bridge the knowledge gap [105]; REPR34 = Putting in place a centralized communication system [105]; REPR35 = After each meeting, making a report of the proceedings. Any member of the team or moderator ought to outline which issues were presented at the meeting, what decisions were taken about every issue, still open issues, who is responsible for gathering more data, and whose guidance should be solicited in the event of each issue [106]; REPR36 = To use a Requirements Management System (to regulate and follow changes) that has the succeeding characteristics: Searching a list of requirements, extracting individual requirements, and organizing requirements according to certain criteria. Administration of the requirements modification process, assistance for requirements traceability, and development of various forms of requirements reporting. Acceptance of external documents via an interface. Managing several versions of requirements. Aid for carrying out various forms of analyses (e.g., impact analysis, knowing whether a requirement is orphan, status tracking). Limiting access and editing privileges to the list of requirements [29]; REPR37 = Notifying the pertinent partner regarding the change in requirements by: Communication technologies such as telephone, emails, and the internet. Using the system to send out automated notifications [107]; REPR38 = In the event that there are a large number of partners: Designating a person (communication channel) out of each organizational unit or group of requirements sources to collect requirements from that unit or group. The requirements are then transferred to an expert via communication channels, where they might be combined [108]. Obtaining unanimity on requirements employing group elicitation approaches like Brainstorming, JAD, Focus groups, and requirements Workshops [25]. Generating a consolidated requirements document that includes all of the requirements [108]; REPR39 = Adopting the following steps to address cultural challenges: (REPR6) Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]. Advising members of the team to tour other partners’ sites [109]. Organizing cultural training sessions [109]. Offering cross-cultural orientation sessions [109]. Considering stakeholders’ cultural beliefs when determining female responsibilities [109]. Introducing a ’Negotiated Culture,’ a negotiated culture created to respect all partners’ cultural standards [103]. Identifying persons with expertise and familiarity with the customer’s culture to support for requirements discussion and definition [89]. (REPR4) Choosing and utilizing a standardized communication language [88]. (REPR5) Concentrating on communication language improvement, such as English language classes [87, 89, 90]. The project manager or/and experienced team members planning and supervision of all the efforts that are carried out to cope with cultural differences [109]; REPR40 = Presenting the Equality Model (EM) for all partners, in which all partners are treated equally and can discuss each other’s preferences, religion, and social traditions. They can also exchange knowledge and make recommendations based on others’ perspectives and roles [110]; REPR41 = Defining the procedures, techniques, and policies that must be followed [111]; REPR42 = Knowledge exchange [111]; REPR43 = Observance of common hopes [111]; REPR44 = Possessing technological, managerial, and personnel capabilities for satisfying quality standards & meeting deadlines [5]; REPR45 = To inspire non-fluent or less confident partners to participate in the discourse, begin with an informal dialogue [112]; REPR46 = Making use of translation facilities: Utilizing human interpreter [112, 113]. Utilizing real-time machine conversion facilities [113]; REPR47 = Utilizing scales to calculate the mean time it takes for hopes to be met. For example, providing a feature that determines the average time it takes a person or team to react to an email. If the mean time to respond is three days, the sender may anticipate receiving a response within three days [114]; REPR48 = Developing and utilizing a vocabulary and notations for requirements description [88]; REPR49 = Vendor managers can take the following steps to establish collaboration: Establishing team members’ roles and tasks, as well as constructing Organizational Charts that show their roles and obligations [115]. Obtaining and administering the appropriate human resources using Resource Calendar [115]. Appropriate task distribution [115]. (REPR28) At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]. (REPR29) Partly orchestrating inter-organizational procedures [91]. (REPR30) Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]. (REPR31) Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR50 = Achieving partners’ agreement on meeting attendance terms and conditions, as well as fulfilling timelines and obligations [116]; REPR51 = Identifying each team member’s function and suggesting who might interact with whom [16, 117]; REPR52 = In terms of decisions, keep in constant contact with customers by organizing: Meetings in person. Video conferencing [16]; REPR53 = Selecting a teammate that works beyond the typical business hours and responds to questions [118]; REPR54 = Educating on in what manner to: Make use of the available tools. Interact efficiently in a situation where partners are scattered at remote sites [18]; REPR55 = Giving prospective team members training about how to use relevant procedures, as well as associated tools and technology [119]; REPR56 = Performing six general steps for RE, in absence of any standard RE process [20, 120], which are: i) Requirements Elicitation, ii) Requirements Analysis & Negotiations, iii) Specifying Requirements, iv) System Modeling, v) Requirements Validation, and vi) Requirements Management [13, 22, 121]; REPR57 = Adopting procedures that have been discussed and agreed upon [97]; REPR58 = Utilizing tools which can connect with one another [107]; REPR59 = Utilizing the ISO/IEC TR 24766:2009 framework and related data, for evaluating the functionalities of RE tools [122, 123]; REPR60 = Nominating a practitioner as requirements engineer or system analyst who possesses: Domain knowledge or is ready to understand domain and sophisticated elicitation procedures [124]. Capabilities for working in the global context, with remote teams and people from other cultures [124]. Ability to settle problems and operate in unclear and uncertain conditions [124]. Case tools, system modelling, computer languages, requirements management systems, and human-computer interface knowledge [125]. Traits for interaction, socializing, conflict resolution, teamwork as well as individual work, creativity, and adaptability to change [126]; REPR61 = Selecting an appropriate requirements elicitation approach by applying a right procedure [127]; REPR62 = Establishing and adhering to a standardized document format [22]; REPR63 = For structuring the requirements description document, employing IEEE Standard 830–1998 [88]; REPR64 = Developing bare minimum standards to document requirements [88]; REPR65 = By negotiating, positioning the customer and vendor’s goals [119]; REPR66 = Developing a plan for RE and allocating 15 to 30 percent of overall project efforts to RE [128, 129]; REPR67 = Creating metrics for gauging performance [116]; REPR68 = Creating methods to track and report progress [116]; REPR69 = Raising the frequency of RE deliverables to improve progress monitoring and transparency [116]; REPR70 = Locating and gaining access to critical users [119, 130]; REPR71 = Inquiring from known or recognized partners about additional partners, creating partners’ social networks, and then ranking partners based on social network measurements [131]; REPR72 = Forming a Change Control Board (CCB) [102] and incorporating new requirements through an appropriate requirement change management procedure (change assessment and dissemination mechanism) [132–135]; REPR73 = Including actual system operators during RE process [136]; REPR74 = Standardizing requirements description template, by following guidelines of the IEEE Standard 830–1998 [88]; REPR75 = Meeting the criteria described in IEEE Standard 830–1998 in terms of quality [88]; REPR76 = Utilizing Wikis, physically dispersed partners are involved in the exploration of their wants, discussion of relevant issues, requests for additional characteristics, and formation of requirements [137]; REPR77 = Employing asynchronous communication, such as email, so that partners with lower capability have opportunity to grasp and respond to delivered messages [96, 98]. Features such as spell-checking and grammatical correction, as well as language interpretation, should really be incorporated with the email service [90]; REPR78 = Leveraging requirements visualization tools (such as use case and business process diagrams) and social visualization approaches to encourage partners’ participation and improve awareness about requirements [138]; REPR79 = Using Felder-Silverman’s Learning Style Model to choose appropriate groupware tools and strategies to elicit requirements while considering cognitive traits of partners [139]; REPR80 = Utilizing the same collection of tools [97]; REPR81 = Conducting workshops to elicit requirements [140]; REPR82 = Replacing conventional head-on workshops with a peer-to-peer workshop technology [141] which should offer services such as: Direct messaging. Document exchange, inspection, and modification. Negotiations over audio link up. Autonomy (by employing access privileges, a peer sends data to others while simultaneously imposing limits, such as not providing data to specific peers) provision. Intermittency (removal of a peer as a result of network disconnect, which can be purposeful or unintentional) detection [141]; REPR83 = Taking into account Hofstede’s cultural dimensions, for assisting managers in identifying individual and group conduct [109], which are: The distance between the power sources. Collectivism as opposed to individualism. Masculinity as opposed to Femininity. Avoiding uncertainty. Short-term opposed to Long-term adjustment [92, 142]; REPR84 = Encouraging informal contact amongst partners who are dispersed [143]; REPR85 = Making it easier for partners to communicate with one another on a regular basis [144]; REPR86 = Applying a proper requirements traceability method throughout the stages of requirements, design, and implementation [145]; REPR87 = Identifying co-change tendencies to forecast future requirements changes and developing a corresponding policy [146, 147]; REPR88 = Utilizing altered 100 $ method for requirements prioritization [148]; REPR89 = Considering that the client communication and requirements phase accounts for 10 to 25 percent of the overall project effort [149]; REPR90 = Forming the groups in a manner that work overlaps so that employees are aware of the other individuals’ duties [150]. The RQ1 is answered in this way. 4.1.1. Systematic literature review. The targeted sources to find relevant studies are IEEE Xplore, ACM, Science Direct, Springer Link & Web of Science. Fig 3 depicts the SLR process. To eliminate bias, two other investigators have been engaged throughout the process, and each phase has been concluded after reaching an agreement. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. Studies selection procedure. https://doi.org/10.1371/journal.pone.0269607.g003 After a rigorous review and screening procedure, 117 studies were chosen for extracting data. 4.1.2. The RE practices to tackle SDO RE process issues. The 90 RE practices have been discovered, after a thorough examination of 117 studies, that can be applied to tackle the RE process issues in SDO scenario. The 90 RE practices denoted by the initials REPR1, REPR2, REPR3,…, REPR90 are as follows: REPR1 = Putting in place the necessary infrastructure to support communication and guaranteeing that it is operational [87]; REPR2 = Promoting synchronous communication using chat rooms, phone conversations, and videoconferencing [87]; REPR3 = Adjusting to and comprehending various stakeholders’ cultures [87], means being familiar with a culture’s customs, values, ethos, and local language [5]; REPR4 = Choosing and utilizing a standardized communication language [88]; REPR5 = Concentrating on communication language improvement, such as English language classes [87, 89, 90]; REPR6 = Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]; REPR7 = Creating a ’proximity training center’ in a time zone that is the same or somewhat different from the client’s zone [93]; REPR8 = Attempting to identify natural overlaps in work time [94]; REPR9 = Evaluating a person’s capacity to work ’around the clock’ [94]; REPR10 = Time-shifting (adjusting one’s working time to coincide with the work time of others) to attain time zone closeness, a variety of approaches for this purpose, are: Flextime (functioning on a flexible schedule to allow for overlapping). Overtime (functioning for additional time for overlapping). Telework (functioning for elastic schedules from home for overlapping). Long working days (allowing for work time overlapping at the beginning or finish of the day). Unrestricted working hours (employees decide their own operating time for overlapping and there are no standard work hours) [95]; REPR11 = Providing electronic message "drop in", remote phoning, and artefact distribution capabilities to distant practitioners’ rooms [96]; REPR12 = Enabling professional integration from the outset of the project, such as by holding face-to-face kick-off meetings to create personal interactions [21, 97]; REPR13 = Organizing regular visits to isolated locations in order to foster trust [18, 98, 99]; REPR14 = Encouraging direct contact amongst stakeholders [100]; REPR15 = Assuring that stakeholders are introduced to each other from the start of the project [101]; REPR16 = Facilitating interaction in the client’s original tongue [5]; REPR17 = Advising on the usage of groupware tools [99]; REPR18 = Attempting to convince stakeholders that disclosing concerns or sharing information would have beneficial repercussions rather than adverse effects [94]; REPR19 = Organizing video or teleconferences on day-to-day, weekly, semi-monthly, or monthly basis such that no or a few awkward hours exist for all the partners [98]; REPR20 = Organizing requirements engineering sessions by: Using a human moderator and a rich communication medium that allows data, audios, and videos to be integrated. Making and sticking to an agenda. Identifying appropriate participants and notifying them on time to participate in requirements engineering sessions. Exchanging of reference materials in a timely manner to allow participants ample time to view the essential content. Giving attendees of requirements sessions access to resources (like emails, relevant papers, work artefacts, and so on) containing information on the requirements [21]; REPR21 = Setting up assertive governance at the project manager and team leader levels [102]; REPR22 = Keeping track of the directives in a certain order [102]; REPR23 = Personal and group obligations must be clearly stated and agreed upon [102]; REPR24 = Getting obviously defined and grasped requirements engineering processes [102]; REPR25 = Utilizing email as a communication verification tool because it preserves a written copy of contact [21, 89, 96]; REPR26 = Getting agreements in writing and adequately documented [103]; REPR27 = Creating an organizational structure with clear communication roles [91]; REPR28 = At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]; REPR29 = Partly orchestrating inter-organizational procedures [91]; REPR30 = Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]; REPR31 = Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR32 = Making use of an awareness support system to manage requirements, all partners ought to be able to obtain the following details: Specifications, justifications, and priorities of various requirements. Requirements dependencies, as well as design, code, and testing dependencies. Duties of every member of the team in relation to specific requirement(s) and contact particulars like email address and phone number. The people who took initiatives for the requirements. Issues relating to requirements, issues’ activators, state of issues’ resolution, and judgments made because of issues. Dates, times, and venues of the meetings, as well as the present stakeholders, debated issues and judgments done. Demands for change, change demand activators, state of every change demand, personnel engaged in making judgments, and judgments made [104]; REPR33 = Retaining senior professionals on the team and persuading those professionals to bridge the knowledge gap [105]; REPR34 = Putting in place a centralized communication system [105]; REPR35 = After each meeting, making a report of the proceedings. Any member of the team or moderator ought to outline which issues were presented at the meeting, what decisions were taken about every issue, still open issues, who is responsible for gathering more data, and whose guidance should be solicited in the event of each issue [106]; REPR36 = To use a Requirements Management System (to regulate and follow changes) that has the succeeding characteristics: Searching a list of requirements, extracting individual requirements, and organizing requirements according to certain criteria. Administration of the requirements modification process, assistance for requirements traceability, and development of various forms of requirements reporting. Acceptance of external documents via an interface. Managing several versions of requirements. Aid for carrying out various forms of analyses (e.g., impact analysis, knowing whether a requirement is orphan, status tracking). Limiting access and editing privileges to the list of requirements [29]; REPR37 = Notifying the pertinent partner regarding the change in requirements by: Communication technologies such as telephone, emails, and the internet. Using the system to send out automated notifications [107]; REPR38 = In the event that there are a large number of partners: Designating a person (communication channel) out of each organizational unit or group of requirements sources to collect requirements from that unit or group. The requirements are then transferred to an expert via communication channels, where they might be combined [108]. Obtaining unanimity on requirements employing group elicitation approaches like Brainstorming, JAD, Focus groups, and requirements Workshops [25]. Generating a consolidated requirements document that includes all of the requirements [108]; REPR39 = Adopting the following steps to address cultural challenges: (REPR6) Employing cultural liaisons [87, 89, 91] or intermediaries (people who are conversant with customer and vendor cultures) [92]. Advising members of the team to tour other partners’ sites [109]. Organizing cultural training sessions [109]. Offering cross-cultural orientation sessions [109]. Considering stakeholders’ cultural beliefs when determining female responsibilities [109]. Introducing a ’Negotiated Culture,’ a negotiated culture created to respect all partners’ cultural standards [103]. Identifying persons with expertise and familiarity with the customer’s culture to support for requirements discussion and definition [89]. (REPR4) Choosing and utilizing a standardized communication language [88]. (REPR5) Concentrating on communication language improvement, such as English language classes [87, 89, 90]. The project manager or/and experienced team members planning and supervision of all the efforts that are carried out to cope with cultural differences [109]; REPR40 = Presenting the Equality Model (EM) for all partners, in which all partners are treated equally and can discuss each other’s preferences, religion, and social traditions. They can also exchange knowledge and make recommendations based on others’ perspectives and roles [110]; REPR41 = Defining the procedures, techniques, and policies that must be followed [111]; REPR42 = Knowledge exchange [111]; REPR43 = Observance of common hopes [111]; REPR44 = Possessing technological, managerial, and personnel capabilities for satisfying quality standards & meeting deadlines [5]; REPR45 = To inspire non-fluent or less confident partners to participate in the discourse, begin with an informal dialogue [112]; REPR46 = Making use of translation facilities: Utilizing human interpreter [112, 113]. Utilizing real-time machine conversion facilities [113]; REPR47 = Utilizing scales to calculate the mean time it takes for hopes to be met. For example, providing a feature that determines the average time it takes a person or team to react to an email. If the mean time to respond is three days, the sender may anticipate receiving a response within three days [114]; REPR48 = Developing and utilizing a vocabulary and notations for requirements description [88]; REPR49 = Vendor managers can take the following steps to establish collaboration: Establishing team members’ roles and tasks, as well as constructing Organizational Charts that show their roles and obligations [115]. Obtaining and administering the appropriate human resources using Resource Calendar [115]. Appropriate task distribution [115]. (REPR28) At the various levels of team, project, and management; creating peer-to-peer connectivity across remote locations [91]. (REPR29) Partly orchestrating inter-organizational procedures [91]. (REPR30) Providing open channels of communication amongst stakeholders with clearly defined responsibilities [91]. (REPR31) Assessing and communicating development on jointly approved artefacts on a regular basis [91]; REPR50 = Achieving partners’ agreement on meeting attendance terms and conditions, as well as fulfilling timelines and obligations [116]; REPR51 = Identifying each team member’s function and suggesting who might interact with whom [16, 117]; REPR52 = In terms of decisions, keep in constant contact with customers by organizing: Meetings in person. Video conferencing [16]; REPR53 = Selecting a teammate that works beyond the typical business hours and responds to questions [118]; REPR54 = Educating on in what manner to: Make use of the available tools. Interact efficiently in a situation where partners are scattered at remote sites [18]; REPR55 = Giving prospective team members training about how to use relevant procedures, as well as associated tools and technology [119]; REPR56 = Performing six general steps for RE, in absence of any standard RE process [20, 120], which are: i) Requirements Elicitation, ii) Requirements Analysis & Negotiations, iii) Specifying Requirements, iv) System Modeling, v) Requirements Validation, and vi) Requirements Management [13, 22, 121]; REPR57 = Adopting procedures that have been discussed and agreed upon [97]; REPR58 = Utilizing tools which can connect with one another [107]; REPR59 = Utilizing the ISO/IEC TR 24766:2009 framework and related data, for evaluating the functionalities of RE tools [122, 123]; REPR60 = Nominating a practitioner as requirements engineer or system analyst who possesses: Domain knowledge or is ready to understand domain and sophisticated elicitation procedures [124]. Capabilities for working in the global context, with remote teams and people from other cultures [124]. Ability to settle problems and operate in unclear and uncertain conditions [124]. Case tools, system modelling, computer languages, requirements management systems, and human-computer interface knowledge [125]. Traits for interaction, socializing, conflict resolution, teamwork as well as individual work, creativity, and adaptability to change [126]; REPR61 = Selecting an appropriate requirements elicitation approach by applying a right procedure [127]; REPR62 = Establishing and adhering to a standardized document format [22]; REPR63 = For structuring the requirements description document, employing IEEE Standard 830–1998 [88]; REPR64 = Developing bare minimum standards to document requirements [88]; REPR65 = By negotiating, positioning the customer and vendor’s goals [119]; REPR66 = Developing a plan for RE and allocating 15 to 30 percent of overall project efforts to RE [128, 129]; REPR67 = Creating metrics for gauging performance [116]; REPR68 = Creating methods to track and report progress [116]; REPR69 = Raising the frequency of RE deliverables to improve progress monitoring and transparency [116]; REPR70 = Locating and gaining access to critical users [119, 130]; REPR71 = Inquiring from known or recognized partners about additional partners, creating partners’ social networks, and then ranking partners based on social network measurements [131]; REPR72 = Forming a Change Control Board (CCB) [102] and incorporating new requirements through an appropriate requirement change management procedure (change assessment and dissemination mechanism) [132–135]; REPR73 = Including actual system operators during RE process [136]; REPR74 = Standardizing requirements description template, by following guidelines of the IEEE Standard 830–1998 [88]; REPR75 = Meeting the criteria described in IEEE Standard 830–1998 in terms of quality [88]; REPR76 = Utilizing Wikis, physically dispersed partners are involved in the exploration of their wants, discussion of relevant issues, requests for additional characteristics, and formation of requirements [137]; REPR77 = Employing asynchronous communication, such as email, so that partners with lower capability have opportunity to grasp and respond to delivered messages [96, 98]. Features such as spell-checking and grammatical correction, as well as language interpretation, should really be incorporated with the email service [90]; REPR78 = Leveraging requirements visualization tools (such as use case and business process diagrams) and social visualization approaches to encourage partners’ participation and improve awareness about requirements [138]; REPR79 = Using Felder-Silverman’s Learning Style Model to choose appropriate groupware tools and strategies to elicit requirements while considering cognitive traits of partners [139]; REPR80 = Utilizing the same collection of tools [97]; REPR81 = Conducting workshops to elicit requirements [140]; REPR82 = Replacing conventional head-on workshops with a peer-to-peer workshop technology [141] which should offer services such as: Direct messaging. Document exchange, inspection, and modification. Negotiations over audio link up. Autonomy (by employing access privileges, a peer sends data to others while simultaneously imposing limits, such as not providing data to specific peers) provision. Intermittency (removal of a peer as a result of network disconnect, which can be purposeful or unintentional) detection [141]; REPR83 = Taking into account Hofstede’s cultural dimensions, for assisting managers in identifying individual and group conduct [109], which are: The distance between the power sources. Collectivism as opposed to individualism. Masculinity as opposed to Femininity. Avoiding uncertainty. Short-term opposed to Long-term adjustment [92, 142]; REPR84 = Encouraging informal contact amongst partners who are dispersed [143]; REPR85 = Making it easier for partners to communicate with one another on a regular basis [144]; REPR86 = Applying a proper requirements traceability method throughout the stages of requirements, design, and implementation [145]; REPR87 = Identifying co-change tendencies to forecast future requirements changes and developing a corresponding policy [146, 147]; REPR88 = Utilizing altered 100 $ method for requirements prioritization [148]; REPR89 = Considering that the client communication and requirements phase accounts for 10 to 25 percent of the overall project effort [149]; REPR90 = Forming the groups in a manner that work overlaps so that employees are aware of the other individuals’ duties [150]. The RQ1 is answered in this way. 4.2. Step 2: Sommerville and Sawyer’s significant RE practices to tackle issues of SDO RE process There is a need to study which of Sommerville & Sawyer’s suggested practices are critical for addressing the RE process issues in the context of SD. 4.2.1. Identification of the significant RE practices for SDO through questionnaire survey. The S1 Appendix presents the questionnaire employed for the survey. (a) Questionnaire format: The closed format questions ask you to rank the advantages of RE techniques for SDO on a scale of one to four. The open-ended questions are designed to find out whether respondents are using any additional RE practices except the ones listed. The questionnaire is split into two sections. The first section’s goal is to gather information on the respondents’ work experience, job kind, and businesses. The second section is for data collection about key RE practices based on their assessed advantages for SDO. Two rounds of pilot study were undertaken to enhance the questionnaire layout. The following are the various types of purported benefits of RE practices [8, 70]: High Perceived Benefits (Hi): If a RE practice is mandated and always utilized, it has a "high perceived benefit". Medium Perceived Benefits (Mi): If a RE practice is not obligatory but is commonly or often utilized, it has “medium perceived advantages”. Low Perceived Benefits (Li): If a RE practice is only employed for a few projects, it has "low perceived benefits". Zero Perceived Benefits (Zi): If a RE practice is never or just seldom employed, it has "zero perceived benefits". (b) Sampling and population: For acquiring a valid sample of respondents, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the participants. These professionals are classified as ’developers, ’managers,’ and ’senior managers,’ [71]. (c) Response rate: As interested professionals have been in constant communication, 45 out of 60 answers have been received by email. The 108(T) replies were chosen for data analysis, from a total of 115 (70+45) responses, grounded on the participant’s company profile, job description, and appropriate experience. Table 1 displays the results of the first questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. Particulars of the 1st questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t001 (d) Criteria for choosing significant RE practices: If at least 50% of respondents believe that a RE practice’s perceived advantages fall into the ’high perceived benefits’ and ’medium perceived benefits’ categories, then that RE practice is considered ’significant’ for resolving RE process issues for outsourced software development projects. An approach comparable to this, has been used successfully in previous investigations [70–72]. 4.2.2. Survey outcomes and selecting the significant RE practices. To determine the significant RE practices, out of the four classes of the RE practices’ perceived benefits, only the RE practices belonging to ’high perceived benefits’ and ’medium perceived benefits’ classes have been regarded based on the definitions of perceived benefits’ classes [8]. The Prominence Level (PL) for every RE practice indicates the percentage of replies in the ’high perceived benefits’ and ’medium perceived benefits’ classes, and is computed as specified in Eq 1: (1) The survey’s findings are reported in S2 Appendix. The findings reveal that the bulk of the RE practices advised by Sommerville and Sawyer are significant for SDO with 43 out of 49 practices (87.76%) meeting the essential criterion. Fig 4 depicts the percentages of practices and significant practices in relation to major RE process steps. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Percentages of the RE practices and significant RE Practices w.r.t phases of RE process. https://doi.org/10.1371/journal.pone.0269607.g004 4.2.3. Significant RE practices to tackle issues of RE process for SDO. Sommerville and Sawyer’s 43 RE practices are significant for addressing the RE process issues for SDO. The 43 RE practices denoted by REPR91, REPR92, REPR93, …, REPR133 are: REPR91 = Evaluate the system’s effectiveness; REPR92 = Recognizing system stakeholders and taking into account their requirements; REPR93 = Sources of information must be recorded; REPR94 = Determining the system’s operational environment; REPR95 = Leveraging business needs to derive the requirements’ elicitation; REPR96 = Search for the specific constraints of domain; REPR97 = Document the justification for the requirements; REPR98 = Use prototyping to understand the uncertain requirements; REPR99 = Use scenarios to elicit requirements; REPR100 = Outline operating procedures; REPR101 = Utilize requirements from comparable systems that have already been created; REPR102 = Outline boundaries in case of each system; REPR103 = When assessing requirements, consider checklists; REPR104 = To help negotiating, employ communication channels; REPR105 = Prepare a strategy for identifying and resolving disputes; REPR106 = Consultation with partners to prioritize requirements; REPR107 = Categorize requirements by employing a multi-dimensional methodology; REPR108 = Evaluate the risks associated with the requirements; REPR109 = Develop and apply templates’ standard to describe requirements; REPR110 = To express requirements adopt basic, uniform, and brief language; REPR111 = Employ diagrams as needed; REPR112 = Other representations for the requirements should also be incorporated to support the natural language specification; REPR113 = Describe requirements numerically wherever possible; REPR114 = Create a model of the system’s surroundings; REPR115 = Sketch the architecture of the proposed system; REPR116 = When modelling a system, utilize structured methodologies; REPR117 = Prepare and utilize a data dictionary; PR118 = Define the linkage between needs of the various partners and system models; REPR119 = Evaluate requirements documentation to check that it adheres to your stated criteria or not; REPR120 = Arranging the requirements evaluations; REPR121 = Evaluating requirements by involving interdisciplinary teams; REPR122 = Creating checklists to validate the requirements; REPR123 = Animating the partners’ needs by utilizing prototypes; REPR124 = Creating a draft version of the user manual; REPR125 = System models’ rephrasing by utilizing native language; REPR126 = Uniquely distinguishing every requirement of the partners; REPR127 = Creating guidelines to help you manage requirements; REPR128 = Establishing policies to trace various partners’ needs; REPR129 = Keeping the traceability guide up to date; REPR130 = Managing partners’ needs by employing database; REPR131 = Creating guidelines to deal with changing needs; REPR132 = Defining the system’s global needs; REPR133 = Determining the needs that are prone to change. The RQ2 is answered in this way. 4.2.1. Identification of the significant RE practices for SDO through questionnaire survey. The S1 Appendix presents the questionnaire employed for the survey. (a) Questionnaire format: The closed format questions ask you to rank the advantages of RE techniques for SDO on a scale of one to four. The open-ended questions are designed to find out whether respondents are using any additional RE practices except the ones listed. The questionnaire is split into two sections. The first section’s goal is to gather information on the respondents’ work experience, job kind, and businesses. The second section is for data collection about key RE practices based on their assessed advantages for SDO. Two rounds of pilot study were undertaken to enhance the questionnaire layout. The following are the various types of purported benefits of RE practices [8, 70]: High Perceived Benefits (Hi): If a RE practice is mandated and always utilized, it has a "high perceived benefit". Medium Perceived Benefits (Mi): If a RE practice is not obligatory but is commonly or often utilized, it has “medium perceived advantages”. Low Perceived Benefits (Li): If a RE practice is only employed for a few projects, it has "low perceived benefits". Zero Perceived Benefits (Zi): If a RE practice is never or just seldom employed, it has "zero perceived benefits". (b) Sampling and population: For acquiring a valid sample of respondents, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the participants. These professionals are classified as ’developers, ’managers,’ and ’senior managers,’ [71]. (c) Response rate: As interested professionals have been in constant communication, 45 out of 60 answers have been received by email. The 108(T) replies were chosen for data analysis, from a total of 115 (70+45) responses, grounded on the participant’s company profile, job description, and appropriate experience. Table 1 displays the results of the first questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. Particulars of the 1st questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t001 (d) Criteria for choosing significant RE practices: If at least 50% of respondents believe that a RE practice’s perceived advantages fall into the ’high perceived benefits’ and ’medium perceived benefits’ categories, then that RE practice is considered ’significant’ for resolving RE process issues for outsourced software development projects. An approach comparable to this, has been used successfully in previous investigations [70–72]. 4.2.2. Survey outcomes and selecting the significant RE practices. To determine the significant RE practices, out of the four classes of the RE practices’ perceived benefits, only the RE practices belonging to ’high perceived benefits’ and ’medium perceived benefits’ classes have been regarded based on the definitions of perceived benefits’ classes [8]. The Prominence Level (PL) for every RE practice indicates the percentage of replies in the ’high perceived benefits’ and ’medium perceived benefits’ classes, and is computed as specified in Eq 1: (1) The survey’s findings are reported in S2 Appendix. The findings reveal that the bulk of the RE practices advised by Sommerville and Sawyer are significant for SDO with 43 out of 49 practices (87.76%) meeting the essential criterion. Fig 4 depicts the percentages of practices and significant practices in relation to major RE process steps. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. Percentages of the RE practices and significant RE Practices w.r.t phases of RE process. https://doi.org/10.1371/journal.pone.0269607.g004 4.2.3. Significant RE practices to tackle issues of RE process for SDO. Sommerville and Sawyer’s 43 RE practices are significant for addressing the RE process issues for SDO. The 43 RE practices denoted by REPR91, REPR92, REPR93, …, REPR133 are: REPR91 = Evaluate the system’s effectiveness; REPR92 = Recognizing system stakeholders and taking into account their requirements; REPR93 = Sources of information must be recorded; REPR94 = Determining the system’s operational environment; REPR95 = Leveraging business needs to derive the requirements’ elicitation; REPR96 = Search for the specific constraints of domain; REPR97 = Document the justification for the requirements; REPR98 = Use prototyping to understand the uncertain requirements; REPR99 = Use scenarios to elicit requirements; REPR100 = Outline operating procedures; REPR101 = Utilize requirements from comparable systems that have already been created; REPR102 = Outline boundaries in case of each system; REPR103 = When assessing requirements, consider checklists; REPR104 = To help negotiating, employ communication channels; REPR105 = Prepare a strategy for identifying and resolving disputes; REPR106 = Consultation with partners to prioritize requirements; REPR107 = Categorize requirements by employing a multi-dimensional methodology; REPR108 = Evaluate the risks associated with the requirements; REPR109 = Develop and apply templates’ standard to describe requirements; REPR110 = To express requirements adopt basic, uniform, and brief language; REPR111 = Employ diagrams as needed; REPR112 = Other representations for the requirements should also be incorporated to support the natural language specification; REPR113 = Describe requirements numerically wherever possible; REPR114 = Create a model of the system’s surroundings; REPR115 = Sketch the architecture of the proposed system; REPR116 = When modelling a system, utilize structured methodologies; REPR117 = Prepare and utilize a data dictionary; PR118 = Define the linkage between needs of the various partners and system models; REPR119 = Evaluate requirements documentation to check that it adheres to your stated criteria or not; REPR120 = Arranging the requirements evaluations; REPR121 = Evaluating requirements by involving interdisciplinary teams; REPR122 = Creating checklists to validate the requirements; REPR123 = Animating the partners’ needs by utilizing prototypes; REPR124 = Creating a draft version of the user manual; REPR125 = System models’ rephrasing by utilizing native language; REPR126 = Uniquely distinguishing every requirement of the partners; REPR127 = Creating guidelines to help you manage requirements; REPR128 = Establishing policies to trace various partners’ needs; REPR129 = Keeping the traceability guide up to date; REPR130 = Managing partners’ needs by employing database; REPR131 = Creating guidelines to deal with changing needs; REPR132 = Defining the system’s global needs; REPR133 = Determining the needs that are prone to change. The RQ2 is answered in this way. 4.3. Step 3: Identification of the additional RE practices to tackle issues of SDO RE process Another questionnaire survey was employed for identification of the additional RE practices which are adopted by SDO professionals for addressing RE issues. 4.3.1. Questionnaire survey for finding additional SDO RE practices. The S3 Appendix presents the questionnaire employed for the survey. Questionnaire format: The questionnaire is split into two segments. The first segment’s goal is to gather information on the participants’ work experience, job kind, and businesses. The second segment is dedicated for gathering the RE practices used by SDO practitioners to handle the issues they confront. Two rounds of pilot study were undertaken to enhance the questionnaire design. Sampling and population: For acquiring a valid sample of participants, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the respondents. Response rate: There have been a total of 110 replies. The 106 replies were chosen for data analysis from 110 responses grounded on the participant’s corporate profile, job title, appropriate experience, and data reliability. Table 2 includes details about the study’s second questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Particulars of the 2nd questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t002 4.3.2. Consolidation of SDO RE practices. A focus group session was held with the help of two other researchers to develop the finalized listing of additional RE practices. The terminologies have been clarified, and similar RE practices from the literature and the SDO professionals have been merged. 4.3.3. Additional RE practices to tackle the SDO RE process issues. The second questionnaire survey highlighted 14 additional RE practices that may be employed to solve the RE process issues for SDO. REPR134, REPR135, REPR136, …, REPR147 denote 14 RE practices: REPR134 = Motivate employees to utilize Facebook or Twitter as means of communication [Proposed]; REPR135 = Record synchronous communication in form of telephonic calls, Skype conversation and through videoconferencing [Proposed]; REPR136 = Finding and gaining access to all means of requirements which are: System’s end users, managers, executives, supervisors, customers, designers, and maintenance workers. Persons who take part in the business processes’ pursuits. As mentioned by client services, persons who are interested or effected. Client-supplied requirements or the requirements of multiple partners. Challenges that stakeholders encounter. Specialists in the field. Limitations, rules, and criteria that must be adhered to in the specific domain. Existing comparable systems. Consumers of the existing comparable systems. Records pertaining to the target system such as ledger books, bills, invoices, and notifications. Different applications or systems that integrate with the to-be-created system [Proposed]; REPR137 = Prior to actually picking RE tool(s), acquiring experience and knowledge about distinct aspects of the RE tool(s) [Proposed]; REPR138 = If feasible, seeking the advice of subject matter experts [Proposed]; REPR139 = Evaluating the likelihood of interruptions, as partners are dispersed, when estimating the time needed for various operations [Proposed]; REPR140 = Estimating and, if feasible, incorporating Float or Slack Time in the plan [Proposed]; REPR141 = In the event that development is delayed: investing additional time and supplies; OR after discussing with the various partners, decreasing the effort related to RE; OR delegating some of the workload to a separate contractor [Proposed]; REPR142 = Establishing a list of basic criteria that will meet the customer’s demands [Proposed]; REPR143 = Creating a Software Requirements Specification document that everyone agrees on [Proposed]; REPR144 = Just share information, regarding requirements, with those who need to know [Proposed]; REPR145 = Assigning more funds and resources to additional needs [Proposed]; REPR146 = If it is impractical to adopt same operating standards or procedures, the minimal number of same operating standards or procedures should be observed [Proposed]; REPR147 = Notifying the customer as soon as feasible, regarding any requirement(s) that is/are not possible to accomplish [Proposed]. The RQ3 is answered in this way. 4.3.1. Questionnaire survey for finding additional SDO RE practices. The S3 Appendix presents the questionnaire employed for the survey. Questionnaire format: The questionnaire is split into two segments. The first segment’s goal is to gather information on the participants’ work experience, job kind, and businesses. The second segment is dedicated for gathering the RE practices used by SDO practitioners to handle the issues they confront. Two rounds of pilot study were undertaken to enhance the questionnaire design. Sampling and population: For acquiring a valid sample of participants, the Convenience Sampling approach was used. Project managers, software engineers, team leaders, quality assurance managers, programmers, designers, requirements engineers, analysts, and operations managers with no less than 5 years of SDO experience are among the respondents. Response rate: There have been a total of 110 replies. The 106 replies were chosen for data analysis from 110 responses grounded on the participant’s corporate profile, job title, appropriate experience, and data reliability. Table 2 includes details about the study’s second questionnaire survey. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Particulars of the 2nd questionnaire survey. https://doi.org/10.1371/journal.pone.0269607.t002 4.3.2. Consolidation of SDO RE practices. A focus group session was held with the help of two other researchers to develop the finalized listing of additional RE practices. The terminologies have been clarified, and similar RE practices from the literature and the SDO professionals have been merged. 4.3.3. Additional RE practices to tackle the SDO RE process issues. The second questionnaire survey highlighted 14 additional RE practices that may be employed to solve the RE process issues for SDO. REPR134, REPR135, REPR136, …, REPR147 denote 14 RE practices: REPR134 = Motivate employees to utilize Facebook or Twitter as means of communication [Proposed]; REPR135 = Record synchronous communication in form of telephonic calls, Skype conversation and through videoconferencing [Proposed]; REPR136 = Finding and gaining access to all means of requirements which are: System’s end users, managers, executives, supervisors, customers, designers, and maintenance workers. Persons who take part in the business processes’ pursuits. As mentioned by client services, persons who are interested or effected. Client-supplied requirements or the requirements of multiple partners. Challenges that stakeholders encounter. Specialists in the field. Limitations, rules, and criteria that must be adhered to in the specific domain. Existing comparable systems. Consumers of the existing comparable systems. Records pertaining to the target system such as ledger books, bills, invoices, and notifications. Different applications or systems that integrate with the to-be-created system [Proposed]; REPR137 = Prior to actually picking RE tool(s), acquiring experience and knowledge about distinct aspects of the RE tool(s) [Proposed]; REPR138 = If feasible, seeking the advice of subject matter experts [Proposed]; REPR139 = Evaluating the likelihood of interruptions, as partners are dispersed, when estimating the time needed for various operations [Proposed]; REPR140 = Estimating and, if feasible, incorporating Float or Slack Time in the plan [Proposed]; REPR141 = In the event that development is delayed: investing additional time and supplies; OR after discussing with the various partners, decreasing the effort related to RE; OR delegating some of the workload to a separate contractor [Proposed]; REPR142 = Establishing a list of basic criteria that will meet the customer’s demands [Proposed]; REPR143 = Creating a Software Requirements Specification document that everyone agrees on [Proposed]; REPR144 = Just share information, regarding requirements, with those who need to know [Proposed]; REPR145 = Assigning more funds and resources to additional needs [Proposed]; REPR146 = If it is impractical to adopt same operating standards or procedures, the minimal number of same operating standards or procedures should be observed [Proposed]; REPR147 = Notifying the customer as soon as feasible, regarding any requirement(s) that is/are not possible to accomplish [Proposed]. The RQ3 is answered in this way. 4.4. Exhaustive list of RE practices to tackle usually arising SDO RE process issues To address the usually arising issues of RE process in the context of SDO, it can be seen in sections 4.1.2, 4.2.3, and 4.3.3 that: The present literature was used to investigate the 90 RE practices. Sommerville and Sawyer offer 43 RE practices, which are significant, and SDO industry professionals have suggested the 14 more RE practices. As a result, there are 147(90+43+14) RE practices in the full list. Table 3 indicates the specifics. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 3. No. of identified RE practices to tackle SDO RE process issues. https://doi.org/10.1371/journal.pone.0269607.t003 This delivers a cumulative reply to RQ1, RQ2, and RQ3. The proportions of the total 147 RE practices acquired from different sources can be seen in Fig 5. As presented in Fig 5, 61 percent of RE practices were collected from the literature, 29 percent were Sommerville and Sawyer’s significant RE practices, and 10% of RE practices were proposed by SDO industrial professionals. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. Percentages of RE practices from various resources. https://doi.org/10.1371/journal.pone.0269607.g005 S4 Appendix comprises of an extensive compilation of 147 RE practices for tackling typical SDO RE process issues. 5. Ranking RE practices To rank the RE practices, for addressing RE process issues in case of SDO, requirements prioritization techniques have been employed. Several requirements prioritization techniques exist like Analytic Hierarchy Process (AHP), Numerical Assignment, Cumulative Voting or Hundred Dollar, Bubble Sort and Ranking etc. [151–153]. To make prioritization easy and efficient, some of the requirements prioritization techniques are combined [152, 154]. For example, for Planning Game (PG), Numerical Assignment and Ranking are combined [152, 154]. For this study, Numerical Assignment and Hundred Dollar techniques have been combined. In the first step, by applying. Numerical Assignment technique, RE practices have been divided into High, Medium, and Low groups [153, 155] based on the importance of RE practices to address SDO RE process issues. In the second step, RE practices within each group have been ranked through Hundred Dollar technique. 5.1. Focus group sessions To rank the RE practices, two Focus Group sessions have been conducted and each session continued for four hours. Three experts having academic and industrial experience have participated in the sessions. The details about the participants have been provided in the Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. Details of focus group meeting participants. https://doi.org/10.1371/journal.pone.0269607.t004 5.2. Prioritizing RE practices into High, Medium, and Low groups through Numerical Assignment technique The RE practices having High, Medium and Low importance to address SDO RE process issues, have been presented in Tables 5–7 respectively. In High importance group there are 83 RE practices, in Medium importance group there are 41 RE practices whereas in Low importance group there are 23 RE practices. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. RE Practices belonging to ‘High’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t005 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 6. RE Practices belonging to ‘Medium’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t006 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 7. RE Practices belonging to ‘Low’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t007 5.3. Ranking RE practices within each group through Cumulative Voting The ranks of the RE Practices within High, Medium, and Low groups, have been shown in Tables 5–7 respectively. 5.3.1. Ranking RE practices within High importance group. For ranking of RE practices that belong to Highly important group, 4000 points or dollars have been given to each participant of the focus group sessions. After mutual discussion, the participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of RE practices have been ascertained. For example, RE practice REPR1 has been awarded 90 dollars, REPR2 has been awarded 89 dollars and REPR3 has been awarded 88 dollars. Therefore, ranks of REPR1, REPR2 and REPR3 are 1, 2 and 3 respectively as shown in the Table 5. Total of all the awarded points or dollars is 4000. Normally, 100 dollars are considered and given to each participant or stakeholder but depending upon the number of items to be ranked, more points or dollars are also deemed. For example, Regnell et al. [156] have considered 100,000 dollars to rank 75 items (58 features and 17 feature groups). Within Highly important group, ranks of all the 83 RE practices have been shown in Table 5. 5.3.2. Ranking RE practices within Medium importance group. For ranking of RE practices that belong to Mediumly important group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of 41 RE practices have been decided that have shown in Table 6. 5.3.3. Ranking RE practices within Low importance group. For ranking of RE practices that belong to Low importance group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars to each RE practice. Based on the number of awarded dollars, the ranks of 23 RE practices have been decided that have shown in Table 7. This answers RQ4. 5.1. Focus group sessions To rank the RE practices, two Focus Group sessions have been conducted and each session continued for four hours. Three experts having academic and industrial experience have participated in the sessions. The details about the participants have been provided in the Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. Details of focus group meeting participants. https://doi.org/10.1371/journal.pone.0269607.t004 5.2. Prioritizing RE practices into High, Medium, and Low groups through Numerical Assignment technique The RE practices having High, Medium and Low importance to address SDO RE process issues, have been presented in Tables 5–7 respectively. In High importance group there are 83 RE practices, in Medium importance group there are 41 RE practices whereas in Low importance group there are 23 RE practices. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. RE Practices belonging to ‘High’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t005 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 6. RE Practices belonging to ‘Medium’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t006 Download: PPT PowerPoint slide PNG larger image TIFF original image Table 7. RE Practices belonging to ‘Low’ importance group along with respective ranks within group. https://doi.org/10.1371/journal.pone.0269607.t007 5.3. Ranking RE practices within each group through Cumulative Voting The ranks of the RE Practices within High, Medium, and Low groups, have been shown in Tables 5–7 respectively. 5.3.1. Ranking RE practices within High importance group. For ranking of RE practices that belong to Highly important group, 4000 points or dollars have been given to each participant of the focus group sessions. After mutual discussion, the participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of RE practices have been ascertained. For example, RE practice REPR1 has been awarded 90 dollars, REPR2 has been awarded 89 dollars and REPR3 has been awarded 88 dollars. Therefore, ranks of REPR1, REPR2 and REPR3 are 1, 2 and 3 respectively as shown in the Table 5. Total of all the awarded points or dollars is 4000. Normally, 100 dollars are considered and given to each participant or stakeholder but depending upon the number of items to be ranked, more points or dollars are also deemed. For example, Regnell et al. [156] have considered 100,000 dollars to rank 75 items (58 features and 17 feature groups). Within Highly important group, ranks of all the 83 RE practices have been shown in Table 5. 5.3.2. Ranking RE practices within Medium importance group. For ranking of RE practices that belong to Mediumly important group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of 41 RE practices have been decided that have shown in Table 6. 5.3.3. Ranking RE practices within Low importance group. For ranking of RE practices that belong to Low importance group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars to each RE practice. Based on the number of awarded dollars, the ranks of 23 RE practices have been decided that have shown in Table 7. This answers RQ4. 5.3.1. Ranking RE practices within High importance group. For ranking of RE practices that belong to Highly important group, 4000 points or dollars have been given to each participant of the focus group sessions. After mutual discussion, the participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of RE practices have been ascertained. For example, RE practice REPR1 has been awarded 90 dollars, REPR2 has been awarded 89 dollars and REPR3 has been awarded 88 dollars. Therefore, ranks of REPR1, REPR2 and REPR3 are 1, 2 and 3 respectively as shown in the Table 5. Total of all the awarded points or dollars is 4000. Normally, 100 dollars are considered and given to each participant or stakeholder but depending upon the number of items to be ranked, more points or dollars are also deemed. For example, Regnell et al. [156] have considered 100,000 dollars to rank 75 items (58 features and 17 feature groups). Within Highly important group, ranks of all the 83 RE practices have been shown in Table 5. 5.3.2. Ranking RE practices within Medium importance group. For ranking of RE practices that belong to Mediumly important group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars or points to each RE practice. Based on the number of awarded dollars or points, the ranks of 41 RE practices have been decided that have shown in Table 6. 5.3.3. Ranking RE practices within Low importance group. For ranking of RE practices that belong to Low importance group, 1000 points or dollars have been given to each participant of the focus group sessions. The participants have unanimously awarded dollars to each RE practice. Based on the number of awarded dollars, the ranks of 23 RE practices have been decided that have shown in Table 7. This answers RQ4. 6. Conclusion and future work Because of the occurrence of Requirements Engineering (RE) process issues, the predicted benefits of software development outsourcing (SDO) are not realized in numerous instances. This study offers a collection of 147 RE practices to handle frequently occurring RE process issues. By referring 117 studies, the 90 RE practices were discovered, 43 RE practices were retrieved from the RE practices suggested by Somerville and Sawyer by contacting 108 SDO industry experts through a questionnaire survey, and 14 additional RE practices were brought out by involving 106 SDO industry practitioners through another questionnaire survey. By conducting two Focus Group sessions and applying Numerical Assignment prioritization technique, in the first step, 147 RE practices have been divided in to High, Medium, and Low importance groups. In the second step, RE practices within each group have been ranked through the Hundred Dollar technique. The suggested RE practices can be employed to tackle the commonly recurring RE process issues in the context of SDO. As a result, the study not only helps to avoid adopting haphazard RE practices for resolving frequent issues, guaranteeing RE process improvement, but also serves to actualize the predicted SDO advantages. Now next step is to develop a model for coping with the RE process issues that arise commonly in the context of SDO. Supporting information S1 Appendix. Questionnaire employed for the 1st survey. https://doi.org/10.1371/journal.pone.0269607.s001 (DOCX) S2 Appendix. Results of the 1st questionnaire survey to identify Sommerville and Sawyer’s significant RE practices. https://doi.org/10.1371/journal.pone.0269607.s002 (DOCX) S3 Appendix. Questionnaire employed for the 2nd survey. https://doi.org/10.1371/journal.pone.0269607.s003 (DOCX) S4 Appendix. Comprehensive list of 147 RE practices to address SDO RE process issues. https://doi.org/10.1371/journal.pone.0269607.s004 (DOCX)
TI - Towards dealing with commonly occurring requirements engineering process issues during software development outsourcing
JF - PLoS ONE
DO - 10.1371/journal.pone.0269607
DA - 2022-07-14
UR - https://www.deepdyve.com/lp/public-library-of-science-plos-journal/towards-dealing-with-commonly-occurring-requirements-engineering-5mC5yfG80k
SP - e0269607
VL - 17
IS - 7
DP - DeepDyve
ER -