Feature‐driven systems engineering procedure for standardized product‐line development

Numerous systems engineering (SE) methods for the model‐based and textual specification of systems focus on managing complexity solely by partitioning the system based on physical structures or by defining different views of the system and therefore reach their limits in agile development. The increasing demand for an agile system development requires an agile systems engineering procedure for the model‐based and textual top‐down specification of systems. Although function‐based development, variant management, and product line development are well established in software engineering, previous work has failed to introduce methods for the agile specification of systems by combining established methods from systems and software engineering. For that purpose, this paper demonstrates a new SE methodology, which for the first time combines conventional SE methods with the agile development procedure of feature‐driven development. The methodology is systematically developed based on theoretical analyses and its suitability for the application‐specific definition of feature‐driven development processes is demonstrated using the example of reference architectures for XiL simulation models of electric vehicles. By applying feature‐driven development, the resulting CUBE methodology enhances collaboration in interdisciplinary development teams and enables companies to adapt development processes to a more agile top‐down specification of systems.

variant management, and product line development are well established in software engineering, previous work has failed to introduce methods for the agile specification of systems by combining established methods from systems and software engineering. For that purpose, this paper demonstrates a new SE methodology, which for the first time combines conventional SE methods with the agile development procedure of feature-driven development. The methodology is systematically developed based on theoretical analyses and its suitability for the application-specific definition of feature-driven development processes is demonstrated using the example of reference architectures for XiL simulation models of electric vehicles. By applying feature-driven development, the resulting CUBE methodology enhances collaboration in interdisciplinary development teams and enables companies to adapt development processes to a more agile top-down specification of systems.

INTRODUCTION
In the last decades, the increasing complexity of products in various industrial sectors has led to a growing importance of systems engineering in conjunction with project management. 1,2 Especially in the automotive industry, component-based development of the system was established, which resulted in a division of responsibilities and a definition of the system elements according to the physical separation of the system or the development disciplines involved. The insufficient coordination between the disciplines involved and consideration of interdependencies on the upper hierarchical levels of the system resulting from a lack of system thinking led to low specification quality in the form of incorrect, inconsistent, or incomplete requirements. 3,4 For relatively simple systems where much experience is available or where the innovation rate is low, engineers were able to cope with this while bypassing the official process. Often this led to problems with the integration of the system elements to a complete product, caused by incompatibilities and gaps between the requirement specification and the test cases, finally leading to a rise in development costs and time. 4 The trend of increasing system complexity, caused by increasing networking (e.g., in the fields of Advanced Driver Assistance Systems, Automotive Connectivity, 5 or Internet of Things, 6 ) or increasing degrees of automation, and at the same time shortening development cycles, additionally increase the cost pressure for manufacturers and require high specification quality to avoid delays in the development process. [3][4][5][6][7][8] One core strategy for solving the conflicts between time-to-market, cost reduction, and emerging quality problems is the frontloading of development activities. 4,9 This requires increased effort in early development stages, such as requirement specification and architectural design. 9,10 One possible type of frontloading is model-based systems engineering, which focuses on the system-based consideration of products and associated processes in all phases of the product life cycle. 4,8,11 A special meaning is assigned to the systembased development of architectures and requirements on basis of continuously extended models. 3,[12][13][14] Model-based systems engineering requires high coordination efforts between all relevant stakeholders in the early phases of the development, but allows a complete consideration of relevant system interdependencies and technical and subject-specific aspects, which leads to an increased quality of requirements. 3,4 In contrast to classical mechanical engineering, system-based product development is widely established in the area of software, taking into account solution-neutral and product-specific views. Methods for the suitable reuse of system elements and for the realization of variant management have become indispensable in the field of software product line development, but are only rarely used in the design of hardware-based systems. 7 Model-based specification can contribute to improve communication in interdisciplinary development teams, to the avoidance of inconsistencies between requirements as well as errors and failures that would otherwise only be perceived at later verification levels. 4,8 A transfer of these methods for the design of hardware-oriented products or embedded systems represents a large optimization potential in mechanical engineering dominated industries.
Additionally, agile development is continuously gaining relevance also in companies dominated by mechanical engineering. 7,15 The shortening of development cycles enables an improved cooperation, a faster reaction to changed boundary conditions and thus an increased quality of the development artifacts. 7,16,17 The application of development procedures, which have already been validated and established in the field of software engineering, can further contribute to the optimization of product development.
The demand for an agile system specification and development as well as the increase of development efficiency by using established methods of software development leads to the following objective: all presented contents are critically reflected and summarized.

