Model to cope with Requirements Engineering Issues for Software Development Outsourcing

The anticipated benefits of Software Development Outsourcing (SDO) are not achieved in case of several projects because of the issues that emanate from Requirements Engineering (RE) process. This research work presents a Requirements Engineering Practices (REP) model to cope with the customarily occurring issues of the RE process for SDO. To formulate the model, five workshops have been conducted and Root Cause Analysis has been performed by considering 43 commonly occurring SDO RE process issues, and 147 RE practices to tackle the issues. To discover the root causes for commonly transpiring issues, 5- Whys technique has been employed. The relevant RE practices that can be used to deal with the root causes, have been endorsed by applying Brainstorming technique. For the 43 frequently occurring issues, 89 root causes have been discovered. Afterwards, 124 relevant RE practices have been recommended to eradicate the root causes and hence to address the corresponding issues. Thus, REP model postulates the root causes for commonly occurring issues of the SDO RE process, maps the root causes to the relevant best RE practices to address the corresponding issues. The model has been evaluated by an expert panel and evaluation results have been analysed through Inter-Rater Reliability analysis and Analysis of Means. The REP model supports the RE process for SDO by i). evading the adoption of random and inappropriate RE practices for dealing with the common issues of the process, ii) helping to attain the expected benefits of SDO.


I. INTRODUCTION
Software Development Outsourcing (SDO) is a type of Information Technology Outsourcing in which some or all activities of the software development are contracted out by a client to the vendor(s) [1]- [4]. The idea of SDO is becoming prevalent rapidly [5]. SDO has several forms like vendor providing services at outsourcing location, Onshoring or Domestic Outsourcing, Nearshoring, Offshoring, Distributed Software Development (DSD) and Global Software Development (GSD). In these various scenarios, stakeholders are often physically scattered.
Software projects are outsourced owing to the associated benefits like cost reduction, availability of the specialized and high-class capabilities, process improvement, outsourcing no-core activities and freeing the internal resources [6]- [8]. However, many risks are involved in this process [9]. The failure rate of SDO projects is high as 40% of offshore projects did not manage to achieve the expected benefits [10] and half of the companies that tried GSD failed to attain the anticipated results [11] [12]. Industry surveys show that although SDO is becoming popular, but only half of the SDO projects are successful [13]. The studies show that Requirements Engineering (RE) related problems are one of the basic reasons for the failure of SDO projects as most of the factors contributing to such failures are related to the requirements [12] [14] [15]. According to Verner and Abdullah, the requirements cause the outsourced software development project to fail [16]. Meeting clients' requirements is a challenge in the case of offshore software development outsourcing [17]. Compromising on the quality of requirements can cause project failure [18]. The requirements errors are common for the offshore outsourced software development projects [5]. RE problems are the main reasons for the inefficient and failed software projects [19]. The geographical dispersion of the stakeholders is the basic source of issues during the RE process for SDO. This dispersion affects the RE process for SDO and introduces many issues for it [14] [20]. The delayed responses, unawareness from the effects of new system implementation, poorly defined requirements, and incomplete requirements are some of such important issues.
Therefore, objective of this study is to pave the way to attain the projected benefits of SDO and eradicate the common issues of SDO RE process by presenting a model to cope with the commonly occurring issues of SDO RE process. For this purpose, the frequently occurring or common issues of the SDO RE process need to be identified. Moreover, the root causes for the common issues must be exposed and the relevant RE practices must be recommended to eliminate the root causes for the issues. Thus, this research work intends to propose and evaluate a model called the Requirements Engineering Practices (REP) Model. In this context, these Research Questions (RQs) need to be answered: RQ1: Which are categories of the commonly occurring issues of the RE process for SDO? RQ2: Which are the commonly occurring issues of the RE process during SDO and which are categories of the issues? RQ3: Which RE practices can be followed to address commonly occurring issues of the RE process for SDO? RQ4: Which are the root causes for the commonly occurring issues of the RE process for SDO, and which are the relevant RE practices to eliminate the respective root causes?
The rest of the paper is organised as: related work has been discussed in Section II, Section III focuses on research steps followed, Section IV presents model formulation, Section V concentrates on model evaluation whereas Section VI concludes the work.

II. RELATED WORK
Several studies in the existing literature focus on the issues that come up during the RE process when stakeholders are geographically dispersed and addressing the issues. Thus, the related studies can be divided into three segments.

A. RE PROCESS ISSUES WHEN STAKEHOLDERS ARE GEOGRAPHICALLY DISTRIBUTED
The studies focusing on RE issues when stakeholders are geographically dispersed are:

1) FACTORS GENERATING RISKS DURING REQUIREMENT ENGINEERING PROCESS IN GLOBAL SOFTWARE DEVELOPMENT ENVIRONMENT
The factors and the risks which are generated from those factors during the RE process for GSD, have been identified in a study [22] by performing a systematic literature review and applying the grounded theory. The 74 discovered factors have been grouped into 8 categories: i) Communication and distance, ii) Cultural, organizational and time zone differences, iii) Knowledge management and awareness, iv) Management, v) Tools, technologies, and standards, vi) Stakeholders, vii) Project and process, and viii) Requirements.

2) IMPEDIMENTS TO REQUIREMENTS ENGINEERING DURING GLOBAL SOFTWARE DEVELOPMENT
An important study reports the results of case study regarding a large-scale project outsourced for software development with the stakeholders distributed to two distinct countries [23]. The study argues that: i) Electronic communication medium is required for achieving the economic benefits of GSD, ii) For an effective RE process and maintaining the long-term relationship with client during GSD, the cultural aspects of the RE should be addressed.
Further, the physical and cultural dispersion among the stakeholders creates many issues for GSD. To address such issues, the study provides several suggestions: i) Social exchanges among the stakeholders ii) Providing awareness about cultural diversities iii) Alleviating time pressure from developers iv) Providing access to the key users, and v) Appointing communication coordinators.

