# Decision-Making Framework of Requirement Engineering Barriers in the Domain of Global Healthcare Information Systems

Authors: Muhammad Hamza; Muhammad Azeem Akbar; Abeer Abdulaziz Alsanad; Lulwah Alsuwaidan; Hatoon S. AlSagri; Halah Abdulaziz Al-Alshaikh; Maliha Kanwal
Journal: Mathematical Problems in Engineering
 (2022)

---

## Abstract

The smart healthcare information system offers several benefits including effectively reducing the cost and risk of medical procedures, improving the utilization efficiency of medical resources, promoting exchanges and cooperation in different regions, pushing the development of telemedicine and self-service medical care, and ultimately connecting people (patients and medical teams). The development of smart healthcare information systems in a globally distributed environment is a swiftly followed paradigm in the recent era. The development and implementation of a global healthcare information system (GHIS) are complicated as it faces several important problems that are more related to requirement engineering (RE). The ultimate aim of this research study is to explore and prioritize the barriers that would hinder the actual RE process in GHIS. To meet the research objective, 17 barriers of RE in GHIS have been identified through literature review and verified with practitioners using a questionnaire survey approach. Moreover, the analytical hierarchy process (AHP) approach was applied to rank the investigated barriers considering their significance for GHIS. The outcomes revolved that coordination is the most critical category for RE barriers in GHIS. Emotions and personal values, scope change, and creep are considered, and ad hoc exchange management and the absence of traceability are analyzed as the high-priority barriers to RE in GHIS. The findings of this study provide a robust framework that is beneficial for researchers and practitioners to consider the most critical barriers on a priority basis and develop the new strategies for RE process success in GHIS.


---

## Body

## 1. Introduction

The smart healthcare information system is considered an integral but independent part of the healthcare system. These systems are developed based on the service delivery system [1]. Smart healthcare information systems are used for information gathering, management of the information, analyzing, and propagation of information that tremendously paved the path to the improvement of the healthcare sector. The machine that collects data from the fitness area and different applicable sectors, analyzes the facts, ensures their typical relief, relevance, timeliness, and converts records into facts for health-related selection making [2]. Occasionally, these systems are associated with monitoring and evaluation of a patient’s health. The healthcare information systems support an alert and early warning after monitoring the patient's status. The systems also support patients and health facility management, planning, stimulating research, supporting global reporting, etc [3]. Therefore, the healthcare information system has tremendously gained popularity as it improved the clinical decision-making, planning process, and healthcare management and has been developed and deployed to several areas for patient monitoring and management.While developing these kinds of systems, there needs to involve the requirement engineering phase of the software development life cycle (SDLC), as it is considered the foundational part of every system before the initiation of development and during the development process [4].Requirement engineering is one of the most crucial phases of the software development life cycle (SDLC) while developing any type of software or system [5]. This phase is considered the most complicated in the overall development of any software or system. The requirement engineering is a process of determining the objective of the prosed project, by way of investigating the expectancies of stakeholders and documenting those expectancies in this sort of manner that can be analyzed and implemented. Almost 80% of software fails due to a lack of gathering accurate requirements. The vital and complicated phase of software engineering is to determine exactly what to build, who might be concerned within the system, and how real functionality can be performed [5]. Furthermore, requirement engineering is comprised of 5 central segments (i.e., “elicitation of the requirements from stakeholders,” “evaluations of the identified requirements,” “specification of the actual requirements,” “validation of the requirements,” and finally “control over the requirements”) [6]. The requirements are collected using different techniques and recorded into a documented form called a software requirement specification (SRS). The SRS specifies the functional and nonfunctional requirements of any proposed system [7]. The requirement engineering is still in its nascent stage while considering the healthcare information system development. Healthcare information systems are complex to develop; thus, requirement phases need much more attention before the actual development of these systems.However, for the betterment of healthcare services, software firms are consistently developing intelligent systems to attain the particular health-related information of patients and to make regular decisions based on the information generated by the systems. So, healthcare is an important research area, and automation in healthcare makes this domain more critical and significant, though the development of efficient and intelligent systems helps the medical industry to keep humans' life safe and better. The advancement in information technology connects people around the globe that makes it possible to safely and easily carry different businesses in the global market as the easy availability of information assists to carry people around the globe. For example, a large number of students travel over the globe from one country to another. As the medical treatment of a person is based on its previous history, the increasing trend of traveling of people from one location to another over the globe raises the significance of the global healthcare information system (GHIS). To expand powerful GHIS, the collection of natural and distinctive requirements performs a crucial function [8]. As the activities concerned utilizing the RE method are conversation and collaboration orientated, for this reason, it is far difficult to acquire the requirements in a worldwide context. The RE has a protracted history of studies, but still, RE is a very critical segment of software program improvement, in particular, in a fitness care facts gadget. Some research highlighted the societal and cultural characteristics of RE and recognized “lack of belief” as a crucial challenge between requirement engineering and GHIS control [9, 10]. Several other research studies have been performed to cope with the challenges confronted by means of the RE method that is popular as nicely in global software program development. Similarly, the requirement elicitation model was developed by Pandey aiming to better understand the requirement engineering phases. The Pandey model contained four core levels, namely, “elicitation and development of requirements,” “documentation of those requirements,” “verification and validation of requirements,” and “planning and management of identified requirements” [11]. We further discovered that Beecham developed a requirement engineering adulthood version (R-CMM). R-CMM version consists of 5 core tiers that help to evaluate the RE process of a company and to improve its RE readiness [12]. Consequently, Mellado advanced a model for the corporation of a cozy RE procedure (SREP) [13]. The key components of the model are based on commonplace criteria (CC) (ISO/IEC 15408). Several other research studies highlighted and defined the parameters to restore the limitations of the RE procedure [12, 14–19]. However, we found some to no studies that address the key barriers being faced by the practitioners while developing the healthcare information system in the context of global software development (GSD).The vitality of the RE within the context of GHIS encouraged us to explore the challenges faced by way of industry practitioners. To address the limitation in the existing research, we performed a literature review and identified several barriers being faced in the requirement engineering phase in the system developed in the context of the GHIS. We further shortlisted the most influencing barriers and analyzed them with industrial researchers. In the very last phase, we have applied the analytical hierarchy process (AHP) technique to rank the investigated barriers. The detailed examination will help the researchers and practitioners to expand and revise their strategies in an effective manner that could help to improve the RE process. The following research question was developed to meet the objective of this study:RQ1. What are the key barriers being faced by GHIS firms during the requirement engineering process, as reported within the literature?RQ2. Are the industry practitioners agreeing with the research findings?RQ3. How the analyzed barriers are ranked?The rest of this study is organized as follows: Section2 contains the research techniques that were employed. In part 3, the study's findings are addressed. A study summary was included in Section 4. Section 5 summarizes the findings and future work.


## 2. Research Methodology

We used three potential research approaches in order to meet the study objectives: (i) “an informal literature review,” (ii) empirical research based on a questionnaire survey, and (iii) an analytical hierarchy method (AHP). In the next sections and in Figure1, all the techniques are briefly explained.Figure 1
Proposed research methodology.


### 2.1. Informal Literature Review

The informal literature review is considered an effective approach for analyzing the state-of-the-art literature. Thus, this approach was targeted in order to identify the requirement engineering barriers focusing on the GHIS phenomena. To do this, we have explored the following online digital research databases: “Google Scholar,” “SpringerLink,” “IEEE Xplore,” “Wiley InterScience,” “ScienceDirect,” and “ACM Digital Library.” Furthermore, for extracting the research articles related to requirement engineering, in general, and requirement engineering in the healthcare information system we applied a search string containing our research study objective. The search string was formulated according to the search mechanism of databases. For developing the search string, we used keywords and their alternatives and concatenated them by using Boolean “AND” or “OR.” However, the following is the search string for an example:(“Challenges” OR “hindrance” OR “obstacles” OR “complications” OR “impediments” OR “barriers” OR “obstructions”) AND (“requirements engineering” OR “RE” OR “collection of requirements” OR “elicitation of requirements” OR “requirements updating” OR “requirements process assessment”) AND (“global healthcare information system” OR “GHIS” OR “distributed healthcare management systems” OR “offshore healthcare systems” OR “health-care informatics”). The search phrases were compiled utilizing our research knowledge and references [20–24].


### 2.2. Empirical Study

The empirical study approach was adopted to validate the identified challenges from the informal literature review with industrial practitioners. Following are the steps that were applied for conducting the empirical study.


#### 2.2.1. Survey Questionnaire Development

We prepared an online survey questionnaire based on the findings of the literature study to evaluate the challenges of the requirement engineering process in the context of GHIS. The survey approach was successful in obtaining data from a broad target population [21]. Furthermore, the survey approach allows us to gather data that are difficult to obtain using the observational method [25, 26]. To collect information from RE, GHIS, and healthcare information system practitioners, we devised a closed-ended questionnaire. The poll questions were based on the 17 challenges that the literature research looked at. The respondent's response was obtained using a five-pointed Likert scale that included “strongly agree, agree, neutral, disagree, and strongly disagree.” The survey instrument was then tested with professionals to ensure that it was readable and understandable. The professionals came from five different companies (Techlogix Pvt, Netsole, and Radixwb) and two educational institutions (“Abu Dhabi University, UAE, and King Fahd University of Petroleum and Minerals, Saudi Arabia, Nanjing University, Nanjing”). They suggest certain changes to the questionnaire’s framework and the bibliographic information provided by responders. The questionnaire was revised based on expert comments, and the final version was utilized for data collection. A sample of the used questionnaire was given in Table 1.Table 1
Questionnaire survey.
Section-A1 Respondents personal detailFull name (optional)E-mail addressCountryJob title in industry/academicThe current address of your organizationWorking experience (Years) in global healthcare information system and requirement engineering process.How many years of industry/academia experience do you have in your field?Have you ever participated in requirement engineering and management activities?Yes □No □Section-A2 respondents organization detailName of organization (optional).What is the primary business of your organization?□ Collected software development□ Global healthcare information system□ Others□ Research□ EducationPlease specify the number of employees in your organization?□ Less than 20□ 20–100□ 101–200□ More than 200Please specify the nature of your organization?□ National□ Multinational□ Not sure□ OthersDoes your organization adopt software requirement engineering standards or models? (Please specify)How long has the requirement engineering process been in operation in your organization? (Years)Section B-Software requirement engineering barriers and their best practices in the global healthcare information system environment.The aim of this section is to specify the barriers that could negatively impact the requirement engineering process in global healthcare information system organizations. Please rank each barrier according to your understanding and experience.S. D = strongly disagree, D = disagree, N= neutral, A = Agree, and S. A = strongly agreeSr.NOIdentified barriers of the requirement engineering process in GHIS environmentS.DDNAS.AB1Consider emotions and personal values□□□□□B2Scope change and creep□□□□□B3Ad hoc change management and lack of traceability□□□□□B4Fear of intrusion□□□□□B5Distributed healthcare teams□□□□□B6Uncertainties and rapidly changing technology□□□□□B7Insufficient requirement quality□□□□□B8Unclear and fuzzy stakeholders’ expectations□□□□□B9Lack of terminologies understandings□□□□□B10The negative attitude of society toward using HIS□□□□□B11Missing traceability□□□□□B12The difference in working situations□□□□□B13Environmental constraints at GHIS sites□□□□□B14Communication flows in project teams and clients□□□□□B15Privacy and protection of patient data□□□□□B16Volatile client business domain□□□□□B17Regulatory issues between distributed teams□□□□□Please add additional barriers if any.Section-CBest practices for software requirement engineering process in GHIS (available from authors)