BOUNDARY CONDITIONS FOR METHODOLOGY
The first section of this chapter is intended to ensure a consistent interpretation of technical terms in the field of systems engineering and a common understanding of the presented contents. Following, an overview of existing methods and procedures as well as the underlying targets in the area of SE will be presented.

Technical terms in systems engineering
A system is a collection of elements and a collection of relationships between these elements so that they can be regarded as a limited whole in relation to the elements surrounding them. 18 The term element is used in the broadest sense to capture simple physical things, complex organisms (including humans), environments, and technologies, as well as organizations of humans, information, or ideas. 18 Open systems exist in an environment described by related systems with which they can interact and under conditions to which they can respond. 18 Systems engineering is intended as an "interdisciplinary approach" to enable the realization of successful (engineered) systems. 11,18,19 It integrates all disciplines and specialty groups into one team and forms a structured development that takes into account all phases of the system life cycle. 11,19 One of the main tasks in systems engineering is to work with stakeholders (including customers), represent their points of view to the team and the team's perspective to them, and create a constructive environment for teams, including bridging cultural and communicative differences in multidisciplinary teams. 11 In this context, unambiguous definitions of all technical terms are of crucial importance in order to achieve unequivocal and clear communication.
In recent years, this problem has already been addressed in numerous publications and standards in the fields of systems and software engineering. However, the analysis of several publications shows an inconsistent use or an unestablished, non-uniform understanding of the technical vocabulary in the field of SE. In order to clarify the meaning of these terms in context of this publication, the central and relevant terms are defined by extending and summarizing existing publications and standards. It is important to distinguish the meaning of the terms methodology and method, process and procedure as well as activity and approach: "A methodology can be defined as the collection of related activities, methods, procedures, processes and tools used to support a specific discipline or to a class of problems that all have something in common." 11,12,20 In other words, a methodology is essentially a "recipe" to address a common group of problems. 12,21 No detailed application directives are made, for example, standardized duration of phases of the procedure, but only means are provided for addressing the problem or the group of problems, which must be adapted project-and product-specifically.
The associated processes represent a group of elements of a methodology (cf. Figure 1). These include the definition of activities for the realization of a desired result on the basis of provided input information. In addition, all time aspects, such as the duration of activities or necessary start/end points including the necessary resources, their roles and responsibilities as well as the resulting work products are defined.
"A process is a set of interrelated activities that is concerned with transformation of input to output, including definition of roles, responsibilities, milestones, work products, duration, resources and not concerning how the required output is obtained.'' 8,12,20,[22][23][24] Activities represent the sub-elements of a process. 25 In turn, they can be broken down into tasks and are characterized by time expendi-F I G U R E 1 Relation of technical terms in systems engineering ture, a duration for execution, clearly defined start and end times, and associated resources. 25,26 "An activity is a set of distinct scheduled tasks that consume time and resource and that are assigned to perform the realization of necessary outcomes.'' 8,20,[25][26][27] When defining processes or activities, no concrete description is given of the way in which a process step is to be performed. Likewise, no logical dependencies of steps are defined. These contents are represented by methods, which can be used for the execution of the process steps. 12,28,29 Exemplary is the specific transfer and application of model-based development for the execution of an activity in the development process.
A method is a systematic way to accomplishing projects or solve problems through detailed and logical plans based on a specific mindset. 12,[28][29][30][31] Established methods that specify concrete sequences of steps for the implementation of activities or processes and whose application achieve reliable and consistent results are defined as procedures. The waterfall model, V-model, or similar approaches are exemplary models for the presentation of an established procedure. 8,11,16 In contrast to the process, procedures only define logical dependencies of steps during execution, but without defining time sequences, durations, respon-

sibilities.
A procedure is an established method of accomplishing a consistent performance or result. A procedure typically defines the sequence or ordered series of steps to perform an activity or process. 20,[22][23][24]32 In the field of systems engineering, the term approach is often used and inconsistently equated with the meaning of the previously defined terms. The currently valid versions of the norms relevant to SE do not define the term approach. In common parlance, an approach is understood as a specific way or idea to deal with a problem. For this reason, it will be used in the following as a synonym for the term method.

