Transforming Multidisciplinary Customer Requirements to Product Design Specifications

Abstract

With the increasing of complexity of complex mechatronic products, it is necessary to involve multidisciplinary design teams, thus, the traditional customer requirements modeling for a single discipline team becomes difficult to be applied in a multidisciplinary team and project since team members with various disciplinary backgrounds may have different interpretations of the customers’ requirements. A new synthesized multidisciplinary customer requirements modeling method is provided for obtaining and describing the common understanding of customer requirements (CRs) and more importantly transferring them into a detailed and accurate product design specifications (PDS) to interact with different team members effectively. A case study of designing a high speed train verifies the rationality and feasibility of the proposed multidisciplinary requirement modeling method for complex mechatronic product development. This proposed research offersthe instruction to realize the customer-driven personalized customization of complex mechatronic product.

1 Introduction

With the mass customization of product design and development, the individuality and diversity of customer requirements for a complex mechatronic product is ever increasing, the manufacturer enterprises are facing tremendous pressures and challenges to deal with the diverse and rapid changing customer and market requirements. Under the new trend of crowdsourcing-based product design and development [1], the traditional “product-centric” design method for complex mechatronic products has been unable to adapt to the growing market competition, therefore, the enterprises should shift the design focus to the ”customer-centric” design methods for complex mechatronic products. Customer requirement modeling thus becomes a highly significant part of a product development process and it also has been a research topic for years and used in the field of system and software development [2].

The ultimate purpose of traditional customer requirements modeling is that realizes the mapping of CRs in the customer domain to PDS (a formalized specification of customers’ requirements and a list of the product performance, environment, quality, reliability, security, life cycle and other elements with considering performance and cost constraints, design inputs, constraints and goals, and so on [3]) in the designer domain to improve the development efficiency and reduce the development cost. Through many years of research and application, the process of traditional customer requirements modeling, encompassing requirement elicitation, requirement analysis and requirement verification, has been formed into a standardization process from a system and software engineering point of view [4]. The requirement elicitation is to extract and make an inventory of the customer requirements with several methods including interviews, market analysis, feasibility studies, etc. During the phase of requirements analysis, the unclear, vague and initial CRs are interpreted and translated into a complete specification of design requirements that is suitable and understood for the designers. The requirements verification is to validate the CRs are fulfilled or not fulfilled with the virtual or physical tests.

Over the last two decades, an increasing number of methods and tools have been used in the field of customer requirement modeling along with many endeavors in industrial applications. With the increasing complexity of a multidisciplinary development process for complex mechatronic products, there is a major shortcoming of those studies mainly concentrating on comprehensive analysis and mapping in a single discipline or ignoring the multidisciplinary characteristics of complex mechatronic products. However, the designers from different disciplinary teams have different understandings and views of the same customer requirement and employ different sets of context and discipline-specific languages to express the CRs based on their own knowledge and disciplinary background. Those differences in understanding, semantics and terminology will impair the ability to convey requirement information effectively from customers to designers and obstruct the communication between different disciplines, resulting in a PDS with incompleteness, ambiguity, or inconsistency. It can lead to problems during the design process and require unnecessary design iterations which results in increased design time and cost. Therefore, how to quickly and effectively transfer the subjective and fuzzy CRs into a more complete, effective and less coupling PDS as an input to a conceptual design is crucially challenging in the requirement analysis stage of complex mechatronic products.

In order to solve the above problem, this paper provides a new synthesized multidisciplinary customer requirements modeling method on the basis of traditional requirements modeling. Its features include the following:

• 1. Firstly, it distributes the collected fuzzy and incomplete CRs into a multidisciplinary design team after requirement elicitation for generating discipline-specific PDSs. In each disciplinary design team, the designers use their own knowledge, experience and terminology to realize the mapping of CRs to discipline-specific design specifications with the method of QFD.

• 2. Secondly, according to the expert knowledge, a disciplinary specialty language dictionary is established for transforming disciplinary design specifications with different semantics and terminology from different disciplines into a general and standard PDS with semantics which can clearly describe relevance and eliminate ambiguity between each disciplinary design specifications.

• 3. Thirdly, it combines and integrates all disciplinary design specifications to form a complete, efficiency and less coupling PDS as a collaborative working lookup table and as a concept design input to reduce the iterations of product design and improve the efficiency of a whole complex mechatronic products development.