#### 2.2.2. Data Sources

The purpose of this survey is to learn more about the challenges that practitioners in the requirement engineering of GHIS confront. Hence, gathering information from the industrial practitioners that work on the development of GHIS is crucial for knowing the significance of identified factors. The snowball approach [27] was used to invite survey participants. All participants were connected through various means, such as Facebook, e-mail, LinkedIn, and professional relationships with their other researchers. The data were collected from January 2021 to December 2021. We have received responses from 56 participants based on the questionnaires survey. The responses were further checked, and thus, none were found incomplete. We observed that most of the responses are from developing organizations that were residing both in Asia and Europe. Members of the development team varied from software developers to project managers. They were all well versed in both the RE and GHIS processes. Table 2 contains the demographics of the respondents.Table 2
Respondent’s demographic data.
S. NoJob titleExperience (years)CountryPrimary business functionAdopted RE standards/modelsRE process in operation (years)1Software application developer7AustraliaCollected/GHISCMMI Level 232Professor10ThailandResearcherCMMI Level 243Project manager8AustraliaCollected/GHISCMMI Level254CEO5ItalyCollected/GHISCMMI Level 235Senior web developer4PakistanCollected/GHISNo06IT in-charge3Saudi ArabiaCollected/GHISNO17Software Manager3PakistanCollected/GHISNO08Associated project manager4GermanyCollected/GHISCMMI Level259IT instructor3ArgentinaEducation researcherCMMI level 2010Professor9Saudi ArabiaEducation researcherCMMI Level 2211Software developer5MalaysiaCollectedNo312Global software project manager4TurkeyCollected/GHISNot sure513Research assistant3PakistanCollected/GHISNo014Operational manager8PakistanCollected (ERP-SAP)Not sure015Software manager2ItalyCollected software developmentNO216Software developer5VietnamCollected/GHISOwn developed117Management system controller5MalaysiaCollected/GHISNo018Manager4UAECollected/GHISNot sure319Researcher7CanadaCollected/GHISSSP-3 CMMI-2320Professor11NetherlandResearcherCMMI level 2321Professor (researcher)6IndonesiaEducation (collected/GHIS)No022Software tester3JapanCollected/GHISSSP-CMMI Level 2223Lecture6SwedenGHISSelf-developed424Director of it3PakistanEducationNot sure025Software developer7IndonesiaCollected/GHISNil226Director of finance6PakistanEducationNot sure127Requirement engineer5USAGHISSelf-developed328Software project manager4SpainMulti-site developmentNot sure229Lecture6SwedenEducationNot sure030Assistant project manager2ThailandLocal development and global developmentLocal developed231Research assistant4UKEducation and researchSelf-developed332Cite manager2CanadaGHISCMMI-2233Product manager3New- ZealandResearch/local developmentNot sureNil34Quality controller7USASoftware development/and researcherSelf-developed435Professor12AustraliaResearcherCMMI-Level 2536Software developer7AustraliaGHIS/local developmentLocal developed537Assistant professor6IndiaResearcherNot sureNot sure38Deputy IT manager4PakistanEducation/researcherSelf-developed139Manager5MalaysiaLocal software maintenanceDeveloped by organization440Director of IT department3PakistanEducationNil041Senior developer9NetherlandLocal developmentOrganization procedureNot sure42Professor6Saudi ArabiaEducationSpecial practice CMMI243Web engineer4ChinaLocal/GHISNo044Researcher7GermanyEducationNot sureNot sure45Project controller3SpainResearcherSelf-organizedNil46Project coordinator4JapanGHIS developmentSelf-developed447Requirement engineer6New-ZealandSoftware development and managementNot sureNot sure48Project controller2VietnamCollected/GHISSelf-developedNot sure49Professor (researcher)7ThailandEducation/researcherNONil50Web developer7FranceCollected/GHISNilNil51Research associate6PakistanEducationNot sure05253Chairman department of the software system5PakistanResearcher/teachingNot sure354Lecture10+AustraliaEducationCMMINil55Dot net developer12IndiaDistributed software developmentOrganization framework456Senior developer9NetherlandLocal developmentOrganization procedureNot sure


#### 2.2.3. Survey Data Analysis

A frequency analysis technique was followed to organize descriptive data. Frequency tables were used to show the frequencies and percentages of the data collected throughout the primary studies. Frequency analysis may be used to investigate variable groupings and ordinal and numeric data [28]. We examined the respondents’ agreement with each identified difficulty to determine the significance of the researched challenges. Different scholars have used the frequency analysis approach in several contexts [29].


### 2.3. Analytical Hierarchy Process (AHP)

The analytical hierarchy process (AHP) is considered a multicriteria decision-making method that is employed to rank factors. This strategy has been previously used in several studies to prioritize the aspects of their interest project [30–32]. To prioritize the researched challenges of the requirement engineering process in the context of GHIS, the same technique is used in this study. The stages of AHP are depicted in Table 3.Table 3
AHP steps for analysis of factors.
Sr. NoAHP phasesPhase 1As indicated in Figure2, classifying the goals, categories (factors), and their related barriers (subfactors).Phase 2Based on the expert’s opinions, a pairwise comparison matrix of obstacles is created.Phase 3Using pairwise comparisons, the priority weight of each barrier category and subcategory is calculated.Phase 4The reliability of the decisions is examined.Phase 5The local weights of each barrier in their resultant categories are calculated.Phase 6The global weight of each category and factor is calculated.Phase 7The final ranking of the identified challenges.Figure 2
Hierarchy of the AHP.


## 2.1. Informal Literature Review

The informal literature review is considered an effective approach for analyzing the state-of-the-art literature. Thus, this approach was targeted in order to identify the requirement engineering barriers focusing on the GHIS phenomena. To do this, we have explored the following online digital research databases: “Google Scholar,” “SpringerLink,” “IEEE Xplore,” “Wiley InterScience,” “ScienceDirect,” and “ACM Digital Library.” Furthermore, for extracting the research articles related to requirement engineering, in general, and requirement engineering in the healthcare information system we applied a search string containing our research study objective. The search string was formulated according to the search mechanism of databases. For developing the search string, we used keywords and their alternatives and concatenated them by using Boolean “AND” or “OR.” However, the following is the search string for an example:(“Challenges” OR “hindrance” OR “obstacles” OR “complications” OR “impediments” OR “barriers” OR “obstructions”) AND (“requirements engineering” OR “RE” OR “collection of requirements” OR “elicitation of requirements” OR “requirements updating” OR “requirements process assessment”) AND (“global healthcare information system” OR “GHIS” OR “distributed healthcare management systems” OR “offshore healthcare systems” OR “health-care informatics”). The search phrases were compiled utilizing our research knowledge and references [20–24].


## 2.2. Empirical Study

The empirical study approach was adopted to validate the identified challenges from the informal literature review with industrial practitioners. Following are the steps that were applied for conducting the empirical study.


### 2.2.1. Survey Questionnaire Development

We prepared an online survey questionnaire based on the findings of the literature study to evaluate the challenges of the requirement engineering process in the context of GHIS. The survey approach was successful in obtaining data from a broad target population [21]. Furthermore, the survey approach allows us to gather data that are difficult to obtain using the observational method [25, 26]. To collect information from RE, GHIS, and healthcare information system practitioners, we devised a closed-ended questionnaire. The poll questions were based on the 17 challenges that the literature research looked at. The respondent's response was obtained using a five-pointed Likert scale that included “strongly agree, agree, neutral, disagree, and strongly disagree.” The survey instrument was then tested with professionals to ensure that it was readable and understandable. The professionals came from five different companies (Techlogix Pvt, Netsole, and Radixwb) and two educational institutions (“Abu Dhabi University, UAE, and King Fahd University of Petroleum and Minerals, Saudi Arabia, Nanjing University, Nanjing”). They suggest certain changes to the questionnaire’s framework and the bibliographic information provided by responders. The questionnaire was revised based on expert comments, and the final version was utilized for data collection. A sample of the used questionnaire was given in Table 1.Table 1
Questionnaire survey.
Section-A1 Respondents personal detailFull name (optional)E-mail addressCountryJob title in industry/academicThe current address of your organizationWorking experience (Years) in global healthcare information system and requirement engineering process.How many years of industry/academia experience do you have in your field?Have you ever participated in requirement engineering and management activities?Yes □No □Section-A2 respondents organization detailName of organization (optional).What is the primary business of your organization?□ Collected software development□ Global healthcare information system□ Others□ Research□ EducationPlease specify the number of employees in your organization?□ Less than 20□ 20–100□ 101–200□ More than 200Please specify the nature of your organization?□ National□ Multinational□ Not sure□ OthersDoes your organization adopt software requirement engineering standards or models? (Please specify)How long has the requirement engineering process been in operation in your organization? (Years)Section B-Software requirement engineering barriers and their best practices in the global healthcare information system environment.The aim of this section is to specify the barriers that could negatively impact the requirement engineering process in global healthcare information system organizations. Please rank each barrier according to your understanding and experience.S. D = strongly disagree, D = disagree, N= neutral, A = Agree, and S. A = strongly agreeSr.NOIdentified barriers of the requirement engineering process in GHIS environmentS.DDNAS.AB1Consider emotions and personal values□□□□□B2Scope change and creep□□□□□B3Ad hoc change management and lack of traceability□□□□□B4Fear of intrusion□□□□□B5Distributed healthcare teams□□□□□B6Uncertainties and rapidly changing technology□□□□□B7Insufficient requirement quality□□□□□B8Unclear and fuzzy stakeholders’ expectations□□□□□B9Lack of terminologies understandings□□□□□B10The negative attitude of society toward using HIS□□□□□B11Missing traceability□□□□□B12The difference in working situations□□□□□B13Environmental constraints at GHIS sites□□□□□B14Communication flows in project teams and clients□□□□□B15Privacy and protection of patient data□□□□□B16Volatile client business domain□□□□□B17Regulatory issues between distributed teams□□□□□Please add additional barriers if any.Section-CBest practices for software requirement engineering process in GHIS (available from authors)


