A Model-Based Design Method for the Correlation between Customer Feedback and Technical Design Parameters in the Context of Systems Engineering

Abstract

Nowadays considering trends such as digitalization, automated driving as well as electric mobility in products in automotive development processes is a major challenge, which has led to an enormous increase in the number of product functions of technical systems. However, the recognized processes in automotive development are strongly component-oriented and such processes partially support the development of product functions. In order to meet future trends and ensure long term customer satisfaction, a transfer from component-oriented to function-oriented development is necessary. Accordingly, a holistic concept can be useful that enables the integration of customer feedback into the early phase of product development in the context of function-orientation. However, the customer feedback evaluation and their mapping with technical subsystems have been considered mainly in the context of component-oriented development. In this contribution, a method is proposed, which is generated in the context of a product model of product generation engineering. Product Generation Engineering enables the structuring of the development process of a product generation and supports function-oriented development. The Product Model provides customer- oriented development of mechatronic products. The proposed method is achieved in the sense of model-based systems engineering and validated by the exemplarily application of a case study of a specific vehicle. Both the past and current product generations of the specific vehicle are taken into account in the development of the subsequent product generation.

1. Introduction

Trends in automotive development such as digitalization, autonomous driving as well as electro mobility have led to an enormous increase in the number of product functions of technical systems. However, in automotive development, the popular and recognized processes are strongly component oriented. Such processes partially support the development of product functions. In order to meet future trends and ensure long term customer satisfaction, a transfer from component-oriented to function-oriented development is necessary.

In addition, complex products such as vehicles usually have numerous customer requirements as well as technical subsystems. Interactions or conflicts arise both between the requirements and between the derived technical subsystems. Therefore, it is necessary to apply approaches, such as Systems Engineering (SE), which divide the required evaluation, and finally the decision, into manageable subtasks in the context of function-oriented development. In order to overcome the challenges of SE, and to structure the product development process of a new product generation, Product Generation Engineering (PGE) is developed, which also supports function orientation considering reference products [1]. Moreover, the increase in complex products has led to a growth in diverse application systems. Due to growing product complexity, networking of these data is required to a higher degree. The access to these data must be controlled by appropriate systems so that the processing of these data can be realized by different developers in a distributed development environment (e.g., electrics and electronics development, construction development, concept pre-development etc.). To support this, tools can be used—built in the context of model-based systems engineering (MBSE).

In order to ensure long term customer satisfaction in the context of function orientation, customer requirements of existing products should be determined and integrated into the early phase of next product generation development. Ideally, these customer requirements are addressed with technical subsystems. To support customer-oriented development, customer research instruments, such as empirical surveys are used by many manufacturers. Ideally, the determined customer feedback information from these surveys is addressed with technical subsystems.

Consequently, the aim of research in this contribution is to address both function-orientation and customer-orientation in the development of complex products. The research lies on the integration of the customer feedback from external resources, such as empirical surveys, into the early phase of product development and their interactions with technical subsystems. This will be executed in the context of PGE and MBSE. The present contribution shows in addition the validation of exemplary application of a case study and modelling of a specific vehicle. Thereby, the past and current product generation of the considered vehicle is compared in order to be incorporated in the development of the next product generation. The present method contribution ends with a discussion of the results and gives an outlook in the conclusion.

2. State of the Art

Systems engineering (SE) can be used as a methodological support with an interdisciplinary approach in the development of technical subsystems [2]. At this point, a system represents not only the sum of its elements but is also defined by their interrelationships [3,4]. It is a discipline that is based on requirements and all related activities [5].

In order to overcome the shortcomings of earlier document-based SE approaches in product development, like the lack of traceability and dependencies between requirements and system elements, approaches have been developed, and are still being developed, in the context of MBSE [6,7]. MBSE supports a collection of applicative modeling methods and is centered on the evolving systems model, deals with the design of complex systems and produces mostly point solutions [7,8,9,10]. MBSE contains different types of aspects, such as behavioral analysis, system architecture, simulation, requirement traceability, etc. [11]. The goals of MBSE are the integration of the results of different development activities in a central common system model [12], a description of the interrelationships and interactions of these individual elements [3] as well as generating a mechanism for driving more SE depth, where the increase of costs are prevented [11]. According to Zafirov, to describe the structure in a multidisciplinary system model, four key artifacts are identified, which are referred to as the system architecture elements. These elements are the requirements, the product functions, the logical system elements and the physical system elements (hardware and software) [13]. With the help of MBSE, a model or set of models can be used in order to document and communicate from the system requirements level down to the software implementation level [4,11]. By using a set of models, the connection of models is provided, and these models are dependent on each other. This ensures an automatic requirement of the update of the set of models if there are any changes in one model [4]. Furthermore, models, based on SE, are also relevant for other fields of manufacturers, such as production, which supports to start from the concepts of a manufacturing system. This will be integrated in related models to prevent for e.g., interoperability problems [14]. One of the major advantages of MBSE compared to a document-based approach is that all relevant information about the system is captured in a holistic system model. This information can be transferred to the respective addressee in a user-friendly manner via different views [2,4].

The PGE approach has been developed for describing new generation developments of technical systems. With the help of PGE, it is possible to develop beneficial methods and processes to meet the challenges of product development in the context of function-orientation [1,15]. Function orientation leads, for example, to increased efficiency by linking product features with technical subsystems via product functions [16]. The increase in product complexity also makes the product development process more complex, resulting in the need for communication, coordination and information exchange between the disciplines involved [17]. The Product Model of PGE was developed by Albers et al. and provides customer-oriented development of mechatronic products [1]. This model ensures support of the concretization of the technical problem solving process starting from an open solution to the specific description of solutions of a product generation. In addition to this, specific information of reference products, as well as systems can be analyzed. The description of solution-open, customer-experience product attributes or customer requirements (CRs) is considered on the most abstract level of the Product Model. These properties are concretized via product functions of the technical subsystems that have the highest level of detail in terms of content. The subsystem level consists of the system elements hardware and software that ensure the realization of the product functions. [1,15,16].