• 4. Finally, it fully takes into account the multidisciplinary differences and coupling of customer requirements for a complex mechatronic product to obtain an effective and reasonable complete PDS. It can reduce the difficulty and complexity and improve the efficiency and accuracy of requirement analysis of complex mechatronic products.

The remaining of this paper is structured as follows. After reviewing the related work, the proposed multidisciplinary customer requirements modeling process is presented. A case study of designing a high speed train is given to verifies the rationality and feasibility of the proposed multidisciplinary requirement modeling. Finally, the conclusions are drawn.

2 Literature Review

The customer requirements modeling has been widely used in the field of software and information systems and proved that it can improve the design efficiency avoid the repeated modification [2]. With the fierce market competition, product users pay more and more attention to the satisfaction of individual requirements, requirements engineering has received increased attention in the field of consumer and capital product design [4], mass customization design, mechanical design [5] and large-scale complex mechatronic products, like aircraft, cars, industrial robots, machine tools and etc. Sheng, et al. [6] studied the customer requirement modeling and its mapping to a numerical control machine design. Beiter, et al. [7] researched on industrial robot examples to describe strategies for clarifying the product definition early in the development phase by deploying the right mix of key tools for management of the product development process. Stechert, et al. [8] applied the managing requirements to the design process of parallel robots to provide the desired fast time-to-market as well as high quality and optimal products to the CRs. At present, the theoretical research of customer requirements modeling mainly focused on the phases of requirement elicitation and analysis [2]. They are detailed below.

2.1 Requirement Elicitation

The main concern of requirement acquisition is how to collect a reasonable and complete customer requirements and accurately express them. Shan, et al. [9] used the gray system theory to gain the customer requirements and then obtained the design structure matrix to analyze the CR. Bae, et al. [10] researched through the analysis of customer data, and then used the data mining technology to obtain customer requirements. Shieh, et al. [11] proposed a graph classification method to collect customer requirements. Zhu, et al. [12] focused on the expression of requirement, and for the fuzzy characteristics of customer requirement, proposed a method based on fuzzy number and fuzzy set uncertainty to express the customer requirement. Violante, et al. [13] developed an user-based strategy to define a structured set of guidelines to support the design of the features of an integrated PLM requirement management tool based on Kano methodology. Yaman, et al. [14] proposed a Product Design Requirement Ontology Model which provides rich requirement semantics to support a new level of engineering requirement storage and analysis by addressing different facets of requirement specifications. Wei, et al. [15] presented a product requirement modeling method based on configuration design. It used ‘tabular layouts of article characteristics’ technology to interact with customers about requirements and obtain the model. Based on the perspective of software implementation, Bakhshandeh, et al. [16] proposed an ontology-based requirements elicitation method to make enterprise ontology and domain ontology as the basic clues of requirements elicitation. Li, et al. [17] proposed a novel domain specific requirements model to facilitates the communication across the domain boundary between the scientific computing domain and the software engineering domain. Goknil, et al. [18] presented a meta-modeling approach to reason about requirements and their relations on the whole/composed models expressed among different requirements modeling approaches.

2.2 Requirement Analysis