3) THE CHALLENGES OF DISTRIBUTED SOFTWARE ENGINEERING AND REQUIREMENTS ENGINEERING: RESULTS OF AN ONLINE SURVEY
The issues of the DSD and the distributed RE along with the countermeasures to address those issues, have been presented in a study [24]. For this purpose, an online questionnaire survey has been conducted with practitioners having DSD experience. According to the results, the issues of the distributed RE process are ambiguous requirements specification, using inconsistent terminologies or notations for requirements specification, incomplete requirements, changing requirements, incorrect requirements, inefficient RE processes, requirements prioritization, and a high number of stakeholders to elicit the requirements. The most frequently recommended solution to RE issues is the face-toface communication. The other suggested countermeasures are frequent communication, training, defining, and using a common glossary, testing requirements specification early, following standardized formats and defining the minimum standards to be followed.
The first issue is requirements elicitation when stakeholders are distributed. The recommended practices to address this issue are following common processes, encouraging shared responsibilities, and maintaining trust.
Second issue mentioned in the study is improper communication during the RE process. The approaches to deal with the issue of inadequate communication, in a distributed context, are: i) A well-defined organizational structure with clearly defined communication responsibilities ii) All the distinct sites should have peer to peer linkages at the management level, project level and teams' level iii) Inter-organizational processes should be synchronized to a possible extent, and contacts and deliverables should also be frequent iv) Cultural liaisons should also be appointed v) Maintaining open communication lines among the main stakeholders vi) Informing and monitoring progress on agreed upon artefacts.
The third issue is creating and maintaining an intense cooperation among the stakeholders. The suggestions to deal with this issue are: i) Creating communication links at earlier stages of the project ii) Using a standard language for communication like English iii) Appointing cultural liaisons, and iv) Establishing peer to peer linkages at all possible levels.

5) STAKEHOLDERS IN GLOBAL REQUIREMENTS ENGINEERING: LESSONS LEARNED FROM PRACTICE
According to D. Damian, the three challenges that arise when stakeholders interact during the global RE are: i) Attainment and sharing of the relevant knowledge ii) Alignment of the RE processes and supporting tools, and iii) Enabling useful communication and coordination among the distributed teams [26].
The relevant strategies to deal with these challenges are: i) A well-defined organizational structure with clearly defined communication responsibilities ii) All the distinct sites should have peer to peer linkages at the management level, project level and teams' level iii) Inter-organizational processes should be synchronized to a possible extent, and contacts and deliverables should also be frequent iv) Cultural liaisons should be appointed v) Maintaining open communication lines among the main stakeholders vi) Informing and monitoring progress on the agreed upon artefacts.

B. ADDRESSING RE PROCESS ISSUES WHEN STAKEHOLDERS ARE GEOGRAPHICALLY DISTRIBUTED
The studies to deal with the RE issues when stakeholders are geographically dispersed are:

1) SITUATIONAL REQUIREMENT ENGINEERING FRAMEWORK FOR GLOBAL SOFTWARE DEVELOPMENT
A situational RE framework has been proposed in [21] for identification of the situational factors and the most influential situational factors which affect the different activities of the RE process for GSD. The study focuses on the activities of requirements elicitation, analysis, specification, validation, and management. According to the results, the most influential situational factors for the various RE activities are understanding and stating requirements, clients, teams, stakeholders' mode of interaction, culture, characteristics of project, resources, evolution of requirements, estimations about requirements, technical maturity level, problem domain, standards, occurrence of defects and testing.

2) REQUIREMENTS SPECIFICATION IN DISTRIBUTED SOFTWARE DEVELOPMENT -A PROCESS PROPOSAL
An iterative requirements specification process has been proposed in a study [14] to address the issues that arise during the RE process in a distributed environment. The issues belong to the four categories of: i) Communication, ii) Culture, iii) Knowledge management, and iv) Technical aspects.

3) OVERCOMING REQUIREMENTS ENGINEERING CHALLENGES: LESSONS FROM OFFSHORE OUTSOURCING
Practitioners have shared their experiences about the challenges encountered during the RE process for the offshore SDO in [27]. Based on the 9 industrial case-studies, 9 challenges have been mentioned: i) Client and vendor have conflicting interests, ii) Lack of involvement from client side, iii) Client and vendor follow conflicting RE approaches, iv) Client does not fulfil commitments, v) Conflicts on selection of the tools, vi) Communication lapses, vii) Vendor disowns responsibilities, viii) Signing-off issues regarding the RE deliverables, and ix) Selected tools are different from the expectations.
Based on the Root Cause Analysis, the 5 success factors have been identified to deal with these challenges: i) Setting the common goals, ii) Adopting the shared culture, iii) Following the shared processes, iv) Sharing the responsibilities, and v) Maintaining trust.

4) GLOBREQ: A FRAMEWORK FOR IMPROVING REQUIREMENTS ENGINEERING IN GLOBAL SOFTWARE DEVELOPMENT PROJECTS: PRELIMINARY RESULTS
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Another study on GSD [12] describes the methodology and the preliminary results for the development of GlobReq which is a framework to improve the RE process for GSD. GlobReq is based on the 66 RE practices recommended by Sommerville & Sawyer, and empirical studies with the organizations which deal with GSD. The four categories of the perceived benefits of the RE practices for GSD are High, Medium, Low, and Zero.