State-of-the-art systems engineering processes and procedures
In the field of systems engineering, several procedures and methods have been published in recent decades. In the following, single publications will be exemplarily presented. An exhaustive description of all existing methods is expressly not guaranteed.
One of the best known standards in the field of SE is part of ISO Standard 15288-Systems and Software Engineering-System life cycle processes. 19 The standard provides a "set of related processes" that can be used to design appropriate system life cycle models appropriate to their products and services. 19 The provided descriptions are divided into four groups (agreement processes, technical management processes, technical processes and organizational project-enabling processes). The philosophy behind this standard is based on the ability of the system engineer to divide the presented descriptions into an order of activities that are applicable to the program. 33 At the same time, there is no specific logical order presented for sequencing activities, nor are durations, resources, or tools defined. 33 For this reason, it should be understood not as processes but as a set of activities necessary to achieve a desired result.
A similar objective is pursued by the BWI Hall Concept. 34 This method places particular emphasis on general applicability, is not oriented to specific fields and is intended to offer support where other SE methods do not provide an answer. 34 The method is to be regarded as a formal framework that provides methods without prescribing a procedure. 34 For this purpose, general descriptions of the "SE philosophy," for example, system thinking, as well as four essential modules for the design of systems are provided. The first module is called "Top-Down" and describes the continuous decomposition of the whole system into smaller elements whereby the detailing is increased (cf. A II). 34 The second model "Variant Development" contains the formation and consideration of possible variants in order to consider all possible solutions of the system. 34 The "phased approach" (project phases) as the third module represents a planning instrument (macro instrument) for F I G U R E 2 The systems engineering method top-level flow diagram 33 deciding which activities are necessary to achieve the desired results in different project phases (management-oriented components of the model) (cf. A IV). 34 The problem-solving cycle is the fourth module and should be used in the implementation of all phases, corresponding to the third module. 34 It forms the micro-strategy for structuring the phase cycle. The situation-related combination of the building blocks is intentionally left open, so that the users themselves should choose which and in which form, modules are used. 34 A transfer of the method to agile applications is made possible by the modularity and thus good adaptability to the development processes.
According to the definitions presented in the last section, the "Systems Engineering Method" 33 is a scientific procedure to the engineering of a complex system. Four steps are defined, which are to be run through systematically in order to determine an optimal solution based on customer needs (cf. Figure 2). At the beginning, all requirements to be considered (requirements analysis) are collected, which are then used for functional descriptions of the system (functional definition). 33 The third step involves the synthesis of a series of alternative system components representing a variety of design solutions to implementing the required functions (physical definition). 33 Systematic, physically oriented partitioning is recommended for system design, but no clear instructions are given for implementation. The final step is the validation of the previously defined solution (design validation). 33 In each of the steps mentioned, knowledge could be gained that would make it necessary to repeat the previous step. In particular, the validation can lead to an additional specification of new requirements that were not considered at the beginning, which requires a complete, iterative execution of the steps. The described four-stage procedure can be applied in different project phases. Depending on the project phase, the focus of the development is on different aspects, so that the scope of the activities must be adapted.  The Object-Oriented Systems Engineering Method (OOSEM) is again a stepwise procedure for the design and specification of systems (cf. Figure 3). 11 Analogous to The SE-Method, the first step is to analyze the needs of the stakeholders. 11 In a second step, the system requirements are analyzed, followed by the definition of a logical architecture. 11 In the last step, possible physical system architectures are considered. 11 These steps can be applied to different system hierarchies and run iteratively. 11 Overall, OOSEM represents a collection of activities for each phase of the quadrinomial procedure that can be used for specification of systems. Procedures for the implementation of the individual steps must be defined application-specific by the user. 11 Special focus is put on the model-based implementation of the specification, which is realized by an initial creation of a system model. 35 Furthermore, parallel activities for variant evaluation and traceability of requirements are demanded. 35 Analogous to the methods and procedures presented so far, the definition of the system elements at OOSEM is carried out based on the physical system structure. A feature-based development is not explicitly considered by OOSEM, BWI Hall Concept and The Systems Engineering Method, even if the functionality is described on a system level and partitioned into functional elements. An explicit description of the hierarchy levels to be considered is not given by OOSEM. The definition of logical architectures supports in particular the consideration of variation points as well as the associated possibility to specify product lines.
Consequently, this procedure does not focus exclusively on the specification of an ideal solution for the realization of the requirements.
The lesser-known SE methods SPES (Software Platform Embedded Systems) (cf. A II) 36 and its extension SPES XT 37 as well as SMArDT (Specification Method for Architecture, Design and Test) (cf. A I) 3 and it's project-specific extension MTSF (Model-based Testing of Software-based Functions) 3,4,38 focus on the system-based design of embedded systems. These methods combine four viewpoints respec-tively abstraction levels with different granularity layers respectively decomposition levels. 4,37 Analogous to OOSEM, the four viewpoints are divided into consideration of all relevant requirements (requirements viewpoint), description of functions assigned to the system or system elements (functional viewpoint), definition of logical architectures (logical viewpoint) as well as of the technical system realization (technical viewpoint). 4,37 The logical system view is not emphasized by SMArDT and MTSF, but the "realization" is defined as the fourth system view. 3,4 After defining the technical solution, the details specific to the implementation are specified and then implemented. 3 The granularity levels of SPES and SPES XT correspond to the physical partitioning of the system. 36,37 SMArDT and MTSF also pursue additionally the goal of function-based development. 4 For this purpose, the four abstraction levels are used to describe a system from the point of view of a feature.
A clear separation of the function-based consideration and the physical partitioning does not occur.
The aspect of variability is made possible in the methods mentioned, analogous to OOSEM, by the consideration of a logical architecture.
Furthermore, SPES XT defines variability as orthogonal relationship, which has to be considered in the system design. 37 Concrete procedures, how the specification of product lines is to be realized, are not described in detail. Additionally, SMArDT and MTSF focus in particular on the aspect of verification and validation of the specified system. 3,4 The model-based specification is used for the automated generation of test cases by means of high formalization of the artifacts. 3 The increased efforts for the creation of model-based and formalized artifacts are more than compensated by strongly reduced efforts for the test case definition. 3 The application of SPES XT and MTSF for agile development processes as well as the consideration of temporal product versions are not explicitly defined by the methods.
The procedures and methods described in this section target the improvement in all phases of the development cycle. They differ in the addressed life cycle phases, the intended application contexts and the focused aspects of development. Depending on the planned field of application, project or system to be developed, the advantages and disadvantages of the methods must be weighed up and the most suitable must be selected accordingly.
The need to implement systems engineering in a more agile way has led to the derivation of key characteristics of agile development for the field of SE. Based on the assumption that agile is much more a mindset than a set of rules to be followed without regard to their appropriateness, the consideration of these characteristics should enable more agile development based on unchanging SE fundamentals. 39 In this way, the customer should prioritize the requirements, progress should be measured against operational features, and lessons learned should be used to adapt both processes and the system under development to meet the customer's needs. 39 Short iterations with the goal of executable work products, continuous integration, lean processes that only specify the essentials, and a focus on team ownership should also contribute. 39 As an example, Harmony aMBSE can be cited, which defines a concrete procedure for the development of optimized systems with a focus on agile key characteristics. 40 For system design, a model-based procedure is proposed using different system views and physical partitioning. The realization of incremental and agile system development is made possible in particular by the use of numerous iterations during development. 40 The assumption that systems are becoming larger, more complex, and more software-based again reinforces the use of agile development. By focusing on software development, SE can leverage the flexibility and adaptability of software to define the system and its components in such a way that software development is less complex and the system architecture and design supports the effectiveness of software development. 39 In particular, a common high-level system architecture can enable both the process and the product to respond effectively to new and immediate situational requirements. 41 A combination of the agile approach of FDD and at the same time a physically oriented decomposition of the system is not yet addressed by the existing methods and procedures, can contribute to the implementation of the agile key characteristics and will therefore be investigated in more detail in the following.

