Role of Critical Success Factors in Offshore Quality Requirement Change Management Using SLR

In software engineering field, requirement change management is a challenging job. Ignoring incoming changes results in customer displeasure. It may also result in late product transportation. Managing requirement changes in poor way is the main cause of product failure. It has more diverse effect in global software outsourcing. In software quality requirement change management, it is necessary to address success factors in order to accomplish the requirements of the customers. In this paper, systematic literature review approach is used for documentation and scrutinization of success factors. Total sixteen success factors were recognized having great impact on quality software requirement change management. Our identified success factors like ‘Proper Requirement Change Management’, ‘Rapid Delivery’, ‘Quality Software Product, Access to Market’, ‘Project Management’, ‘Skills and Methodologies’, ‘Low Cost/Effort Estimation’, ‘Clear Plan and Road Map’, ‘Agile Processes’, ‘Low Labor Cost’, ‘User Satisfaction’, ‘Communication/Close Coordination’, ‘Proper Scheduling and Time Constraints’, ‘Frequent Technological Changes’, ‘Robust Model’, ‘Geographical juncture/Cultural differences’ are the crucial factors that affect software quality requirement change. Company size and different database have been used for the analysis of success factors. The databases/search engine used are Google scholar, Science Direct, IEEE Explore and Springer for the exploration of success factors. Companies are analyzed on the basis of their size such as small, medium and large.