C. THE OTHER LATEST STUDIES RELATED TO GEOGRAPHICALLY DISTRIBUTED STAKEHOLDERS
A study extricates and categorises 43 commonly occurring arising issues of SDO RE process [28]. The SDO RE process issues have also been ranked based on the frequency of occurrence.
Shafiq et al. identify and validate the 25 success factors for RE process in the case of offshore SDO [29]. Another study evaluates, with respect to productivity and cost abatement, the impact of requirements associated local decisions on the software customization in the DSD context [30]. A study introduces a tool-based approach to support RCM in case of Agile DSD [31]. Another study identifies 15 challenges for quality requirements in the context of large DSD agile projects, and also presents 13 mechanisms and 9 practices for addressing the challenges [32]. A study suggests well-ordered domain ontology to support specifically RCM process for GSD [33]. Akbar et al. explore 46 best practices for RCM in the case of GSD with respect to client GSD organizations and vendor GSD organizations [34]. Another study identifies 31 RCM process challenges for GSD and further classifies challenges with respect to organization size and type [35]. Ali and Lai recommend a three-step method for abetment of requirements changes in the case of GSD [36]. A study explores and analyses success factors that affect requirements implementation in the case of GSD [37]. Shafique et al. emphasize the significance of project management in the case of RE and RCM processes for GSD by recommending and validating two frameworks [38].
Nicolos et al. present 218 risks for GSD RE process and suggest 146 safeguards against the risks [39]. Through a framework, Arif et al. explore the effect of geographical, cultural and temporal distances on the communication during RCM in the case of GSD [40]. Based on a graph generated from requirements, another study presents a method to specify and validate requirements specifically for the GSD projects [41]. Another study presents 13 practices to enable fruitful communication for requirements elicitation in the GSD context [42]. A study identifies, validates, and quantifies the RCM process barriers for GSD [43]. Shafiq et al. have found 14 obstacles for RE process in the case of Offshore SDO and have prioritized the obstacles through Analytical Hierarchy Approach [44]. Considering three parameters of weight, vote and priority of stakeholder, another study proposes a two-stage prioritization technique for prioritizing requirements especially in the GSD context [45]. Shameem et al. suggest and validate a model to inspect the impact of requirements volatility on the success of GSD projects [46]. Ali et al. analyse the factors which are vital for fruitful communication during requirements elicitation in the case of GSD projects [47].
Founded on block-chain, Gull et al. introduce a framework to deal with conflicting requirements in the GSD context [48]. Kamal et al. explore 21 success factors for Agile RCM and prioritize the factors by employing Analytical Hierarchy Approach [49]. Another study presents the Software Requirements Engineering Maturity Model to evaluate and quantify RE process preparedness in the case of offshore SDO [50]. A study presents 14 requirements reuse challenges for large agile DSD projects and 10 strategies to deal with those challenges [51]. By identifying 32 communication issues and 28 mitigation RE practices, another study presents a framework to deal with communication issues for RE process in GSD context [52].
Thus, the RE process for SDO involves various types of issues. The analysis of the related studies shows that the studies partially deal with such issues and their solutions. Moreover, no study presents the root causes for the occurrences of the common issues of RE process for SDO, and RE practices to eliminate the root causes. This deficiency of the existing literature hinders the proactive project planning in the case of SDO. Therefore, this research work presents a model for addressing the commonly occurring issues of the RE process for SDO by discovering the root causes for commonly occurring issues, and by identifying and mapping the best RE practices to eradicate the corresponding root causes. Hence, the proposed model addresses commonly occurring issues for SDO RE process.

III. RESEARCH STEPS
The REP model has been formulated by following 3 steps: i) Step 1: Extracting the commonly occurring issues of RE process in the case of SDO and identifying categories of the issues.
ii) Step 2: Finding RE practices, from the literature and the industry, which can be utilized to deal with commonly occurring issues of RE process in the case of SDO. iii) Step 3: Identifying the root causes for the commonly occurring issues of RE process in the case of SDO, and recommending and mapping the relevant RE practices to eliminate respective root causes and hence to address the corresponding issues. Figure 1 depicts three steps of the research.

IV. MODEL FORMULATION
The objective of this research work is to formulate REP model to address the frequently occurring issues of RE process for SDO. To achieve the objective, academic and industrial perspectives have been combined. Therefore, in first step frequently occurring issues of SDO RE process have been extracted by exploring contemporary literature and This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.

A. STEP 1: EXTRACTING THE COMMONLY OCCURRING ISSUES OF RE PROCESS IN CASE OF SDO AND IDENTIFYING CATEGORIES OF THE ISSUES
The 150 issues of the RE process for SDO and seven categories of the issues have been identified [53]. The seven categories of the issues are: i) Communication(C1), ii) Management and coordination(C2), iii) Knowledge management and awareness(C3), iv) Requirements centric(C4), v) Cultural diversities(C5), vi) Processes and tools(C6), and vii) Relationship among stakeholders(C7). This answers RQ1 of the study. Out of the 150 issues, 43 issues have been extricated as commonly or frequently occurring issues for SDO RE process [53]. The 43 frequently occurring issues have been denoted by I1, I2, I3, ..., I43 whereas issues I1 to I6 belong to Communication category; I7 to I11 belong to Management and coordination category; issues I12 to I18 belong to Knowledge management and awareness category; I19 to I27 are Requirements centric issues; I28 to I32 belong to Cultural diversities category; I33 to I37 belong to Processes and tools category; and I38 to I43 belong to the category of Relationship among stakeholders. Table I shows number of frequently occurring issues in each category. Knowledge management and awareness 7 4.
Relationship among stakeholders 6 Total 43 The 43 frequently occurring issues are I1: Deferred replies. I2: Deficiency of casual correspondence amongst the shareholders. I3: Typically, there is non-recording of the promises that are done amid videoconferencing or discussions on the telephone, consequently such pledges cannot be alluded when needed. I4: Deficiency of synchronized correspondence. I5: Occasional and controlled correspondence amongst the shareholders. I6: The gatherings that are held for making decisions regarding requirements are fruitless. I7: Postponement in elucidations regarding requirements and finalizing decisions. I8: Failure in performing RE associated assignment(s) as everyone believes this is obligation of another person. I9: Improperly defined or vague obligations. I10: Complications in grasping evidences, motives and actions needed for mutual Requirements Understanding amongst the scattered shareholders. I11: Genuine requirements are needed to be altered to interface with different software systems. I12: Inadequate management of the modifications in requirements. I13: Unfamiliarity of the shareholders from existing/recent data regarding requirements. I14: Unfamiliarity with or not consulting all the origins of requirements. I15: Reviving of the previously conversed and apparently resolved issues. I16: Requirements engineers are ignorant of the impacts of novel system deployment upon customer's organization. I17: Operating on the outdated requirements. I18: Obstacles in flow of requirements related information towards organization or from organization. I19: Customers emphasis on including more requirements whereas cost and schedule have been settled. I20: Not giving data or giving deliberately vague data about requirements. I21: Confirming requirements in case of all shareholders relying on the requirements collected or data acquired only from the accessible shareholders. I22: Analysts are influenced to conceal certain data associated with requirements that grounds for compromises to elicit and describe the requirements. I23: Uncompleted requirements. I24: Goldplated or additional requirements. I25: Applying presumptions to confirm or conclude requirements. I26: This completes Step 1 of the study and answers RQ2.

B. STEP 2: FINDING RE PRACTICES TO DEAL WITH COMMONLY OCCURRING ISSUES OF RE PROCESS IN THE CASE OF SDO
The consolidated list of 147 RE practices has been prepared to address the frequently occurring issues of RE process in the case of SDO [53]. The 147 RE practices numbered as 1, 2, 3, …, 147 have been presented in Appendix A. This concludes Step 2 of the study and answers RQ3.

