Requirements Engineering: A State of Practice in Gulf Cooperation Countries

Requirement Engineering (RE) is one of the crucial elements for successful software development. Nevertheless, in terms of research discussing the failure or success of various products, little has been undertaken to examine this area as it pertains to the Gulf Cooperation Council (GCC) nations, i.e. Saudi Arabia (KSA), Kuwait, United Arab Emirates (UAE), Bahrain, Qatar, and Oman. The aim of this research is to present an analysis of the current ways in which software is developed in these nations. The researchers undertook a survey of practitioners in software development, asking questions regarding their recent work. The survey was based on an extensive survey that was adapted in view of contemporary software development practice. The research reports on requirement practices and how they relate to project sponsors/customers/users and project management. The respondents came from GCC nation companies, most of whom worked on developing software in-house. The outcomes demonstrate that the majority of IT companies in these nations do not employ the optimal methodologies for requirement engineering processes, using their own. In addition, project managers are often lacking in complete authority. Making comparisons between our findings and past research, requirements engineering practices is still inadequate in these nations. Thus the research results are particularly useful as the data is derived from countries where published research about software development practices is scant. Keywords—Requirements engineering; project success; software development; requirements engineering practices; GCC


I. INTRODUCTION
Although a considerable amount of research has been undertaken with the aim of designing novel improved solutions to address software development (SD) difficulties [1][2][3], it is crucial to develop an understanding of contemporary software development methods and which of them offers optimal outcomes. Past research has demonstrated that accuracy and completeness in the requirements engineering (RE) practices of developers play a significant part in the success or failure [4][5][6].
Hall et al. [7] have stated that a significant number of difficulties with SD are a result of poor RE. Having to amend requirements in the final stages of a project is extremely expensive [8,9]. Much research [10][11][12] has found that successful IT projects are comparatively rare, with approximately 20% being complete failures, with 50% either being delivered late, over budget, and/or without all requirements fulfilled. 44% of projects that fail do so as a result of inadequate RE. From the 1990s onwards, researchers have proposed that RE is a crucial and major reason for project failure [13,14]. The high failure rate of software development projects and the way in which this correlates with RE has led to a greater focus on RE, both by practitioners and management. As a result, novel methodologies for both RE and SD have been developed that use incremental systems for dealing with requirements (e.g., continuous deployment/integration and agile processes).
Verner and Evanco undertook a survey of software developers in Chile, Australia, the USA, and Vietnam [15]. Their results found a clear correlation between good RE and successful projects. Although both academics and practitioners have noted globally that there are difficulties and issues with RE in many software development projects [6,11,14], there has been little focus on what difficulties and problems there are in this area in GCC nations. To develop an understanding of how software is developed in Kuwait and other GCC countries, authors employed an existing questionnaire [3] for collecting data from companies in this region regarding their recent software projects. Thus the aim of this research is to make a comparison of its outcomes with the outcomes found by Verner et al. [6,15], in the research previously mentioned. Authors wish to reveal which RE practices lead on to successful projects in this region. The structure of the research paper takes the following pattern: Section 2 offers background information and a review of the literature, Section 3 details the research methodology, Section 4 details and discusses the findings, with Section 5 offering a conclusion.
II. BACKGROUND AND LITERATURE REVIEW RE practices have been shown to be a crucial element of successful projects [4,5,16]. Research into software engineering has demonstrated that both clients and organizations involved in software development are lacking in knowledge about RE practices [17][18][19][20].
Successful software projects almost always have completeness and accuracy in RE [21]. Managing requirements is one of the initial phases of any SD project and can make a contribution to every phase of the project if the correct development methodologies are employed [22]. If organizations use RE effectively, they will generally accrue numerous benefits across the project's life-cycle. To improve the RE practices Pandey et al. [23] proposed a method for requirements gathering and management. This method is divided into four key phases: "requirements elicitation and development," "requirements documentation," "validation and verification of requirements", and "requirements management 52 | P a g e www.ijacsa.thesai.org and planning". The method provides a high-level framework for the requirements engineering process. Additionally, good practice with RE can cut the economic costs of SD and produces better quality results [24,25]. Whilst the demands of gathering requirements appear basic, this is frequently neglected despite its crucial influence on all SD projects [26]. RE are crucial in the definition, estimation, and management of all software projects [27]. Whether the methodology used for a requirements process is traditional or agile, there is still the same demand for good quality RE [28]. If every facet of quality RE is in place, including ownership, support from management, clear requirements, and stakeholder involvement, a project will begin with higher chances of succeeding [29]. However, if requirements are incomplete or change, if management is not supportive, and if stakeholders are not involved, costs will most likely increase and the project risks failing [29]. Research into 12 UK companies revealed that problems with RE represented 48% of all problems in SD [7]. Because of this, the industry has been seeking to develop reliable, effective RE frameworks. From the 1990s onwards, numerous methodologies have been created to attempt to address this need [30]. Nevertheless, no complete solution for the problems has yet been found. Siahaan and Irhammi demonstrated that 43% of failed projects were caused by the use of unsuitable RE [31]. It has been suggested that one way of avoiding failed projects is to switch from the traditional waterfall methodology to novel methodologies, e.g., agile development [32]. When employing agile methodologies, it is possible to split up the requirements of a project into smaller sections and address them in a gradual manner. This method removes the need to define all of the system requirements initially, and makes it easier to correct errors as they arise. Nevertheless, if a developer doesn't/can't have enough dialogue with the client to enable them to correctly define the requirements of the system, agile methods will often lead to a project stalling [33].
Up to now the position in GCC nations has not been sufficiently researched, with just a few works looking at RE in one country in the GCC, e.g. Kuwait or Saudi Arabia [34][35][36]. There has been no research examining RE practices across the GCC nations. For this reason, Authors undertook to survey software development companies in this region in order to gain an overview of the difficulties with RE and SD currently being experienced. The survey employed for this research is an adaptation of the one used by Verner and Evanco [3].

