Risk Factors for Software Requirements Change Implementation

Requirements change has been regarded as a substantial risk in software development projects. The factors that contribute to the risk are identified through impact analysis, which later determine the planning of the change implementation. The analysis is however not straightforward as the risk factors that constitute requirements change implementation is currently not much explored. This paper identifies the risk factors by firstly collating them qualitatively through a review of related work and a focus group study. The factors are then confirmed quantitatively through a survey in which data is analysed by using Partial Least Squares Structural Equation Modelling (PLS-SEM). The survey comprise of 276 practitioners from software industry who are involved in the impact analysis. The results indicate that User, Project Team, Top Management, Third Party, Organisation, Identification of Change, Existing Product and Planning of Change Implementation are the significant risk factors in planning of requirements change implementation. Keywords—Requirements change; risk factor; structural equation modeling


I. INTRODUCTION
Changes in system requirements have negative and positive impacts on system development projects.The changes will have a negative impact if the processes are not properly managed [1].Errors in managing the change requirements may result in project's cost increases, delay in the system development and affecting the system quality [2].On the other hand, the process will have a positive impact if the changes conducted to the system are successfully implemented.System improvements can improve the level of user trust in the system [3].
Requirements change is one of the crucial risks in software projects [4], [5].Requirements changes are inevitable in software system development projects.The addition of new requirements and changes to the existing requirements can occur at all stages of the system development process [6].New requirements come in tandem with technological developments.As such, consumer needs are changing to meet the organisation's policies and operating and business operations environments.The changes occur due to several factors such as errors in original requirements, evolving customer needs, technological changes, and changes in the business environment or organisational policy [6].
Requirements change is proposed through change requests.Dealing with requirements change requests is a decisionintensive process [7], as it involves cost and resources [8].
Deciding whether or not to accept the change request is done by an important team called Change Control Board (CCB).CCB conducts impact analysis before the decision is made by comparing cost and risk [9], [10].Impact analysis has great benefit in reducing the risks of implementing requirements change [11], [12].By identifying potential impacts before making a change, the risks of embarking on a costly change can be greatly reduced [11], [13].To ensure an accurate decision, CCB should be able to analyse the impacts of the identified factors holistically and assess their risk levels.Also, in order to ensure informed decision during impact analysis, CCB needs a predetermined risk factors or criteria to evaluate a requirements change request [14].
The risk factors to be considered in assessing the requirements change requests are however still indeterminate.Previous studies have shown that there are several risk factors that influence the change requirements and thus contribute to the successfulness of their implementation [15], [16].The studies are more focused on technical aspects [17], instead of the non-technical aspects [18].This resulted in unreliable and inaccurate decision making in the change request implementation.
Hence, the aim of this paper is to present the risk factors of the requirements change implementation.It focuses on change impact elements.The study uses a partial lease square structural equation modelling (SEM) technique.The identified risk factors discussed in this paper were acquired through series of work conducted previously, reported in [19].
The paper is organized as follows: Section 2 provides the related work on the subject matter.Section 3 elaborates the research model and hypothesis.Section 4 briefly explains the methodology used.Section 5 provides the results.Finally, Section 6 concludes the paper with a summary that outlines the main findings and future work.

