## 7 Combination of the Models  
This section deals with the core innovative approach of the described research. From the last two sections, both conditions for the approach to connect requirements with the product are satisfied, and a model for generating railway vehicle gear systems as well as an innovative model for requirementsmanagement were developed. In these two sections, no special focus was on the explicit digital mapping of requirements to the product model. For this kind of mapping, the definition of an interface between both models (\"requirements\"-\"geometry synthesis\", compare Section 1) is needed. This aspect will be addressed in this section. The term \"interface\" may also understood as \"combination\". A combination of both models can lead to model-based requirements management. The model-based requirements management has in very general terms three main aspects which could also be understood as dimensions (Figure 15). The first dimension equals the model for generating gear system design variants (compare Section 5, Figure 15, right red frame), the second dimension equals the model for requirements management (compare Section 6, Figure 15, left red frame), and the third dimension equals the main approach (objective) of this research, the linking of requirements to the product graph. This linking is represented by a blue association link (Figure 15, between red frames, Result) that forms the connection between both models. Requirements can be linked to modules or components of the product or to the product as a whole, regardless of the point at which the product life cycle is situated. That leads to an assignment of gear system classes to requirements or vice versa (compare Figure 15, blue association between red frames). Hence, attribute \"RelatedToPart\" is introduced within structuring of requirements, and a concrete assignment from a certain requirement to its related product, module, or part can be described. Figure 16 shows an example for the general approach of model-based requirements management. A connection exists for an instance of the class \"requirement\" that specifies the distance between axle center and center of motor shaft (compare Figure 16, highlighted blue node) to the related part of the gear system, instance of class \"Housing\". Whereas the instance of the class \"Housing\" has an influence on its underlying components/parts. Consequently, changes in the requirements entity (compare Figure 16, value in red) lead to changes of the product (here: causes topology changes of the resulting gearbox). The connection between requirements and the design process can be expanded. A more advanced mapping of requirements to components and assemblies will be implemented in near future. The assignment process (instances of \"requirement\" to \"geometry synthesis\" or vice versa) is currently carried out by using search words. This kind of search has been defined and programmed  
Figure 15: General approach of model-based requirements management. for the case of rather obvious requirements. In order to achieve appropriate general validity, it is conceivable to use an intelligent search algorithm here. Also, the concrete value of the requirement is passed through the content of instances to which a connection exists. Thus, the requirements are used for the layout process of the product variant and furthermore to a consistency between product variants and its requirements. Since that mapping process of requirements has happened gradually in the design process, design decisions are carried out based on the requirements. As an example, the gear ratio has an influence on the topology of the resulting gearbox. One may note that requirements can be mapped to all layers of the product architecture. Figure 16 shows an example of how requirements can be mapped to the product architecture. The product as a whole consists of five layers in the upper area of Figure 17. The layers below represent the classification of a requirements collection by using the taxonomy of [PERSON] et al.