III. METHODOLOGY
The questionnaire, adapted from that created by Verner and Evanco [3], reveals certain issues with software engineering in relation to development teams, development processes, customers and users, and management. In the revised questionnaire, a four point Likert type scale (not at all/partially/somewhat/yes) was employed for the majority of questions. Certain questions were changed from a five point scale to a four point one, e.g. the (RE2) question. Employing a four point scale ensured that respondents could not give neutral answers. In addition, a new section dealing to global SD projects is being included, as this is becoming an important element of SD [16]. As there were four possible answers to each question, two positive and two negative, these were occasionally consolidated in reporting the results.
Responses to the questions were harvested using in-person interviews, phone calls, and email. Respondents were asked to answer the questions in relation to an SD project they had worked on recently. At the end of the questionnaire, respondents were asked whether they regarded the SD project to which they were referring to have been a success or failure (see Table I). In addition, respondents were asked whether a project was generally regarded as a success by their organization, giving us two perspectives on project success, that of the developer and that of the organization for which they worked. A predefined definition of success was not provided, instead allowing respondents to define it in their own words. This accord with contemporary practice, e.g., Osei-Kyei & Albert [37] suggested that success is perceived differently by different stakeholders, and that those undertaking research should not impose a general definition of what makes a successful project. The survey was sent to a number of SD companies across the GCC region, asking respondents to answer the questions with reference to a recent IT project on which they had worked.