I. INTRODUCTION
OSDO (offshore software development outsourcing) aims on developing low priced product in low waged countries [1]. Software outsourcing is a business base on agreements between vendor organizations and clients. Vendor organizations returned services to the clients after receiving desired compensations [2].
For organizational survival, it is compulsory to develop the system. For development, it is mandatory to make changes in organizational structure and policies [3]. Question is why quality requirements are changing? Requirements are changing due to ill-defined requirement development procedure, The associate editor coordinating the review of this manuscript and approving it for publication was Easter Selvan Suviseshamuthu . discounted requirements, undeveloped technologies, unexpected problems, essential changes, misplaced stakeholders, excessively optimistic budget or schedule, boundary not adequately defined, changing needs, wholly products lifecycle phases not addressed [3].
We need requirement changes because some people have no idea what is their wish unless they utilize it. There are different types of requirement change. These are reactive change, happened change, preventive change, incremental change, planned change, operative change, calculated change, central change, turning change and entire change [4].
Managing quality requirement change in offshore development is a thought-provoking task because analysis of whole system change is more challenging which has negative impact on business process [5]. There are certain factors who effect system requirement change. These factors are: Quality Software Product, Skills and Methodologies, Low Cost/Effort Estimation, Structural differences, Component Model, close communications, Market access, management methods etc. [6].
In business environment, change in quality requirement is a key challenge. Business environment is closely related to customer wishes and technological change [7]. There must be quality requirement change management techniques in order to achieve business goals and objectives. When there come requirement changes from customer side, Requirement change management fulfils this demand [8]. High quality requirements measurement results in high quality system at the last stage of development. A product with high quality requirement must possess the qualities of wholeness, unambiguity, reliable, precision, feasibleness, traceable, demonstrable and changeable [4]. Mutual understanding among stakeholders in necessary for successful implementation of RCM techniques [9], [10]. Implementing RCM techniques without planning results in high cost products and project delays [5]. Worrying thing about RCM is the shortfall in telling and recognizing requirements change. Classifying requirement change management (RCM) challenges helps in showing road map to researchers for finding solution of a particular problem. RCM is a significant technique in prerequisite engineering and reflective consideration of its procedure is a principal success factor to install change in requirements [3]. It is believed that quality of a product depends on quality of a process. it is therefore needed to manage requirement changes through RCM process [11]. Software requirement changes are happening due to: variations in customer requirements, refining in functionalities, and shift in managerial policy, variation in road map, incomplete requirements, eliminating redundancy and revealing requirements [3]. Fig. 1 shows RCM process details [1]. Research shows that when software projects requirements are not handled in a right manner, it plays a primary role in project failure. A report published by Standish group says that there are three main cause of project failure. These are: no role of customers input, variation in requirements. Past presentation report in the eyes of Standish Group of CHAOS Survey is in Fig. 2 [2].
From the diagram, it is clear that the main factor behind project failure is the poor requirement management.  Another survey conducted by Standish group based in USA reports that the main factor behind project failure is the miss managed requirements. What types of requirements we may face during project management? These are as mentioned in Figure 3 are: requirements with no use, absence of proper scheduling, variation in requirements, no role of management support, impractical expectations, lack of capitals, low customer involvement and incomplete requirements as depicted in the this Figure [2].
In the Fig. 3, it is clear that most important factor having negative impact on project failure is the incomplete requirements of ration13.1%. The other most important factor is the low customer involvement of percentage ratio 12.4.
Global software development (GSD) is a platform in which different skilled persons sit at different places remotely with different culture and time zone differences and exchange their views for preparing business product in order to satisfy end users [3]. Distributed software development is a challenging platform.
Software requirement change management is a key challenge among these. It is more challenging in GSD perspective. Global software development face more hurdles as compare to single-site development in terms of management and technicality [4]. Achieving high valued product in the eyes of end users is the main objective of today's VOLUME 9, 2021 business environment. Requirement change in the shape of functional requirement or non-functional requirement will be fulfilled [5]. This process is not free from tension. Because business experts in quality outsourcing requirement change belong from different culture, different time zones, miscommunications remotely and organizational problems [6]. Distributed teams are facing hurdles linked to coordination, differences in time zone, differences in culture, and information supervision [7]. But dispersed teams, different time zones and variance in culture have a meaningful influences on communication and project success [8].
There have been developed so many models and techniques in offshore quality requirement change management. These models and techniques overcome the challenges being faced by vendor organizations in quality requirement change management process. A model developed by Akbar [9] tells about the different process of requirement change management about initial stage, its calculations and variation in last stage of product development. Main goal of this model is how to keep focus on success factors like time constraints, cost issue in quality requirement change management in the direction of RCM. A model called change management process model(CMPM) was introduced by Bhatti [10]. Main focus of this model is on how requirement change management activities ae going on? Disadvantages of this model is that it does not focus on verification segment. Another model called Ince's RCM model. This model handles main activities of quality requirement change management. when there comes change from customers'/end users side, it will be transferred to change control board (CCB). These changes are verified/clarified in CCB with cooperation all six stages (this model has six stages). Its weak point comes as it ignores coordination factor in communication between clients and vendor organizations. Although the above mentioned models giving valuable guidelines in managing quality requirement change. And tying to prepare top quality product for end users satisfactions [3]. But managing quality requirement change globally is not an easy task [11]. Most of business sites ae spread worldwide. Role of RCM activities in GSD platform cannot be denied. Very few studies have been shown in resolving RCM concerns [3]. No SLR strategy has been formulated for examining success factors having constructive impression on requirement change management processes in global software development stage [12].
The main objective of this study is to categorize the success factors having positive influence on quality requirement change management process in GSD platform. This paper also observes different stages of a business product in the respect of quality requirement change management. We have formulated the following research questions to adjust our claim.
RQ1. What types of success factors that should be considered by vendors' organization in quality requirement change management software development?
RQ2. What types of most critical success factors that should be considered by vendors' organization in quality requirement change management software development?
RQ3. Do the recognized success factors, as acknowledged in the literature, vary from company to company size?
RQ4. Do the recognized success factors, as identified in the study, change from search engines/database to search engines/database? RQ5. Do the recognized success factors, as identified in the study, change from decade to decade?
We have found through literature review that quality change management is the critical issue in software development and maintenance. Most of the software contract failed due to poor requirement change management. Our study focus on to bridge this gap. This paper is one component of our proposed model that will assist vendor organization to gauge their status for quality requirement change management in context of quality software development.
The rest of the paper is planned as: unit two consists of Background and Motivation. Unit three consists of Systematic literature review (SLR). In section 4, result of our research work is shown. Section 5 consists on discussion. Section 6 is about study limitations. In section 7, Conclusion and Future work has been mentioned.