The requirement analysis mainly focuses on some useful approaches and methods to realize the mapping of CRs to PDS. The main research on the mapping technique is QFD (Quality Function Deployment), which developed in Japan during the 1960s by Joji Akao and his colleagues and has widely been used in field of CR analysis to translate CRs to PDS developed. Generally, the QFD utilizes four sets of matrices called the house of quality (HOQ) to translate customer requirements into engineering characteristics. Spanning more than four decades, there are a large number of studies on the QFD and recent developments to investigate the transformation of CRs to PDS [19]. Lai, et al. [20] analyzed customer requirement through the combination of Kano model and QFD in the process of product design. This approach used Kano model to analyze customer requirements and used QFD to map the requirement to product design date. Lee, et al. [21] proposed an integrated approach which fused the fuzzy model of model Kano and QFD matrices to obtain and analyze customer requirements. Zhang, et al. [22] used the rough set theory to enhance the accuracy of relationship and self-determination correlation between importance of CR and technical identity, and build optimization integer programming model to realize mapping of CR to the technical characteristics. Chan, et al. [23] used the genetic programming to generate accurate nonlinear models in QFD systems to relate the CR and the engineering characteristics. Wang, et al. [24] established a theoretical mapping model from CR to quality characteristics, covering the classification of CR, the transformation of product quality characteristics with Analytic Network Process approach, and product quality characteristics optimization with matching and conflict-resolving algorithms. For utilizing the historical transaction data adequately, Qin, et al. [25] used association rule mining technique to improve the QFD method to realize the mapping process of CR to function requirement FR. Jin, et al. [26] proposed a probabilistic language analysis approach which translates customer requirements in online reviews into engineering characteristics for QFD automatically. Sun, et al. [27] based on the HOQ matrix, rough set and fuzzy conversion matrix, proposed a simplified systematic approach to transform CR to design specifications. In some cases the QFD techniques become cumbersome and error prone in complex designs. In addition to QFD method, there are a number of other ways to study the mapping of customer requirements and PDS. Krishnapillai, et al. [28] studied the mapping method from requirement domain to product function domain based on the theory of axiomatic design, and three kinds of mapping relations including direct mapping, function mapping and configuration mapping were proposed. Based on existing customer choices data, Wang, et al. [29] used a probabilistic Naïve Bayes approach to addresses the issue of mapping CR to product variants. Guenov, et al. [30] proposed a covariance structural equation models for designing engineering systems to addresses the problem of modeling and mapping of customer needs to technical requirements. Based on knowledge-based artificial neural network and decision tree, Yu, et al. [31] proposed a mapping modeling method to support the mapping from CR to product functions. Mousavi, et al. [32] proposed a CORE model to address interactions between design and market needs, a customer optimization route and evaluation (CORE) to translate CR into design technical attributes. Chen, et al. [33] established a laddering-based design knowledge hierarchy to achieve transformation of customer preferences to specific product concepts. Wang, et al. [34] proposed a product requirement modeling and optimization method to express mapping relation between customers’ functional requirements and product design parameters, and used a Naive Bayes based approach to elicit, characterize the qualitative customers’ latent and subjective preferences and map them to detailed attributes and design parameters.

However, the above studies address the problem of how to objectively analyze and transform the CRs from customer domain to PDS in the design domain in a single discipline but not pay enough attention to the multidisciplinary design characteristics of complex mechatronic products. Due to the difference of knowledge among different disciplines, the designers come from different disciplines have the different understanding, semantics and terminology of each customer requirement from their own perspective, so the resulting PDS must be flawed, and difficult to be communicated among different disciplinary designers at the conceptual design stage, in turn it causes unnecessary design iterations in the entire design process. Therefore, a good customer requirement modeling for complex mechatronic products shall cover a variety of disciplinary views and contain the multidisciplinary design information, helping the designers get access to the complete and accurate PDS easily and quickly before conceptual design stage. However, the existing modeling methods of customer requirements lack the ability of systematic analysis and researches from a multidisciplinary point of view. To sum up, at the requirements analysis stage of complex mechatronic products, an appropriate method of analyzing the customer requirements from a multidisciplinary point of view plays a vital role at the beginning of product development process. In other word, the transformation of CRs to PDS should be determined by designers in different disciplines with their previous experiences and design knowledge and intuition in each discipline, but this has not yet been well developed. Here, we propose a new method for multidisciplinary customer requirement modeling, which can not only facilitate the solution to the above problems but also can contribute to realize the rapid and effective mapping from CRs to PDS. Besides a large number of studies of product design had been made on the PLM like the product concept design, the detailed design, the production, etc. [35,36,37,38,39], but there was no relevant research on the stage of customer requirement analysis.

3 Multidisciplinary Requirements Modeling and its Mapping to PDS

As shown in Figure 1, the multidisciplinary customer requirements modeling includes three stages: requirement elicitation, requirement analysis and requirement verification.

Figure 1

Multidisciplinary customer requirements modeling and its mapping to PDS

3.1 Requirement Elicitation

In the stage of requirement elicitation, use the traditional methods suitable for each discipline to collect vague and abstract discipline-specific original customer requirements from a combination of stakeholders and users. On the other hand, with the new emerging crowdsourcing tools, customers’ requirement information can be acquired through various crowdsourcing platforms, accessing potentially most users or stakeholders over the world [1].