IV. RESULT AND DISCUSSION
163 individuals responded to research questionnaire, 36 from UAE, 36 from Qatar, 6 from Oman, 12 from Kuwait, 36 from Saudi Arabia, and 37 from Bahrain; all of these individuals had worked on different projects. In terms of demographics, 5 respondents were MIS managers, 20 were customers, 28 were users, 37 were project managers, 47 were developers, and 26 were in some other form of management; the respondents were involved with developing software to be deployed inside their organizations. The organizations represented included banks, other financial institutions, and educational institutions situated in GCC nations. Authors feel that sampling over 163 separate projects is a suitable cohort for search into software engineering. 154 projects were seen as having been a success and 8 as failures (4 in Qatar and 4 in Saudi Arabia). 17% of the projects were substantial maintenance/enhancement projects (15% success), and 72% were development projects (69% success). Bahrain had the highest proportion of successful projects. It may be that either the organizations with which the respondents are involved enjoyed a high level of successful projects, or possibly the respondents found it preferable to refer to a successful project when responding. For the purposes of reporting and analysis, the four point Likert scale was sometimes consolidated to only two points of success or failure.
The questionnaire was divided into subsections which covered the whole SD process. This paper considers questions around RE/requirements management, as shown in Table I. The table illustrates the percentage of survey questions that elicited a "Yes" response. Table II illustrates the significant correlations of questions with project success (>0.05) and how responses to selected questions were associated. The questions in these tables are divided into the following categories: RE (questions about requirements), PM (questions about how the development 53 | P a g e www.ijacsa.thesai.org process was managed), UC (questions related to project sponsors, clients, and users). Requirements Questions.
On the basis of previous research [38], it was predicted that for all projects that the respondents regarded as successful would begin with full and accurate requirements that had been gathered using a specific methodology, having a clear definition of scope that was not changed across the course of the project. Bearing in mind such elements, the following questions were asked in relation to requirements.

A. Were Requirements Gathered Using a Particular Method?
(RE1) When organizations define requirements when commencing a project, it is expected that they would employ an RE methodology [39]. Nevertheless, the outcomes of the chi-square test did not have significance (p = 0.546), which suggests that there was no significant correlation between using a specific methodology for harvesting requirements and project success, either from the perspective of the respondents or their organizations. No successful project from Bahrain employed a specific methodology for harvesting requirements. 125 out of 163 (75%) respondents used no specific methodology, with just 38 projects doing so. Seven projects that did not use a specific methodology for harvesting requirements did not experience success as they were unaware of what methodology they should employ. This demonstrates that a number of organizations do not have experience with methodologies for harvesting requirements. In the successful projects that did employ a specific methodology, nine of them used meetings, six of them used interviews, two of them used workshops, two of them used brainstorming meetings, one of them used previous system analysis, four of them employed email, telephone calls, and online research, two of them used an agile methodology, two of them used ASAP, and one of them used a questionnaire. The only projects which had complete and accurate harvesting for requirements and where sufficient time was set aside to complete the harvesting were ones in which project managers had employed phone calls, online discussion, emails, interviews, and stakeholder meetings. Only one project employed a specific methodology: this was the method of their own devising and the project ended in failure. Closer investigation of this failed project shows that it failed due to the requirements methodology being changed across the life-cycle of the project, not enough time being set a time to harvest requirements, and developers being unaware of how the new methodology should be used. The results of this research are comparable to those of Verner et al. [6] in that only four projects employing UML to document requirements experienced success. Verner and Evanco found that developers were either not familiar with UML or were using non-requirement notation to record requirements [3]. Additionally, there was a significant correlation between successful projects and the use of defined SD methodologies (PM3) and methodologies that were tailored to the specific project (PM4) identified in Verner and Evanco's research [15]. RE1 is the most effective predictor of successful companies in Saudi Arabia (KSA) when using univariate analysis variance. Only 2.6% of projects employed specific methodologies, and the chi-square outcomes for this result do not have a significant correlation with project success, either from the organizational or respondent perspective. This result is explainable by the fact that so few projects employed requirements methodologies, and the findings do not preclude the suggestion that requirement methodologies could be effective if they had been employed by more projects in the sample. Additionally, It was discovered that employing defined methodologies (PM3) did not have significance with the chi-square testing in terms of completeness and accuracy of requirements (RE2) when the results was divided into successful and unsuccessful projects. However, in terms of organizational management perspectives, there is significance to the chi-square test outcomes: organizational management was more likely to view a project as having been a success when specific methodologies were employed to eliciting requirements.