### 2.2.2. Data Sources

The purpose of this survey is to learn more about the challenges that practitioners in the requirement engineering of GHIS confront. Hence, gathering information from the industrial practitioners that work on the development of GHIS is crucial for knowing the significance of identified factors. The snowball approach [27] was used to invite survey participants. All participants were connected through various means, such as Facebook, e-mail, LinkedIn, and professional relationships with their other researchers. The data were collected from January 2021 to December 2021. We have received responses from 56 participants based on the questionnaires survey. The responses were further checked, and thus, none were found incomplete. We observed that most of the responses are from developing organizations that were residing both in Asia and Europe. Members of the development team varied from software developers to project managers. They were all well versed in both the RE and GHIS processes. Table 2 contains the demographics of the respondents.Table 2
Respondent’s demographic data.
S. NoJob titleExperience (years)CountryPrimary business functionAdopted RE standards/modelsRE process in operation (years)1Software application developer7AustraliaCollected/GHISCMMI Level 232Professor10ThailandResearcherCMMI Level 243Project manager8AustraliaCollected/GHISCMMI Level254CEO5ItalyCollected/GHISCMMI Level 235Senior web developer4PakistanCollected/GHISNo06IT in-charge3Saudi ArabiaCollected/GHISNO17Software Manager3PakistanCollected/GHISNO08Associated project manager4GermanyCollected/GHISCMMI Level259IT instructor3ArgentinaEducation researcherCMMI level 2010Professor9Saudi ArabiaEducation researcherCMMI Level 2211Software developer5MalaysiaCollectedNo312Global software project manager4TurkeyCollected/GHISNot sure513Research assistant3PakistanCollected/GHISNo014Operational manager8PakistanCollected (ERP-SAP)Not sure015Software manager2ItalyCollected software developmentNO216Software developer5VietnamCollected/GHISOwn developed117Management system controller5MalaysiaCollected/GHISNo018Manager4UAECollected/GHISNot sure319Researcher7CanadaCollected/GHISSSP-3 CMMI-2320Professor11NetherlandResearcherCMMI level 2321Professor (researcher)6IndonesiaEducation (collected/GHIS)No022Software tester3JapanCollected/GHISSSP-CMMI Level 2223Lecture6SwedenGHISSelf-developed424Director of it3PakistanEducationNot sure025Software developer7IndonesiaCollected/GHISNil226Director of finance6PakistanEducationNot sure127Requirement engineer5USAGHISSelf-developed328Software project manager4SpainMulti-site developmentNot sure229Lecture6SwedenEducationNot sure030Assistant project manager2ThailandLocal development and global developmentLocal developed231Research assistant4UKEducation and researchSelf-developed332Cite manager2CanadaGHISCMMI-2233Product manager3New- ZealandResearch/local developmentNot sureNil34Quality controller7USASoftware development/and researcherSelf-developed435Professor12AustraliaResearcherCMMI-Level 2536Software developer7AustraliaGHIS/local developmentLocal developed537Assistant professor6IndiaResearcherNot sureNot sure38Deputy IT manager4PakistanEducation/researcherSelf-developed139Manager5MalaysiaLocal software maintenanceDeveloped by organization440Director of IT department3PakistanEducationNil041Senior developer9NetherlandLocal developmentOrganization procedureNot sure42Professor6Saudi ArabiaEducationSpecial practice CMMI243Web engineer4ChinaLocal/GHISNo044Researcher7GermanyEducationNot sureNot sure45Project controller3SpainResearcherSelf-organizedNil46Project coordinator4JapanGHIS developmentSelf-developed447Requirement engineer6New-ZealandSoftware development and managementNot sureNot sure48Project controller2VietnamCollected/GHISSelf-developedNot sure49Professor (researcher)7ThailandEducation/researcherNONil50Web developer7FranceCollected/GHISNilNil51Research associate6PakistanEducationNot sure05253Chairman department of the software system5PakistanResearcher/teachingNot sure354Lecture10+AustraliaEducationCMMINil55Dot net developer12IndiaDistributed software developmentOrganization framework456Senior developer9NetherlandLocal developmentOrganization procedureNot sure


### 2.2.3. Survey Data Analysis

A frequency analysis technique was followed to organize descriptive data. Frequency tables were used to show the frequencies and percentages of the data collected throughout the primary studies. Frequency analysis may be used to investigate variable groupings and ordinal and numeric data [28]. We examined the respondents’ agreement with each identified difficulty to determine the significance of the researched challenges. Different scholars have used the frequency analysis approach in several contexts [29].


## 2.2.1. Survey Questionnaire Development

We prepared an online survey questionnaire based on the findings of the literature study to evaluate the challenges of the requirement engineering process in the context of GHIS. The survey approach was successful in obtaining data from a broad target population [21]. Furthermore, the survey approach allows us to gather data that are difficult to obtain using the observational method [25, 26]. To collect information from RE, GHIS, and healthcare information system practitioners, we devised a closed-ended questionnaire. The poll questions were based on the 17 challenges that the literature research looked at. The respondent's response was obtained using a five-pointed Likert scale that included “strongly agree, agree, neutral, disagree, and strongly disagree.” The survey instrument was then tested with professionals to ensure that it was readable and understandable. The professionals came from five different companies (Techlogix Pvt, Netsole, and Radixwb) and two educational institutions (“Abu Dhabi University, UAE, and King Fahd University of Petroleum and Minerals, Saudi Arabia, Nanjing University, Nanjing”). They suggest certain changes to the questionnaire’s framework and the bibliographic information provided by responders. The questionnaire was revised based on expert comments, and the final version was utilized for data collection. A sample of the used questionnaire was given in Table 1.Table 1
Questionnaire survey.
Section-A1 Respondents personal detailFull name (optional)E-mail addressCountryJob title in industry/academicThe current address of your organizationWorking experience (Years) in global healthcare information system and requirement engineering process.How many years of industry/academia experience do you have in your field?Have you ever participated in requirement engineering and management activities?Yes □No □Section-A2 respondents organization detailName of organization (optional).What is the primary business of your organization?□ Collected software development□ Global healthcare information system□ Others□ Research□ EducationPlease specify the number of employees in your organization?□ Less than 20□ 20–100□ 101–200□ More than 200Please specify the nature of your organization?□ National□ Multinational□ Not sure□ OthersDoes your organization adopt software requirement engineering standards or models? (Please specify)How long has the requirement engineering process been in operation in your organization? (Years)Section B-Software requirement engineering barriers and their best practices in the global healthcare information system environment.The aim of this section is to specify the barriers that could negatively impact the requirement engineering process in global healthcare information system organizations. Please rank each barrier according to your understanding and experience.S. D = strongly disagree, D = disagree, N= neutral, A = Agree, and S. A = strongly agreeSr.NOIdentified barriers of the requirement engineering process in GHIS environmentS.DDNAS.AB1Consider emotions and personal values□□□□□B2Scope change and creep□□□□□B3Ad hoc change management and lack of traceability□□□□□B4Fear of intrusion□□□□□B5Distributed healthcare teams□□□□□B6Uncertainties and rapidly changing technology□□□□□B7Insufficient requirement quality□□□□□B8Unclear and fuzzy stakeholders’ expectations□□□□□B9Lack of terminologies understandings□□□□□B10The negative attitude of society toward using HIS□□□□□B11Missing traceability□□□□□B12The difference in working situations□□□□□B13Environmental constraints at GHIS sites□□□□□B14Communication flows in project teams and clients□□□□□B15Privacy and protection of patient data□□□□□B16Volatile client business domain□□□□□B17Regulatory issues between distributed teams□□□□□Please add additional barriers if any.Section-CBest practices for software requirement engineering process in GHIS (available from authors)


## 2.2.2. Data Sources