Obviously, the original customer requirements data sets from different methods may overlap with each other explicitly or semantically. Therefore, how to use the original data sets to product a complete customer requirements set need a requirement analysis.

3.2 Requirement Analysis Leading to PDS

3.2.1 Decomposition and Semantic Mapping

The requirement analysis is part of the customer requirement modeling process and through the analysis, a set of complete customer requirements will be developed and transferred to product design specification.

In the analysis process, firstly, cleanup original customer requirements by merging some semantic similar (or the same) items into one. Secondly, conduct a decomposition operation on each cleaned customer requirement using like semantic decomposition, to breakdown it into a series of explicit and detailed minimum requirement units (RUs) [6].

For all decomposition RUs, some may be semantically the same or similar. Therefore, these units will be identified by semantic mapping and will be merged and united as a single RU.

Finally, synthesize all RUs together to obtain a complete set of customer requirements as CR = [RU ₁, RU ₂,…, RU _n ] and assign a weight vector as W =  [w ₁, w ₂, …, w _n ], where w _i (the value is between 0 and 1) describes degree of importance each element of CRs and it can be decided using some method such as analytic hierarchy process (AHP) [40], Fuzzy AHP [41], entropy method or by the subjective or objective experience. The resultant vector of CR × W ^T can represented CR ^W vector, that is,

$$CR^{\text{W}} = CR \times W^{\text{T}} .$$

(1)

Now, the elements of CR can be listed in order by its weight. At the same time, weight values of design requirement elements can be directly obtained from the expectation value of CRs, the design knowledge and experience. These CRs may address the design concerns around safety, cost, performances, etc.

3.2.2 Semantic Transformation of CRs to PDS

After obtaining all RUs or formal customer requirements, the next phase is semantic transformation of the customer requirements to product design specification as a result of common understanding of the customer requirements across multiple teams with different disciplines. It is a bridge between the requirement analysis and requirement verification. This phase entails two steps, in step 1, the RUs are interpreted and transferred into a discipline-specific PDS. And in step 2, all discipline-specific PDSs are integrated to produce a unified PDS for design documentations and guides and the possible conflicts and different understanding of the customer requirements from different disciplines can also be identified for multidisciplinary collaboration.

Suppose that for a complex mechatronic product development, it requires multidisciplinary design efforts from p discipline teams D  =  {D ₁, D ₂,…, D _p } its elements represent the different disciplinary design team.

• 1. Disciplinary mapping of CRs to PDS

In this step, we present the CRs to different discipline teams D  =  {D ₁, D ₂,…, D _p }. For each team, based on their own knowledge and experience, they can map the CRs into design requirements (DRs) in a PDS by applying QFD approach. Here, we do not discuss QFD in detail. The readers can refer to Ref. [22]. For generality, in the kth disciplinary design team, the designers use their subjective experience and knowledge to confirm the design specifications, $\varvec{DS}^{\varvec{k}} = [dr_{1}^{k} ,dr_{2}^{k} , \cdots ,dr_{m}^{k} ]$and the relationship of CRs and PDS elements in a House of Quality can be described by a matrix M ^k.

$$M_{{}}^{k} = \left[ {\begin{array}{*{20}c} {a_{11}^{k} } & \cdots & {a_{1m}^{k} } \\ \vdots & \ddots & \vdots \\ {a_{n1}^{k} } & \cdots & {a_{nm}^{k} } \\ \end{array} } \right],$$

(2)

where the element a _ij (i = 1 to n; j = 1 to m) refers to the correlation relationship between the ith RU _i and the jth dr _j , with four degrees “no relevancy ”, “weak relevancy”, “medium relevancy ”, “ strong relevancy ”.

We can use the relevancy matrix M ^k to realize the mapping from CRs to a design specification and confirmed the weight of each element of the design specifications, through Eq. (3):

$$\begin{aligned} W_{\text{DS}}^{k} = W \times M_{{}}^{k} = \left[ {w_{1} { ,}w_{2} { ,} \cdots { ,}w_{n} } \right] \times \hfill \\ \left[ {\begin{array}{*{20}c} {a_{11}^{k} } & \cdots & {a_{1m}^{k} } \\ \vdots & \ddots & \vdots \\ {a_{n1}^{k} } & \cdots & {a_{nm}^{k} } \\ \end{array} } \right] = \left[ {w_{{dr_{1} }}^{k} ,w_{{dr_{2} }}^{k} , \cdots ,w_{{dr_{m} }}^{k} } \right]. \hfill \\ \end{aligned}$$