Empirical surveys are used by many manufacturer for different purposes. One of the main purposes is to identify the customer requirements of existing products. Within the framework of empirical surveys, customer feedback from open and closed questionnaires can be determined and evaluated so that customer needs can be subsequently identified. Open questionnaires offer customers the opportunity to express their opinions creatively and freely (e.g., “The button for the digital clock should be near the radio”), while closed questionnaires result in well-defined customer feedback guided by predetermined answers (e.g., a rating scale from 1 to 10 or “bad”, “good” and “very good”) [18,19]. With the help of predetermined answers in closed questionnaires, it can be possible to evaluate the customer answers automatically [18]. This ensures the results are evaluated objectively, which can be executed with the help of statistical/quantitative as well as qualitative evaluation methods. The structure of the answers of these questionnaires can result in qualitative and quantitative way. In comparison to the results of closed questionnaires, the open questionnaires’ results can contain unstructured information, which can make the evaluation more complex and complicated. The customer responses cannot be statistically evaluated and, due to the detailed customer statements, the identification of relevant data may require appropriate methods [20].

The results of open questionnaires can be referred to as qualitative customer feedback (QFB). Here, it is important to emphasize that because of its imprecise nature, which is anonymous, the structure of the feedback is “qualitative”. This, because of its relevance to existing products is becoming increasingly important in industrial practice [21,22]. On the one hand, many manufacturers see this as a chance to receive detailed feedback. On the other hand, however, the evaluation of QFB requires the identification of product development relevant information, the consideration of the affective declarations of customers as well as the causes of problems, all of which is more complicated to evaluate objectively. After the evaluation of QFBs, customer requirements are determined and associated with technical data (e.g., technical subsystems hardware and software). Ideally, these data, based on customer requirements, are prioritized and integrated into the early phase of a product development process [23].

In various studies of PGE, different approaches are evident. One of the PGE study focuses on the handling of a large number of influencing factors, which can have an impact on customer satisfaction [24]. In the context of this study, the authors consider especially the identification of trends for the future. In addition, their focus lies on variations of customer experiencable product attributes, which are based on different scenarios [24]. In another study of PGE by Albers et al. [25], integrating customer benefits into the early stage of a product development process is handled. Through the usage of defined product profiles, the authors show the validation of customer, user and provider benefits. This helps to create an overview of the conflicts between customer and provider benefits [25]. Further study of PGE focus on supporting the interactions between customer benefits and technical subsystems. This study handles also the validation of customer benefits [1]. Analyzing the impact of variations in design engineering activities on technical subsystems is considered in the context of another study of PGE. This study presents the interactions between technical subsystems that helps to show the impact of relevant variations. With the help of this study, it is possible to create an overview of all relevant functions of specific technical subsystems and the associated variation types with the relevant reference products [26].

Regarding the statement that QFB can contain unstructured information, several approaches have been used to evaluate this type of customer feedback and link them with technical subsystems as well as with product attributes. Some of them focus on, for example, identifying causes of problems as well as affective declarations [27,28]. The Ishikawa diagram is used for analyzing the causes of the situation and supports the description of the problem more detailed [18,27]. The study of Schütte [28] focuses on enhancing Kansei Engineering method, in order to link the affective declarations of customers with technical product attributes. In the study of Rai [29], the author classifies verbs, nouns and, adjectives, etc. to map them to the technical subsystems, so that the relationship between customer needs and product properties can be identified. The authors Wang et al. [21] focus on the usage of word count by deep learning, in order to link online customer feedback with technical subsystems. The focus of this study lies especially on the frequency of related subsystems that are mentioned by customers [21]. The key words identification by defining the relevant key words and linking them to product features from online reviews are handled in another study by Park et al. [30], in order to support new product concept generation. Mapping affective declarations to product features by text mining and utilizing online reviews is handled by Wang et al. [31] Here the focus lies on the classifying the affective declarations of customers [31]. The authors Yagci et al. [32] present in their study a data collection, which is executed considering the most mentioned product attributes by customers from online websites. These attributes are mapped with customer opinions [32]. Additionally, quality function deployment (QFD) that provides the translation of customer needs into the technical requirements has been used and enhanced by several authors [33,34]. The approach of Schulte [33], in particular, is based on a semantic mapping of customer feedback on the product structure.

3. Materials and Methodology

Based on VDI 2221 [35], which helps to design products with optimum solutions according to the description of development and design task, V-Model [36] and the completed PGE Product Model by Albers [1], a method has been developed. The PGE Product Model of Albers et al. [1] was completed, in order to systematically integrate the QFBs from open questionnaires into the early phase of product development.

In this study, the Product Model of Albers et al. [1] is completed up to the next concrete subsystem level, design parameter (DP) for each hardware (H) and software (S). In addition, the evaluation of QFB, the structuring of the content of QFBs and determining customer requirements are integrated into an enhanced Product Model [23]. The completed Product Model has been named Product Model M (PMM) and is depicted in the following Figure 1.

In the context of the completed PMM, first, the evaluation of the QFB, the structuring of the QFB with Module Conception Factor for Logical System (MCF) and determining the CRs take place. Subsequently, the CRs resulting from the QFBs, are then assigned to product functions and to the technical subsystems DP of each H and S. The mentioned activities that are relevant for PMM are described below.

Based on VDI 2221 [35], V-Model [36] and the completed PGE product model by Albers et al. [1], the developed method is depicted in the following Figure 2.

According to Figure 2 above, the task clarification takes place first. For the task clarification, the product, the market and the specific topic, which is accepted as a MCF, are defined. An MCF helps to structure the QFB according to its contents. For this purpose, a topic differentiation takes place within the QFBs. Subsequently, it is ensured that product- and market-specific QFBs from the selected empirical survey are provided. The following step is the evaluation of the QFBs, which is necessary for the development of a new market-specific product generation. This evaluation is carried out with the help of defined categories that help to identify development information within the QFB [23].

To sum up, the evaluation of the QFBs, the differentiation of topics within the QFBs and the determination of requirements are relevant for the clarification of the task. These activities start in product planning and are comparable to the step of clarifying and specifying the task definition according to VDI 2221 [35]. An iterative procedure, if necessary, is provided within steps 1 to 4, as depicted in Figure 2.

The determined CRs are then processed within the left-hand side of the development methodology V-Model up to the DP level (steps 4 to 8). All this up to the DP level takes place according to the completed Product Model PGE by Albers et al. [1] and is modelled following an MBSE-approach.

The CRs, the technical subsystems H, S and the DPs resulting from the described steps above are then used in the framework of the customer satisfaction and product quality model with a focus on identifying the weighting factors of the DP (steps 9 to15). The description of this part of the method is presented in Aksoy et al. [23]. In this publication, the focus is on steps 1 to 8.

Next, the completed product model PGE will be described, in order to represent the relations between the customer and technical subsystems. Afterwards, the categories and MCF will be presented. Subsequently, the modelling part of the developed method will be described. For this modelling, the graphical modelling language System Modeling Language (SysML) is used, and the chosen SE software tool is Enterprise Architect.