II. BACKGROUND AND MOTIVATION
Requirement change management working closely on delivering quality product to end user. It has scale for prioritizing customers wish and trying to fulfill each and customer's wish [13]. Unless there is not a change concept in a business organization, it can't achieve it milestone. Nurmuliani [14] is of the view that quality requirements are changing because a change comes from customer wishes, market change, policy change and variation in products' quality. Linquist [14] is of the view that nearly half of the business activities fail due to unplanned RCM activities. Sirvio and Tihinen [15] also think same by saying that 40% business process fails by not applying well-structured RCM techniques. Most research work in the form of different models and framework have been done in order to handle issues related to quality requirement change management [8]. But their contributions were only related to problems related to specific software product [16].
How can we development software quality requirements and for what purpose we develop it? Purpose of software requirement is to study different developed requirements [17]. This scenario is best described in the following diagram.
In the Figure 4, it is showed that software requirements can be developed and updated when customer wishes and will are fulfilled. Change in business scenario, change in skills and tools can positively impact on requirement development. Raw requirements are unstructured requirements, and they are not yet defined in a well manner. After receiving comments from customers, they are further furnished. At last they are transformed into full-fledged requirements. Research work in the field of quality requirement change management has less contributions for developing standards and models particular in the field of GSD [2]. Lai et al. [18] and Ramadan [19] are of the view that no attention has been given for preparing standard tools in quality requirement change management in GSD environment. In GSD environment, dispersed cites create more problem in business situation. It is a worse situation for business experts to survive in today's business and technological competition [8]. Researchers in the field of GSD business environment, has paid less attention to the role of success factors having positive effect of quality Requirement Change Management [20].

A. REQUIREMENT CHANGE MANAGEMENT PROCESS MODELS
A change management model developed by Minhas and Zulfiqar for managing requirement change in single site. But it has no role to manage changes in GSD environment. Another framework of RCM model proposed by Akbar [21] covers all stages of change management but no road map of change in GSD environment. A framework developed by Niazi et al. [22] to instrument a special practice of CMMI model also does not deal with communication and coordination happenings in global software development environment. Another change management model designed for small and medium sized organization by Keshta et al. [23]. This model has no role in large and distributed organizations. Another model called formal RCM model developed by Bhatti et al. [10] addresses all the significance changes but silent in verification stage. Ice's model also addresses nearly all stages of RCM activities. But it also does not focus on verification segment in GSD environment [24]. This model is completely silent in decision making in bringing change. Who will perform the business activities is also missing?
The above frameworks and models help when there comes a requirement change in situation of insourcing (not outsourced). In Model called requirement change management for global environment (GRCM) helps when sudden change is needed in global software development paradigm. But weak point is that no facilitated tool was proposed for communication and coordination. It only touches predevelopment stage [25]. Another model developed by Kumar and Kumar for handling issues of requirement change management. weak point is that the nature of communication is not clearly defined [26]. Another model developed by Rabia fulfils and handles all issues of RCM activities. Weak point is that the model is not yet validated [26]. Another framework developed by Khan et al. addresses all the activities of RCM activities especially in global software development. But this framework does not addresses the culture and language barriers [27]. Lai presented a framework called ontology based requirement repository. In this framework quality requirement change management is dealing in GSD environment. But the process of quality requirement change management is complete and not mentioned clearly [18]. Sinha et al. [3] developed a tool called EGRET in requirement change management. Its weak point is that change in time shape not clearly addressed. It will result in rework. Another framework proposed by Minhas et al. [28] for requirement change management covers nearly all activities in global requirement change management. But culture and time success factors are not addressed. These success factors should be handled for the smooth running of global business activities. Heindl et al. [29] proposed an approach called requirement tracing based approach. This approach is used for tracing requirement change by totaling stakeholders' assessment. Although this approach is used for requirement traceability for handling GSD issues. But it does not address most of the hurdles like culture awareness, time constraints and coordination issues. Details of further different RCM models and differences among them are mentioned in the following Table 1 [19].
Change implementation is absent in Dean Leffingwell and Widrig model [30]. No testing facilities is present. So it will be difficult to check whether business activities are going well and smoothly or not. When there comes a future change plan, no such facilities are present here. Who has requested for change, will not be answered.
In V-like model [31], there is no concept of budget and resource management. When there comes change in requirements. When there are no budget and resources, it will be difficult to implement. Like Ice's model, Spiral model also does not focus on decision making in business process development process. No testing facilities are provided [32]. Simon Lock model has no role when there comes requirement change in initial stage. Although research work on empirical studies to classify success factors has been done in GSD environment [6]. But has failed to classify success factors having positive effect on quality requirement change management in GSD business scenario. Success factors identified in this research work help GSD engineers to identify, schedule and achieve quality requirement change in GSD environment.