C. STEP 3: DEALING WITH THE COMMONLY OCCURRING ISSUES OF SDO RE PROCESS
The Root Cause Analysis method has been employed to find the root causes for the frequently occurring issues of RE process for SDO. Then, the relevant RE practices have been recommended to eradicate the corresponding root causes and hence to address respective issues.

1) ROOT CAUSE ANALYSIS
Root Cause Analysis (RCA) method is used in numerous fields to handle the problems by focusing on knowing root causes for occurrence of those problems and by recommending preventive or corrective actions to deal with the corresponding problems [54] [55]. A Cause or Casual Factor is a condition or an event that creates an effect [56]. Sequence of Events is a cause-andeffect sequence in which a condition or event results in an event or condition that in turn creates a new condition or event and so on [56]. A cause is called Root Cause if its correction prevents its recurrence and that of other unwanted results [56]. According to Lehtinen et al. [57], Root Cause is the deepest cause at the end of casual structure and as per another definition [54], Root Causes are underlying causes. RCA method comprises of three steps: i) Detecting problems: To define the problems or issues. ii) Detecting root causes: To discover the root causes of problems or issues.
iii) Recommending corrective actions: To recommend the actions to be taken or practices to be followed in order to correct or address the issues [57].

2) DETECTING THE PROBLEM(S)
The 43 frequently occurring issues of RE process for SDO have been extracted out of 150 issues (section 4-A) like [58]. To find the root causes for the frequent occur-ring issues of RE process in case of SDO and recommending RE practices to address those issues, root cause analysis workshops have been conducted like [58] [59]. a) Root Cause Analysis workshops: Five workshops were held, one in a week, and three participants contributed to each workshop. Among the three participants, one was researcher and two were SDO practitioners having 10-and 12-years' experience respectively. The researcher also acted as moderator or facilitator during the workshops. The agenda of each workshop was available to participants in advance. Each workshop was continued approximately for 4 hours (2 sessions, each session of 2 hours). Thus, total duration of workshops was 20 (5x4) hours. As, there were three participants; so, actual effort to apply RCA method was 60 (20x3) man-hours.

3) DETECTING ROOT CAUSES
Many techniques are available that can be used to discover the root causes for frequently occurring issues of RE process for SDO like Cause-Effect Analysis, Fault-Tree Analysis, Causal Factor Charting, Brainstorming and 5 Whys [55]. In this research work, 5 Whys technique has been employed.
a) The 5 Whys Technique: The 5 Whys technique is based on asking the questions to find the root cause(s) [55]. While applying this technique up to 5 questions, all starting with why, are raised and answered [60]. The answer of first why-question leads to second why-question, answer of the second why-question guides to third why-question and so on. This process is continued till the discovery of root cause(s). Generally, first why-question is to know why an issue is occurring. For example, an issue may be that some of the team members are not using recommended software. To apply the 5 Whys technique, first why-question is: Why-Question-1: Why team members are not using recommended software? The likely answer is because they do not like it. From this answer, second why-question can be formulated as: Why-Question-2: Why team members do not like software?
The answer may be that for some team members this software is not easy to use, and it requires information that all team members do not have. From this answer, two whyquestions are generated. The first one is: Why-Question-3.1: Why software is difficult to use for some team members? The probable answer is that they have not been trained for using this software.
So, one root cause has been discovered by using just three Why-questions and the root cause is not providing training to team members. The second question generated from the answer of second why-question is: Why-Question-3.2: Why some team members do not have required information to use software? The possible answer is that they do not have access to that information. Thus, another root cause has been identified again just by asking three why-questions. The root cause is that team members do not have access to the relevant information. The sequence of Why-questions has been shown in Figure 2.

FIGURE 2. Steps to find root causes through 5 whys technique
The 5 Whys technique has been used in similar way to determine the root cause(s) for each of the frequently occurring issue of the RE process for SDO. Thus, 89 root causes have been discovered for the 43 frequently occurring issues of RE process for SDO [53]. The 89 root causes numbered as 1, 2, 3, …, 89 have been presented as Appendix B.

4) RECOMMENDING THE CORRECTIVE ACTION OR RE PRACTICES TO ADDRESS ISSUES
The relevant RE practices, which can be used to address the frequently occurring issues, have been recommended and mapped to corresponding issues by applying Brainstorming technique like another study [57]. a) Brainstorming: During the Brainstorming as many ideas are gathered about the subject as possible and all participants are encouraged to present ideas without any criticism [55] [60]. For this research work 147 RE practices have been collected, from relevant literature and SDO industry (Appendix A), to address the frequently occurring issues of SDO RE process. Those RE practices have been presented during the brainstorming sessions, some technical reports and research papers have also been consulted, and then the best available RE practices have been selected and mapped to corresponding issues by using multi-voting like method. Six Brainstorming sessions have been held, and three participants have contributed to each session. Among the three participants, one was researcher and two were SDO practitioners having 10-and 12-years' experience respectively. The researcher has also acted as moderator or facilitator during the Brainstorming sessions. Each session continued approximately for 2 hours.
By performing RCA, 89 root causes have been discovered (Appendix B) for the 43 frequently occurring issues of RE process for SDO. For the 89 root causes, 124 relevant RE practices have been recommended to remove the corresponding root causes and hence to address the respective issues.
The 124 RE practices denoted by P1, P2, P3, …, P124 have been presented in Appendix A whereas the 89 root causes denoted by RC1, RC2, …, RC89 have been presented in Appendix B. This completes Step 3 of the study and answers RQ4. By integrating the results of the Step 1, Step 2 and Step 3, REP model is formulated.

D. THE REP MODEL
The 43 frequently occurring issues of the RE process for SDO, root causes for occurrence of the issues and the relevant RE practices to address the corresponding issues have been presented in the Table II. The seven categories of the issues have been represented by C1, C2, …, C7. The I1, I2, I3, …, I43 represent the 43 frequently occurring issues of RE process for SDO. The RC1, RC2, RC3, …, RC89 represent 89 root causes. The P1, P2, P3, …, P124 represent 124 RE practices to eliminate corresponding root causes and hence to address the respective issues. This accomplishes formation of the REP Model. Figure 3 shows relationships among the various units of REP Model.