METHODOLOGY
The following chapter presents the novel systems engineering methodology -Compositional Unified system-Based Engineering (CUBE). CUBE can be seen as an extension of SMArDT 3 and combines established methods from systems and software engineering, such as the agile procedure feature-driven development. 11 In the field of SE, the use of the System Modeling Language (SysML) is well-established for model-based system specifications. The language provides a large number of structure and behavior diagrams to define systems from different perspectives and at different abstraction levels. 4 However, it does not provide detailed instructions as to which diagram types to use in which order or for which abstraction level. 3,38 A textual specification is possible as a supplement to or exclusive to model artifacts. The new methodology shall enable textual as well as model-based specification of products with different kind of software tools suitable in this context. Due to the large number of established software tools for textual and model-based specifications, the aspect of tool support will not be dealt with in the chapter III.A-D, but instead the focus will be on the procedure model underlying the methodology. In section A, the underlying objectives are presented. Sections B-D focus a description of CUBE and the covered aspects as well as a description of the theoretical, ideal sequence of phases for the system-based topdown specification of products and product lines using the new procedure. In chapters E and F an application example as well as explanations for industrial application to realize agile processes are presented.

Objectives
The following procedure focuses and is at the same time limited to the system-based and feature-driven specification of products, whereby the product to be specified can be understood as a system according to the definition in section II.A. Consequently, in the specification of the system, its elements and the internal and external interactions, the concept and development phase in the system life cycle are addressed. 11 Consideration of the subsequent development phases, such as production, utilization, and retirement, is not carried out. 11 Furthermore, the procedure exclusively describes the core area of development. Support processes, such as supplier management or product management, are not described in detail.
The conceptual design of a product is characterized by different trends, such as rising complexity due to the increasing connectivity and intelligence of systems, from which challenges result that must be addressed in an appropriate manner. 5,6,8 In the following sections the objectives are presented, which address current challenges in product development and have led to the development of the new procedure model.
According to the principles of agile development, customer satisfaction is the most important asset in product development and the most decisive factor for the success of a product. 17 If the customer is not satisfied with the product, the product is not bought and recommended, which leads to a decline in sales figures and thus to low long-term sales for the manufacturing company. Therefore the focus of the entire development must be on the satisfaction of the customer.
Consequently, all the wishes and needs of the customer must be taken into account when developing the product (analogous to the OOSEM procedure, The Systems Engineering Method and SMArDT). The analysis and specification of these needs must be done in cooperation with the customer to determine the actual needs, which often cannot be fully specified by the customer itself at the beginning of the development.
The procedure must support this analysis and specification by defining required activities. In this context, the customer can not only be understood as the end customer who acquires the product, but also internal stakeholder that has to be considered. Furthermore, the interactions of the product with other systems must be considered in order to ensure correct operation in all use cases. This is the main objective in the development of a product: Objective I: Specification of the product or product line with focus on stakeholder needs, respectively their expectations, as well as the system context The creation of specification artifacts during the system design phase is very time-consuming. Too much effort drives up development costs, which can result in a lower company profit. Therefore, the ideal procedure has to limit the number of artifacts required for specification as well as offer measures for controlling product development

