## 1 Introduction  
Studies from different development contexts show the high amount of requirements changes [1, 2, 3, 4]. Half of all system requirements are assumed to have a high likelihood of change [5], which is why requirement changes are given priority over additions or solutions, especially in the early phases of development [3]. As an example, the empirical study of a six-year project for the development of an aircraft turbine by the Rolls-Royce company can be cited: In a set of 700 system requirements, more than 1000 adjustments of requirements were documented (addition, change or deletion), of which the majority were requirement changes [3]. The actual extent of the requirement changes is assumed to be even greater, since undocumented requirement changes that do not go through the formal change process are not considered in change statistics. Every change to a requirement leads to cost increases and additional time required for development. Besides the initial effort, changes to requirements can have an effect on dependent requirements (change propagation). Due to logical or physical dependencies, requirements form a complex network [6]. Therefore, a single requirement change often leads to a series of subsequent requirement changes [7, 8, 9]. The following example from the development of an LED headlight for BMW [10] illustrates such change propagation: The requirement of the maximum temperature of the LED substrate is critical for the headlight performance. It was initially set at 120 \({}^{\circ}\)C. In the course of the development, the maximum temperature was reduced to 90 \({}^{\circ}\)C. To reduce the temperature of the LED substrate while maintaining the performance of the headlamp, more LEDs, but with lower energy consumption, had to be considered. This, in turn, required changes of the building-space requirements. So the initial requirement change resulted in interdisciplinary requirement changes for energy demand, number of LEDs, and building-space due to propagation effects. Efficiently managing such requirement changes is a key challenge in the development of complex systems [2,3,5,11]. However, requirement changes in development practice have been handled reactively, unsystematically, and based on subjective expert assessments so far [12, 13, 14]. For many years, studies have shown that inefficient management of requirement changes is a major cause of missing the specified project goals (quality, cost, and time) [1,4,15,16,17,18]. Despite these findings, industrial practice lacks tools that go beyond the reactive management of change requests and support a systematic data-based approach to proactive management of requirement changes. Proactive management means forward planning and directed actions to influence the evolution of the change event and frontloading decision situations [19]. It requires the identification and handling of potential requirement changes in the phase before the change need has been captured in a formal change request [20]. Neither commercial software products supporting requirements engineering, such as the market leaders IBM Doors, Sparx Enterprise Architect, or Siemens Polarion [21], offer functionalities for proactive management, nor does sufficient research exist on the proactive management of requirement changes [2,5,13]. Instead, the focus is on reactive management of formally recorded change requests. This is focused on effective decision making and efficient change implementation, but does not enable prevention and frontloading measures. Thereby the action space is limited. Proactive management of requirement changes can open up this action space and reduce the negative effects by considering the phase before a formal change request (cf. Figure 1). Major action strategies are change prevention [20] and frontloading in order to reduce the change impact [22,23]. The aim of this research is to unlock the potential of proactive change management for requirement changes in industrial practice.