1) RELATIONSHIP AMONG THE UNITS OF THE REP MODEL
As Figure 3 shows, there are four basic units of the REP Model: i) Categories of issues, ii) Issues, iii) Root Causes, and iv) RE Practices.
For a category, CATId represents category identification, CATName denotes name of the category, CATRank shows rank of the category with respect to other categories and CATNoOfIss indicates no. of the frequently occurring issues in the category.    , P42  RC33  P34  RC34  P41, P101, P42, P22  I13  RC1  P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11,  P12, P13, P14, P15, P16, P17   RC35  RC36  RC37   P34, P35, P36   I14  RC38  P45, P57, P100  RC39  P58, P118  I15  RC40  P1, P2 For an issue, IssId represents identification of a frequently occurring issue, IssCat denotes category of the frequently occurring issue, IssCatRank shows rank of the frequently occurring issue in the respective category whereas IssOveRank indicates overall rank of the frequently This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3182393 occurring issue with respect to frequently occurring issues of all the categories.
For a root cause, RCId represents root cause identification and IsssToACaus indicates issues which are caused by the root cause.
For a RE practice, REPId represents identification of RE practice and RCsToAdd shows root causes which are addressed by the requirements engineering practice. The REP Model diagram shows that there are the four scenarios of the RE process for SDO (S1, S2, S3 and S4) that may encounter a RE process issue say I. There are seven categories of the issues 9of RE process for SDO (Communication, Management and coordination, Knowledge management and awareness, Requirements centric, Cultural diversities, Processes and tools, and Relationship among stakeholders) and 43 frequently occurring issues of RE process for SDO (I1, I2, I3, …, I43) belong to these seven categories. The issue I may be any one of these 43 issues. To address an issue, root cause(s) for the issue must be known. So, next step is to identify root cause(s) for the issues. The RC1, RC2, RC3, …, RC89 are 89 root causes for 43 frequently occurring issues. For example, there are three root causes for issue I1 that are RC1, RC2 and RC3. The issue I1 may occur because of RC1 or RC2 or RC3 or (RC1 and RC2) or (RC1 and RC3) or (RC2 and RC3) or (RC1 and RC2 and RC3). Similarly, the issue I may occur because of one or more root causes that can be identified from the root causes given for that particular issue.

2) THE REP MODEL DIAGRAM
For addressing an issue, after identification of the root cause(s) for the issue, next step is to adopt the relevant RE practices to eradicate the issue. The 124 RE practices have been recommended for this purpose that are P1, P2, P3, ..., P124. In case of the issue I1, for the root cause RC1, 17 RE practices have been recommended that are P1, P2, P3, …, P17; for RC2 four RE practices have been recommended that are P7, P8, P9, and P10; and for RC3 three RE practices have been recommended that are P2, P18 and P73. Likewise, the issue I can be addressed by adopting one or more relevant RE practices that can be selected from the RE practices recommended for that particular issue, keeping in view the root cause(s) for the issue.

3) DEFINITIONS AND PROPERTIES
Basic definitions and properties used during formation of the REP Model are: i) Definition 1: An Issue is defined as "A matter that is in dispute between two or more parties" [61] or "A problem that people are thinking and talking about" [62].
So, a Requirements Engineering process issue denoted by "Ii" can be defined as the problem about which practitioners think or talk about during Requirements Engineering process and which can create dispute among the parties involved.
Let I be set of all the frequently occurring issues of RE process for SDO, then I = {Ii} where i = {a: a∈N∧1 ≤ a ≤ 43} ∧ N = Set of Natural Numbers ii) Definition 2: A Category is defined as "a class or division of things having common characteristics" [63].
Using Definition 1, Category of Issues can be defined as.
A Category of Issues denoted by "Cz" is a class or division of issues (issues of Requirements Engineering process for Software Development Outsourcing) having common characteristics. iii) From definition 2, following property of the "REP Model" can be derived.
A cause is called Root Cause denoted by "RCy" if its correction prevents its recurrence and that of other unwanted results [56].
Let So ∃!Ii , ∃RCy : ∃!Ii ⇒ ∃RCy And ∃!RCy , ∃Ii : ∃!RCy ⇒ ∃Ii ∀ y = (1,2,3,...,89) ∧ i = (1,2,3,..., 43) vii) Definition 4: A Practice is defined as "The action or process of doing something" [64] or "A way of doing something that is usual or expected in a particular situation" [63] or "Repeated performance or systematic exercise for the purpose of acquiring skill or proficiency" [64]. According to IEEE definition "A software requirement is a condition or capability which is needed by a user to solve a problem or achieve an objective, and it must be met or possessed by a software system or system component" [65].
Thus, Requirements Engineering Practices denoted by "Ps" are the actions which are per-formed customarily during Requirements Engineering process to successfully: i) Collect, write, validate, and organize software requirements, ii) Avoid or eliminate the problems that arise or are expected to arise during software requirements' collection, documentation, validation, and organization.
Let P be the set of all the Requirements Engineering Practices that can be used to address the frequently occurring issues of SDO RE process, then P = {Ps} where s = {d: d ∈ N ∧ 1 ≤ d ≤ 124} ∧ N = Set of Natural numbers viii) From Definitions 3 and 4, following property can be derived:

Property 4:
To address one root cause, one or more Requirements Engineering Practices can be recommended, and one Requirements Engineering Practice can be recommended to address one or more root causes.

V. REP MODEL EVALUATION
This section presents the evaluation of REP model. The expert judgment technique has been used for evaluation.

A. CRITERIA FOR DEVELOPMENT OF THE REP MODEL
The main purpose of this research work is development of a: i. Comprehensive (complete), ii. Practical (easy to adopt), and iii. Useful (beneficial to address issues) model to address the frequently occurring issues of SDO RE process for assisting the academicians, researchers and SDO practitioners. The criteria of completeness, practicality and usefulness have been considered for model evaluation as they cover all the aspects of a pragmatic and effective model to address the common issues of SDO RE process issues.

1) COMPLETE
By 'Complete' means that the model covers almost all the relevant categories of the frequently occurring issues of RE process for SDO, almost all the frequently occurring issues, sufficient root causes for occurrence of corresponding frequently occurring issues and sufficient RE practices to address corresponding frequently occurring issues.

2) PRACTICAL
By 'Practical' means that for each frequently occurring issue of RE process for SDO, corresponding root causes and RE practices have been clearly defined and are unambiguous. Further, in case of each frequently occurring issue, recommended set of RE practices is easy to adapt in most of scenarios without any special arrangements.