Overview of compositional unified system-based engineering
Compositional Unified system-Based Engineering (CUBE) is targeting generic, system-based specification of products and product lines based on stakeholder needs by providing a standardized, uniform procedure for the specification of systems, regardless of the industry. The CUBE model (cf. Figure 4) illustrates five central dimensions that are recommended to be taken into account when specifying a system and which are covered by the CUBE procedure.
As an extension of MTSF and SPES XT, the compositional character is a central dimension of the procedure (addressing Objective III). As a base for development, the system context of the product to be devel-  The second central dimension is the definition of five different abstraction levels to represent different views of the system with a consistent system boundary (addressing Objective II). An abstraction level, which is independent of the physical decomposition of the system, allows a focused view on a system element, independent of the decomposition layer. Furthermore, it enables a continuous extension of the specification artifacts for the focused decomposition element with stepwise addition of more detailed system information.
The first level of abstraction focuses on a black box view of the focused element and includes the specification of all external requirements for the system, such as stakeholder needs (customer value) and expectations of other involved systems or actors. 11 Furthermore, the interfaces to these adjacent systems and the relevant system context are defined. This view on the considered element describes the most abstract view on the system. The following levels of abstraction describe a white-box view of the system. The main focus here is on the functionality and the internal structure of the system. 11 The for each requirement must be ensured already during system design in order to guarantee a successful implementation of the functionality required by the product. For this reason, the model also highlights crucial elements of the verification and validation phase, which must already be considered in the specification phase. In this context a manual creation of test cases but also an automatic test case generation, analogous to MTSF, can be applied. The application of test case generation requires the creation of a consistent and formalized system model (according to MTSF and OOSEM), which can be used as a basis for test case generation.
As a fourth aspect, the specification of functional product variants is addressed (addressing Objective V). In contrast to the technical variants mentioned in the paragraph on abstraction layers, these do not diverge through functionally identical implementation decisions, but rather exhibit different functionality. Thus, the system to be developed can be realized by different operating principles and still fulfill the same customer benefit equally, for example, different types of powertrains in a vehicle to fulfill the customers demand for mobility. In comparison, the choice of the product design (e.g., the product color) represents a non-functional aspect, would require an identical functionality and for this reason would be assigned to the area of technical variability.
As the last dimension, the model illustrates versioning of the product specification (addressing Objective VI). In this context, versioning must be considered from two different perspectives. On one hand, the product itself can have different product versions in terms of time and function due to further development and changing customer requirements. The procedure for specifying the product must therefore offer the possibility of documenting these different product versions. On the other hand the specification of a certain product is subject to a temporal duration, so that during the specification phase, in particular up to the complete conclusion of the specification, a versioning of the artifacts is necessary. Depending on the type and size of the project team or the company, the complexity of the product, the company structure and the development processes, an adaptation to agile and flexible or also conventional development processes is required.
The type of process strongly influences the frequency of the necessary versioning of specification artifacts. The procedure model can be used as base for the definition of different specification processes and thus provides a possibility to address these challenges in the context of versioning.