B. Were the Requirements Complete and Accurate at the Start of the Project? (RE2)
There was no surprise that the outcomes of the chi-square test of this variable against project success had significance (p <0.001), which suggests that when there was completeness and accuracy regarding requirements, a project was more likely to experience success. Nevertheless, 31 projects were successful when they had only partially complete requirements, and just 8 failed. The outcomes demonstrated that 33% of the projects did not adequately harvest requirements, 50% only harvested then partially, and in all cases users and/or clients did not set aside sufficient time for the process. 20% of such projects ended in failure, and this creates significance with the chi-square test, which suggests that a project is more likely to fail if requirement harvesting is only partially complete as compared to a project where no requirement harvesting occurs. This is due to the fact that partially completed harvesting adds no new functions to the existing product, so if clients take a decision to halt development in particular areas or a complete product, or partially completed harvesting has been wasted [40]. Results of this research show that if requirements are only partially www.ijacsa.thesai.org harvested, there are generally very low levels of user involvement. Additionally, it was discovered that the majority of projects with incomplete requirements used in-house approaches or none at all.
By regarding projects that were only part successful as being failures, it was estimated that 39% (15/38) of projects that only partially completed their requirement were failures. There is also significance in the organizational perspective for this variable.

C. If Requirements were not Complete and Accurate at the Start, were they Completed Adequately? (RE3)
The outcome of the chi-square test for this question had significance (p <0.001), which suggests that there is a correlation between successful projects and completing requirement harvesting. The answer to this question was given as yes for just 25% of failed projects, whilst it was given as yes for 60% of successful projects, with a significance of 0.007. This element also had significance (0.002) when a fourpoint scale was employed regarding project size which showed that the majority of the large and small scale projects enjoyed success. This analysis also had significance from an organizational perspective. In 10 projects, the project was regarded as a success even though requirements had not been adequately completed. Examining these 10 projects more closely, it was shown that in the majority of the projects the project manager had complete or almost complete control and authority; only a small number of projects succeeded if the project manager possessed little authority. In addition, when delivery date decisions were taken using suitable requirements information (PM1), there was accurate estimation of the project length and requirements and sufficient staff were imported as required. Project managers played a significant part in respondents regarding a project as being a success, because project managers required clear vision for the project, understanding of user requirements, the ability to communicate well with staff, and the ability to create a working environment that suited developers. This concurs with the findings of Verner and Cerpa [15], who demonstrated that a project had a good chance of success if requirements had been completed at some point. In six of eight projects there was inadequate completion of requirements; in 33 of 52 projects (63%) the project enjoyed success even with partial or no completion of requirements. Chi-square testing demonstrates that on the whole this variable has no significance for the success of a project. RE3 had significance when the true success of a project was closely examined using a four point scale for level of success rather than conflating the scale into just successful or unsuccessful. Employing a univariate analysis of variance, the regression effect (B = 13.032; Sig = 0.012) demonstrated that RE3 is the most effective means of predicting project success.

D. Was the Scope of the Project Well Defined? (RE4)
Being well defined in scope means that a team knew what was required to complete a project and what the aims of the project [41]. Research findings with a chi-square test demonstrated significance (p = 0.032), which suggests a correlation between defined scope and project success (RE4). Haass and Neda found that a failure to define scope in the beginning phases of a project generally introduces problems in the process of implementing the project later [42]. Research findings demonstrate that around 50% of projects did not have a clearly defined scope for their project, although this is almost the same level as for successful projects. Nevertheless, in the majority of projects the project scope changed, although from the organizational perspective it was felt that two thirds of projects had no change in scope and that there was no significance from this perspective. It was found that 17/50 projects which had changing scope were regarded as failures, and this also did not have significance from the organizational perspective. Thus there was no correlation between a project failing and its scope being changed in the course of the project. This finding accords with those of Verner and Evanco [3] and Suchan [43]; these authors stated that projects will inevitably change and there must be a capacity for coping with this if it happens. Fabiola et al., [44] note that there may be a number of reasons why project scope could need changing, which includes internal influences as stakeholders get a better idea of the problem and external influences, e.g., changes in the market or government regulations. Nevertheless, research findings do not concur with those of Boehm [45] who argues that when a project changes scope this has a correlation with projects failing.