3) USEFUL
By 'Useful' means that for each frequently occurring issue of RE process for SDO, given set of root causes is beneficial enough to explore RE practices for addressing corresponding issue, and recommended set of RE practices is beneficial enough to address corresponding issue. Additionally, proposed model is beneficial enough to support RE process for SDO.
The model is evaluated through the expert panel of researchers, academicians, and practitioners. For evaluation, 'Completeness', 'Practicality' and 'Usefulness' are the three criteria. The experts have evaluated the model against the three criteria by using a 7-point Likert Scale. The expert panel evaluation is analyzed by performing i) Inter-Rater Reliability analysis through the calculation of Cohen's kappa coefficient (k), and ii) Analysis of Means (ANOM). Figure 5 highlights the evaluation process for the REP Model. The REP Model evaluation process is described step by step.

B. THE REP MODEL EVALUATION THROUGH THE EXPERT PANEL
Experts and practitioners having diverse backgrounds and relevant experience are recommended for an effective evaluation [66]- [68]. Therefore, experienced SDO practitioners and academicians with varied backgrounds have been engaged for evaluation of the REP Model. The efficacy of evaluation through experts, in a field, is widely recognized [69] [70] and numerous fields like medicine, building construction, operational research, sports, computer science, agriculture and sociology etc. are benefited momentously from it [68] [71]- [74].
The small number of experts can be used for development and testing [75]. For example, in the studies [70] [76] [77], three experts have been employed for review and evaluation. Similarly, in this research work for evaluation of the REP Model, an expert panel of three experienced academicians and researchers has been involved. Out of three experts, two possess industrial experience as well. Two experts have more than 10 years' experience whereas one expert has more than 15 years' experience. Table III provides details about the experts.

C. CONDUCTING THE REP MODEL EVALUATION THROUGH EXPERTS
An online questionnaire survey has been conducted to evaluate the REP Model through expert panel. Guidelines provided in study [78] have been used to design and conduct the survey.

1) DATA COLLECTION
The online questionnaire, provided in Appendix C, has been used for the REP Model evaluation through expert panel. The model, link to online survey-questionnaire and related information have been emailed to three experts. The survey has been conducted by using semi-supervised approach [79].

Survey's objectives and respondents' queries have been made clear through Computer-Assisted Telephone
Interviewing technique [80].

2) QUESTIONNAIRE FORMAT
The questionnaire contains two parts. The purpose of the first part is to collect data about the experts' experience, job nature and respective organizations. The second part is meant for evaluation of the REP Model. To improve the questionnaire layout, assess the language comprehension and estimate the time required to complete the questionnaire, two rounds of pilot study have been conducted. Recommendations have been incorporated after the first round. The second round has been carried out to ensure that the changes made are according to the given suggestions.

3) SAMPLING AND POPULATION
The Convenience Sampling method has been employed for obtaining a valid sample of respondents. The convenience Sampling method is used when participants are selected based on availability and accessibility [81]. For model evaluation, Convenience Sampling method has been used because keeping in view expert selection criteria only limited number of experts were available. Therefore, only the available and accessible experts have been targeted for evaluation.
Seven experts having research and academics background with at least 10 years' experience have been invited to participate in the model evaluation. But only three of them have shown their willingness to participate in the evaluation. Demographic information of those three academicians and researchers has been provided in Table III.

4) RESPONSES
The experts have been solicited to answer the survey questions by using the seven-point Likert Scale. All the three academicians and researchers have performed evaluation based on given criteria. Out of the 3 experts, one expert has given suggestions for improvement. The suggestions have been accommodated and relationship diagram has been sketched to show relationship among the instances of the various units of REP Model. The expert has been requested to perform evaluation again.
The seven-point scales provide better reflection of the respondents' point of view and are considered more accurate and easier to use [82] [83].

D. DISCUSSIONS AND RESULTS OF THE REP MODEL EVALUATION
For the REP Model evaluation through experts, an online questionnaire survey has been conducted. The results have been presented in Table IV. Figure 6 shows evaluation results for 'Completeness' criterion.
There are four questions to evaluate the criterion of 'Completeness'. Q1 is 'The proposed model deals with all the relevant categories for the frequently occurring issues of RE process for Software Development Outsourcing'. Q2 is 'The given set of issues contains almost all the frequently occurring issues of RE process for Software Development Outsourcing'. Q3 is 'Each set of Root Causes contains sufficient Root Causes for the occurrence of the corresponding Issue'. Q4 is 'Each set of Requirements Engineering Practices contains sufficient Practices to address the corresponding Issue'. This can be observed from the Figure 6 that in case of Q1, Q3 and Q4, all experts 'Agree Strongly'. For Q2, all experts 'Agree Moderately'. It indicates that the model deals with all the relevant categories of frequently occurring issues, contains almost all the frequently occurring issues, each set of Root Causes contains sufficient root causes and each set of RE practices contains enough practices to address corresponding issue. Figure 7 shows evaluation results for 'Practicality' criterion. For evaluation of the 'Practicality' criterion, three questions (Q5, Q6 andQ7) have been designed. Q5 is about clarity and unambiguousness of each set of Root Causes. According to Figure 7, all experts 'Agree Strongly' that each set of Root Causes has been clearly defined. Q6 is related to clarity and unambiguousness of each set of recommended RE practices. Like Q5 again experts 'Agree Strongly'. This proves that given sets of Root Causes and RE practices have been clearly defined and are unambiguous. Q7 deals with the adaptability of each set of recommended RE practices in different situations. Two experts 'Agree Slightly' but one expert 'Agree Moderately' that each set of RE practices is easy to adapt in the most of scenarios. This may be because of the fact that various organizations prefer to follow certain practices and do not utilize certain practices because of the organizational rules and structures.   This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.  To evaluate the criterion of 'Usefulness', there are three questions (Q8, Q9 and Q10). The Q8 is to judge that in case of the each frequently occurring issue, the given set of Root Causes is how much beneficial to explore the RE Practices for addressing corresponding issue. According to Figure 8 all the experts 'Agree Strongly' that in case of each issue, the given set of Root Causes is beneficial enough to explore the RE Practices for addressing corresponding issue. This proves the usefulness of given set of Root Causes in case of each issue. Through Q9 it has been inquired that in case of each issue, the recommend set of RE practices is how much beneficial to address the corresponding issue in case of each corresponding root cause. Again experts 'Agree Strongly' that endorsed sets of RE practices can address the corresponding issues. It helps to determine the usefulness of the recommended set of RE practices in case of each issue and each respective root cause. The last question (Q10) is regarding usefulness of the overall REP Model for RE This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3182393 process during SDO. This is evident from the Figure 8 that while agreeing strongly, experts are of the point of view that the model supports RE process for SDO.
To analyze the level of consensus among the three experts, Inter-Rater Reliability analysis has been performed.