The purpose of this survey is to learn more about the challenges that practitioners in the requirement engineering of GHIS confront. Hence, gathering information from the industrial practitioners that work on the development of GHIS is crucial for knowing the significance of identified factors. The snowball approach [27] was used to invite survey participants. All participants were connected through various means, such as Facebook, e-mail, LinkedIn, and professional relationships with their other researchers. The data were collected from January 2021 to December 2021. We have received responses from 56 participants based on the questionnaires survey. The responses were further checked, and thus, none were found incomplete. We observed that most of the responses are from developing organizations that were residing both in Asia and Europe. Members of the development team varied from software developers to project managers. They were all well versed in both the RE and GHIS processes. Table 2 contains the demographics of the respondents.Table 2
Respondent’s demographic data.
S. NoJob titleExperience (years)CountryPrimary business functionAdopted RE standards/modelsRE process in operation (years)1Software application developer7AustraliaCollected/GHISCMMI Level 232Professor10ThailandResearcherCMMI Level 243Project manager8AustraliaCollected/GHISCMMI Level254CEO5ItalyCollected/GHISCMMI Level 235Senior web developer4PakistanCollected/GHISNo06IT in-charge3Saudi ArabiaCollected/GHISNO17Software Manager3PakistanCollected/GHISNO08Associated project manager4GermanyCollected/GHISCMMI Level259IT instructor3ArgentinaEducation researcherCMMI level 2010Professor9Saudi ArabiaEducation researcherCMMI Level 2211Software developer5MalaysiaCollectedNo312Global software project manager4TurkeyCollected/GHISNot sure513Research assistant3PakistanCollected/GHISNo014Operational manager8PakistanCollected (ERP-SAP)Not sure015Software manager2ItalyCollected software developmentNO216Software developer5VietnamCollected/GHISOwn developed117Management system controller5MalaysiaCollected/GHISNo018Manager4UAECollected/GHISNot sure319Researcher7CanadaCollected/GHISSSP-3 CMMI-2320Professor11NetherlandResearcherCMMI level 2321Professor (researcher)6IndonesiaEducation (collected/GHIS)No022Software tester3JapanCollected/GHISSSP-CMMI Level 2223Lecture6SwedenGHISSelf-developed424Director of it3PakistanEducationNot sure025Software developer7IndonesiaCollected/GHISNil226Director of finance6PakistanEducationNot sure127Requirement engineer5USAGHISSelf-developed328Software project manager4SpainMulti-site developmentNot sure229Lecture6SwedenEducationNot sure030Assistant project manager2ThailandLocal development and global developmentLocal developed231Research assistant4UKEducation and researchSelf-developed332Cite manager2CanadaGHISCMMI-2233Product manager3New- ZealandResearch/local developmentNot sureNil34Quality controller7USASoftware development/and researcherSelf-developed435Professor12AustraliaResearcherCMMI-Level 2536Software developer7AustraliaGHIS/local developmentLocal developed537Assistant professor6IndiaResearcherNot sureNot sure38Deputy IT manager4PakistanEducation/researcherSelf-developed139Manager5MalaysiaLocal software maintenanceDeveloped by organization440Director of IT department3PakistanEducationNil041Senior developer9NetherlandLocal developmentOrganization procedureNot sure42Professor6Saudi ArabiaEducationSpecial practice CMMI243Web engineer4ChinaLocal/GHISNo044Researcher7GermanyEducationNot sureNot sure45Project controller3SpainResearcherSelf-organizedNil46Project coordinator4JapanGHIS developmentSelf-developed447Requirement engineer6New-ZealandSoftware development and managementNot sureNot sure48Project controller2VietnamCollected/GHISSelf-developedNot sure49Professor (researcher)7ThailandEducation/researcherNONil50Web developer7FranceCollected/GHISNilNil51Research associate6PakistanEducationNot sure05253Chairman department of the software system5PakistanResearcher/teachingNot sure354Lecture10+AustraliaEducationCMMINil55Dot net developer12IndiaDistributed software developmentOrganization framework456Senior developer9NetherlandLocal developmentOrganization procedureNot sure


## 2.2.3. Survey Data Analysis

A frequency analysis technique was followed to organize descriptive data. Frequency tables were used to show the frequencies and percentages of the data collected throughout the primary studies. Frequency analysis may be used to investigate variable groupings and ordinal and numeric data [28]. We examined the respondents’ agreement with each identified difficulty to determine the significance of the researched challenges. Different scholars have used the frequency analysis approach in several contexts [29].


## 2.3. Analytical Hierarchy Process (AHP)

The analytical hierarchy process (AHP) is considered a multicriteria decision-making method that is employed to rank factors. This strategy has been previously used in several studies to prioritize the aspects of their interest project [30–32]. To prioritize the researched challenges of the requirement engineering process in the context of GHIS, the same technique is used in this study. The stages of AHP are depicted in Table 3.Table 3
AHP steps for analysis of factors.
Sr. NoAHP phasesPhase 1As indicated in Figure2, classifying the goals, categories (factors), and their related barriers (subfactors).Phase 2Based on the expert’s opinions, a pairwise comparison matrix of obstacles is created.Phase 3Using pairwise comparisons, the priority weight of each barrier category and subcategory is calculated.Phase 4The reliability of the decisions is examined.Phase 5The local weights of each barrier in their resultant categories are calculated.Phase 6The global weight of each category and factor is calculated.Phase 7The final ranking of the identified challenges.Figure 2
Hierarchy of the AHP.


## 3. Study Findings

The results of the study are discussed in this section.


### 3.1. Informal Literature Review (RQ 1)

Healthcare is a field in which it needs to develop a system that precisely and accurately mitigates the healthcare-related problem in an efficient way. Furthermore, it helps doctors or researchers to identify the actual problem and research limitations. But while developing these kinds of complex systems, there needs to be an understanding of the significant role of the requirement engineering stages of the system development life cycle (SDLC). It becomes more difficult to address or collect the requirements when the system has to be developed in the global healthcare information system (GHIS) domain due to the high competition among organizations that develop the complex healthcare system.The software businesses are driven to shift their development events from a collocated development environment to be distributed such as GHIS [21] due to the business gains in the healthcare area. The implementation of GHIS, however, is not simple. GHIS is tied with several challenges, the most significant of which is the requirement engineering process [33]. A little research has been undertaken to identify the challenges in requirement engineering procedure, according to the extant literature. The research found that the challenges to the RE process are the fundamental reasons for project failure in a case study [34]. Furthermore, another research said that the requirement engineering is considered as the fundamental part of the software development process and that all development activities are dependent on it, demonstrating the importance of the RE process in software development [35]. As a result, in the GHIS environment, there is a large research gap in the requirement engineering process. However, the growing popularity of GHIS prompted us to look at the challenges related to the requirements of engineering working in GHIS. We conducted a thorough review of the state-of-the-art literature and discovered that several researchers described the challenges that RE practitioners encounter while using GHIS. According to research by Kotonya [36], there is insufficient practice and standards for requirement engineering at GHIS locations. The relevance of standard and method for requirement engineering at GHIS was underlined by [37]. They further said that since there are no RE standards, and practitioners are unsure about how to gather and manage needs. The majority of the known types of research suggested that insufficient economic maturity is a barrier to the implementation of RE processes [19]. Most vendor businesses were experiencing financial difficulties and did not view the RE process as a key activity in software development [38]. The RE process is negatively impacted by a lack of funding, which is the primary source of inefficient requirement gathering and management [14]. We identified insufficient management of commitment as a significant barrier to the RE process in the GHIS context through our literature review. Because of the geographical distance between GHIS locations, due to a lack of established linkages between client and vendor organizational management, both are afraid to provide critical information [24]. Furthermore, another research claims that GHIS practitioners lacked confidence due to the physical distance between development locations [39]. The absence of trust is a key challenge in software development, particularly in the RE process, because RE is completely reliant on communication and collaboration [40]. When there is an absence of confidence among RE practitioners, collecting pure criteria becomes extremely challenging. Furthermore, we discovered cultural differences to be a significant impediment to the RE process in the GHIS area [41, 42]. Team members in GHIS may be geographically and culturally diverse [43]. It is critical to overcome these cultural disparities in order to successfully carry out the RE process [44]. Distributed sites, for example, may not be able to interact with one another in their original languages [29]. The language barrier between geographically separated teams is a substantial impediment to proper requirement collection [45]. Furthermore, the difference between geographically dispersed practitioners is a key roadblock in the gathering and administration of requirements. Table 4 lists all of the various barriers that were explored.Table 4
A list of the challenges to the requirement engineering process in GHIS.
Sr. NoInvestigated barriersB1Consider emotions and personal valuesB2Scope change and creepB3Ad hoc change management and lack of traceabilityB4Fear of intrusionB5Distributed healthcare teamsB6Uncertainties and rapidly changing technologyB7Insufficient requirement qualityB8Unclear and fuzzy stakeholder expectationsB9Lack of understanding of terminologiesB10The negative attitude of society toward using HISB11Missing traceabilityB12Difference in working situationsB13Environmental constraints at GHIS sitesB14Communication flows in project teams and clientsB15Privacy and protection of patient dataB16Volatile client business domainB17Regulatory issues between distributed teamsThe investigated barriers were further categorized into three core categories, i.e., “organizational management,” “human resource management,” and “coordination.” The investigated barriers were categorized based on the understanding with respect to the effect of barriers on the RE process in the context of GHIS. In the categorization process, all the authors and experts (discussed in Section2.2.1) were involved [8, 25, 38]. The mapping results revealed that the majority of the challenges analyzed are connected to the “coordination” category. All the mapping results are given in Table 5.Table 5
Categorization of investigated barriers.
Organizational managementB1Consider emotions and personal valuesB2Scope change and creepB3Ad hoc change management and lack of traceabilityB4Fear of intrusionHuman resource managementB5Distributed healthcare teamsB6Uncertainties and rapidly changing technologyB7Insufficient requirement qualityB8Unclear and fuzzy stakeholder expectationsB9Lack of understanding of terminologiesCoordinationB10The negative attitude of society toward using HISB11Missing traceabilityB12The difference in working situationsB13Environmental constraints at GHIS sitesB14Communication flows in project teams and clientsB15Privacy and protection of patient dataB16Volatile client business domainB17Regulatory issues between distributed teams


### 3.2. Results of Empirical Investigation (RQ 2)