E. Did the Customer/Users Make Adequate Time Available for Requirements Gathering? (RE6)
The outcome for the chi-square testing of this variable against project success had significance (p = 0.002), which suggests that projects are more likely to succeed when customers/users make sufficient time for developers to gather requirements. Only 25% of failing projects returned a yes answer for this variable; where 60% of successful projects returned a yes answer with the chi-square having significance at 0.007. There was also significance (0.002) when a fourpoint scale was used in relation to project size; there is also significance from an organizational perspective. Organizations appear to be acutely aware of this characteristic. Research findings demonstrated that the correlations between RE6, UC3, and RE2 suggests that when customers/users have high levels of confidence in their project manager (UC3) they provide sufficient time for gathering of requirements (RE6) and this leads to adequate completion of requirement gathering (RE3).

F. Did the Size of the Project Negatively Affect Requirements
Elicitation? (RE7) The outcomes of the chi-square testing for this variable did not have significance in terms of project success (p = 0.128), which suggests that project success and project size are not correlated. The majority (74.5%) of successful projects was not influenced by the size of the project, and this was also true for 59% of somewhat successful projects and 54% of partially successful projects, while 50% of unsuccessful projects were influenced by size.
These outcomes suggest that as the size of the project increases there is a greater likelihood that this will influence the ability to elicit requirements, but the chi-square test does not show a significant correlation with project success. This element also does not have significance when size is viewed www.ijacsa.thesai.org from the organizational perspective. These findings differ from those of Suchan, [43] who suggested that project size can have a negative correlation with requirement elicitation and can be the cause of a lack of clarity, instability, and incomplete requirements. Nevertheless, a comparison of research findings with those of other practitioners shows similarities with the findings of Verner and Evanco [3], who felt no negative correlation between project size and requirement gathering. It may be the case that developers, users, and managers have a greater awareness that problems may come up with larger projects and so are more prepared to address them.

G. Sponsor, Customer and User Questions
Researcher findings demonstrate a negative correlation for project success and UC3/RE6. This shows that projects fail even if users set aside sufficient time for collecting requirement (RE6) but did not have confidence with their project manager (UC3). Research has demonstrated that customer/user involvement across the development of a project (from collecting requirements to final acceptance) is crucial if a project is to succeed. The research of Glass [46] and Zhiwei [47] accords with this research result, agreeing that it is crucial for users to be involved in the requirement gathering process (RE6). The correlations of stakeholder commitment/involvement across the project (UC1) as well as adequate completion of requirements by developers (RE3) had a significant correlation with the influence of senior management right across the project. Thus support from management must be available at every phase of the project. These findings accord with those of Kitapici and Boehm [26], who found that the absence of support from management has now become the biggest reason for a project failing, replacing user involvement which was previously the primary cause. Employing univariate analysis of variance, UC for well shown to be the most effective predictor for questions for users, customers, and sponsors in successful projects in in UAE specifically and GCC region in general.

H. Project Manager (PM) Questions
Research findings demonstrate that the experience level of the project manager (PM2) did not have a significant correlation with the success of a project. This accords with the findings of Verner and Evanco [3] that indicated that project manager success is more likely to stem from their skills as a manager and interpersonal abilities, not technical knowledge [48,49]. The findings of this research additionally demonstrate that projects that have continual senior management support alongside involvement and commitment from stakeholders, as well as projects in which the project manager has selected a suitable means of collecting requirements, have the greatest likelihood of success. This accord with the research of Young and Jordan [50], which demonstrated that senior management support is the primary necessity for a successful project. Nevertheless, it is of greater importance that a project manager should be an effective communicator and have a healthy relationship with stakeholders than that they should have technical knowledge. This agrees with the research of Siahaan and Irhammi [31] and De Araujo and Pedron [51]. Projects for which the delivery date is created on the basis of suitable requirements information (PM1) are positively correlated with collecting requirements using a specific methodology (RE1). Nevertheless, there is a negative correlation between PM1 and successful projects. When the research findings are examined more thoroughly, it becomes clear that project managers frequently have no involvement over delivery date decisions and are not consulted in any meaningful way during the planning process. Research findings suggest that successful projects are those in which the project manager is involved with planning from the outset. Using univariate analysis variance, it was discovered that PM1 is the best predictor for KSA in particular and GCC nations in general.

