Understanding the Impact of Requirements Evolution and Reaction on Evolution of Software: a Survey and Comparison

: In software systems, the continuous changing of requirements, known as requirements evolution, is considered one of the significant issues. Requirements' evolution denotes the post ـdeployment changes in the requirements. This article reviews the most related requirements evolution approaches. Different approaches have been presented in modelling requirements evolution, managing requirements evolution, and relevant analysis techniques, like inconsistency detection and change impact analysis. The relevant approaches of requirements evolution can be generally classified into the impact of evolution and reaction on evolution. The article also has given a comparison among those approaches. The approaches that have been surveyed in this article exhibited many limitations. These limitations need to be addressed and coped with for the approaches to be more effective in managing the evolution of software requirements. One of the solutions to these limitations is to develop a framework that addresses the modelling and reasoning behind software requirements evolution. The framework will include evolution rules to capture evolution in the requirements model, particularly observable rules for capturing potential changes and their uncertainty and controllable rules for capturing different reactions from the designing aspect


Introduction
In software systems, the continuous changing of requirements, known as requirements evolution, is considered one of the significant issues.Practically, requirements evolution is still a major problem since the constant change makes the traceability and monitoring of requirements complicated and unreliable.However, it is an unavoidable activity since useful and successful software motivates users to demand new and improved requirements [1,2].
Requirements' evolution occurs throughout the development life cycle due to continuous changes.Requirements' evolution denotes the post‫ـ‬deployment changes in the requirements.These changes happen when the system starts operating due to many factors, such as operational environments, changing technologies, and business needs [3].These changes may involve qualitative and/or quantitative features of requirements.For instance, the specifications can be increased or more precise; tacit requirements have to be more explicit, or specifications are no longer needed and may be totally discarded [4].Requirements' evolution is unavoidable throughout the software project lifecycle.It can make the systems faster, more reliable, and more efficient [5].
Additionally, requirements could be evolved to increase the understanding of the problem by the designers and the users themselves [6].
After this introduction of requirements evolution, an explanation of requirements evolution perspectives is presented.Then, requirements evolution approaches and their two classes, the impact of evolution and reaction on evolution, are illustrated, followed by a comparison and discussion of them.Finally, the conclusion of this article is derived.

Requirements Evolution Perspectives
Requirements' evolution is studied within a specific period.This period might be short (a few years) or long (10 years and above), depending on the lifetime of the software system [7].Different evolution perspectives depend on the scenarios of how the study may evolve.Lund et al. [8] defined three evolution perspectives related to risk analysis: maintenance, before‫ـ‬after, and continuous evolution.
i. Maintenance evolution: This perspective is concerned with updating the documents for an available system.This perspective will not be considered in this paper as it mainly concentrates on the solution in advance of requirements model evolution in the early stages.ii.Before‫ـ‬After evolution: This perspective expects future contexts through predicting the unplanned and planned changes in existing models of requirements when the study is complete.Several evolutions' probabilities will be considered, and each probability can happen.For instance, the Air Traffic Management (ATM) 2000+ Strategic Agenda [9] and "European Single European Sky ATM Research Initiative (SESAR)" [10] have defined the direction of the ATM improvements in the period from 2010 until 2020 to get one or more alternatives of novel tools of queue management.This management comprises Departure Management (DMAN), Arrival Management (AMAN), and Surface Management (SMAN).iii.Continuous evolution: This perspective expects existing contexts' evolution over the study period, relying on gradually planned changes.The whole period of study will be divided into many milestones.Within each milestone, the possible changes in the requirements model can be predicted.Numerous evolution possibilities are also considered.
The critical distinction between the before‫ـ‬after and the continuous evolution is that before‫ـ‬after evolution is concerned with only one evolution possibility at definite points of time in the future.In contrast, continuous evolution enables numerous possibilities at definite points [8].The former can be collapsed to the latter when there will be a single evolution possibility at each point.Thus, the definition of continuous evolution here can be considered as the generalization described in the study of Lund et al. [8].
Furthermore, the changes that Lund et al. [8] have addressed from the perspective of continuous evolution are considered expectable and gradual evolution that can be defined as time functions.The expectations can be based on planned developments or well‫ـ‬founded predictions.This means that they are related to the situation in which they were designed to evolve over time, or, in other ways, they can expect continuous changes over time.Figure 1 shows the perspectives of evolution.In this figure, the requirements models are represented as clouds.Figure 1 (a) demonstrates before ‫ـ‬ after requirement evolution.This evolution examines requirements in a finite and determined period throughout the study.It can be analyzed throughout this period concerning how the requirement model will look at the beginning (before the model) and possibly at the end (after the model).Only one after model will happen [11].On the other hand, Figure 1 (b) illustrates the continuous requirement evolution that at the time (t0), RM0 represents the original requirements model that can be evolved to one of RMi at t1.The evolution constantly occurs at the end of the study (tn).Consequently, the original requirement model can be one of RMkj.The main distinction between the before‫ـ‬after and the continuous requirement evolution is that before ‫ـ‬ after evolution refers to one evolution possibility at specific points in the future.On the contrary, continuous requirement evolution enables many possibilities at specific points [12].