III. SYSTEMATIC LITERATURE REVIEW
To identify success factors in software outsourcing quality requirement change management, we have taken help from systematic literature review(SLR) [33]. So many other researchers have also taken advantages from this method [34]. SLR is diverse from OLR in that it shadows systematic protocol. Systematic literature review helps in collecting relevant information with the help of systematic protocol having search string along with research questions. The results of SLR are measured more precise, trustworthy and less biased when we compare it to OLR. This segment is used for collecting data according to research questions. It is used for identifying success factors having positive impact on quality requirement change management process. two SLRs have been used for identifying success factors, challenges and practices. One is used for critical success factors and critical challenges while the other for validation of practices. We know that an SLR acts like a map for gathering and identifying related data [35]. Stages of SLR are shown in Figure 5. We have used Google scholar, Science Direct, IEEE, Explore and Springer, because these databases and search engines gave result matched to our title of our research article and RQs defined.
Desired result did not come on the above string. We modified it. Updated version is as under.     Table.1. This is an extended form of the paper accepted in ICGSE 2021: International Conference on Global Software Engineering, Moscow, Russia.
We have used Google scholar, Science Direct, IEEE, Explore and Springer, because these databases and search engines gave result matched to our title of our research article and RQs defined.

B. PUBLICATION COLLECTION 1) ENCLOSURE STANDARDS
Enclosure criteria is used which type of works will used for data extraction process. VOLUME 9, 2021 The following standard is used.
• Make a part of those papers written in English language • Those papers will be included related to research topic. • Terms specific to RQs.

2) EXCLUSION CRITERIA
Those work not related to research area will be eliminated.
We have made the following criteria.
• Research papers not related to RQs.
• Studies not related to the title to the research.
• Papers not in English language.

C. DATA EXTRACTION
This segment was finished by the first author. Data abstraction process was completed by the primary two authors of the paper. Success factors, challenges, practices were registered distinctly with respect to country, data, methods etc.

D. DATA SYNTHESIS
This step was completed by the author in coordination with the supervisor. Success factors were listed from 116 papers. at first stage, total 34 success factors were listed with the help of systematic literature review. After receiving comments from supervisor, these were reduced to 16 as a final.
We have found through literature review that quality change management is the critical issue in software development and maintenance. Most of the software contract failed due to poor requirement change management. Our study focus on to bridge this gap. This paper is one component of our proposed model that will assist vendor organization to gauge their status for quality requirement change management in context of quality software development.