Product specification procedure and application
In the previous section, the CUBE model with its recommended dimensions was presented. A concrete sequence of steps to pass through the levels of abstraction and decomposition defined in the model and which relates the dimensions has not yet been considered. The application of CUBE for process definition within a development project is always subject to project-, company-, and product-specific constraints. Nevertheless, based on theoretical considerations, there is a recommendable sequence of steps for addressing the objectives mentioned in Chapter III.A, which is defined in the form of a procedure (cf. Figure 5).
The basis for the specification of a system (SoI) is a consideration and definition of the system boundaries of the SoI, its system context and the system stakeholders. On the basis of these clear definitions, the expectations or needs of the stakeholders with regard to the systemof-system as well as the interactions of the SoS with its system context can be specified in the form of black box requirements in a first step. These include both functional as well as non-functional requirements. The relevant stakeholders can be manifold, so that an analysis considering different views on the system, for example, for architectural aspects using "4+1 View Model,'' 48   With the further addition of customer-specific requirements to SoI that were not part of the consideration at SoS level, the definition of a new group of functional features (e.g., fully automated and energyefficient transport of vehicle passengers on highways) for addressing the customer requirements addressed to SoI ensues. Analogous to the procedure on the previously specified decomposition level, a feature-specific description of the SoI is used to specify an operating principle and a logical architecture for each feature. The combination of the data from the feature-specific logical architectures is in turn used to define the logical architecture of the SoI. The architectural elements contained represent the structure and configuration of the SoI and are considered separately on the following decomposition level. In contrast to the transition from the first to the second decomposition level, all elements described in the LAS(SoI) must be considered, as this is the only way to ensure a complete specification of the SoI. With the optional addition of specific customer requirements, a group of system element specific features is defined and the feature-based procedure, analogous to the previous decomposition levels, is applied. This can be used to systematically decompose the system using an arbitrary number of hierarchy levels to reduce system complexity.
After completion of the specification of the logical architectures