(3)

Finally, we can obtain a weighted design specifications set with weights. And the resultant vector of $\varvec{DS}^{\varvec{k}} \times \varvec{W}_{\text{DS}}^{{\varvec{k}{\text{T}}}}$ is called the kth disciplinary design specification vector DS ^kW. Similarly, other disciplinary design specification vectors can be obtained.

• 2. Standardize disciplinary design specifications

After obtaining all the disciplinary design specifications vectors as {DS ^1W, DS ^2W,…, DS ^pW}, note that the dimensions of disciplinary design specification vectors may be different, here we use m to indicate a general term, and focus on the standardization of disciplinary PDSs and in next section we will integrate them with different dimensions to form a unified product design specification set PDS for design documentations and communications.

Although each disciplinary PDS aims to address the same set of CRs, it is still different with each other because different disciplines have different potential solutions and understandings of how to achieve each RU. Due to multidisciplinary relationships, these design specification elements are coupled an interrelated, in other words, for some customer requirements a single disciplinary design team is not good enough to handle them, and there is a need for multidisciplinary design teams efforts to identify the interactions and coupling elements from different disciplinary design specifications to meet those customer requirements. But there will be a problem here. In requirement mapping phase, different disciplinary designers use their own semantic and terminology to describe their design specifications, and it may result different expressions of design requirements with the same meaning in different design disciplines. For example, the terminology of “operation” and “run” can express the same meaning, but they are two different vocabularies. So the semantic difference of design specifications among different disciplinary design teams will make a designer difficult to understand other disciplinary design specifications and this will obstruct the communication between different discipline teams. Therefore, it is necessary to analyze and translate all the disciplinary design specifications from different disciplines into a general semantics and terminology to make all disciplinary design teams can easily understand each other. In order to solve this problem, we establish a disciplinary specialty language dictionary to realize the mapping of the terminology and semantics of design specifications among different disciplines into the standard semantics and terminology, like “operation” and “run” can be expressed as standard vocabulary “operation”.

To establish this dictionary, there is a need for multidisciplinary team efforts to define the mapping rules of terminology and semantic between different disciplines with knowledge and experience of experts. With this dictionary, we can in turn to transform all the design specifications sets {DS ¹, DS ²,…, DS ^p} to standard semantic design specifications set {DS ^1S, DS ^2S,…, DS ^pS}, which can be easily understood by designers from different disciplinary design teams. In addition, this disciplinary specialty language dictionary not only help transform disciplinary professional terminologies to standard terminologies, but also can serve as a language aid to make cross-disciplinary design communication easier and reversely produce a discipline-specific PDS from the standard PDS with their own unique terminology system to support design communications with a single disciplinary team.

• 3. Unify different standard design specifications

When all disciplinary design specifications with the standard semantics are obtained, we can evaluate and integrate them into a unified list as a complete PDS. Each disciplinary PDS may have different dimensions (or elements). If an element in one disciplinary design specification is independent and not coupled with other disciplinary design specification elements, it means that a single disciplinary design specification element is found and it should be added in the unified PDS with an annotation to indicate which disciplinary design team it belongs to. If there are some identical elements among different disciplinary design specifications with the same description and value, we need to combine those same elements into one element in the unified PDS and add an annotation to indicate it is a collective design goal needing multidisciplinary collaboration efforts to achieve among the related disciplinary design teams. In addition, there may be some conflicts among some different disciplinary design specifications, due to that the value of a design specification element confirmed by a certain disciplinary design team may limits or conflicts the value of the element from other disciplines. Thus, it is necessary to coordinate and eliminate the design conflict with an effective method in this integration process. For this case, we can eliminate conflicts based on interdisciplinary design knowledge and experience, by compromising the degree of customer requirement satisfaction (DoCRS).