1) INTER-RATER RELIABILITY ANALYSIS
To measure the degree of consensus among the three experts, Cohen's kappa coefficient (k) has been calculated for each pair of experts. Kappa coefficient helps to measure the degree of agreement between evaluators [84] [85]. Usually, Kappa coefficient's value greater than .60 is considered an acceptable degree of agreement between experts [86]. Table  V, VI, VII, VIII, IX, and X show results of Inter-Rater Reliability Analysis. Table V shows cross tabulation for Academician&Researcher1 and Academician&Researcher2.            Kappa coefficient for Academician&Researcher1 and Academician&Researcher3= 1.00 Kappa coefficient for Academician&Researcher2 and Academician&Researcher3= . 71 It is already known that usually Kappa coefficient's value greater than .60 indicates an acceptable degree of agreement between experts [83]. This confirms the 'Completeness', 'Practicality', and 'Usefulness' of the REP Model according to perception of experts.

2) ANALYSIS OF MEANS (ANOM)
To analyze whether the means of responses from an expert are statistically different from the overall mean or not, Analysis of Means (ANOM) has been performed. The tool 'Q1 Macros for Excel' has been used for performing ANOM. a) ANOM for criterion of 'Completeness' Figure 9 shows ANOM plot for 'Completeness' criterion covering questions Q1, Q2, Q3 and Q4. Figure 9 shows that Upper Decision Line (UDL) is at 1.82, Lower Decision Line (LDL) is at .68 whereas Central Line (CL) representing mean of means is at 1.25. This can be observed from the Figure 9 that in case of all the three This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and   Figure 10 shows ANOM plot for 'Practicality' criterion covering questions Q5, Q6 and Q7. Figure 10 shows that Upper Decision Line (UDL) is at 3.00, Lower Decision Line (LDL) is at .11 whereas Central Line (CL) representing mean of means is at 1.56. This can be observed from the Figure 10 that in case of all the three academicians and researchers, means fall within the Upper Decision Line and Lower Decision Line limits. Thus, it can be concluded that no individual mean differs from overall mean and all respondents are inclined towards the practicality of the proposed model. c) ANOM for criterion of 'Usefulness' Figure 11 shows ANOM plot for 'Usefulness' criterion covering questions Q8, Q9 and Q10. Figure 11 shows that Upper Decision Line (UDL) is at 1.00, Lower Decision Line (LDL) is also at 1.00 whereas Central Line (CL) representing mean of means is also at 1.00. This can be observed from the Figure 11 that in case of all the three academicians and researchers, means (all three at 1) fall inside the Upper Decision Line and Lower Decision Line limits. Thus, it can be concluded that no individual mean differs from overall mean and all respondents are inclined towards the usefulness of the proposed model. d) Overall ANOM Figure 12 shows overall ANOM plot covering all questions that are Q1, Q2, …, Q10. Figure 12 shows that Upper Decision Line (UDL) is at 1.65, Lower Decision Line (LDL) is at .88 whereas Central Line (CL) representing mean of means is at 1.27. This can be observed from Figure 12 that in case of all the three This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3182393 academicians and researchers, means fall inside the Upper Decision Line and Lower Decision Line limits. Thus, it can be concluded that no individual mean differs from overall mean and all respondents are inclined towards the completeness, practicality and usefulness of the proposed model. The primary focus of this research work is to propose a Requirements Engineering Practices (REP) model to address the common issues of SDO RE process. For this purpose, by performing Root Cause Analysis and by employing 5-whys technique, 89 root causes have been discovered for the occurrence of the 43 common issues of SDO RE process. To perform Root Cause Analysis, 5 workshops have been held This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. The REP model has been evaluated by the expert panel of three researchers and academicians through an online questionnaire survey and by employing a 7-point Likert scale. Out of three experts, two also possess industrial experience. The criteria for evaluation are: i) completeness, ii) practicality, and iii) usefulness. The analysis of the evaluation results by performing i) Inter-Rater Reliability analysis through the calculation of Cohen's kappa coefficient (k), and by ii) Analysis of Means (ANOM) proves that REP model satisfies the defined criteria. Thus, the REP model assists in materializing predicated benefits of SDO and also supports SDO RE process by avoiding the adoption of adhoc RE practices through recommendation of the best RE practices for dealing with the common SDO RE process issues.

Practices Recommended
After Root Cause Analysis

P1
Establishing proper infrastructure to facilitate communication and ensuring that it works properly.

P2
Encouraging Synchronous communication in form of chatting, telephone calls, and videoconferencing 3

P3
Adapting and understanding the culture of other stakeholders means knowing about the traditions, beliefs, ethos and native language. 4 P4 Deciding and using a standard language for communication.

P5
Focusing on improving the communication language, for example, offering English language courses.

P6
Appointing cultural liaisons or Proxies (individuals who are familiar with the culture of client and vendor).

P7
Establishing 'proximity development center' in the region having no or a little time zone difference from the region of client. 8

P8
Trying to find natural overlapping of working hours. 9 P9 Assessing 'around-the-clock' capability of working.

P10
Achieving time zone proximity through time-shifting (changing one's working hours in order to overlap with other's working hours) for which different approaches are: i) Flextime (working at flexible timings to overlap). ii) Overtime (working for extra time to overlap). iii) Telework (working with flexible schedules from residence to overlap). iv) Long working days (availing working time overlap either at start of day or at end of the day). v) Unrestricted working hours (there are no restricted working hours and employees set their own working hours to overlap).

P11
Equipping remote practitioners' rooms with electronic message "drop in", remote calling and artifacts sharing facilities.

P12
Facilitating socialization among the practitioners from the beginning of the project, like arranging face-to-face start-off meetings to establish personal relationships. 13 P13 Arranging traveling to remote sites frequently in order to build trust. 14 P14 Facilitating direct communication among the stakeholders.

P15
Ensuring that stakeholders introduce themselves to one another right from beginning of the project. 16

P16
Encouraging communication in the native language of client. 17 P18 Promoting the use of groupware tools.