II. RELATED WORK
Requirements change has been recognised as a major issue in software development projects.One main issue is about how to assess a requirements change request before deciding either to accept or reject it for implementation [20].The decision has to be made after impact analysis [21], [22], by which the affected elements are identified and scrutinised [23].
Over the past decade, impact analysis has become a major concern among practitioners and researchers in software engineering [8], [20], [24], [25].For instance, a study has www.ijacsa.thesai.orgproposed a tool to ensure an accurate impact analysis by identifying the hardware and software in the current system that are likely to be impacted by the proposed change [26], [54].Another study developed a tool to determine the planning strategies in assigning human resources to change activities [27].Both tools however have lack of functions which are to store and retrieve information of past changes [28].
The system is developed for users and based on user requirements.Change requests are triggered by users based on the experiences that they had with the system.When requesting a change, the users must provide information about the current system and clarify the change that they request to the project team [29].Users must be involved in the process so that they are aware of the system operations after the requested change has been made [30], [54].Among the identified risks involved is the less user involvement during systems development and inadequate user's knowledge regarding the developed systems [31].The users also often lack of cooperation with the project team when needed [31], [32], less commitment towards the systems and has a negative attitude towards the system [32].
Later, project team is responsible to bring forward the request to CCB meeting for them to analyse and assess its impacts [54].The project team plays an important role in system development.Among the risks involved with the project team are low-skilled capability in the development of the system [32].As such, new members that are involved in the project may have less knowledge about the system that is being developed [32].This might be due to the limited training given to the project team [33].Besides that, the project team is also identified to have less experience in system development projects [31].Experience gives the project team confidence to develop systems.On the other hand, there is also issue regarding the project team's lack of commitment in the system development [31].During impact analysis, it is important to assess the project team's capability such as experience, motivation, skill and knowledge in order to ensure the feasibility of the change [34].
Besides that, support and commitment from the top management are also essential [31], [32].Top management is responsible for the implementation of system development.The top management commitment is needed to make the decision of a subject matter.The absence of specific communication channel among the top management may lead to lack of commitment in the project [32].Besides that, support from top management is also crucial.It is identified that there are top managements that failed to give support when needed, affecting the change requirement process [31].
Furthermore, the degree of dependency on the third party [32] and their involvement in the project [31] also contribute to the risks.The project development also involves third parties such as suppliers and external organisations related to the system.The risk factors that arise are the number of third parties involved [31].When the number of third parties is large, related management becomes difficult.In addition, the high levels of dependence by the project team to third parties also pose a risk to system development projects [32].
The change request might affect the existing software components such as source code [35], [36], documentation [37], tools [38] and architecture [36], as well as the hardware components such as memory usage [39], performance [12] and platform [40].There are also risks of complex architecture [4].Out of all the components, the technology component is identified to have highest risk.Due to that reason, the analysis of a change request must consider not only the people involved but also the hardware and software used in the current system.
The costs and schedules are also important for project implementation.Determining the estimated cost and the schedule is not easy [32].The cost to implement requirements change is influenced by the number of project team members and consultants as well as project duration, size and scope [41].In fact, the incorrect or insufficient estimation of cost and schedule may contribute to more risk to the project [31].On the other hand, optimising the schedule for implementing any requirements change schedule can result in significant time saving [42].Therefore, it is important to judge the affected and affecting elements accurately to ensure an adequate allocation of time and cost in implementing the change [33], [31].Strategic planning and technology standards imposed by the organisation also have been found to influence the change implementation [19], [43].
The goal of requirements change is to improve the value of the current software system.However, it triggers the risks in terms of late delivery, cost overrun, low product quality and sometimes failure to the entire software project [44].As requirements change effort is considered as a project, the risk factors concerning projects also apply to them.Some instances of project risks are inexperienced project team members [33], commitment from team members towards the project and effective communication between team members and users [31].
The review above indicates that there are various elements that are deemed necessary when managing requirements change.As the elements contribute to the success or failure of a requirements change project, they are considered as risk factors.To date, it is uncertain how CCB should analyse the impacts of those risks and subsequently decide the way forward [45].There are interrelationships between the risks [46].The significance of these interrelationships needs to be confirmed objectively [4], [5] so that an accurate impact analysis can be made [20].

III. METHODOLOGY
The methodology for this study is the combination of qualitative and quantitative approach (mixed-method) [47], [48].Fig. 1 illustrates the research design which contains the main activities involved in the study.The qualitative part consists of literature review and focus group study which have been conducted earlier to gather the identified risk factors as well as to confirm them.The findings have been reported in [19].However, the findings from empirical study was only validated solely through opinion-based perspective, thus it should be refined and strengthen further by confirming the risk factors quantitatively through a large scale survey.www.ijacsa.thesai.orgThe questionnaires were distributed to a number of information technology (IT) and software organisations in Malaysia within the period of 3 months.The organisations comprised of public and private sectors as well as local and multinational companies.There were 400 questionnaires disseminated but only 287 questionnaires were returned.However, 11 out of 287 questionnaires were omitted from the analysis due to incomplete answers.Therefore, analysis was made towards a number of 276 questionnaires which were answered completely.This caused the response rate to be 69.
The demographic information of the 276 respondents are listed in Table I.
The collected data were then analysed by using Partial Least Squares Structural Equation Modelling (PLS-SEM).Based on the conceptual model, the hypotheses were derived as depicted in Table II.The related works that support the hypotheses are also included in the table.V. RESULTS

IV. MODEL AND HYPOTHESES
The common analysis conducted in PLS-SEM approach comprises of two stages [47].The first stage is the analysis of measurement model.The purpose of measurement model is to examine the relationships between the latent constructs and their measures.This is to ensure the reliability and validity of the model.On the other hand, the goal of structural model is to assess the relationships between the latent constructs.The following paragraphs explain each model and its analysis, respectively.