We created an online questionnaire survey document to validate the identified barriers that are hindering the successful implementation of the healthcare information system. In the questionnaire survey study, the barrier was analyzed based on the influence of positive, negative, or natural categories. The respondents can choose any option based on their experience and assessment of the significance of the barrier. Furthermore, “strongly agree (S.A)” and “agree (A)” are in a positive category, whereas “strongly disagree (S.D)” and “disagree (D)” are in the negative category (N). The positive group included replies from survey responses who believe the examined barriers are crucial to address, whereas the negative category included responses from survey participants who did not see the researched barriers as challenges for the GHIS. The results of those who took part in the survey were unsure about the literature survey that studies were given in the neutral category.Table6 shows that more than 70% of respondents agreed with the conclusions of the literature survey. The respondents’ opinions show the investigated barriers have a negative influence on the requirement engineering process in GHIS.Table 6
Response of questionnaire survey study.
S. no.Investigated barriersEmpirical observations (N = 56)PositiveNegativeNeutralS.AA%S.DD%N%B1Consider emotions and personal values14348623935B2Scope change and creep1625732314713B3Ad hoc change management and lack of traceability12277006111120B4Fear of intrusion16175941127814B5Distributed healthcare teams1425703820611B6Uncertainties and rapidly changing technology1228712716713B7Insufficient requirement quality1823730351221B8Unclear and fuzzy stakeholders’ expectations1825771511713B9Lack of terminologies understandings1523685721611B10The negative attitude of society toward using HIS162980227713B11Missing traceability1725752411814B12Difference in working situations172779329713B13Environmental constraints at GHIS sites1129712818611B14Communication flows in project teams and clients1626752411814B15Privacy and protection of patient data19308805924B16Volatile client business domain1624713291120BA17Regulatory issues between distributed teams222584113814However, B15 (Privacy and protection of patient data, 88%) and B1 (Consider emotions and personal values, 86%) were cited as the most important barriers. Few researchers conducted a case study and emphasized that standards and procedures for the requirement’s engineering phase are necessary in order to collect the pure requirements and to manage the requirements based on the stakeholder’s expectations. Another study emphasized the need for standards and processes for the successful execution of the requirement engineering process, particularly at GHIS sites [25, 46]. Another research conducted a study that indicated the importance of geographically distributed client-vendor relationships. Similarly, requirement engineering, according to Prikladnicki, is communication- and collaboration-focused activity in the software development life cycle, which is based on the relationships of GHIS teams. Khan argued that good relationships are helpful to create trust among GHIS practitioners [47]. So, in the case of GHIS, the lack of geographically scattered client-vendor interactions is a significant impediment to the requirement engineering process.In addition, B4 (Fear of intrusion, 27%) was observed as an important barrier in a negative category (Table5). This indicated that 27% of the survey participants were agreed that the B4 is not a barrier for requirement engineering in GHIS. B5 (Lack of terminologies understandings, 21%) and B16 (Distributed healthcare teams, 20%) were declared as the second and third most significant barriers in the negative category.Table6 displays the findings of the study, and thus, B7 (Insufficient requirement quality, 21%) and B3 (Ad hoc change management and lack of traceability, 20%) were the most commonly discussed barriers in the neutral category in the literature. This meant that 21% of respondents were not clear how B7 and B3 affected the requirement engineering process.


### 3.3. Analytical Hierarchy Process (RQ 3)

We used the AHP steps, which are described in Section2.3, to rank the investigated RE process challenges and their categories (Table 4). This strategy was developed by Saaty [48] and has been applied to solve complicated decision-making issues in a variety of other disciplines [49–51].


#### 3.3.1. Phase 1 (Categorizing the Objective, the Categories (Factors), and the Challenges (Sub-Factors) That They Entail)

We divided a complex decision-making problem into interlined decision elements at this step. As illustrated in Figure2, the complex judgment problem is broken into at least three levels in the hierarchy structure. The first level of this hierarchical structure indicates the core purpose of the decision-making problem, while levels 2 and 3 identify the subcategories. The proposed hierarchy structure of this study is indicated in Figure 3.Figure 3
Proposed hierarchy structure.


#### 3.3.2. Phase 2 (Based on Expert Judgment, a Pairwise Comparison Matrix of Barriers Was Built)

The phase 2 of the analytical hierarchy process describes the use of the pairwise comparison technique [31]. The weight (W) of each identified barrier from the primary research and their associated category can be calculated using the pairwise comparison approach. In this approach, the challenge factor and their supercategories are compared with other categories and barriers on each level. Therefore, the pairwise matrix was adopted and then calculated the weight (W) of barriers and categories based on the comparison. The calculated weight (W) revealed the ranking level of each category and then among all three categories. We further invited an expert panel (discussed in Section 2.2.1) to validate our result of comparison scores. The questionnaire survey was used to collect the responses from the practitioners that are available at https://tinyurl.com/yachfe6h. We utilized a “standardized nine-point comparison scale” to report the thoughts of the respondents (Table 7). As illustrated in matrix A (n n), a comparison matrix was created for each reported barrier and its categories. Table 8 shows the comparison matrix for the organization category.Table 7
Description of the intensity scale.
DescriptionSignificance intensity“Equally important”1“Moderately important”3“Strongly more important”5“Very strongly more important”7“Extremely more important”9“Intermediate values”2, 4, 6, 8(1)Matrix−An×n1a12a1na211a2nan1an21.Table 8
Comparison of the barriers in the “organizational management” category on a pair-by-pair basis.
S. NoB1B2B3B4B11756B21/711/53B31/5511/5B41/61/351Total1.5113.3311.2010.20


#### 3.3.3. Phase 3 (Calculation of Priority Weight (W) of Each Barrier)

Phase 3 calculates the priority weights (W) of each identified barrier from the primary study. Therefore, the following steps were considered to calculate the priority weight.(i)
Normalization, calculated by dividing each element in the column by the sum of that column(ii)
Weight (W), calculate the average of each row


#### 3.3.4. Phase 4 (Determining the Matrix's Consistency)

The following steps were followed to calculate the matrix consistency.(i)
λ = [Calculated sum of every column of pairwise comparison matrix (Table 8)] × {Weight (W) vector (Table 9)}(ii)
λ = (1.51 × 0.36) + (13.33 × 0.11) + (11.20 × 0.10) + (10.20 × 0.11)(iii)
λ = 4.20(iv)
Consistency index (CI) =λ−n/n−1 = 0.067 (n = Number of criteria)(v)
Random index (RI) = 0.9 (RI = Random index, Table10)(vi)
Consistency ratio (CR) =CI/RI = 0.074 < 0.1 (consistent)Table 9
Normalized matrix of “organizational management” category.
S. NoB1B2B3B4Weight (W)B10.510.270.230.440.36B20.090.080.020.240.11B30.130.170.090.020.10B40.110.020.190.100.11Table 10
Random consistency index (RI) with respect to matrix size.
Size of matrix12345678910RI000.580.91.121.241.321.411.451.49The aforementioned steps were followed in order to calculate the weights and consistency of the respective categories of barriers such as “human resource management category” Table11 and “coordination category” Table 12. The comparison among all categories is then presented in Table 13.Table 11
Pairwise comparison between the barriers of the “human resource management” category.
S. NoB5B6B7B8B9Weights (W)B5131/51/730.10B61/311/31/530.09B75311/530.15B87551½0.14B91/31/31/3210.13Λ = 5.37, CI = 0.0925, RI = 1.12, CR = 0.08 < 0.1 (consistent).Table 12
Pairwise comparison between the barriers of “coordination” category.
S. NoB10B11B12B13B14B15B16B17Weight (W)B1011/3431/521/71/30.04B113131/61/731/540.09B121/41/3131/51/31/41/20.03B131/361/311/331/530.08B1457531721/30.17B151/21/331/31/711/750.06B1675451/27150.11B1731/421/331/51/510.07Λ = 8.65, CI = 0.0928, RI = 1.41, and CR = 0.067 < 0.1 (consistent).Table 13
Pairwise comparison between the categories of the barriers.
Sr. NoOrganizational managementHuman resource managementCoordinationWeight (W)Organizational management131/30.31Human resource management1/311/50.11Coordination2510.58Λ = 3.043, CI = 0.025, RI = 0.57, and CR = 0.0385 < 0.1 (consistent).


#### 3.3.5. Phase 5 (Determining the Local Weight)

Phase 5 focuses on calculating the local weight (LW) of the identified barriers from the primary study. The local weight helps in ranking the identified barriers within each respective category such as the local weight of B1 is 0.36 in the organizational management category. Therefore, the local weights (LW) of barriers are calculated and presented in Table14.Table 14
Local and global ranking of barriers.
CategoriesCategory weightsBarriersLocal weightsLocal rankingGlobal weightsGlobal rankingOrganizational management0.30B10.3510.1111B20.1060.0338B30.970.0309B40.1060.0338Human resource management0.10B50.0970.01015B60.0880.00816B70.1430.01512B80.1340.01413B90.1250.01314Coordination0.57B100.02120.02210B110.0880.0514B120.02130.01811B130.0790.0455B140.1620.0972B150.05110.0347B160.1160.0643B170.07100.0406


#### 3.3.6. Phase 6 (Determining the Global Weight)

The barriers were further analyzed and in phase 6 and thus calculated the global weight (GW) of identified factors from the literature review. The global weight (GW) is then presented in Table14. The ultimate objective of calculating the global weight was to figure out the influence of identified barriers on the overall study. However, the global weight is obtained by multiplication of local weights presented in (Tables 9, 11, and 12) with category weight (as determined in Table 13), e.g., B1 = 0.36 ∗ 0.31 = 0.112 is the global weight of B1. The global weight would help us to prioritize the barriers in phase 7.Figure4 demonstrates that B1 (Consider emotions and personal values), B2 (Scope change and creep), and B4 (Fear of intrusion) were cited in most of the primary studies in the organizational management category, which are essential to address the requirement engineering process in the domain of GHIS. Similarly, B7 (Insufficient requirement quality) is considered as the highest priority barrier in the human resource management category. The second most important barrier in the human resource management category is B8 (Unclear and fuzzy stakeholders’ expectations).Figure 4
Taxonomy of RE barriers with global and local weights.Furthermore, we observed that the most significant cited barrier in the coordination category is B14 (Communication flows in project teams and clients) and the B16 (Volatile client business domain) was reported in the primary study as the second most important barrier for the successful execution of requirement engineering process in the context of GHIS. The global weight was further calculated based on the categories, and thus, results showed that the coordination category is the most important to address and then organizational management and human resource management, respectively. This analysis shows the importance of categories and their respective barriers that need much intention to address.