V. LIMITATION AND VALIDITY OF THE RESULTS
This study contains limitations that may affect the validity of its findings. This research was built by the authors after a thorough evaluation of the literature. Because there is a scarcity of material on RE practices in the GCC area, the authors relied on some older material as evidence. Furthermore, as a secondary piece of evidence, the authors examined some of the participants' software documentation, which they had collected during the interview. Only the perceptions of software engineers were reported in the survey. However, when conducting a survey, the authors relied on the information supplied by the respondents. There is a good chance that the software developers' perspectives will alter when the project is completed. It is also likely that respondents choose to choose only successful projects. Because software engineers were the only participants surveyed by the authors, the findings were limited to their views and opinions about the projects and teams in which they worked. The data gathered by the software engineers working in various positions and directly participating in the projects was used to generate the conclusions of this study; the views of the software engineers were studied without the author's influence. The questionnaire used by the authors had been used effectively in other studies [4], [6], [15].

A. Internal Validity
The authors applied exploratory research to investigate the issue of RE practices from the perspective of software engineers in the GCC area. They comprised project managers, users and clients, as well as programmers and developers, all of whom had varying perspectives on project success.

B. Construct Validity
The author's questionnaire, which was employed in this study, has been utilized effectively numerous times with other software engineers from other nations [6], [15]. As a result, because the questionnaire had been tested several times, the authors could utilize it as a valid tool to investigate the RE practices for software engineering in the GCC nations.

C. External Validity
Because this research sample is convenient rather than random, the authors does not believe the results are as trustworthy as a random survey. This is due to the fact that a convenient sample may be biased and entails inference. However, respondents took part in software development procedures in a variety of projects. Because this study was conducted in the GCC nations, which constitute a tiny portion of the globe, the findings cannot be generalized. The study is www.ijacsa.thesai.org limited to the sample population size at the time the survey was completed.

VI. CONCLUSION AND FUTURE WORK
This research is the first to discuss IT project success and failure in GCC countries. For the IT projects in this research sample, found that project success has a negative correlation with project manager's experience and that the best predictor of successful projects is that requirements should be complete and accurate. Comparing current research results with previous research conducted in 2005, reviewing projects in the US, Chile, Australia and Vietnam, current results show that requirements problems still exist in the GCC countries and not have been completely solved. Most of the projects in the current research dataset either used their own requirementsgathering methods or did not use a methodology for the software development process. Only a few projects used a well-known requirements-gathering methodology that fitted with development approaches, such as a waterfall method, or modern development methods, such as agile methodologies. Authors suggest that this situation is due to either the developers being inexperienced in using well-known methodologies or that they are using an inconsistent notation for the requirements. This study also finds that the most important factor in project success is that requirements should be completed adequately; this is followed by top management support and effective project planning. It is interesting to note that it is worse to have partially completed requirements than not completing the requirement process at all. The study also confirms that the project team, project manager, and a suitable requirements methodology are important for project success. However, project sponsor and stakeholder involvement from the project's start also contribute to project success. It was also found that altering the project scope during the project stages is not always associated with project failure. Furthermore, the findings of this study demonstrate that senior management support, as well as stakeholder engagement and involvement throughout the project, are critical for project success. Authors believe that the research results are especially interesting as the data comes from countries where there has been very little published about their software development practices.
Future work will include an in-depth analysis of the rest of the research survey dataset. Authors would be interested in applying the survey being used in Europe, the Asia/Pacific region, and the Americas to investigate the current state of practice of SD and whether these practices have changed significantly over the past 15 years.