A. Measurement Model
The measurement model refers to the relationships between the constructs and the items used to measure them.The analysis evaluates the convergent validity and discriminant validity of the constructs [48].The convergent validity of a construct is established when the reliability level of the individual items that measure the construct is above 0.70, the composite reliability (CR) of the construct exceeds 0.70 and the average variance extracted (AVE) of the construct exceeds 0.5 [49].The discriminant validity of a model is assessed by comparing each construct's square root of AVE against its bivariate correlations with other constructs as well as checking cross-loading cases [50].
The results of measurement model are shown in Table III.The descriptions of items used for the measurement are listed in Table IV.According to [51], the factor loading for items that exceed the level of 0.6 is acceptable in exploratory research, whereas the factor loading of 0.70 to 0.90 is satisfactory [52] and above 0.90 indicates that the items measure the phenomenon accurately.The table shows that most items are satisfactory and above.There are only two items below 0.70, namely PT4 and PL2.They are still retained because they are within the acceptable level.
Convergent validity is the degree to which multiple items measure the same construct under the study.The common approach to examine convergent validity is the factor loadings and AVE.In this study, the AVE values are greater than 0.50.This suggests convergent validity is at the construct level.In addition, the CR values are greater than 0.70.This indicates the reliability is acceptable.
Discriminant validity is the degree to which the measures of different concepts are distinct.The discriminant validity is established between two constructs if the square root of AVE of each one is higher than the shared variance.The shared variances are compared to AVEs as shown in Table V.Since the AVE values of the two constructs are higher than the squared correlation, the discriminant validity among the latent constructs is supported [51].

B. Structural Model
The structural model describes the dependency relationships between the constructs, as presented in Fig. 2. The analysis was done on the explanatory capacity of the model and the statistical significance of the various structural factors.Based on the results, the coefficient of determination (R 2 ) value of planning (0.4879) was considered as moderate [53].However, R 2 value of change identification (0.2206), software (0.2725) and hardware (0.2020) was weak.
Apart from R 2 , Q 2 coefficient was also used as a threshold for predictive relevance [51].The Q 2 coefficient in PLS-SEM was generated from a technique called blindfolding.The generated result of Q 2 for this model was 0.2927.Q 2 values were considerably above zero.This indicates the model's predictive relevance for the construct [51].
After evaluating the explanatory capacity of the structural model, the statistical significance of the various structural coefficients was tested through technique called bootstrapping to generate t-statistic value associated with each path.The outcomes are showed in Table VI.
The results showed that User and Project Team had significant relationship with Identification of Change.These results were similar with [33].It means that the identification of change highly depended on user and project team.The Identification of Change also had significant relationships with Hardware and Software, which were also supported by [39].The factors that are significant are important during impact analysis.Therefore, they are considered as risk factors for requirements change implementation.This finding provides empirical evidence that the risks factors can decrease the degree of project success [31].

VI. CONCLUSION AND FUTURE WORK
This study aimed to confirm the risk factors for requirements change implementation.A survey was conducted to collect the data, which were then analysed using PLS-SEM approach.The results showed that user, project team, top management, identification of change, strategic management, hardware and software were significant factors for planning of change implementation.On the other hand, two factors were found not significant for the planning of change implementation; namely the third party and technology standard.As these findings were obtained through quantitative study, the reason of the insignificant results could not be determined clearly.Hence, future work on qualitative approach could be conducted to investigate the underlying reason behind those opinions.
The analysis focused on impact analysis.Therefore, the analysis can be replicated to other determinant risk factors for requirements change implementation.The model could then be extended as a risk measurement model for requirements change initiatives.

Fig. 1 .
Fig. 1.Research Design.Hence, a survey was conducted to confirm the existence and significance of the risk factors as the continuation work of one of the stage in the study.The questionnaires consisted of 37 questions covering the identified risk factors.The questions used a 7-point Likert agreement scale from (1) strongly not important to (7) strongly important.A panel of software experts validated the questions.Then, a pilot study was conducted involving 50 software practitioners from the University's Computer Centre and 10 postgraduate students from the University.The questionnaires were then improved based on the findings received from both exercises.

Fig. 2
Fig. 2 below illustrates a conceptual model of requirements change implementation which was based on previous conceptual model work [19].The conceptual model was updated with the empirical output from the focus group to produce the model.The model contains eight essential components: User, Project Team, Top Management, Third Party, Organisation (Strategic Planning, Technology Standard), Identification of Change, Existing Product (Software, Hardware) and Planning of Change Implementation.

The
Project Team, Top Management, Strategic Management, Hardware and Software had significant relationships with Planning of Change Implementation.It means that planning of change implementation should consider the impact of change on project team, top management, strategic management, hardware and software.On the other hand, the relationship between Third Party and Technology Standard with Planning of Change Implementation was not significant.

TABLE I .
DEMOGRAPHIC INFORMATION OF RESPONDENTS

TABLE IV .
ITEM DESCRIPTION

TABLE VI .
RESULTS OF PATH COEFFICIENT AND T-VALUE