Requirements Evolution Approaches
The relevant approaches to requirements evolution can be generally classified into 1) the impact of evolution and 2) the reaction to evolution.Approaches to the impact of evolution aim to identify possible effects on artefacts (like models and specifications) and security properties or consistency violations.In contrast, approaches in the evolution reaction propose reactions to requirements evolution [13].

Approaches in Impacts of Requirements Evolution
As mentioned before, approaches to the impact of evolution focus on recognizing possible consequences on artefacts (like models and specifications) and violating security or consistency properties.There are many approaches related to the impact of requirements evolution.The most related of them are explained in Table 1.

Approaches in Reaction to Requirements Evolution
There are several approaches that aim to support the requirements evolution of the systems.Some of those approaches concentrate on early design phases, while others focus on the phases of deployment and implementation.There are many approaches related to the reaction of evolution.The most related of those approaches are explained in Table 2. Determine which tasks must be completed in a prescribed order and which were independent.Overall, these strategies were effective in understanding possible evolutions of the requirements.Goal modelling for early ‫ـ‬ phase requirements engineering can be improved by explicitly modelling and analyzing intention evaluations over time.
Operationalized intentions' changing evaluations with the dynamic functions, but did not establish that this was the best representation.Given the research bias discussed in the paper, there is a risk that the model may not be representative of other iStar goal models.This paper dealt with only "relative" times and can be extended by adding "wall clock time" to the analysis.

7
"Sentiment Analysis-Based Requirement Evolution Prediction [27]."Propose a framework that combines a supervised deeplearning neural network with an unsupervised hierarchical topic model to analyze user reviews automatically for product feature requirements evolution prediction.
The results of this study contribute to efforts toward automatic textmining analysis for product requirements engineering.The approach detected product features mentioned in the user review text for different granularities with sentiment orientation.Distributed word embedding can differ from the training objectives and language models.Therefore, the quality of the word embedding could impact the efficacy of the sentiment classification results.
The text analysis‫ـ‬based approach to product requirements evolution detection should be adapted to the implicit context to identify implicit product features and sentiment.Used hierarchical Latent Dirichlet (LDA) to extract software features.However, LDA is not suitable for analyzing shorter texts such as tweets due to the sparsity of word co ‫ـ‬ occurrence patterns in the individual document [28].

8
"Evaluating Mutual Requirements Evolution of Several Information Systems [29]." Proposed and exemplified a method of eliciting and evaluating requirements of several systems together.
The proposed method can help analysts discover unaware requirements for each system, improving each system and its supported activities.In this method, analysts can use any modelling language to focus on different aspects of systems.Therefore, this method may improve the efficiency of human, time, and space resources and system development efforts.

The method primarily depends on the insight of analysts (subjective views).
There is a limitation in managing the links between model elements.Therefore, the method must develop a traceability management tool based on an existing modelling editor.
Formal reasoning for analyzing goal models that evolve over time [30].The study empirically showed that requirements are not elicited in the strict sense but co-created through interviews, with analysts playing a crucial role in the process.The study also showed evidence that app store-inspired elicitation could be particularly beneficial to completing the requirements.