Achieving higher DoCRS is the goal of product design, closely related to product design specifications. Due to the bidirectional influence between the customer requirements and disciplinary design specifications, the changed elements in a disciplinary design specification can lead to the changes of DoCRS. Therefore, we propose a method to eliminate conflicts based on maximizing DoCRS after the modifications of disciplinary design specifications. In each disciplinary design team, let original DoCRS to be 1, which mean the obtained original design specifications elements meet all the customer requirements before changed. Apply this method through modifications of the conflicted disciplinary design specification elements across the different disciplinary design teams to obtain multiple correction schemes, and for each scheme, we can calculate the total changed DoCRS S ^C from different disciplinary design team and find the optimal solution with the maximized absolute term of S ^C as follows:

$$S^{\text{C}} = \sum\limits_{{}}^{{}} {S_{{}}^{{k{\text{C}}}} } ,$$

(4)

where S ^kC is the DoCRS after the change in the kth disciplinary design team. This term can be represented as

$$S_{{}}^{{k{\text{C}}}} = \sum\limits_{i}^{{}} {w_{i}^{{}} \sum\limits_{k}^{{}} {f (a_{ij}^{k} } } \times \Delta dr_{j}^{k} ) ,$$

(5)

where w _i is the weight value of element RU _i in the set CR. The $a_{ij}^{k}$ from the matrix M ^k represents the quantitative relationship between the ith customer requirements RU _i and the jth design requirement element $dr_{j}^{k}$in the kth disciplinary design team and its sign could be “+” and “−” indicating positive correlation and negative correlation respectively. The $\Delta dr_{j}^{k}$represents the changed state of $dr_{j}^{k}$and when it increases, its value is assigned as 1, conversely, it is −1 and when it has no change, it is 0. Let a represents the term $a_{ij}^{k}$ and b represents the term $\Delta dr_{j}^{k}$, the f(a×b) in Eq. (5) can defined as follows:

$$f\left( {a \times b} \right) = \left\{ \begin{array}{*{20}l} 0, \quad a \times b < 0, \hfill \\ a \times b, \quad a \times b> 0, \hfill \\ \left| a \right|, \quad a \times b = 0. \hfill \\ \end{array} \right.$$

(6)

As shown in Figure 2, the process of this method are detailed as follow:

Figure 2

Process of conflict resolution

Step 1. Extracting conflict elements from different disciplinary design specifications DS ¹,…, DS ^p and identify the corresponding $a_{ij}^{k}$ in M ^k (k  =  1,…, p). Assuming that there is a conflict between the ith element in DS ^j and the gth element in DS ^h (j and h belong to 1 to p).

Step 2. With multidisciplinary collaboration from different disciplinary design teams to develop change schemes of affected elements in the conflicted disciplinary design specifications.

Step 3. Calculate the degree of customer satisfaction after change with Eqs. (4)–(6).

Step 4. Based on the maximum customer satisfaction degree, choose the best change scheme for all affected elements.

After eliminating all the conflicts among different disciplinary design specifications, we can integrate them to form a complete PDS to support the subsequent conceptual design and product manufacturing processes.

3.3 Requirement Verification

In the stage of requirement verification, we also still use the existing traditional method. After obtaining the final conceptual design scheme or physical tests, we can organize field experts, designers, product users and so on to assess that all customer requirements are fulfilled or not fulfilled.

4 Case Study

In this paper, the design of a high-speed train is selected as a case study. The proposed methods, strategies and process of multidisciplinary customer requirements modeling are verified and applied to obtain the complete and less coupling PDS. The high-speed train is a typical complex mechatronic product, which has diversified functions and complex structure hierarchy and it’s design process often needs collaboration with the experts in various disciplinary teams, such like body system, internal loading system, traction system, braking, system bogie, HVAC, water supply and sanitation. With the increasing difference of train’s running environment, customers have more and higher requirements for the high-speed train and the enterprise also wants to understand those requirements in a timely manner. But it is difficult to use the traditional customer requirements modeling process to realize rapid and effective customer requirements analysis to obtain an accurate and reasonable PDS as the input of conceptual design is an important problem at the requirements analysis stage. The proposed multidisciplinary requirement modeling can solve this problem very well.

Firstly, use the method of interviews and market analysis to elicit the initial customer requirements of the high-speed train, and then interpret the initial CRs and derive explicit requirements into a form list as the input vector with the corresponding weighting vector. As shown in Figure 3, due to the a very larger number of customer requirements of high-speed train and the limited development time crossing related multidisciplinary design teams, we selected some key requirements (design speed RU ₁, comfortable RU ₂, security RU ₃) and asked multidisciplinary design teams (traction design team D ₁, car body design team D ₂, braking design team D ₃, bogie design team D ₄) for CR analysis and verification. Secondly, distributed the key customer requirements into the different disciplinary design teams and asked the designers to use their product design knowledge and experience to map the customer requirements to DRs in each disciplinary team with the method of QFD. The design requirements of each design team are finally obtained as {DS ¹, DS ², DS ³, DS ⁴} shown in Figure 3.

Figure 3

Multidisciplinary customer requirement modeling of high-speed train

Thirdly, used the disciplinary specialty language dictionary to transform the different semantics of design requirement elements among different disciplinary design teams into the standard universal semantics and terminology. For example, the “carbody strength” in the DS ¹ and the “Frame strength”, “Wheel strength”, “Axle strength” in the DS ⁴ all represent the structural strength properties of products and chose the same strength standard, so they all can be expressed by standard semantics as word “strength”. Similarly, the “Traction drive ratio” in DS ² and the “transmission ratio” in the DS ⁴ can be transformed into “ Gear transmission ratio”.

Finally, through the comparison and analysis of all the disciplinary design specifications sets, the DS ¹, DS ², DS ³ and DS ⁴ had the same elements as “Design speed”, “strength”, “maximum operating speed”, “maximum test speed”. When the disciplinary design specifications were integrated, these elements were combined as one element. In addition, when the running speed was 300 km/h, the designers from D ₁ and D ₄ obtained the different values of the gear transmission ratio, and that difference caused a conflict. The gear transmission ratio mainly influences the running speed and with the decrease of it, the train running speed become higher, in other words, there is a negative correlation between the running speed and the gear transmission ration. Hence, based on analysis of minimum difference before and after the DoCRS changes to coordinate the conflict and the results are as Table 1, where the weight value of running speed is w ₁ = 0.4, it can be seen that the DoCRS in scheme 2 is maximum. So the scheme 2 is the final solution, means the value of “gear transmission ration” in the D ₁ and D ₄ is 2.7.

Table 1 Conflict resolution of the gear transmission ration between D ₁ and D ₄

Through the above analysis, all design requirements sets form different disciplinary design team were integrated into a complete PDS to meet the key customer requirements as shown in Figure 3. This PDS can clearly show which is the single disciplinary design requirements and which is multidisciplinary design requirements to be resolved in a multidisciplinary collaborative work. As a result, the PDS can be used as a collaborative work lookup table to guide the collaborative design process in the stage of concept design, for example, the “design speed” needs all four disciplines to work together in order to achieve while the fulfilment of “Gear transmission ratio” only needs traction design team and bogie design team to have a joint solution. In addition, with the specialty language dictionary, we can reversely transform the PDS into a discipline-specific PDS-D for each disciplinary design team and those PDS-Ds are delivered to the subsequent conceptual design stage for further analysis as in Ref. [3], which proposed the P-B-S model and developed a vector-based mapping tool to realize the mapping of PDS to conceptual design schemes.

5 Conclusions

• 1. A new conceptual method for modeling multidisciplinary customer requirements is proposed.

• 2. The proposed modelling method can support the mapping from the fuzzy and incomplete customer requirements in the marketing domain to a detailed and accurate PDS in the design domain, which results from multidisciplinary teams’ efforts.

• 3. The proposed establishment and utilizing of a disciplinary specialty language dictionary enables that the semantics of disciplinary design specifications among disciplinary design teams can be transformed into a general and standard semantics which can clearly describe relevance and eliminate ambiguity between each disciplinary design specifications to make all disciplinary design teams can easily understand each other.

• 4. Combining elements with same semantics and coordinating the conflicts among different disciplinary design specifications with the proposed method can integrate all different disciplinary design specifications into a more complete, efficiency and less coupling PDS with comments.

• 5. The resultant PDS can not only be as a collaborative work lookup table to guide the multidisciplinary collaborative design, but also can be inversely mapped into each disciplinary design specifications PDS-Ds through the specialty language dictionary disciplinary.

• 6. The case study indicated that the integrated PDS and the corresponding disciplinary PDS-Ds can be documented and used as concept design inputs with suitable semantics for multidisciplinary collaborative design work.