3.1. Evaluation and Structuring of Customer Feedback and Customer Requirement Determination

QFBs based on a selected empirical study provided by a specific company, contain many themes that are investigated for many products. Customer satisfaction with the product is one of these themes and is the focus of the QFB evaluation in this work. As mentioned in Section 2, the feedback is based on closed and open questionnaires. An example of a closed question would be “Please evaluate navigation controls using the scale 1 to 10”, while open questionnaires give customers the possibility of evaluating the relevant product independently of concretely created questions. The following question is a typical example found in open questionnaires, “What do you particularly like or dislike about your Bluetooth connection?” and a possible answer would be, for example, “There are always delays when I try to connect my cell phone with my car”. QFBs are not always well defined by customers. There can also be superficial types of feedback, which are difficult to interpret. These kinds of QFBs are hard to transfer into the technical subsystems. The following feedback is an example of this kind of feedback “I find it now so easy to adjust the seats”. With this comment, it is difficult to derive concrete information about the main problem.

3.1.1. Evaluation of QFBs with the Help of Categories

QFBs from open questionnaires can be regarded as an amount of unstructured information, as described above. In order to facilitate access to the given information, it is necessary to categorize it. One of the major advantages of using categories is the differentiation and filtering of several kinds of product development relevant information [23]. The categories are defined according to different factors (for example, discussions with specialists in industrial practice or the consideration of existing approaches) and shown as follows in Figure 3, which maps the product development information of QFB examples, according to their relevance:

In category 1, information relevant to technical requirements such as geometrical issues or product safety can be determined (e.g., the storage capacity in the door panel of the vehicle). Category 2 helps to filter affective customer opinions (e.g., it’s nice, long, etc.). For this purpose, customer statements are classified by taking into account the perceptions of sight, hearing, touch, smell and taste [28]. The interpretation of the identification of functional customer preferences is done in such a way that the information based on the product functions can be identified by using category 3. In contrast to the emotional opinions of customers, the function-based statements are more objective. The application of category 4 ensures that the opinions expressed by customers can be reconciled, for example, with objects or with abstract product-related information. This category also provides support for identifying colloquial expressions. The analysis of the QFBs of various vehicles over different years in the selected empirical survey has shown that customers often express the reasons for their complaints. Category 5 supports the identification of the causes of product-related customer dissatisfaction. The analysis of the QFBs from the relevant empirical survey has shown that QFBs also include much information, such as a comparison with other products or with previous products. Category 6 determines this information [23].

3.1.2. Structuring QFBs with the Help of MCFs

To support the integration of the customer perspective into the product development process, QFBs can be structured according to their content. To this purpose, topics within the QFBs can be differentiated [23]. In order to systematically distribute the topics within QFBs, the MCFs are used, which result from the harmonization of modules and conceptual factors of Nehuis [37], from the overall vehicle modules, parameters of Prinz [38] and the fields of the selected empirical survey (for e.g., Navigation System, Storage Aspects, etc.). The elements of Prinz and Nehuis support the description that a vehicle is as neutral as possible. Finally, the harmonized elements are aligned with logical systems that are used in industrial practice.

Logical systems are used to define a solution concept that is relevant in industrial practice. The logical system architecture is applied to specify the system structure. The term “logical” is relevant for the logical interfaces, which are explicitly included in the system architecture. Such a solution concept includes technical subsystems in addition to the logical elements [39,40]. Some of the logical systems that are considered and applied in industrial practice are, for example, “communication system”, “energy system”, etc.

To harmonize these, first, the relationship between the elements of Prinz and Nehuis with empirical survey fields is identified. Second, considering this relationship, the relevant fields are aligned with logical systems. Subsequently, the MCFs are derived in the context of these logical systems. The following Figure 4 shows a small part the elements and the derived MCF in the context of logical systems:

The MCF may need to be updated, if new features are implemented within the product or if the fields of the relevant empirical survey are changed.

3.1.3. Determination of CRs

In the next step, the formulation of CRs is described. For this formulation, the determined information from the QFB evaluation is taken into account. Subsequently, it will be possible to derive product functions regarding PMM (Figure 2) from these CRs.

In order to formulate requirements, some tools can be useful. Toro et al. [41] developed a functional requirement template to support users. According to this, the question “what do you want the system to do with the stored information in order to achieve your business goals” is considered. In this template, the source, pre- and post-conditions, the importance, and the urgency of the requirement, etc., are all relevant in formulating and determining the requirements and describing the use-cases. Hooks [42] mentions in her research the importance of avoiding common problems by writing/formulating good requirements. She emphasizes that good requirements focus on necessity, verification as well as feasibility. Focusing on “what” instead of “how” is depicted as a common problem for Hooks when writing a requirement. At this point, to avoid a wrong implementation, the question “how?” should be asked. The usage of terms in a specific manner plays an important role for Hooks. She emphasizes that the term “shall” must be verifiable. In her study, other terms, such as “will” or “should”, do not belong in a requirement. As well as making requirements specific by avoiding unnecessary items, Hooks emphasizes the importance of verification in writing good requirements [42]. Rupp [43] also emphasizes linguistics. With the help of his template, the author seeks to avoid the necessity of a high analytical effort. Consequently, the goal is to generate perfect requirements [43]. The functionality of the requirement plays an essential role in this template, which is defined as the “process word” in his template. Rupp emphasizes that processes should be defined by verbs. Moreover, the process word must be determined at the very beginning of writing a requirement because the functional aspect depends on the process word. In contrast to Hooks, Rupp uses the terms “must, should or can” for formulating requirements in order to determine the importance of the requirements.

Regarding the role of the importance of requirements and the usage of terms by classifying requirements in design engineering literature [44], Rupp’s template was selected for this present work, which is also used in industrial practice. The following template in Figure 5 depicts the sentence template, which is published in the work of Pohl and Rupp [45]:

With the help of the sentence templates, it is possible to standardize CR formulations. This improves comprehensibility and minimizes the complexity of the formulation [45].

In order to make the usage of sentence templates more comprehensible, the product development relevant information in the following two QFBs of MCF “Communication System” are categorized. Subsequently, the CR will be determined:

• QFB 1: “The clock is not visible (3) unless the radio is on (4, 5). My previous car Y (6) had not such a problem like this.”
• QFB 2: “Most of the time (2) I have to turn off the radio (4) so that it can show the clock (3) on the display.”