Formalize
Only focusing on the requirement evolution after a software product is deployed might make the tags less fitting for requirements before a product has been deployed [31].

Union
Models: Support for Efficient Reasoning About Model Families Over Space and time [32] Proposes union models as a paradigm supporting the representation of model families (for time and space dimensions) using one generic model.
Demonstrate empirically the usefulness of union models for analyzing a family of models all at once, compared to individual models, one model at a time.Suggests that the use of union models facilitates efficient analysis in several contexts.
The study is limited to simple type graphs, where attributes of model elements have to be expressed structurally with named nodes and edges.The study also limited to languageindependent, syntactic properties (which describes the structure of models) other than semantic properties (which describe the behaviour of models, e.g., traces).

Comparison and Discussion
From the surveys of Tables 1 and 2, it can be noticed that there are limitations in evolution uncertainty and systematic and quantitative reasoning of many existing approaches of requirements evolution modelling.These limitations can restrict their utilization in managing the uncertainty of software requirements evolution.For instance, studies such as Russo, Nuseibeh, & Kramer [14], Hassine et al. [1], Côté & Heisel [16], Bergmann et al. [17], Schneider [12], and Mehmood [20] have focused on the issue of management and consistency of requirements without addressing the modelling and reasoning of requirements evolution uncertainty.
Furthermore, the studies of Zowghi & Offen [22], Brier et al. [23], Ernst, Borgida, & Mylopoulos [24], Souza et al. [26], and Ferreira [13] proposed the implementation of management or testing consistency on the evolution of requirements; however, they did not develop an evident approach for the reasoning of requirements evolution.
It is observed that the reviewed studies lack a comprehensive framework that can be used for modelling and reasoning requirements evolution.This modelling and reasoning for the requirement is essential to predict the most accurate and low-cost requirements for the software systems that suffer from continuous changes over time.

Conclusion and Future Work
Software requirements change and evolve continuously.The evolution of software requirements is an unavoidable phenomenon during the operation of long‫ـ‬lived software systems because of the dynamic nature of their operating environments.Therefore, software systems may be unstable or non‫ـ‬operational.Requirements' evolution occurs throughout the development life cycle due to continuous changes.If this evolution is not appropriately managed, it can cause costly repairs and time-consuming inconsistencies.The approaches of requirements evolution surveyed in this article exhibited many limitations.These limitations need to be addressed and coped with for the approaches to be more effective in managing the evolution of software requirements.
One of the solutions to these limitations is to develop a framework that addresses the reasoning behind software requirements evolution.This framework will be based on continuously changing requirements within the software lifecycle.Furthermore, this framework can be designed with factors like time, cost, and behaviour.Moreover, the suggested framework will be modelling and reasoning about the evolution of the requirements model in long-lived software systems.It will aim to provide a means for studying requirements evolution.The framework will include evolution rules to capture evolution in the requirements model, particularly observable rules for capturing potential changes and their uncertainty and controllable rules for capturing different reactions from the designing aspect (i.e., design choices or design alternatives) to these changes.Incorporating evolution in requirements models will allow designers to have a global view of the potential evolution of the system in future.Future research can focus on the following issues: • Replicate the empirical studies in another domain rather than ATM (Air Traffic Management) with different kinds of participants to see whether similar results could be obtained.• Replicate the empirical studies with different requirement engineering languages rather than i*/Tropos to see whether the chosen requirement engineering languages impact the outcome of the studies.• Evaluate different aspects of the framework rather than effectiveness, for example, whether the method is easy to use (i.e., Perceived Ease of Use), whether participants want to apply the method in practice (i.e., Intent of Use), and so on.These aspects could be obtained by performing interviews (with and/or without a predefined questionnaire) with individual participants.

2
Salih et al.: Understanding the Impact of Requirements Evolution and Reaction on Evolution of Software: a Survey and Comparison

Table 1 .
Summary of the approaches in impacts of requirements evolution Salih et al.: Understanding the Impact of Requirements Evolution and Reaction on Evolution of Software: a Survey and Comparison

Table 2 .
Summary of the approaches in reaction to requirements evolution