A. SUCCESS FACTORS RECOGNIZED THROUGH SYSTEMATIC LITERATURE REVIEW (SLR)
Total sixteen success factors were recognized in data extraction process from primary selected papers. In order to answer research Q1, success factors are mentioned in Table 3 and Figure 6 having positive impact on software quality requirement change management. Success factor having high frequency or percentage considered applicable in the literature.
We have used descriptive analysis instead of thematic analysis. Descriptive analysis is a significant primary phase for showing statistical analysis. It gives assistance in relationship among different variables. We have used statistical approaches like Chi-Square Test (Linear by Linear Association) and Spearman's rank correlation for our analysis as numerical data is used for data analysis. The following chart shows identified success factors.
Success factor1 (Proper requirement change management) with 60% is considered critical success factor in literature for quality change in requirement management at global software development environment. Using proper requirement change management, we can easily manage a change of requirement coming from business customers. It can promptly give feedback to a customer requirement change. Lindquist [36] is of the view that proper requirement change management manage customer requirement in a best way. Managing requirement change in well-structured way helps in achieving desired goal of software project procedure [37].
Success factor2 (Rapid delivery) with 38% is the main success factor in quality change in requirement management at global software development process. Rapid delivery focuses on how fast we can deliver required functions. When quality requirement change is occurred. Rapid delivery promptly delivers the said eminent requirements.
Success factor3 (Quality software products) with 37% is another important success factor in quality change requirement management at global software development business process. The main hurdle in development of quality software is exact estimate. The accomplishment of a software project growth is basically measured by several aspects that would help in bringing high quality software on scheduled plan and at low-priced [38]. Quality software product aims on how to maintain the quality of a business product when there comes a change in technological fields.
Success factor4 (Access to market) with 31% is the prominent success factor in quality change requirement in global software development. Most organizations are nowa-days adopting global software development paradigm. It helps in achieving high quality product at low cost. Access to market helps in achieving quality product at door step. Because of several paybacks such as less budget, entree to skilled crews, and entrée to market, many corporations have accepted global software development platform.
Success factor 5 (Project management) with 30% falls in an important category which has positive effect on quality change in requirement management in the field of software development process. Achieving high quality product, it is important to manage project activities. In the view of Khan et al. [39], high and low level management is mandatory for the success implementation of quality product. A worthy change acceptance decision can aid software project manager in managing SRCs (Software requirement changes). Software project management is accountable for the project disaster or project victory. Change impact analysis lessen the burden on development administrators in decision to agree or to reject the business project [40]. According to Ateeqanaseer [41] Project management and project team have a key role in removing time deficiency in quality requirement change management.
Success factor 6 (Skills and methodologies) with percentage has a main role in quality requirement change management in software outsourcing. Team work is fruitful when adopt standard skills and methodologies. According to Khan et al. [39] Quality product is very difficult to achieve when there is no use of standard of framework and models. Software business is transferring towards global software development because of skilled labors. Success factor 7 (Low labor cost/effort estimation) with percentage 27% is another key factor having positive impact on software quality requirement change management. Quality product with low cost will be preferred. When there is an accurate estimation, a product with desired quality requirement will be prepared and maintained. Prikladnicki et al. [42] is of the view that poor cost estimation leads to project failure. It is therefore the need of the business environment to first estimate the cost in a best and better way to develop a quality product. Due to low labor cost, the day to day business is transforming to GSD in order to achieve quality product [43].
Another important success factor in quality requirement is Clear plan and road map with percentage 26. Clear plan and clear road map helps in achieving quality product. Customers cannot be satisfied nor a product be boosted without clear map and clear road map. It guides software organizations in achieving high quality product in software quality requirement change management. Akbar says that eight out ten organizations are failed due to lack of clear plan [37]. Clear plan and clear road map is essential for identification of requirement change management challenges.
Success factor 9 (Agile process) with percentage 22 has its own role in software quality requirement change management process. Without agile process, a quality product can't be maintained. Agile process handles process requirement changes at any stage of software product development process [44]. This factor is used in improving communication among vendor organizations [45].
Another important success factor called low labor cost plays an important role in quality requirement change management. It is used in achieving high quality product. Business is transforming towards software global development due to low labor cost [25]. Customers and vendors are more satisfied with a product having low labor cost.
Success factor11 (User satisfaction) with percentage 22% also plays an important role in software quality requirement change management process. Unless user or customer is not satisfied, a goal regarding achieving quality product cannot be achieved. User satisfaction and quality requirement change is interdependent. Users feedback organize quality requirement change in a better way [46]. User satisfaction process evolves throughout the product life development cycle. This factor us used for computing system progress. User satisfaction is one of the five success factors having positive impact on entire organization.
Success factor12 (Communication and close coordination) with 22% has its own positive impact in quality requirement change management process. We know that policies and rules of the business are varying day by day. It is the need of the day to have close communication and coordination among clients and vendor organizations for achieving extraordinary class product on minimum cost. Coordination among development team and end users is a key process to provoke effective requirements in software requirement change management processes [47]. Communication is used for switching information among organization workers. It has continuous role throughout the product life development life cycle.
Another Success factor13 (Proper scheduling and time constraints) with 19% has its own role in quality requirement change management. business organizations cannot succeed in achieving its business goal until it has its own road map and clear time schedule. Proper scheduling can save time in achieving business quality product [48]. With the help of proper scheduling and time constraints, organizations can easily analyze the upcoming requirement change.
Success factor14 (Frequent technological change) with percentage ratio 17 has its own positive role in quality requirement change management process. requirement change can be managed in a best way with due to frequent technological change. Research shows that change in technology is beneficial for quality requirement change. It is the technological change who has shifted the business to global software development [43].
In success factor15 (Robust model) with percentage ration 12%, when standard tools are used, a product with desired quality can easily be achieved. As a result, customers will also be satisfied. Global software development models, approaches and procedures that can competently and effectively perform GSD work [49].
The low citation success factor in our work is the Geographical juncture and culture awareness. Its percentage is 7. Geographical juncture increases the space of an organization In geographical juncture and culture awareness, a task is accomplished by different team members location at different places [50]. Mission is accomplished by joint efforts of different experts. This success factors have direct impact on all kinds of coordination among expert groups. To answer RQ1 the list of success factors is highlighted at Table 3.