The information that is marked and numbered shows the evaluation of these two QFBs using the categories from Figure 3 above. According to this evaluation, the following CR is determined with the help of the sentence template from Figure 5:

Determined CR: The visibility of the clock should be ensured for the customers, while other infotainment elements, such as radio run.

3.2. Interactions between Customer Feedback and Technical Subsystems in the Context of MBSE

In this section, the completed PMM will be modelled in the context of MBSE in order to show the interactions between QFB and the technical subsystems. The focus of MBSE lies on an interdisciplinary, descriptive system model, which captures the interrelationships and basic ideas of SE [2]. The graphical modelling language SysML, which has been developed for this purpose, can be considered and used for representation. The SysML is a further development of the unified modelling language (UML), whereby the representation of the four key aspects of a system can take place (structure, behaviour, requirements, and parameters). These views of the system support representation of the subsystems, their elements and interconnections [46].

For the modelling of PMM, the SE tool Enterprise Architect (EA) was selected, which is also applied in industrial practice. The modelling of PMM is built on the UML and SysML. The following Figure 6 depicts the completed PMM that shows the relation between QFBs up to the technical subsystem DP.

In order to achieve this target, first the QFBs (QFB₁, QFB₂,…, QFB_f) are mapped into MCFs (MCF₁, MCF₂,…,MCF_x) and sub-MCFs (Sub-MCF₁, Sub-MCF₂,…,Sub-MCF_y) considering the fields of selected empirical survey for structuring the QFBs. Afterwards, the QFBs are evaluated with the help of defined categories (Categories C₁, C₂,…) (Figure 3). Consequently, the CRs (CR₁, CR₂,…,CR_m) are determined according to the categorized information in the QFBs and then split into product functions according to their relevance. Subsequently, the product functions are mapped with technical subsystems Hs (H₁, H₂, …, H_z) and Ss (S₁, S₂, …, S_n), which are finally mapped into the subsystems (DP₁, DP₂,…,DP_p) of S and (DP₁, DP₂,…, DP_q) of H [23].

3.2.1. Generating a Profile for an Object Model

To integrate the QFBs into the product development and to evaluate and structure the QFBs, the definition of a profile is necessary. This profile, which includes different types of specific profiles, such as Stereotype Profile and Toolbox Profile, is created for the modeling of the PMM in the EA tool as a separate model driven generator (MDG) technology. The MDG technology allows users the option of a granular import of the created stereotype profiles and toolbox profiles that will be applied in the Object Model.

The creation of the desired profile in the context of a meta model is done in the EA tool with the purpose of generating which additional stereotypes are relevant for the modelling of the present approach. The new stereotypes and the elements that have already been provided by SysML, are used in the object model. The following

Table 1. Elements of the object model for modelling of PMM.

Object Model System Elements	Type of Element	Stereotype
QFBs	Own element	QFB
Categories	Own element	Category
MCF-logical systems	Own element	MCF-logical system
CRs	Available element of SysML	Block
Product Functions	Available element of SysML	Block
Logical systems	Available element of SysML	Block
Physical elements (H, S, DP)	Available element of SysML	Block

shows the relevant elements of the object model, which are necessary for the modelling of PMM (Table 1).

As a result, a specific profile is first defined, which contains the elements “«QFB»“, “«Category»“ and “«MCF logical systems»“. The Stereotype Profile offers the definition of required stereotypes, while the Toolbox Profile allows the stereotypes to be customized. With the help of the individual Toolbox Profile, which will be applied in the object model, quick access to the profile elements or stereotypes is provided.

Next, the attributes of the newly defined stereotypes (“«QFB»“, “«Category»“ and “«MCF logical systems»“) of the profile are entered. The stereotype profile, the associated attributes as well as the toolbox profile of the individual diagram are shown in the following Figure 7.

The background of the additional input of the physical elements Hs and Ss as well as the categories into the attributes is that this information is considered in the object model during the evaluation of the QFBs. As a result, the stereotype category is described by the attributes Art, while the stereotype MCF logical system is defined with the attributes Art and sub-MCF. The information char in the stereotypes represents their data types.

3.2.2. Generating PMM Specific MDG Technology

For the creation of the PMM-specific MDG technology, the Stereotype Profile and the Toolbox Profile are first generated. The next step is to create the MDG technology (generated MDG technology). For this purpose, Publish Generate MDG technology is selected in the EA tool. Subsequently, the Stereotype Profile and Toolbox Profile are used to complete the creation of the PMM-specific MDG technology.

3.2.3. Modelling the Object Model: Interactions between QFB and Technical Subsystems

Next, the creation of a new project is required so that the MDG technology specific to the PMM can be loaded into the model or EA tool. After creating a new project in the EA tool, the object model can be created. This is called PMM specific MDG technology. Now the MDG technology created for the PMM has been loaded into the model and can be used for modelling the object model. To be able to use the loaded MDG technology, a Package and an associated Diagrams must be created.

Integration of QFB into the EA Tool

In order to minimize the number of repeated iterations in the clarification and specification of the task (VDI 2221 [35]), the QFBs should be provided for the product developers on time, according to the relevant task. However, the availability of the data depends on when the empirical study is published.

The traceability of QFBs and the integration of them into the modelling tool is done by the product developers. The feedback data is then prepared to evaluate the selected product generation, considering the past and current product generation.

To use the QFBs in the object model, which belong to a specific product, market and year (information resulting from the task), they must first be imported into the object model. The relevant QFBs of the empirical survey are initially available as an excel file. To enable the use of this excel file in the object model, an excel template has to be prepared, which has to be created directly in the EA tool and exported for later applications. Only after this export can this specific template be used for the QFB data from the empirical studies so that the QFBs can subsequently be imported into the EA tool. The prepared excel template in this present publication has been named “Application”.

To integrate the QFBs via the excel template Application, the relevant QFBs of the empirical survey are first provided, and the following steps are required:

• The relevant MCF logical system known from the task (Figure 2) (e.g., communication system) is entered into the prepared excel template. For this purpose, the TagValue_MCF logical_system column that is provided in the excel template is used (Activity outside of the EA tool).
• This is followed by the entry of the sub-empirical study field equivalent to the selected MCF logical system (see Section 3.1, the relationship between empirical survey fields and MCF). For this purpose, the excel file of the empirical survey is edited and subsequently, the relevant data from this file are entered into the excel template (Activity outside of the EA tool).

The processing of the excel file of the empirical survey is as follows:

• The QFBs of the study field according to the MCF logical system are prioritized directly in the excel file of the empirical survey considering the number of the QFBs. Then the QFBs belonging to a particular sub-field of the relevant empirical survey field are prioritized (e.g., sub-field: Clock Broken/Controls, field: Feature/Control/Display of the empirical survey).
• The relevant sub-field of the empirical survey is equivalent to an MCF logical subsystem (e.g., the MCF logical subsystem Occupant Interaction System of the MCF logical system Communication System). At this point, the additional input TagValue_Sub_UF and the input of the relevant MCF logical subsystem under TagValue_MCF_logical_Subsystem are done in the excel template Application (Activity outside of the EA tool).
• Now, the prioritized QFBs and their identities from the excel file of the empirical study are entered into the excel template Application. The QFBs are entered into this template under Notes and the identities of QFBs are entered under Name (Activity outside of the EA tool).
• Importing the QFBs into the EA-Tool: For this, the import of the prepared template Application can be performed with the entered data from the empirical survey. Subsequently, the name of the prepared excel template Application is selected in the EA tool under Specification. Afterwards, under File, the selection of the prepared template Application with the relevant QFBs (e.g., data for VW Jetta, USA, 2019), which has already been saved in the desired location, takes place. Finally, Import is selected so that the relevant QFB data can be made available in the Project Browser under the Package diagram (Activity in the EA tool). The integration of the excel template Application (a) (in Figure 8 “Anwendungsbeispiel”) and the QFBs (b) into the EA tool is depicted in the following Figure 8.

Now the relevant QFBs are available. For the evaluation of QFBs with the help of categories, a matrix relationship between the QFBs and the categories is created. Before that, all six categories are added to the processing surface. For this, a separate package has to be created.

Determination of CR

The determination of the CRs is done using the determined product development relevant information, which is located within the respective QFBs under the PMM next to the relevant categories and depicted in the following Figure 9 marked with a yellow tile:

To use the identified information, each QFB must be accessed. For the determination of the CRs, the requirement formulation is accessed, which was explained in Section 3.1. To represent the CR in the model, another matrix relationship between the QFBs and the CRs is created. For this purpose, a new package is first created for the CRs, in which the stereotype Requirement is entered as an element in the editing area. Since the number of CRs is not known at the beginning, several Requirement elements are assigned to the surface. Then, depending on the number of CRs, the elements that are not required can be deleted. With this second matrix, it is possible to identify the number of QFBs that are relevant for the determined CRs.

Interactions with Product Functions, Logical Systems and Technical Subsystems

The CRs derived from QFBs can still be non-specific. As a result, they cannot be directly translated into solution-determining product parameters. As Feldhusen et al. [47] have pointed out, the CRs can be further specified, and this specification can be supported by the definition of product functions. At this point, the identified CRs are used to derive the product functions, which are added to the model as block elements.

The logical systems explained in Section 2, are first linked to the product functions and for this, the block element is used. It should be emphasized here that the logical systems are identical to the MCF, but the terms and uses are different.

Subsequently, the logical systems are linked to the physical elements Hs and Ss and their DPs, which are modelled as block elements.

Relationships between the Stereotypes

Next, the explanations for determining the relationships between the model elements are described:

• The relationship between both matrices (the matrix for the relationship between QFBs and categories and the matrix for the relationship between QFBs and CRs) are represented with satisfy.
• The determination of the CRs requires the application of the relation Derived Requirements between the CRs and the second matrix.
• Satisfying the CRs requires the application of product functions, which requires the relation Satisfy between the CRs and the product functions.
• The relation type between the product functions and the logical systems requires Block Relationships. The corresponding relationship type for this mapping is Allocate.
• The relationship type Allocate is then used for the allocation of logical systems to the technical subsystems Hs and Ss, which are also created as blocks in the object model.
• Further assignments of the subsystems Hs and Ss to the associated DPs are also made as Allocate.

4. Case Study

According to a current situation in industrial practice, there is a need for the optimization of an MCF Communication System in the vehicle Jetta USA, where there was customer dissatisfaction with the technical subsystem “digital clock”. The digital clock is considered under the sub-MCF Occupant Interaction System. This dissatisfaction was identified with the help of discussions in industrial practice as well as by analyzing the QFBs of a selected empirical survey of the product generation G_n−1, which was executed unsystematically. In order to achieve customer satisfaction with the digital clock in the next product generation, G_n+1 of Jetta, it was first necessary to analyze the past product generation, G_n−1 of Jetta. Moreover, it was required to analyze the current generation of Jetta USA G_n so that the results of both generations G_n−1 and G_n could be compared. Through this comparison should identify whether the digital clock still needs to be optimized and how the customer requirements can be extracted into the new product development process. For this application, the QFBs were taken from the mentioned specific empirical survey. The QFBs of Jetta G_n−1 were taken from 2018, while the QFBs of G_n were taken from 2019/2020. It is important to mention that the possibility of contacting customers again was not possible as the feedback from the empirical survey was anonymous.

This case was used to validate the presented method in Section 3. Through the application of the methodical approach, the QFBs were evaluated and it was possible to check whether the identified DPs of the relevant MCF Communication System were relevant for the past G_n−1 and the current product generation G_n of Jetta USA. In the case of identical DPs appearing in both generations, where the DPs of the past and current product generation are compared, they would have to be considered and optimized in the development of the next product generation G_n+1. On the other hand, the validation also made it possible to identify the DPs that had already been optimized in the context of the current generation.

For the execution of the mentioned case above, the procedure of validation is depicted in the following Figure 10, which is based on the steps of the methodology in Section 3:

The realization of the steps A to D were performed and modelled separately for both past and current product generations. For the impulse of the validation (step A, Figure 10), which was performed as part of the methodical approach in Figure 2 above, the task had to be first clarified. In the task definition, it was determined that the MCF Communication System (topic 1) for Jetta USA had to be analyzed and optimized for the next product generation if necessary. At this point, a comparison was first made between the past and current Jetta. The QFBs of the past generation G_n−1 and the current generation G_n of the Jetta resulted from the years 2018 and 2019/2020 and were determined from the selected empirical survey. For the topic Communication System, the equivalent field from the empirical survey was determined, which was named Feature/Control/Display. In the next step, the following prioritization was performed in which the sub-field Clock Broken/Controls from the selected empirical survey was selected, considering the number of QFBs within the field Feature/Control/Display.

The integration of the excel files of the relevant MCF was performed first, as explained in Section 3.2.3. This activity was relevant to realize B from Figure 10.