#### 3.3.7. Phase 7 (Prioritizing the Barriers)

Phase 7 of the analytical hierarchy process (AHP) leads to the ranking of investigated barriers from high to relatively low. Therefore, we considered the global ranking analysis of identified barriers presented in (Table14) and thus arranged them according to their priority. The final ranking list of barriers is presented in Table 15.Table 15
Final priority of the barriers.
S. NoInvestigated barriersPriorityB1Consider emotions and personal values1B14Scope change and creep2B16Ad hoc change management and lack of traceability3B11Fear of intrusion4B13Distributed healthcare teams5B17Uncertainties and rapidly changing technology6B15Insufficient requirement quality7B2Unclear and fuzzy stakeholders’ expectations8B4Lack of understanding of terminologies8B3The negative attitude of society toward using HIS9B10Missing traceability10B12The difference in working situations11B7Environmental constraints at GHIS sites12B8Communication flows in project teams and clients13B9Privacy and protection of patient data14B5Volatile client business domain15B6Regulatory issues between distributed teams16


## 3.1. Informal Literature Review (RQ 1)

Healthcare is a field in which it needs to develop a system that precisely and accurately mitigates the healthcare-related problem in an efficient way. Furthermore, it helps doctors or researchers to identify the actual problem and research limitations. But while developing these kinds of complex systems, there needs to be an understanding of the significant role of the requirement engineering stages of the system development life cycle (SDLC). It becomes more difficult to address or collect the requirements when the system has to be developed in the global healthcare information system (GHIS) domain due to the high competition among organizations that develop the complex healthcare system.The software businesses are driven to shift their development events from a collocated development environment to be distributed such as GHIS [21] due to the business gains in the healthcare area. The implementation of GHIS, however, is not simple. GHIS is tied with several challenges, the most significant of which is the requirement engineering process [33]. A little research has been undertaken to identify the challenges in requirement engineering procedure, according to the extant literature. The research found that the challenges to the RE process are the fundamental reasons for project failure in a case study [34]. Furthermore, another research said that the requirement engineering is considered as the fundamental part of the software development process and that all development activities are dependent on it, demonstrating the importance of the RE process in software development [35]. As a result, in the GHIS environment, there is a large research gap in the requirement engineering process. However, the growing popularity of GHIS prompted us to look at the challenges related to the requirements of engineering working in GHIS. We conducted a thorough review of the state-of-the-art literature and discovered that several researchers described the challenges that RE practitioners encounter while using GHIS. According to research by Kotonya [36], there is insufficient practice and standards for requirement engineering at GHIS locations. The relevance of standard and method for requirement engineering at GHIS was underlined by [37]. They further said that since there are no RE standards, and practitioners are unsure about how to gather and manage needs. The majority of the known types of research suggested that insufficient economic maturity is a barrier to the implementation of RE processes [19]. Most vendor businesses were experiencing financial difficulties and did not view the RE process as a key activity in software development [38]. The RE process is negatively impacted by a lack of funding, which is the primary source of inefficient requirement gathering and management [14]. We identified insufficient management of commitment as a significant barrier to the RE process in the GHIS context through our literature review. Because of the geographical distance between GHIS locations, due to a lack of established linkages between client and vendor organizational management, both are afraid to provide critical information [24]. Furthermore, another research claims that GHIS practitioners lacked confidence due to the physical distance between development locations [39]. The absence of trust is a key challenge in software development, particularly in the RE process, because RE is completely reliant on communication and collaboration [40]. When there is an absence of confidence among RE practitioners, collecting pure criteria becomes extremely challenging. Furthermore, we discovered cultural differences to be a significant impediment to the RE process in the GHIS area [41, 42]. Team members in GHIS may be geographically and culturally diverse [43]. It is critical to overcome these cultural disparities in order to successfully carry out the RE process [44]. Distributed sites, for example, may not be able to interact with one another in their original languages [29]. The language barrier between geographically separated teams is a substantial impediment to proper requirement collection [45]. Furthermore, the difference between geographically dispersed practitioners is a key roadblock in the gathering and administration of requirements. Table 4 lists all of the various barriers that were explored.Table 4
A list of the challenges to the requirement engineering process in GHIS.
Sr. NoInvestigated barriersB1Consider emotions and personal valuesB2Scope change and creepB3Ad hoc change management and lack of traceabilityB4Fear of intrusionB5Distributed healthcare teamsB6Uncertainties and rapidly changing technologyB7Insufficient requirement qualityB8Unclear and fuzzy stakeholder expectationsB9Lack of understanding of terminologiesB10The negative attitude of society toward using HISB11Missing traceabilityB12Difference in working situationsB13Environmental constraints at GHIS sitesB14Communication flows in project teams and clientsB15Privacy and protection of patient dataB16Volatile client business domainB17Regulatory issues between distributed teamsThe investigated barriers were further categorized into three core categories, i.e., “organizational management,” “human resource management,” and “coordination.” The investigated barriers were categorized based on the understanding with respect to the effect of barriers on the RE process in the context of GHIS. In the categorization process, all the authors and experts (discussed in Section2.2.1) were involved [8, 25, 38]. The mapping results revealed that the majority of the challenges analyzed are connected to the “coordination” category. All the mapping results are given in Table 5.Table 5
Categorization of investigated barriers.
Organizational managementB1Consider emotions and personal valuesB2Scope change and creepB3Ad hoc change management and lack of traceabilityB4Fear of intrusionHuman resource managementB5Distributed healthcare teamsB6Uncertainties and rapidly changing technologyB7Insufficient requirement qualityB8Unclear and fuzzy stakeholder expectationsB9Lack of understanding of terminologiesCoordinationB10The negative attitude of society toward using HISB11Missing traceabilityB12The difference in working situationsB13Environmental constraints at GHIS sitesB14Communication flows in project teams and clientsB15Privacy and protection of patient dataB16Volatile client business domainB17Regulatory issues between distributed teams


## 3.2. Results of Empirical Investigation (RQ 2)

We created an online questionnaire survey document to validate the identified barriers that are hindering the successful implementation of the healthcare information system. In the questionnaire survey study, the barrier was analyzed based on the influence of positive, negative, or natural categories. The respondents can choose any option based on their experience and assessment of the significance of the barrier. Furthermore, “strongly agree (S.A)” and “agree (A)” are in a positive category, whereas “strongly disagree (S.D)” and “disagree (D)” are in the negative category (N). The positive group included replies from survey responses who believe the examined barriers are crucial to address, whereas the negative category included responses from survey participants who did not see the researched barriers as challenges for the GHIS. The results of those who took part in the survey were unsure about the literature survey that studies were given in the neutral category.Table6 shows that more than 70% of respondents agreed with the conclusions of the literature survey. The respondents’ opinions show the investigated barriers have a negative influence on the requirement engineering process in GHIS.Table 6
Response of questionnaire survey study.
S. no.Investigated barriersEmpirical observations (N = 56)PositiveNegativeNeutralS.AA%S.DD%N%B1Consider emotions and personal values14348623935B2Scope change and creep1625732314713B3Ad hoc change management and lack of traceability12277006111120B4Fear of intrusion16175941127814B5Distributed healthcare teams1425703820611B6Uncertainties and rapidly changing technology1228712716713B7Insufficient requirement quality1823730351221B8Unclear and fuzzy stakeholders’ expectations1825771511713B9Lack of terminologies understandings1523685721611B10The negative attitude of society toward using HIS162980227713B11Missing traceability1725752411814B12Difference in working situations172779329713B13Environmental constraints at GHIS sites1129712818611B14Communication flows in project teams and clients1626752411814B15Privacy and protection of patient data19308805924B16Volatile client business domain1624713291120BA17Regulatory issues between distributed teams222584113814However, B15 (Privacy and protection of patient data, 88%) and B1 (Consider emotions and personal values, 86%) were cited as the most important barriers. Few researchers conducted a case study and emphasized that standards and procedures for the requirement’s engineering phase are necessary in order to collect the pure requirements and to manage the requirements based on the stakeholder’s expectations. Another study emphasized the need for standards and processes for the successful execution of the requirement engineering process, particularly at GHIS sites [25, 46]. Another research conducted a study that indicated the importance of geographically distributed client-vendor relationships. Similarly, requirement engineering, according to Prikladnicki, is communication- and collaboration-focused activity in the software development life cycle, which is based on the relationships of GHIS teams. Khan argued that good relationships are helpful to create trust among GHIS practitioners [47]. So, in the case of GHIS, the lack of geographically scattered client-vendor interactions is a significant impediment to the requirement engineering process.In addition, B4 (Fear of intrusion, 27%) was observed as an important barrier in a negative category (Table5). This indicated that 27% of the survey participants were agreed that the B4 is not a barrier for requirement engineering in GHIS. B5 (Lack of terminologies understandings, 21%) and B16 (Distributed healthcare teams, 20%) were declared as the second and third most significant barriers in the negative category.Table6 displays the findings of the study, and thus, B7 (Insufficient requirement quality, 21%) and B3 (Ad hoc change management and lack of traceability, 20%) were the most commonly discussed barriers in the neutral category in the literature. This meant that 21% of respondents were not clear how B7 and B3 affected the requirement engineering process.


## 3.3. Analytical Hierarchy Process (RQ 3)

We used the AHP steps, which are described in Section2.3, to rank the investigated RE process challenges and their categories (Table 4). This strategy was developed by Saaty [48] and has been applied to solve complicated decision-making issues in a variety of other disciplines [49–51].


### 3.3.1. Phase 1 (Categorizing the Objective, the Categories (Factors), and the Challenges (Sub-Factors) That They Entail)

We divided a complex decision-making problem into interlined decision elements at this step. As illustrated in Figure2, the complex judgment problem is broken into at least three levels in the hierarchy structure. The first level of this hierarchical structure indicates the core purpose of the decision-making problem, while levels 2 and 3 identify the subcategories. The proposed hierarchy structure of this study is indicated in Figure 3.Figure 3
Proposed hierarchy structure.