P19
Persuading the stakeholders that revealing the issues or providing information will not have negative fallouts instead will have positive consequences. 19 P20 Scheduling video conferences or teleconferences daily, weekly, bimonthly, monthly so

Practices Recommended
After Root Cause Analysis

Literature-based Practices to address the issues of RE process issues for SDO
that there are no or minimal inconvenient hours for all the stakeholders.

P21
Arranging requirements engineering meetings by: i) Engaging a human facilitator and using a rich communication media that supports integration of data, videos and audios. ii) Preparing agenda and following it. iii) Selecting relevant participant and informing them timely to take part in requirements meetings. iv) Timely exchanging supporting documents to give participants enough time to read the relevant material. v) Enabling participants of requirements meetings to access the resources ( Regularly checking and notifying the progress about mutually agreed upon artifacts.

P34
By using an awareness support system for requirements management, all the stakeholders should be able to access following information: i) Requirements' descriptions, rationale and priorities. ii) Dependencies among the requirements and with design, coding and testing. iii) Each team member's responsibilities with respect to particular requirement(s) and contact information like email, phone number. iv) Requirements' initiators. v) Issues related to requirements, issues' initiators, status of the resolution of those issues and decisions taken due to issues. vi) Meetings' date, time and location, stakeholders that are involved, discussed issues and decisions taken. vii) Change requests, initiators of change request, status of the decisions about those requests, people involved in taking decisions and decisions taken. 33

P35
Keeping experienced practitioners in team and those practitioners should bridge the awareness gap. 34 P36 Implementing centralized communication structure.

P37
Describing summary of proceedings after every meeting. A team member or facilitator should summarize that which issues have been raised during the meeting, what has been decided about each issue, which issues are pending, whose responsibility is to find out further information and whose advice should be sought in case of each issue.

P42
Using a Requirements Management System (to control and track changes) that provides following feature: i) Navigating given set of requirements, retrieving specific requirements and grouping requirements based on certain parameters. ii) Management of requirements change process, requirements traceability support and generation of the various types of reports about requirements. iii) Interface to accept external documents. iv) Management of the various versions of requirements. v) Support for performing different types of analysis (like impact analysis, to know a requirement is orphan or not, for tracking of status).

Practices Recommended
After Root Cause Analysis

Literature-based Practices to address the issues of RE process issues for SDO
vi) Restricting rights to access and edit the given set of requirements.

P43
Informing the relevant stakeholder about the requirements change: i) Through the telephone calls, emails and internet supported communication tools. ii) By generating automatic notifications through the system.

P58
In case of high number of stakeholders: i) Appointing a person (communication channel) from each unit of organization or group of requirements information sources for gathering the requirements from respective unit or group. Then communication channels transfer requirements to an expert where these requirements can be bundled. ii) Using group elicitation techniques like group Brainstorming, JAD (Joint Application Development), Focus groups and requirements creativity workshops for getting consensus on requirements. iii) Preparing a combined requirements document containing all the requirements.

P59
Taking following measures to overcome cultural issues: i) (P6) Appointing cultural liaisons or Proxies (individuals who are familiar with the culture of client and vendor). ii) Encouraging team members to visit locations of other stakeholders. iii) Arranging the cultural trainings. iv) Conducting orientation courses for cultural differences. v) Keeping in view cultural values of stakeholders while deciding females' roles. vi) Adopting 'Negotiated Culture', a compromised culture that is developed to honor the cultural norms of all the stakeholders. vii) Nominating the individuals, who are experienced and acquainted with the culture of the client, to assist for requirements negotiation and specification. viii) (P4) Deciding and using a standard language for communication. ix) (P5) Focusing on improving the communication language, for example, offering English language courses. x) Arrangement and monitoring of all the activities that are performed to deal with cultural diversities, by project manager or senior team members.

P60
Introducing Equality Model (EM) for all the stakeholders according to which all stakeholders are equal and can talk about the interests, religion and cultural values of one and another. They can also share knowledge and recommend solutions by considering the perception and position of others. 41 P61 Delineating the processes, tools and policies to be followed.

P100
Asking the known or identified stakeholders about other stakeholders, based on their suggestions building stakeholders' social network and then prioritizing stakeholders based on measures of social network.

P101
Establishing the Change Control Board (CCB) and including new requirements by following proper requirements change management process (change evaluation and propagation mechanism). 73 P102 Involving real system users in RE process.

P118
Using Wikis geographically distributed stakeholders are engaged to explore their needs or requirements, discuss related issues, ask about new features and create requirements.

P119
Adopting asynchronous communication like email so that less competent stakeholder could have time to understand and answer the communicated messages. Features like checking spellings and grammar, and language translation should be integrated with email facility.

P120
Enabling online collaboration using requirements visualization tools (like use case models, business process diagrams) and social visualization techniques to stimulate the involvement of stakeholders and provide better understanding of requirements.

P121
Selecting suitable groupware tools and techniques for requirements elicitation keeping in view cognitive characteristics of stakeholders by using Felder-Silverman's Learning Style Model (LSM). 80 P122 Having a common set of tools. 81 P123 Employing requirements workshop.

-----
Using a peer-to-peer workshop tool to substitute traditional face to face workshops. P2P applications can provide facilities like: i) Instant messaging. ii) Sharing, reviewing and editing documents. iii) Discussions through audio link. iv) Autonomy (A peer can pass on information to others but also can apply restrictions, for not passing information to particular peer(s), by using access rights. v) Intermittency (disappearing of any peer due to network disconnection that can be intentional or accidental).

Practices Recommended
After Root Cause Analysis

89
----Keeping in view that customer communication and requirements phase take 10-25 percent of the total project effort.

P57
Identifying and accessing all requirements sources. The possible requirements sources are: i) End-users of the system, managers, directors, administrators, clients, developers and maintenance personnel. ii) Individuals who are involved in the activities of business processes. iii) Individuals who are concerned or affected as stated by client management. iv) Requirements specification provided by client or needs of various stakeholders. v) Problems or issues faced by stakeholders. vi) Domain experts. vii) Domain constraints, regulations and standards to be followed. viii) Similar existing systems. ix) Users of similar existing systems.
x) Documents about the target system like record-keeping books, bills, receipts and reports. xi) Other software(s) or system(s) that interact with the system to be developed           (7) Suggestions OR Comments for improvement.

« Back Submit
Never submit passwords through Google