First, the evaluation of the QFBs that is presented in Section 3.2.3 was illustrated using the object model (step C in Figure 10 above). After the evaluation, the determination of the CRs was illustrated, which were then assigned to the other system elements within the object model (step D in Figure 10 above).

In order to compare the relevant DPs of the two generations G_n−1 and G_n of the relevant MCF, steps D, E and F from Figure 10 had to be realized. This was done to check whether the DP of the two generations were identical and whether the DP of the G_n−1 generation had already been adjusted in the G_n generation of the Jetta. For this, there was a need to identify the important weights of the identified DPs of both generations G_n−1 and G_n (step D, Figure 10). This was done by using the mathematical Customer Satisfaction Model in [20]. Subsequently, in step G, the determined CRs and DPs of generation G_n of the Jetta could be considered for the next product generation G_n+1. This meant that the resulting CRs and DPs from the G_n generation were taken into account in the development of the G_n+1 generation.

The focus in this publication is on the realization and modelling of steps A to D, which is described in Section 3.2. These steps were modelled for both generations G_n−1 and G_n, where at the end two object models of PMM (object model Jetta G_n−1 and object model Jetta G_n) were generated. The following steps were applied for both object models.

4.1. Integration of QFB into Enterprise Architect and Evaluation of QFB

Performing Steps A and B from Figure 10 for the Jetta G_n−1 and G_n

Regarding the application of the descriptions in Section 3.2.3, the QFBs of Jetta 2018 and 2019/2020 were integrated into the EA tool. Following the relevant task in industrial practice, the topic Communication System as MCF for the Jetta was first analyzed. The aim was to check whether identical DPs appeared in the two generations. For this, first, the QFBs of the Jetta of G_n−1 (from 2018) and G_n (from 2019/2020) were integrated into the EA tool, as explained in Section 3.2.3. It is important to emphasize that the processing of step A was done separately for both generations in the EA tool, as also illustrated in Figure 10.

In the following, the steps for integrating the QFBs of the two product generations are explained in detail:

• The sub-field of selected empirical survey equivalent to MCF Communication System was defined as Feature/Control/Display (Activity outside of the EA tool).
• The QFBs within this sub-field of the empirical survey were prioritized (Activity outside of the EA tool).
• It was determined that the sub-field of empirical survey Clock Broken/Controls for both generations G_n−1 and G_n contained higher QFBs in comparison to the other sub-fields. This supported the decision to select this sub-field for the QFB evaluation for MCF Communication System. The equivalent sub-MCF for sub-field Clock Broken/Controls was Occupant Interaction System (Activity outside of the EA tool).
• By filtering the QFBs according to Clock Broken/Controls, the excel files of the two product generations were prepared for integration into the EA tool under the entries of the MCF Communication System and the sub-MCF Occupant Interaction System in the corresponding column of the already prepared excel template Application (Activity outside of the EA tool). The preparation of the template Application was explained in Section 3.2.3 above.
• Both excel files of the QFBs from 2018 and 2019/2020 were saved under the names “Jetta 2018 Clock” (G_n−1) and “Jetta 2019 Clock” (G_n) for the import activity (Activity outside of the EA tool) and afterwards integrated into the EA tool. For the integration, separate packages were created for the two generations, as explained in Section 3.2.3 (G_n−1 under package “Jetta G_n−1 QFB Clock”; G_n under package “Jetta G_n QFB Clock”) within the EA tool.

Before the QFB statistics of Communication System are presented, the following statistics regarding general information of both product generations G_n−1 and G_n are depicted in Figure 11. The equivalence of these MCFs with the fields of the empirical survey are identified. In addition, these MCFs are equivalent to logical systems in the industrial practice:

Regarding the QFB numbers above in Figure 11, there are some statements that should be described. On one hand, some QFBs of Jetta G_n−1 contain superficial opinions of customers, which can not be classified to an MCF as well as to the fields of the empirical survey. On the other hand, one QFB can be relevant for more than one MCF. Also one MCF can be relevant for more than one field of empirical survey.

The following information is a summary of the number of QFBs of the past and current generation of Jetta:

• G_n−1—Jetta 2018:
  • Total number of QFBs: 336;
  • Number of QFBs of the MCF Communication System: 61 (equivalent to the empirical survey field Feature/Control/Display);
  • Number of QFBs of the sub-MCF Occupant Interaction System: 9 (equivalent to the sub-field Clock Broken/Controls of the empirical survey).
• G_n—Jetta 2019/2020:
  • Total number of QFBs: 468;
  • Number of QFBs of the MCF Communication System: 74 (equivalent to the empirical survey field Feature/Control/Display);
  • Number of QFBs of the sub-MCF Occupant Interaction System: 7 (equivalent to the sub-field Clock Broken/Controls of the empirical survey).

To perform the evaluation of the Jetta G_n−1 and G_n generation QFBs, an additional package was created in which the relevant categories were added to the diagram of this package using the Category stereotype. This step was necessary to create the relationship matrices between the QFB and Category stereotypes.

In the next step, the packages “Jetta G_n−1 QFB Clock” and “Categories” as well as “Categories” and “Jetta G_n QFB Clock” were used for the matrix relationships between the stereotype QFBs and the categories. First, the nine QFBs from 2018 and the seven QFBs from 2019/2020 were evaluated after filtering the 336 QFBs from 2018 and 468 QFBs from 2021/2020 by using the application of the defined categories. These categories were found under PMM in the attributes of the stereotype QFB. An example of this evaluation and the identified information of the relevant QFBs of the two generations are shown in Figure 12 below. As can be seen, for G_n−1, each QFB of the relevant product generation could be evaluated with the help of the categories that could be found in the object model of G_n−1. The categories helped to identify the equivalent information within the QFBs and this information could be typed into the attributes of the relevant categories.

The identified information from the relevant QFBs was additionally numbered, shown in the attribute of the relevant category next to the identified information (Figure 12, category and the identified information with the number). These numbers were equivalent to the sequence of the sentences within a QFB (for example, the first sentence of a QFB was numbered with “1”, the second sentence was numbered with “2” etc.). With the help of these given numbers, it was possible to differentiate the identified information of a QFB, especially if the QFB contained more than one sentence. This helped later in the formulation of CRs.

4.2. Determination of Customer Requirements

Performing Step C from Figure 10 for the Jetta G_n−1 and G_n

The next step showed the determination of the CRs of Occupant Interaction System for “digital clock”, which was done in the context of the identified information with the help of categories. These CRs were described using the requirements template from Figure 5 as follows:

• Derived CR for the object model Jetta G_n−1
  • CR₁: The setting of the clock should be prepared for the customers intuitively and without the need for resetting while other infotainment elements (such as the radio) are running. It should also take into account other products, such as the GTI 2015;
  • CR₂: The location of the clock should be presented intuitively.
• Derived CR for the object model Jetta G_n:
  • CR₁: The visibility of the clock should be ensured while the other infotainment elements, such as the radio, are running;
  • CR₂: The position of the clock should be intuitively displayed (identical CR as G_n−1, see above);
  • CR₃: The timelines and numbers should be displayed better/clearer.
  • CR₄: The position of the clock should not change while other infotainment elements, like the radio, are running.

Next, the steps regarding two matrix representations of the relationship between QFBs and the determined CRs of the Occupant Interaction System of both product generations G_n−1 and G_n of Jetta will be described. For this purpose, the following matrix representations of the two generations were created as explained in Section 3.2.3. In order to do this, further packages “Jetta G_n−1 CR Clock” and “Jetta G_n CR Clock” for both object models were created, to whose diagrams the determined CRs were added. After this step, the relationship matrices between the QFBs and the determined CRs were created. From this matrix relationship, the number of relevant QFBs of the respective CRs was also determined. The matrix relationships between the QFBs and the CRs of both object models G_n−1 and G_n are shown in Figure 13 below.

4.3. Interactions with Product Functions and Technical Subsystems

Performing Step D from Figure 10 for the Jetta G_n−1 and G_n

In the previous steps of Figure 10, first, the evaluation of the QFBs under the usage of the defined stereotypes Category and MCF and the determination of the CRs under the usage of stereotype Requirement were modelled. The QFBs were linked with the stereotype Category for the identification of product development relevant information for both generations G_n−1 and G_n, which was modelled in the context of the matrix presentation. Using the identified information, the CRs were determined, which were then mapped to the QFBs with the help of the matrix representation as well.

According to the required step D of Figure 10, the determined CRs for the Jetta G_n−1 and G_n were linked to the required product functions, which were then represented as a Block element of SysML. A further linkage was made between the product functions and the logical systems. For this purpose, the Block element was also selected for modelling the relationship between product functions and the logical systems. Subsequently, the relevant logical systems were linked to the required technical subsystems where also the Block elements were applied. The following Figure 14 and Figure 15 show the object models of Jetta G_n−1 and G_n.

For the creation of both object models, the required packages “Jetta G_n−1 Clock Object Model” for the Jetta G_n−1 and “Jetta G_n Clock Object Model” for the Jetta G_n were created. The already created matrix relations and the determined CRs of both generations of the corresponding package diagrams were directly added to the diagrams of the newly created object model packages. As a result, the multiplicity indicators between the system elements were entered. The block elements that were generated for the past generation of the Jetta G_n−1, such as product functions, were taken directly from the project browser in the object model for the current generation of the Jetta G_n.

As depicted in Figure 15, some system elements of the object model G_n−1 were used (e.g., product functions, DP₃ clock position, etc.) by modelling the object model of G_n. Accordingly, it could be ascertained that the system elements of a certain product could be used for the next product generation as well as for other products. Thus, the interrelationships of the system elements of different products could be established.

From the results presented above, it was evident that the DPs, except for the parameter DP₃, of generation G_n−1 did not reappear in generation G_n. At this point, it was determined that the DPs of generation G_n−1 had already been adjusted during the development of generation G_n. As a result, the identified DPs of the Jetta G_n (DP₄, DP₅ and DP₆) and the DP₃ could be considered in the development of the next generation product of the Jetta G_n+1. Subsequently, the mentioned DPs of the generation G_n of the logical system Occupant Interaction System could be considered in the development of the generation G_n+1 of the Jetta along with the other CRs and physical elements.

The experts in the industrial practice evaluated the Communication System QFBs without a given procedure for both product generations G_n−1 and G_n of Jetta. The derived findings of experts for the technical subsystem digital clock are compared with the determined results of the developed method. The comparison between experts and methods results have shown that they are similar, where their findings obtained with higher effort in time as well as in resources. Especially the evaluation of QFBs without a specific procedure caused higher effort. The possibility of the integration of QFBs into the software tool Enterprise Architect, the usage of categories as well as the MCFs for the classification of QFB content have been accepted by developers as an advantage. This confirms the usefulness and supports the feasibility of the method.

In this study, as mentioned in the description of the case study, there was a need for the optimization of the sub-MCF Occupant Interaction System because of the customer dissatisfaction with the technical subsystem digital clock of Jetta G_n−1. Regarding this situation, the relevant QFBs are evaluated and the CRs as well as the technical subsystems of the sub-MCF Occupant Interaction System are identified. Further evaluation of QFBs, s. in Figure 12, of other sub-MCF Communication System as well as the QFBs of other MCFs are not executed. Subsequently, the determination of other relevant CRs and the identification of relevant technical subsystems are not considered.

5. Discussion of the Results

One of the major challenges in evaluating imprecise customer feedback lies in the identification of different types of product development relevant information and the objective execution of the evaluation itself [23]. This process ensures that the determination of the CRs is as complete as possible. For this purpose, categories are defined, which ensure that different types of information are concentrated on. Also, a sentence template is used, in order to derive CRs by using the categorized information. The approaches by Schütte [28] as well as by Wang et al. [31] can support to identify the affective declaration “little” from the depicted QFB in Figure 12 above, as well as other affective declarations in other QFBs. These approaches map the determined information directly with technical subsystem “digital clock”. The information “little” can also be identified with the help of the Ishikawa diagram by analyzing the cause of the main problem [27]. The approach by Rai [29] enables the classification of all relevant verbs, adjectives and nouns of this QFB, such as “little, button, on, dashboard, etc.”, which also provides to link the determined information with “digital clock”. Further approaches [21,30,32] ensure mapping the information within the mentioned QFB in Figure 12 above as well as within the other QFBs of the selected empirical survey. All these mentioned approaches enable also the evaluation of anonymous customer feedback from external resources. However, these approaches do not support the specific determination of CRs. With the help of the developed method, it is possible to not only identify different or specific types of information, but also to determine the CRs. For example, the specific information, such as “GTI 2015” within CR₁ of Jetta G_n−1, could be considered through the usage of the category “Comparison to competitors/comparison with previous product” and this CR₁ could be therefore defined completely. Moreover, the developed method supports developers by focusing on one specific category such as, “comparison to competitor” and the related information of a specific vehicle. The discussion with experts in industrial practice showed that this possibility can support them, especially during benchmarking of competitors in the early phase of development. In addition, the use of categories can support the sifting of relevant information from the colloquial language of customers.