### 3.3.2. Phase 2 (Based on Expert Judgment, a Pairwise Comparison Matrix of Barriers Was Built)

The phase 2 of the analytical hierarchy process describes the use of the pairwise comparison technique [31]. The weight (W) of each identified barrier from the primary research and their associated category can be calculated using the pairwise comparison approach. In this approach, the challenge factor and their supercategories are compared with other categories and barriers on each level. Therefore, the pairwise matrix was adopted and then calculated the weight (W) of barriers and categories based on the comparison. The calculated weight (W) revealed the ranking level of each category and then among all three categories. We further invited an expert panel (discussed in Section 2.2.1) to validate our result of comparison scores. The questionnaire survey was used to collect the responses from the practitioners that are available at https://tinyurl.com/yachfe6h. We utilized a “standardized nine-point comparison scale” to report the thoughts of the respondents (Table 7). As illustrated in matrix A (n n), a comparison matrix was created for each reported barrier and its categories. Table 8 shows the comparison matrix for the organization category.Table 7
Description of the intensity scale.
DescriptionSignificance intensity“Equally important”1“Moderately important”3“Strongly more important”5“Very strongly more important”7“Extremely more important”9“Intermediate values”2, 4, 6, 8(1)Matrix−An×n1a12a1na211a2nan1an21.Table 8
Comparison of the barriers in the “organizational management” category on a pair-by-pair basis.
S. NoB1B2B3B4B11756B21/711/53B31/5511/5B41/61/351Total1.5113.3311.2010.20


### 3.3.3. Phase 3 (Calculation of Priority Weight (W) of Each Barrier)

Phase 3 calculates the priority weights (W) of each identified barrier from the primary study. Therefore, the following steps were considered to calculate the priority weight.(i)
Normalization, calculated by dividing each element in the column by the sum of that column(ii)
Weight (W), calculate the average of each row


### 3.3.4. Phase 4 (Determining the Matrix's Consistency)

The following steps were followed to calculate the matrix consistency.(i)
λ = [Calculated sum of every column of pairwise comparison matrix (Table 8)] × {Weight (W) vector (Table 9)}(ii)
λ = (1.51 × 0.36) + (13.33 × 0.11) + (11.20 × 0.10) + (10.20 × 0.11)(iii)
λ = 4.20(iv)
Consistency index (CI) =λ−n/n−1 = 0.067 (n = Number of criteria)(v)
Random index (RI) = 0.9 (RI = Random index, Table10)(vi)
Consistency ratio (CR) =CI/RI = 0.074 < 0.1 (consistent)Table 9
Normalized matrix of “organizational management” category.
S. NoB1B2B3B4Weight (W)B10.510.270.230.440.36B20.090.080.020.240.11B30.130.170.090.020.10B40.110.020.190.100.11Table 10
Random consistency index (RI) with respect to matrix size.
Size of matrix12345678910RI000.580.91.121.241.321.411.451.49The aforementioned steps were followed in order to calculate the weights and consistency of the respective categories of barriers such as “human resource management category” Table11 and “coordination category” Table 12. The comparison among all categories is then presented in Table 13.Table 11
Pairwise comparison between the barriers of the “human resource management” category.
S. NoB5B6B7B8B9Weights (W)B5131/51/730.10B61/311/31/530.09B75311/530.15B87551½0.14B91/31/31/3210.13Λ = 5.37, CI = 0.0925, RI = 1.12, CR = 0.08 < 0.1 (consistent).Table 12
Pairwise comparison between the barriers of “coordination” category.
S. NoB10B11B12B13B14B15B16B17Weight (W)B1011/3431/521/71/30.04B113131/61/731/540.09B121/41/3131/51/31/41/20.03B131/361/311/331/530.08B1457531721/30.17B151/21/331/31/711/750.06B1675451/27150.11B1731/421/331/51/510.07Λ = 8.65, CI = 0.0928, RI = 1.41, and CR = 0.067 < 0.1 (consistent).Table 13
Pairwise comparison between the categories of the barriers.
Sr. NoOrganizational managementHuman resource managementCoordinationWeight (W)Organizational management131/30.31Human resource management1/311/50.11Coordination2510.58Λ = 3.043, CI = 0.025, RI = 0.57, and CR = 0.0385 < 0.1 (consistent).


### 3.3.5. Phase 5 (Determining the Local Weight)

Phase 5 focuses on calculating the local weight (LW) of the identified barriers from the primary study. The local weight helps in ranking the identified barriers within each respective category such as the local weight of B1 is 0.36 in the organizational management category. Therefore, the local weights (LW) of barriers are calculated and presented in Table14.Table 14
Local and global ranking of barriers.
CategoriesCategory weightsBarriersLocal weightsLocal rankingGlobal weightsGlobal rankingOrganizational management0.30B10.3510.1111B20.1060.0338B30.970.0309B40.1060.0338Human resource management0.10B50.0970.01015B60.0880.00816B70.1430.01512B80.1340.01413B90.1250.01314Coordination0.57B100.02120.02210B110.0880.0514B120.02130.01811B130.0790.0455B140.1620.0972B150.05110.0347B160.1160.0643B170.07100.0406


### 3.3.6. Phase 6 (Determining the Global Weight)

The barriers were further analyzed and in phase 6 and thus calculated the global weight (GW) of identified factors from the literature review. The global weight (GW) is then presented in Table14. The ultimate objective of calculating the global weight was to figure out the influence of identified barriers on the overall study. However, the global weight is obtained by multiplication of local weights presented in (Tables 9, 11, and 12) with category weight (as determined in Table 13), e.g., B1 = 0.36 ∗ 0.31 = 0.112 is the global weight of B1. The global weight would help us to prioritize the barriers in phase 7.Figure4 demonstrates that B1 (Consider emotions and personal values), B2 (Scope change and creep), and B4 (Fear of intrusion) were cited in most of the primary studies in the organizational management category, which are essential to address the requirement engineering process in the domain of GHIS. Similarly, B7 (Insufficient requirement quality) is considered as the highest priority barrier in the human resource management category. The second most important barrier in the human resource management category is B8 (Unclear and fuzzy stakeholders’ expectations).Figure 4
Taxonomy of RE barriers with global and local weights.Furthermore, we observed that the most significant cited barrier in the coordination category is B14 (Communication flows in project teams and clients) and the B16 (Volatile client business domain) was reported in the primary study as the second most important barrier for the successful execution of requirement engineering process in the context of GHIS. The global weight was further calculated based on the categories, and thus, results showed that the coordination category is the most important to address and then organizational management and human resource management, respectively. This analysis shows the importance of categories and their respective barriers that need much intention to address.


### 3.3.7. Phase 7 (Prioritizing the Barriers)

Phase 7 of the analytical hierarchy process (AHP) leads to the ranking of investigated barriers from high to relatively low. Therefore, we considered the global ranking analysis of identified barriers presented in (Table14) and thus arranged them according to their priority. The final ranking list of barriers is presented in Table 15.Table 15
Final priority of the barriers.
S. NoInvestigated barriersPriorityB1Consider emotions and personal values1B14Scope change and creep2B16Ad hoc change management and lack of traceability3B11Fear of intrusion4B13Distributed healthcare teams5B17Uncertainties and rapidly changing technology6B15Insufficient requirement quality7B2Unclear and fuzzy stakeholders’ expectations8B4Lack of understanding of terminologies8B3The negative attitude of society toward using HIS9B10Missing traceability10B12The difference in working situations11B7Environmental constraints at GHIS sites12B8Communication flows in project teams and clients13B9Privacy and protection of patient data14B5Volatile client business domain15B6Regulatory issues between distributed teams16


## 3.3.1. Phase 1 (Categorizing the Objective, the Categories (Factors), and the Challenges (Sub-Factors) That They Entail)

We divided a complex decision-making problem into interlined decision elements at this step. As illustrated in Figure2, the complex judgment problem is broken into at least three levels in the hierarchy structure. The first level of this hierarchical structure indicates the core purpose of the decision-making problem, while levels 2 and 3 identify the subcategories. The proposed hierarchy structure of this study is indicated in Figure 3.Figure 3
Proposed hierarchy structure.


## 3.3.2. Phase 2 (Based on Expert Judgment, a Pairwise Comparison Matrix of Barriers Was Built)

The phase 2 of the analytical hierarchy process describes the use of the pairwise comparison technique [31]. The weight (W) of each identified barrier from the primary research and their associated category can be calculated using the pairwise comparison approach. In this approach, the challenge factor and their supercategories are compared with other categories and barriers on each level. Therefore, the pairwise matrix was adopted and then calculated the weight (W) of barriers and categories based on the comparison. The calculated weight (W) revealed the ranking level of each category and then among all three categories. We further invited an expert panel (discussed in Section 2.2.1) to validate our result of comparison scores. The questionnaire survey was used to collect the responses from the practitioners that are available at https://tinyurl.com/yachfe6h. We utilized a “standardized nine-point comparison scale” to report the thoughts of the respondents (Table 7). As illustrated in matrix A (n n), a comparison matrix was created for each reported barrier and its categories. Table 8 shows the comparison matrix for the organization category.Table 7
Description of the intensity scale.
DescriptionSignificance intensity“Equally important”1“Moderately important”3“Strongly more important”5“Very strongly more important”7“Extremely more important”9“Intermediate values”2, 4, 6, 8(1)Matrix−An×n1a12a1na211a2nan1an21.Table 8
Comparison of the barriers in the “organizational management” category on a pair-by-pair basis.
S. NoB1B2B3B4B11756B21/711/53B31/5511/5B41/61/351Total1.5113.3311.2010.20


## 3.3.3. Phase 3 (Calculation of Priority Weight (W) of Each Barrier)

Phase 3 calculates the priority weights (W) of each identified barrier from the primary study. Therefore, the following steps were considered to calculate the priority weight.(i)
Normalization, calculated by dividing each element in the column by the sum of that column(ii)
Weight (W), calculate the average of each row


## 3.3.4. Phase 4 (Determining the Matrix's Consistency)