B. CRITICAL SUCCESS FACTORS
Success factors will be considered critical success factors whose citation is ≥20%. Criteria was set low in order to give touch more and more success factors who have positive impact on quality requirement change management. Similar standards also used by former researchers [6], [13]. Total fourteen success factors were considered critical success factors. Occurrences of critical success factors are revealed in the Figure 7. In order to answer RQ2 Complete critical success factors with respect to company size and database wise are mentioned in Table. 4 and Table. 5 respectively.

C. COMPARISON OF SUCCESS FACTORS ACROSS DIFFERENT COMPANIES
Among the total 116 research papers extracted for quality requirement change management, company sizes were mentioned in 113 papers shown in given Table 4. We have devided our work in three compani sizes. A company whose employes less than 20 will be considered small company. A medium will be whose employees less than 200. While large company has more than 200 employees. 'Proper Requirement change Management' and 'quality software product' are critical success factors (=>20) found in any company size. It means that these success factors have equal reputation in all type of organizations.
Success factor 'Project Management' is critical in mixed and in large organizations because it has so many tools, labors and assignments to be managed.

Five success factors 'Skills and Methodologies', 'Low
Cost/Effort Estimation', 'Clear Plan and Road Map', 'Communication/Close Coordination' and 'Proper Scheduling and Time Constraints' have same occurrences(28%) in mixed organization. Whether small, medium or large organization, when there is no proper change management, they cant achieve their business goal.
The most cited success factors in all types of organizations is 'Proper requirement change management'.
In order to find exact and authentic difference among success factors identified different Comapany sizes, a help is taken from linear by linear association chi-square test. It is preferable to use when we want to see difference between different variables, the results can be seen in Table 6. In order to answer RQ3, results are shown in Table 6. It shows that identified success factors are varying from size to size.  Our primary papers with respect to company size is shown in figure 8. From the figure, it is clear that most of the articles are related to large organizations.
Applying Spearman's rank correlation on Success factors identified in different company sizes like large size and mixed size in respect of degree of relationship shows that there is a strong relationship between these two terms. The correlation coefficient between them is 0.502 suggesting that a strong and positvie relationship exists. This relationship is shown in the following Table 7.
The association among the two company size have been mentined in Fig. 9. with scatter diagram. Comperison was made between company size large and mixed.

D. COMPARISON OF SUCCESS FACTORS ACROSS DIFFERENT DATABASES/SEARCH ENGINES
Among the total 116 research papers extracted for quality requirement change management, databases are mentioned in 113 papers shown in Table 8 and Fig. 8. From the Table it is shown that success factors are in 97 research papers from  success Factor 'Proper Requirement change Management' has most citation in all databases(Google scholor = 57%, Science Direct = 100%, IEEE Xplore = 100%, Springer = 50%). The frequency of Rapid Delivery is high in Google Scholor while it is low in Scince Direct, IEEE Xplore and Springer. We also see significance difference in success facotr 'User Satisfaction'. It is high in Google Scholor(26%) while it is low in Scince Direct(0%), IEEE plore(0%) and Springer(12%). It means papers of papers of user satisfaction in quality requiremnet change management are mostly cited in Google Scholor. Quality software product is a critical success factor in Google scholor(37%), Science Direct(50%) and Springer(25%). We found another significant difference in success factor project management. Its frequency is high in Google Scholor(31%), Science Direct(50%) and IEEE Xplore(33%) but is low in Springer(0%). It shows management related paperes are mostly cited in first three search engines. Nine success factors have same frequency ratios in IEEE Xplore. In order to answer RQ4, it is clear from Table 8, that identified success factors are varying from database to database or from one search engine to another search engine.   In order to find exact and authentic difference among success factors identified in database wise, a help is taken from linear by linear association Chi-Square Test. It is preferable to use when we want to see difference between different variables, output is shown in Table 8. Figure 10 shows the distribution of an identified articles regarding search engines/digital libraries. It is clear from the figure that most of the paper were collected with the help of search engine google scholar. Springer comes on second position. Details are shown in figure 9.
Similarly, when we Apply Spearman's rank correlation on Success factors identified in databases Google Scholar and IEEE Explore in respect of degree of relationship shows a perfect connection between these two search engines. The correlation coefficient between them is 0.859 signifying perfect and optimistic association exists. This relationship is shown in the following Table 9.
The relationship between the two search engines has been shown in Fig. 11 using scatter diagram.