Furthermore, the mentioned approaches above do not focus on function-oriented development. In fact, the consideration and the determination of CRs plays an essential role by function-oriented development. According to system architecture that is mentioned in Section 2, requirements have to be determined, which then can be linked with other system elements. The PGE approaches [1,24,25,26] support function-oriented development and enable the correlation between CRs and other system elements. Though, the evaluation of QFBs as well as the integration of QFB from external resources into the early phase of product development are not considered and handled by any PGE approach. The approaches by Schulte and Urban [33,34] ensure the correlation between CRs and technical subsystems as well. However, for large amounts of customer data, which can have an impact on the analysis of complex technical subsystems, these studies could be complex to use [33,34]. These approaches do also not support the function-orientation in the development of complex products. Also, the evaluation of imprecise QFB and the determination of CRs are not provided by these studies [33,34]. On the other hand, the present method ensures the linking of related CRs of both product generations G_n−1 and G_n with other system elements, which is modelled in the context of MBSE (see Figure 14 and Figure 15). At this point, traceability and dependencies between requirements and system elements are enabled. Additionally, with the completed Product Model of PGE the integration of QFBs evaluation and their mapping with system elements are provided systematically. The completed PGE Product Model supports the identification of design parameters of technical subsystems, H and S. Moreover, this ensures the fulfilment of the CRs as effectively as possible. To this purpose, specific information of reference products, such as CRs, could be analyzed with the help of this model of PGE, in order to concretize the solution open process, which is also mentioned in Section 2 [1,15,16]. Through the usage of this completed model it was possible to concretize the determined CRs via product functions of the technical subsystems DPs that have a very high level detail in terms of content. These subsystems ensured the realization of the product functions.

To structure QFBs according to their content, the MCF is used. Structuring of QFB is not handled by any approaches that are described in Section 2. With the help of the MCFs, the required theme “Occupant Interaction System” for “digital clock” could be identified and the related QFBs of Jetta G_n−1 and G_n could be classified for the evaluation. Feedback from industrial practice revealed that this transfer should be done within an identical segment class.

However, the developed method does not ensure machine support by evaluating QFBs, such other approaches [21,28,30,31,32]. This is still necessary, in order to minimize the time cost of evaluation and to support the evaluation more objectively. Furthermore, the present method has to be trained by developers, so that a homogeneous evaluation perspective can be provided. The factors, such as intercultural differences of developers as well as different education backgrounds can prevent a homogeneous evaluation perspective. Therefore these factors have to be considered in the training. Also, the usage of MCF can cause complications at some points. Regarding the identical descriptions of MCFs with logical systems of system architecture, developers can be confused by using these MCFs. The purpose of the usage of MCFs must be clear, in order to avoid the possible confusion. In addition, the specific template preparation for MCF, which is required before the integration of QFBs into the EA tool, can require a significant investment of time, if the developers are new in the development. In this context, the developers have to be trained not only in using the software tool but also in preparing the template. Consequently, if the fields of selected empirical survey change or the considered logical systems belonging to the system architecture are supplemented, the MCFs need to be adapted as well by developers. This can also require an investment of time. The software tool EA offers advantages because of the developer’s experience in industrial practice. However, in case other MBSE tools are applied in industrial practice, the profile specifically defined for this EA tool, the procedure for integrating customer feedback data, as well as the processing of this data that was described in Section 3.2.2 and Section 3.2.3, would have to be adapted to the new software tool. It would be desirable to execute and to adapt all relevant steps of the developed method for the relevant tool (Figure 2), which would require a common understanding and an investment of time.

6. Conclusions

This work deals with a methodological approach that establishes the correlation between imprecise customer feedback and the design parameters of a technical system based on MBSE and PGE. Essential elements of the approach are the evaluation of empirical studies resulting from QFBs, the determination of CRs from the evaluated customer feedback, the derivation of product functions from these CRs, which are subsequently assigned to technical subsystems, in order to consider these for the development of next product generation [23].

Section 3 describes the developed method, which was evolved after considering the relevant basics from existing literature and research. In this context, a specific focus was the Product Model of PGE by Albers et al. [1]. Regarding the structure of this Product Model, new levels for customer feedback evaluation and further levels of technical subsystems were enhanced. For the evaluation of customer feedback, categories were defined. Moreover, the sentence template was used for the systematic determination of CRs. Furthermore, a MCF was defined in order to structure the QFBs according to their content. To integrate the QFBs and to generate the interactions between customer feedback and technical subsystems, the MBSE was presented and a specific profile for an object model was generated. Based on the generated object model, the validation was presented in Section 4 with the help of a case study. Through the application of the validation, it was possible to check whether the determined DPs were relevant for the past and the current product generation. At the end of this section, the developed method’s usefulness and feasibility were confirmed.

In the future work, further QFBs of other relevant MCFs could be evaluated so that the interaction between all relevant system elements can be identified, which could have an impact on the segmentation of the CRs when considering them for the next product generation G_n+1 of Jetta. In order to segment the results of both generations and to implement these results into the next product generation G_n+1 of Jetta, the final decision depends on the identified DPs from all relevant QFBs. Additionally, the application of the categories could be performed in the future, e.g., by machine support. For this purpose, the analyzed approaches (e.g., [30]) can be considered. At this point, the evaluation would need to be performed in the context of SE, so that function orientation in product development can be further supported. Moreover, these categories could be extended, depending on emerging technologies and trends in the automotive industry. Also, it would be conceivable to make the process “integration of excel template into the software tool Enterprise Architect”, described in Section 3.2, part of the MBSE, instead of it being document-based. Furthermore, it would be necessary to model the dependencies between CRs and technical subsystems based on product functions. Therefore, using appropriate processes and methods could be necessary to support the validation of these dependencies from the users point of view. Consequently, because of its function-oriented characteristic, the developed method can not only be used in the automotive industry but also in other industries (e.g., by developing kitchen equipment). However, PGE can be complex to understand and the implementation of the method can be expensive for smaller companies, especially regarding integrating the MBSE. In this context, using this method can be less suitable for the products that have shorter product life cycle management. Additionally, the evaluation of QFBs based on other surveys or online websites, which are for example updated constantly, can not be possible to execute. The prepared excel template for the integration of QFB is only usable for the selected empirical in the industrial practice.