The following steps were followed to calculate the matrix consistency.(i)
λ = [Calculated sum of every column of pairwise comparison matrix (Table 8)] × {Weight (W) vector (Table 9)}(ii)
λ = (1.51 × 0.36) + (13.33 × 0.11) + (11.20 × 0.10) + (10.20 × 0.11)(iii)
λ = 4.20(iv)
Consistency index (CI) =λ−n/n−1 = 0.067 (n = Number of criteria)(v)
Random index (RI) = 0.9 (RI = Random index, Table10)(vi)
Consistency ratio (CR) =CI/RI = 0.074 < 0.1 (consistent)Table 9
Normalized matrix of “organizational management” category.
S. NoB1B2B3B4Weight (W)B10.510.270.230.440.36B20.090.080.020.240.11B30.130.170.090.020.10B40.110.020.190.100.11Table 10
Random consistency index (RI) with respect to matrix size.
Size of matrix12345678910RI000.580.91.121.241.321.411.451.49The aforementioned steps were followed in order to calculate the weights and consistency of the respective categories of barriers such as “human resource management category” Table11 and “coordination category” Table 12. The comparison among all categories is then presented in Table 13.Table 11
Pairwise comparison between the barriers of the “human resource management” category.
S. NoB5B6B7B8B9Weights (W)B5131/51/730.10B61/311/31/530.09B75311/530.15B87551½0.14B91/31/31/3210.13Λ = 5.37, CI = 0.0925, RI = 1.12, CR = 0.08 < 0.1 (consistent).Table 12
Pairwise comparison between the barriers of “coordination” category.
S. NoB10B11B12B13B14B15B16B17Weight (W)B1011/3431/521/71/30.04B113131/61/731/540.09B121/41/3131/51/31/41/20.03B131/361/311/331/530.08B1457531721/30.17B151/21/331/31/711/750.06B1675451/27150.11B1731/421/331/51/510.07Λ = 8.65, CI = 0.0928, RI = 1.41, and CR = 0.067 < 0.1 (consistent).Table 13
Pairwise comparison between the categories of the barriers.
Sr. NoOrganizational managementHuman resource managementCoordinationWeight (W)Organizational management131/30.31Human resource management1/311/50.11Coordination2510.58Λ = 3.043, CI = 0.025, RI = 0.57, and CR = 0.0385 < 0.1 (consistent).


## 3.3.5. Phase 5 (Determining the Local Weight)

Phase 5 focuses on calculating the local weight (LW) of the identified barriers from the primary study. The local weight helps in ranking the identified barriers within each respective category such as the local weight of B1 is 0.36 in the organizational management category. Therefore, the local weights (LW) of barriers are calculated and presented in Table14.Table 14
Local and global ranking of barriers.
CategoriesCategory weightsBarriersLocal weightsLocal rankingGlobal weightsGlobal rankingOrganizational management0.30B10.3510.1111B20.1060.0338B30.970.0309B40.1060.0338Human resource management0.10B50.0970.01015B60.0880.00816B70.1430.01512B80.1340.01413B90.1250.01314Coordination0.57B100.02120.02210B110.0880.0514B120.02130.01811B130.0790.0455B140.1620.0972B150.05110.0347B160.1160.0643B170.07100.0406


## 3.3.6. Phase 6 (Determining the Global Weight)

The barriers were further analyzed and in phase 6 and thus calculated the global weight (GW) of identified factors from the literature review. The global weight (GW) is then presented in Table14. The ultimate objective of calculating the global weight was to figure out the influence of identified barriers on the overall study. However, the global weight is obtained by multiplication of local weights presented in (Tables 9, 11, and 12) with category weight (as determined in Table 13), e.g., B1 = 0.36 ∗ 0.31 = 0.112 is the global weight of B1. The global weight would help us to prioritize the barriers in phase 7.Figure4 demonstrates that B1 (Consider emotions and personal values), B2 (Scope change and creep), and B4 (Fear of intrusion) were cited in most of the primary studies in the organizational management category, which are essential to address the requirement engineering process in the domain of GHIS. Similarly, B7 (Insufficient requirement quality) is considered as the highest priority barrier in the human resource management category. The second most important barrier in the human resource management category is B8 (Unclear and fuzzy stakeholders’ expectations).Figure 4
Taxonomy of RE barriers with global and local weights.Furthermore, we observed that the most significant cited barrier in the coordination category is B14 (Communication flows in project teams and clients) and the B16 (Volatile client business domain) was reported in the primary study as the second most important barrier for the successful execution of requirement engineering process in the context of GHIS. The global weight was further calculated based on the categories, and thus, results showed that the coordination category is the most important to address and then organizational management and human resource management, respectively. This analysis shows the importance of categories and their respective barriers that need much intention to address.


## 3.3.7. Phase 7 (Prioritizing the Barriers)

Phase 7 of the analytical hierarchy process (AHP) leads to the ranking of investigated barriers from high to relatively low. Therefore, we considered the global ranking analysis of identified barriers presented in (Table14) and thus arranged them according to their priority. The final ranking list of barriers is presented in Table 15.Table 15
Final priority of the barriers.
S. NoInvestigated barriersPriorityB1Consider emotions and personal values1B14Scope change and creep2B16Ad hoc change management and lack of traceability3B11Fear of intrusion4B13Distributed healthcare teams5B17Uncertainties and rapidly changing technology6B15Insufficient requirement quality7B2Unclear and fuzzy stakeholders’ expectations8B4Lack of understanding of terminologies8B3The negative attitude of society toward using HIS9B10Missing traceability10B12The difference in working situations11B7Environmental constraints at GHIS sites12B8Communication flows in project teams and clients13B9Privacy and protection of patient data14B5Volatile client business domain15B6Regulatory issues between distributed teams16


## 4. Summary of Study Results

Requirement engineering is an initial and fundamental phase of system development that needs a precise concentration aiming to collect and analyze the requirements concerning to stakeholder’s needs, budget, time, and resources [52]. The ultimate objective of conducted research study is to develop a software requirement engineering healthcare implementation maturity model (SRE-HIMMM) for the healthcare organizations working in the global healthcare information system (GHIS). The development of SRE-HIMM consists of three influencing factors, i.e., barriers, success factors, and the best practices. In this study, we discussed an initial phase of SRE-HIMM, which is the identification of barriers from the state-of-the-art literature and prioritizing them after validating with real-world practitioners. For this purpose, we have extracted seventeen challenges that are being faced by organizations developing in the domain of GHIS. The identified challenges were further mapped into three respective categories (i.e., “organizational management,” “human resource management,” and “coordination”). The categorization mapping results show that most of the challenging factors lie in the coordination category than the “organizational management” and “human resource management” categories.Furthermore, we developed and organized the online questionnaire survey study with the industrial practitioners and researchers working in the domain of global software environment (GSD). We collected the responses from the 56 survey respondents and further analyzed them. The result of respondents was further summarized, and it is noticed that respondent’s resultsR.R > 70% were in favor of the identified challenging factors from the state-of-the-art literature review. The result of our findings showed a significant effect of barriers on the development process in the GHIS environment. The finding was further analyzed by applying the analytical hierarchy process (AHP) approach. The AHP techniques helped us to prioritize the investigated challenging factors and their respective categories. The finding of AHP analysis revealed that “coordination” is considered the most influential category that needs much research to address the challenges in order to make the GHIS successful. Similarly, the B1 (Consider emotions and personal values) among the 17 barriers is considered the most important barrier that needs to be addressed for the successful development of healthcare systems in the GHIS environment. Similarly, B14 (Scope change and creep) is considered as the second most important barrier and B16 (Ad hoc change management and lack of traceability) is considered the third most critical challenging factor that needs much attention for the successful implementation of the RE process in GHIS organizations. However, all the challenges and their respective category and final ranking are presented in Table 15.


## 5. Conclusions and Future Directions

To enhance the efficiency and accuracy of the medical field, organizations are developing more and more intelligent healthcare information systems. The significance of healthcare information system development in the context of the global healthcare information system (GHIS) environment encouraged us to explore the barriers of requirement engineering (RE). Thus, the motivation leads us to identify the key 17 barriers that are considered as the most critical for the successful implementation of GHIS phenomena. Furthermore, the questionnaire-based survey study was conducted in order to check the significance of identified factors in the real-world industry. The survey study results highlighted that the identified barriers are critically effective and efficient RE in the GHIS context. We further employed the analytical hierarchy process (AHP) methods for ranking the analyzed barriers concerning their significance for the GHIS RE process. The AHP results show that “coordination” is the highest-ranked barrier category that needs to be considered on a priority basis for effective RE in the GHIS domain. The highest-ranked barriers for the RE process are as follows: “Consider emotions and personal values,” “Scope change and creep,” “Ad hoc change management and lack of traceability,” and “Fear of intrusion.” The results of this study present a priority-based analysis of challenging factors that will assist researchers to consider the highest priority challenges of their interests. The findings of the study provide a framework that is helpful for researchers and practitioners to focus on the most priority barriers of RE in the GHIS context.This study is an initiative toward the development of the software RE global healthcare information system maturity model (SRE-HIMM). The first phase of the model addresses the challenges being faced by organizations and then moves toward the second phase where key success factors will be analyzed. The final phase will address key best practices for motivating and improving the actual RE process leading toward the development of the (SRE-HIMM) maturity model. The anticipated model will follow the guidelines of currently used maturity models in different research areas of software engineering [19]. The model depicted in Figure 5 presents the actual flow toward the development of SRE-HIMM. The proposed maturity models are comprised of two main maturity levels, i.e., critical barriers (CBs) and critical success factors (CSFs). However, this research study addresses the first phase of the proposed model.Figure 5
Proposed guidelines for SRE-HIMM.The analyzed challenges are deemed to be less for the proposed model. Thus, we intended to perform a thorough systematic literature review (SLR) and empirical study with industrial practitioners for the identification of further challenging factors that will support the validity of the proposed model. The aforementioned steps will be followed for the validity of success factors and best practices that are other main elements of the SRE-HIMM model. The final model will assist the organization to better handle the way they are doing RE activities in the GHIS environment.



---

*Source: 8276662-2022-02-15.xml*