E. COMPARISON OF SUCCESS FACTORS ACROSS DIFFERENT DECADES
Among the total 116 research papers extracted for quality requirement change management, decades were mentioned 99692 VOLUME 9, 2021  in 113 papers shown in Table 10. Our paper period start from 1992-2020. We have divided our periods in three parts. First period starts from 1992 to 2002. Purpose was to give touch more and more papers related to our topic and research questions. Second period starts from 2003 to 2012 while third period from 2013 to 2020. Total 75 papers have been published in third period. Which shows that much work has been done in this period. 32 papers published in second period while 6 papers in first period. Less work has been done in third period in quality requirement change management's perspective. Our result shows out of 16 success factors, 16  In order to answer RQ5, it is clear from Table 10, that identified success factors are varying from decade to decade.
In order to find exact and authentic difference among success factors identified in different decades, we have use linear by linear association chi-square test. It is preferable to use when we want to see difference between different variables, the results can be seen in table 10. Fig. 12 shows the distribution of an identified articles regarding different decades. It is clear from the figure that most of the paper were collected from third

V. DISCUSSION
Answering research Q1, total 16 success factors were found in literature. Answering research Q2, total 14 critical success factors found. Our criteria for critical success factors was low in order to give touch more success factors in the field quality requirement change management. Answering research Q3, analysis done by us shows that success factors acknowledged in the study changes from company to company. Answering research Q4, analysis done by us shows that success factors identified in the literature changes from database to database. Answering RQ5, an analysis shows that success factors identified in the literature are changing from decade to decade. Result of the success factors changes from company to papers in quality requirement change management. What is the stage of certification for quality requirement change management? It is possibility that success factors may not be presented in well manner. By using different research methods, some biased reports can have occurred. Some similarities were reported between our findings and findings of other researchers. For authentication and validation of our findings, we will use case studies, same techniques may also be used by other researchers. Some papers came with unclear information regarding company size and different databases. Most of the company were large in size in research study, we company and database to database is shown in Table 3 and Table 4 respectively. Brief discussion is in result section. This paper is one component of our research work where we have a model which will based on CSF/CBs and their practices that will assist vendor organization to gauge their status for quality requirement change management in context GSD.

VI. STUDY LIMITATIONS
We restricted our SLR Study to four search engines and online libraries (Google Scholar, Science Direct, IEEE Explore and Springer). There may be other related search engines and online libraries, we may not have touched. The literature review development phase led by the first author of the paper, therefor it is the possibility the findings of the study can be biased during collection process. However, the second and third authors endlessly inspect the extracted data to find any challenges and hurdles unheeded by the first author.

VII. CONCLUSION AND FUTURE WORK
In this stage, we have only identified the success factors of software outsourcing quality evaluation management Model (SOQEMM). Next stage will be validation process. Validation process will be done in using case study in an outsourcing business. The keynote of this research is to build a model for vendor firms to assist them in managing quality requirement change. Researchers who work in the field of quality requirement change management can take help from this work. Total sixteen success factors have been finalized. Among these sixteen success factors, fourteen success factors have been listed as critical success factors (CSFs). Success factors who citations are equal or greater than 20 are considered critical success factors. We have set the criteria low in order to touch more success factors having positive impact on quality requirement change. Our success factors were compared in different company and different databases. Table 11.

ACKNOWLEDGMENT
The findings achieved herein are solely the responsibility of the authors.