Functional system variant consideration concept
In the previous investigations, the aspect of functional system variants was not considered. However, it is very often necessary to consider system variants when specifying products and especially product lines. In At the following decomposition level, this results in subsets of system elements from the LAS(SoI) that can be assigned to at least one or more system variants. The more variants of the previous decomposition level can be assigned to a subset of the subsequent decomposition level, the higher is the prioritization of a maximum number of elements within this subset. This is due to the fact that the highest possible number of system elements that can be assigned to more than one subset enables system elements to be reused across variants. The specification of these system elements, regardless of whether they can be assigned to one or more system variants, is performed in parallel and analogously to the procedure for a variant-less system element (cf.  According to the FDD procedure, in a second step a feature list is created. Each previously determined requirement of an actor must be assigned to at least one feature. The list itself can be created both textually and model-based. A model-based specification can either be an extension of the use case diagram created in the first step (cf. Figure 8, left) or it can be created as a new view that shows the relationship between use cases and features (cf. appendix A VI). The definition of the feature itself is strongly product dependent and can be done according to different principles. The feature "Simulation of physical electromagnetic system behavior" will be considered in the following. In this example the definition of the feature was mainly made considering different simulation domains. A feature is therefore assigned to as few domains as possible. This makes it possible to reduce the coordination efforts between developers of different domains.

Application example-standardized simulation architectures of electrical vehicles
In a third step, the operating principle of the SoI is described from the perspective of each individual feature. To illustrate this white box view of the features, behavior diagrams of the SysML are well suited, such as activity diagrams (cf. Figure 8, right). The visualization of the operating principles of each individual feature allows a reduction of complexity compared to the behavior representation of the whole system. Furthermore, the freely adjustable definition of the feature allows to limit the behavior to be described to relevant aspects. For example, the feature definition according to simulation domains enables developers of these domains to focus on the aspects relevant to them. The considered feature describes the electromagnetical behavior of the simulation model from the source (e.g., battery) to the sink (e.g., emotor). For reasons of simplicity, it does not show the recuperation path and the information received by or sent to other features. The last activity describes the generation of a magnetic power which can be used to generate kinetic energy. The description of the behavior is F I G U R E 8 Excerpt of use case diagram for BEV plant simulation (SoI) variant 3 including allocation to feature list (left), Activity diagram for feature "simulation of physical electro-magnetical system behavior" (right) solution-neutral, without specifying which activity is realized by which element of the system. The fourth step is to define a logical architecture for the previously specified operating principle of each feature. The activities are assigned to individual system elements, but without defining their kind of realization (cf. Figure 8, right). Based on the object flows defined in the activity diagram, the interfaces of the system elements necessary for the realization of the feature are defined. Structure diagrams, such as internal block diagrams (IBD) (cf. Figure 9, top) are particularly suitable for representing the static aspects of the logical architecture.
In this example the logical architecture consists of eight components.

Definition of industrial specification processes
The presented procedure model defines a logical sequence of steps and their dependencies for the feature-based specification of product lines. For a complete process definition, in addition to the definition of responsibilities and roles, the definition of time constraints, such as milestones or the duration of activities within the specification phases, is required. 8 In particular, these time aspects in the execution of projects are strongly dependent on the corporate culture of the executing company.
In the automotive industry, development of conventional, linear or iterative process models has been state-of-the-art in recent decades and is still widespread today. At the same time, a trend towards the development of more agile and flexible development has been discernible in large companies in various sectors for several years. 47 In order to give both companies with conventional and agile development processes the opportunity to use the proposed methodology, it was developed with the purpose of defining a procedure model which can be used as a base for definition of conventional and more flexible, agile specification processes (addressing Objective VI).
The procedure describes steps for the feature-based development of a logical architectural definition of a decomposition element that is repeatedly applied to hierarchically ordered decomposition levels.
The steps of this structured procedure can be performed completely sequentially, starting with the specification of the SoS. This results in a very thorough specification of the system during the first run through of all decomposition steps, but is at the same time very time-consuming and requires few iterations due to the high duration required to complete a cycle (cf. Figure 10). This procedure is strongly comparable with the conventional waterfall model and shows major weaknesses in the reaction to changes, such as additional or changing customer requirements and the associated specification of necessary product versions.
Alternatively, the FDD allows the specification of individual features to be parallelized. A parallelized specification of individual system It is important to avoid increasing the specification frequency excessively, as this can lead to an excessive reduction in the number of specifications per cycle and thus to a reduction in productivity. An excessive number of parallel processed specification elements at a high frequency can result in an overload and a resulting loss of quality.
In the automotive industry, the organizational structure frequently is oriented towards the physical system architecture, and often reaches its limits when FDD is introduced. New feature-based artifacts in the development process require new responsibilities and, in particular, increased interdisciplinary cooperation between development teams.
To address these challenges, it is recommended that new roles are defined in the development project. Central responsibility for the complete specification, implementation, verification and validation of a feature belongs to the feature owner, who is responsible for monitoring the workflows and quality of the work products for the feature assigned to him. 38  All in all, FDD in large industrial projects allows an additional reduction of complexity by facilitating smaller, independent development teams. 38 Secondly, interdisciplinary cooperation improves both the work product quality by involving all relevant stakeholders at an early stage and the self-commitment of the employees involved by means of joint processing. 38

CRITICAL REFLECTION
The presented theoretical considerations, which led to the development of the methodology, represent an idealized, system, and featurebased top-down specification of product lines. It exclusively describes the system design procedure as part of the concept and development phase in the system life cycle. A consideration of the subsequent development phases, such as production, utilization, and retirement, in the form of a definition of steps for the implementation of these phases is not covered. At the same time, it is essential to ensure that the above-mentioned phases are taken into account in system design and can be implemented by considering the system requirements resulting from these phases. Support processes, such as supplier management or product management, are not described in detail.
Furthermore, the methodology is based on the assumption of a completely new development of the system, so that a solution-neutral consideration of the system can be carried out. However, this is often not possible or desired in industrial projects, since previous versions of the system already exist and are to be reused to the greatest possible extent. A complete new development of systems, in particular if a reuse of already existing product elements will subsequently no longer be possible, leads to significantly increasing product development and production costs. In the case that a purely theoretical consideration is possible and no existing product must be considered, the solution-neutral specification of a system is an idealized procedure. Even in that case, it cannot be carried out completely independently of technical boundary conditions.
The architecture design is influenced by physical boundary conditions in all cases, in which the development is not exclusively addressing software systems. These must be taken into account in the design and lead to an influence on the system design, even if a solution-neutral specification is intended. Consequently, there is always an influence on the architectural design, more or less intensive depending on the system to be specified, by the knowledge of existing or physically feasible technical realizations.
The presented procedure describes FDD, which additionally considers physical partitioning. For less complex products or developments that refer exclusively to a given system element, feature-based development can also be applied without physical decomposition and thus on only one decomposition level.
FDD is an established and scientifically researched part of software development. The combination with methods from the field of SE has not been scientifically researched so far and is therefore of high interest. In particular, the quantification of possible effort reductions in the development of complex systems has not yet been carried out.
In the last section of the previous chapter, the definitions of specification processes based on the introduced procedure were investigated. Especially agile processes have short, iterative development cycles. However, the use of conventional specification processes does not exclude an iterative development. SE is an iterative top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system. 11,54 A pure top-down specification without iterations would not be able to take into account the results of already completed subsequent phases. Iterations should therefore be performed during specification or development whenever necessary. The CUBE procedure does not give any recommendations for action in which cases iterations are meaningful or required, since these decisions are strongly project-and system-specific. Nevertheless, it gives the possibility to perform iterations between single artifacts, single decomposition levels, functional features or system variants. The complete specification can also be run through again after it has been successfully completed, for example to take into account changed customer requirements in the form of a new product version. The decision as to which type of specification process and in which cases iterations make sense must be made by the system developers on a case-by-case basis.
The challenges that an industrial company has to manage when introducing FDD are dependent on the company and product. For example, the definition of internal policies for the definition of features, the definition of new roles in the development process or the adapta-tion of the company structure are not specified by CUBE. A generally valid definition of these aspects is not possible in a reasonable way, so that the named decisions, as well as the training of the employees, have to be carried out in a company-specific way.

CONCLUSION
In this contribution, a novel systems engineering methodology for the feature-driven development of product lines was systematically developed. On the base of a theoretical analysis of existing methods, procedures and current challenges in the field of SE, objectives for the derivation of an appropriate specification methodology were systematically derived. The underlying procedure model combines proven methods from the field of SE, such as stepwise partitioning of the system and structured specification by means of different system views, with the agile procedure of FDD. By combining these methods, it is possible to reduce system complexity in the specification to a greater extent than is possible with non-feature-based development. Additionally, the pre- In the future a more detailed presentation of the application of the methodology for the model-based and textual specification of systems is planned. Especially, the design of new system generations based on already existing system versions has to be investigated in more detail, since an idealized top-down specification is not possible in this case. Furthermore the combination of the presented methodology with scenario-based development for automated or fully autonomous driving functions is already under investigation. In addition, the quantification of effort reductions by applying the new methodology is to be carried out after the successful completion of a large number of development projects.

ACKNOWLEDGEMENT
The authors thank all partners of the HiFi-ELEMENTS project.