3. State of the Art
3.5. Change Propagation Analysis based
The approaches, which analyze the change propagation from requirements to specific systems can be divided into several subcategories due to the domain under study. As this thesis considers the domains of IS, BP, and aPS,
the related approaches to this topic can be divided in further categories, accordingly. The following sections discuss the aforementioned categories in more detail:
3.5.1. Change Propagation Analysis in Information Systems and Business Processes
based on Requirements Modification
This section gives an overview of the related work, which is concerned with change propagation analysis in IS and BP triggered by a change to requirements. For this purpose, this section starts with approaches focusing on change propagation analysis from requirements to IS. Then, it presents approaches, which are concerned with analyzing the change propagation from requirements to BP. Finally, the section discusses the approaches to change propagation analysis from requirements to both IS and BP.
In IS, Ramesh and Jarke present in [RJ01] a reference model for requirements traceability based on analyzing traceability tools and structured interviews with 26 organizations in several business areas. The metamodel comprises the metaclassesobject, stakeholder, and source. Further, they differentiate between high-end users and low-end users regarding their traceability experience and needs. Thus, they provide further reference models for each group of users. Although the proposed models can be further used for the change propagation analysis, the paper does not provide in-depth information about the algorithms to determine the affected requirements or system elements.
To support the consistency between requirements and software architecture, Vogelsang et al. propose a model-based approach in [Vog+14b]. First, the approach formalizes the requirements from artifacts such as use cases. In the next step, the software architecture has to be modeled. The approach relates the requirements to the architecture by connecting the input and the output of the specifications and the architectures. In this way, it is mainly concerned with early detection of inconsistencies. However, the proposed approach does not analyze the propagation of changes from requirements to IS.
Goknil et al. present several approaches to tracing changes in require-ments [Gok+14; Gok+11] and from requirerequire-ments to the software architec-ture [GKB16]. The approaches are based on rules, which use formal models representing requirements and their relations to the software architecture.
Using these rules, the approaches identify the affected requirements and parts of the architecture. Although these approach use more fine-grained semantics of relations, the model of architecture is still at a high abstrac-tion level without differentiating between different types of architectural elements. This can lead to a high overestimation of the results.
The Goal Business Process Management (GoalBPM) approach aims at con-necting the BP models to the stakeholders’ goals. The approach uses BPMN [Obj11] for modeling BP and KAOS [Res07] for modeling goals, as stakeholders’ goals are closely connected to requirements. For this pur-pose, the relationships between stakeholders’ goals, as well as between stakeholders’ goals and activities in the BP model have to be modeled. In this way, changes to the goals or to the BP can be traced to each other in order to identify whether the BP satisfies the goals. However, this approach was conceptually designed and has to be conducted informally and man-ually. Thus, it remains unclear how the propagation of a change can be analyzed in detail.
[ES05] is one of the few approaches concerning the co-evolution of re-quirements on the one hand and IS and BP on the hand. It presents a framework involving five dimensions. Each dimension regards a challenge in requirements engineering during the co-evolution (e.g.,understanding the consistency relationships between the co-evolving entities). Further, they illustrated how the framework can be used based on an application example.
Again, the paper does not propose in-depth information about algorithms for analyzing the propagation of change.
3.5.2. Change Propagation Analysis in Automated Production Systems based on Requirements Modification
In aPS, Requirements reflect “the stakeholders’ needs and therefore the intention of the plant as well as demanded properties to be competitive
and economic” [Vog+15, p. 7]. Thus, requirements changes (e.g., chang-ingmarket requirements) can be considered as a main change trigger in aPS [Vog+15]. Vogel-Heuser et al. describe in [Vog+15, p. 4] the complex dependencies between requirements and the aPS satisfying them during the evolution as “not all changes of requirements can be fulfilled by changes of only the software or only the physical parts alone. Quite often in an aPS, changes of the mechanical and/or the electrical/electronic parts are required, which lead to a subsequent adaptation of the software”. Hence, a change propagation analysis approach, which considers the requirements changes, has to provide a holistic view on the system to avoid overlooking parts of the plant under study. To achieve this, a “semi-formal system re-quirements specifications” can be used [Vog+15, p. 3]. Belgran and Säfsten refer in [BS09] to a study conducted in ten Swedish companies, which shows that a detailed specification of requirements rarely exists in practice [BP95].
However, informal specifications “do not facilitate tests for completeness, unambiguity and consistency” [FL00, p. 2]. Thus, the maintenance of re-quirements remains an open issue in aPS [Vog+15].
Legat et al. present in [LFV13] an evolution model for industrial plant at a high abstraction level. According to their model, evolution drivers for a specific plant result in changing requirements. These changes result in changing the corresponding properties of a plant. Additionally, the application of the evolution model on a community case study is discussed.
However, the proposed model is abstract and mainly illustrates the evolution of a plant conceptually.
The modeling approach of Fay et al. [Fay+15] considers different develop-ment artifacts such as requiredevelop-ments, hardware, and software in aPS. The proposed Systems Modeling Language (SysML)-based approach differenti-ates between functional and non-functional requirements. The functional requirements can be further refined by other requirements. Additionally, they usevalidity relation to represent that a component of a system satisfy a specific functional requirement. However, the proposed approach mainly focuses on modeling a whole system including its requirements and does not analyze the change propagation.
Ladiges et al. [Lad+13] illustrate the effects of changes to a system on the fulfillment of its non-functional requirements using a case study. For
this purpose, the authors categorize the evolution scenarios at a high ab-straction level. According to this categorization, the change triggers are not necessarily the requirements, but the system can be directly changed without adapting the descriptions of requirements. The latter one leads to a gap between the requirements documentation and the system. The categorization was applied to several evolution scenarios of the case study.
However, the influences of changes on the non-functional requirements are mainly illustrated and a solution idea is outlined without providing a mod-eling language and the corresponding algorithm for change propagation analysis.
Jamro focuses in [Jam15b] on requirements modeling for control software based on the IEC 61311-3 standard. The SysML-based modeling approach considers both functional and non-functional (i.e., mainly performance) requirements. Additionally, an explicit modeling of Human Machine Inter-face (HMI) requirements is also possible. Each requirement has a unique id and can be described as a text field. The functional requirements refer to POU in an IEC software and can be verified by unit tests. Further, the approach allows modeling the performance requirements resulted from executing POU and device communications. However, this approach also neglects the change propagation analysis with regard to a system and its requirements.
3.5.3. Discussion on Approaches to Change Propagation Analysis
based on Requirements Modification
The previously described subsections gave an overview on related work to change propagation analysis in different domains triggered by a change to requirements. The approaches to this topic in different domains are designed at different levels of abstraction and are concerned with different aspects such as documentation of requirements, identification of tracing links, or change impact analysis. While in some domains such as IS, there are several approaches dealing with a wide range of the aforementioned aspects, there are only a few approaches to this topic in other domains such as aPS.
The majority of approaches in aPS present formal models for persisting requirements. A subset of these approaches is based on SysML. Thus, these
approaches neglect the change propagation from requirements to the system satisfying them. This issue can also be generalized to the evolution of models and to other domains, as discussed by Etien and Salinesi [ES05]. The authors concluded that “several approaches . . . do not provide indications concerning evolution of the current models. They help to construct new one” [ES05, p. 3]. Further, there are several approaches in different domains such as IS, BP, or aPS discussing the relevance of considering the requirements changes and, thus, describing the change propagation only conceptually and at a high abstraction level. In other words, these approaches do not provide concrete solutions for this issue. Further, there are only a few approaches analyzing the propagation of change from requirements to the systems in more than one domain. Summarized, there is a need for an approach to change propagation analysis based on requirements modification, which can be extended to other domains.