Taking a look at the utilisation of function models in interdisciplinary design: insights from ten engineering companies

Abstract

Interdisciplinary system development requires the integration of diverse expertise to combine different engineering technologies and—increasingly often—services, in order to provide users with expected value and desired functionality in newly developed products. Failure to achieve integration of disciplines can result in design errors posing a direct threat to the users and to the company. Function modelling is expected to provide suitable means for the integration of disciplines early in the development process. However, a plethora of function models can be found within different disciplines or even across, and their divergence has proven to hamper shared, cross-disciplinary function modelling in design teams. This article presents research on function modelling in different disciplines in practice. Conducted research comprises empirical studies in ten companies developing mechatronic systems and/or Product-Service Systems in diverse market areas. The studies provide insights into the utilisation of different function models in different disciplines and across, as well as the specific needs and preferences of practicing designers regarding interdisciplinary function modelling. Finally, the obtained insights and their implications for supporting interdisciplinary function modelling are being discussed. Indications are derived which may guide future research endeavours pertaining to the development of support for collaborative, (cross-)disciplinary function modelling.

1 Introduction

Industry is confronted with increasing and ever-changing demands of customers on global markets for the integration of diverse functions into newly developed systems (McAloone and Andreasen 2004; Gries 2007). In order to address these demands, companies increasingly often combine different engineering technologies in an attempt to diversify their products’ functionality and also more often complement them with associated services in so-called Product-Service Systems (PSS, see Matzen 2009). Developing and implementing such combined solutions necessitates close collaboration of experts from various disciplines (Erden et al. 2008; Müller 2013). The need for successful collaboration is particularly large during conceptual design, i.e. in the transition from a problem to a potential solution (Chakravarthy et al. 2001; INCOSE 2010; Badke-Schaub et al. 2011). Coordination of design activities and ensuring sound decision-making on alternative solution concepts in this process necessitates a continuous exchange of information in the design team (Shai and Reich 2004) and a shared understanding of the problem and the emerging solution alike (Kleinsmann and Valkenburg 2008; van Beek and Tomiyama 2009). Shared understanding and close collaboration demand clarifying the requirements, central functions, and their dependencies, as well as elaborating on different solution elements and their implementation (Frankenberger et al. 1998; Alink 2010). Function modelling addresses solution finding early in the process and on an abstract level (Chakrabarti and Bligh 2001) and—because of its spread to a large variety of disciplines—is considered particularly well suited for contributing to the establishment of the required shared understanding (Ahmed and Wallace 2003; van Beek and Tomiyama 2009). Erden et al. explicitly argue “the barriers between […] disciplines can be overcome by using [a] common language of functionality” (Erden et al. 2008 p. 147, see also Stone and Wood 2000). This is similarly emphasised by Tukker et al. (2006) and Müller et al. (2007) for the integration of engineering disciplines with service development in PSS design. Indeed, novel function modelling approaches like Systems Modeling Language (SysML, OMG 2012) and Object-Process Methodology (OPM, Dori 1995) are increasingly used in interdisciplinary applications and have advanced system-oriented function modelling in companies considerably (Bone and Cloutier 2010). Yet, it appears that they are not widely shared across disciplinary boundaries (Borches and Bonnema 2010; Torry-Smith 2013). This is a fairly common phenomenon and integration of different disciplines through shared function modelling has not sufficiently been established thus far.

A fundamental problem seems to be that the function models from different disciplines differ in terms of addressed contents as well as used terminology and morphology (i.e. their structure and form, see Erden et al. 2008; Eisenbart et al. 2012, 2013a). In addition, function as a term can have a variety of different meanings to researchers and practitioners without them necessarily being aware of this ambiguity (Vermaas 2009; Carrara et al. 2011). Therefore, in spite of its large potential to facilitate integration in interdisciplinary system development, a “common language of functionality” has not sufficiently been attained thus far. The research presented in this article aims to shed light onto the particularities of applying function models and modelling approaches within and between different disciplines. Semi-structured interviews with 35 designers in ten companies active in mechatronic system and PSS development were conducted. The study is explorative by nature and cannot represent the entirety of interdisciplinary design practice, but aims to provide insights that could help to advance function modelling in theory and practice in the future. To contribute to this field of research, the interviews focus on exploring good and bad experiences made during the use of function modelling in (interdisciplinary) design practice. Furthermore, the participants’ demands and desires for future development of function modelling are addressed.

The next section presents existing research by a variety of scholars on function modelling and different notions of function (in different disciplines). In Sects. 3 and 4, the conducted interview study and the obtained findings are presented. Section 5 discusses the insights leading to the derivation of properties that an integrated function modelling approach ought to possess in order to address the needs identified in the visited companies and to help them advance shared function modelling in their development processes in the future. Section 6 concludes and suggests directions for future research that may lead to a more generally applicable support for shared, interdisciplinary function modelling.

2 Function in design

A design task is widely regarded an “ill-structured problem” as at the beginning of a project often neither the problem nor the desired solution are sufficiently defined (Simon 1973; Braha and Reich 2003). Conceptual design therefore cannot directly move from a problem to a solution, but is typically characterised by coevolution, i.e. iterative analysis and evaluation steps leading to a stepwise increase in information about the addressed problem (typically the requirements) in parallel to information about the emerging solution, i.e. the system to be developed and its structure (Poon and Maher 1997; Srinivasan and Chakrabarti 2010). It is often argued that designers use “function reasoning” in this gradual transition (see, e.g. Chakrabarti 1992; Fowler 1998). The term comprises the designers’ considerations about the functionality provided by an existing entity, as well as the elaboration and decision-making on which entities (alone or in combination with others) may be employed in a specific way to implement a desired functionality (Chandrasekaran and Josephson 2000; Far and Elamy 2005). Function modelling allows to make these considerations explicit and thus accessible to others in a design team in the reasoning towards a potential solution.

2.1 Diverse notions of function

Despite the centrality of function to conceptual design, a large variety of definitions of function can be found in the literature (see, e.g. Warell 1999; Chandrasekaran and Josephson 2000; Maier and Fadel 2001; Chiang et al. 2001; Deng 2002; Chandrasekaran 2005; Ericson and Larsson 2005; Crilly 2010; Vermaas 2009; Carrara et al. 2011; Aurisicchio et al. 2011; and Goel 2013). The definitions typically divert in used terminology but most importantly also with respect to the specific notions of function (i.e. the underlying perception and meaning given to the concept of function) they convey. Several of the definitions, for instance, refer to function as the ability of a system to achieve a goal or fulfil a given task by showing certain behaviour (see, e.g. Roozenburg and Eekels 1995 or Buur 1990). Other authors define function as an intended or required transformation, conversion, or change of states of distinct operands (i.e. typically specifications of material, energy, or signals; see, e.g. Rodenacker 1970; Fowler 1998; Cockburn 2000 or Pahl et al. 2007). Finally, many authors refer to function to be equal to (Ropohl 2009; Ullman 2010) or derived from (Sakao and Shimomura 2007) the purpose of a system, respectively, in terms of fulfilling a goal.

As the particular definition of function used is rarely made explicit in design conversations, function as a concept can in fact become ambiguous. This, in turn, is bound to hamper clarity in related discussions and modelling. Based on comprehensive reviews, Vermaas (2009) and Carrara et al. (2011) similarly conclude that “[…] function lacks a single precise meaning. It is a term that has a number of coexisting meanings, which are used side-by-side in engineering” (Vermaas 2011, p. 98). Vermaas (2009, 2013) derives a set of three notions of function that he considers to be archetypical:

• 1. behaviour-related notion: function as the intended behaviour of an entity.

• 2. outcome-related notion: functions as the desired effects of the behaviour of an entity;

• 3. task or goal-related notion: function as the purpose for which an entity is designed.

The latest is closely related to the particular uses that the system is intended to be put to. In addition, Vermaas discusses the concept of capability of a system or artefact—through its particular structure—to show certain behaviour. Behaviour may serve the originally intended purpose but also completely different use plans (Houkes and Vermaas 2010). In this article, function—as opposed to so-called affordances—is considered as something deliberately designed into a system to fulfil a particular task. Affordances (c.f. Maier and Fadel 2001) cover the entirety of uses that a system can be put to due to the specific characteristics (after Weber 2007) it possesses, though they may not have been originally intended by the designers (Brown and Blessing 2005). Similarly, Ullman (2010), for instance, discerns function, as a desired performance of a system, from behaviour, which is related to its actual performance based on the concrete physical properties it possesses.

2.2 Diversity of function modelling across disciplines

Similar to the diverse definitions of function found in the literature, a large variety of function models are proposed in relevant textbooks (see, e.g. Erden et al. 2008; Eisenbart et al. 2012). A considerable amount of function models originates from German mechanical engineering research conducted in the 1960s and 1970s (see, e.g. Rodenacker 1970; Pahl and Beitz 1977; Hubka 1980). They usually represent function as verb/noun combinations related to a transformation of the states of basic operands between the input and output of a system. The underlying principles of these types of models have been widely adopted in mechanical engineering literature (see, e.g. Ullman et al. 1992; Stone and Wood 2000; Ulrich and Eppinger 2008) and in interdisciplinary design approaches (see, e.g. VDI 2004; Cross 2008). The large number and diversity of function models that can be found in the mechanical engineering literature increases substantially when further disciplines are considered.

Comprehensive reviews of 76 function models (61 original models plus 15 variants proposed by different authors, see Table 1 for an overview) by Eisenbart et al. (2012, 2013a, b; Eisenbart 2014) led to the identification of a set of distinct contents addressed in the models, referred to as function modelling perspectives, as well as specific modelling morphologies. Modelling morphologies refer to the way represented information is structured in the respective models; this conveys information about how individual functions are linked or are dependent on one another. Essentially, information may be organised hierarchically, related to a flow of operands or related to a flow in time. Function modelling perspectives refer to the particular information that is, more or less saliently, comprised in a model, related to visualising any aspects concerning system functionality. Seven central function modelling perspectives were identified which are briefly described in Table 2. The reviewed function models typically address different combinations of these modelling perspectives and morphologies.

Table 1 Overview of reviewed function models

Table 2 Central function modelling perspectives

In a few models, additional types of content were found that are likely to have been included by the respective authors as support for the solution finding process and/or the reasoning about specific aspects of system functionality. Additional contents include:

• constraints and target values for function execution (e.g. allowed performance deviation and required torques) and

• impacts from/on the environment (e.g. mutual disturbances affecting function fulfilment).

Various authors propose not a single but multiple function models usually complementing and/or building up on one another. These are typically accompanied by a set of associated (sequential) modelling steps. The proposed (sequence of) function models and modelling steps form a function modelling approach intended to guide designers in their reasoning towards a solution.

Related analyses (see Eisenbart et al. 2013a, b) reveal a large diversity in the reviewed disciplines and particularly across; this refers to the addressed function modelling perspectives, used morphologies, and proposed modelling approaches alike. While most models comprise multiple perspectives in combination, no reviewed model entails all the discussed function modelling perspectives and morphologies. The analysis further suggests that the transformation process perspective is always one of the most prominent perspectives in function models from all reviewed disciplines. Hence, this perspective, uniquely, takes a central role in representing functionality regardless of disciplinary boundaries. The study concludes that transformation processes convey a large potential to serve as a basis in the development of an integrated function modelling approach that may, eventually, adequately support interdisciplinary system development. However, so far, this suggested potential has to be verified in practice.

2.3 Approaches to support shared function modelling

In an interdisciplinary development project, designers from multiple disciplines, and, therefore, the different modelling approaches they use, have to come together. The issue of diversity in function modelling within and across different disciplines is considered a central barrier for seamless collaboration (Booth et al. 2015; Vermaas 2013; Maier et al. 2006) and has been the focus of numerous research endeavours (see Vermaas 2011, 2013 or Carrara et al. 2011 for overviews). Scholars like Erden et al. (2008), but also, e.g. Chandrasekaran and Josephson (2000), Chakrabarti and Bligh (2001), Garbacz et al. (2011), or Srinivasan et al. (2012), provide extensive reviews aimed at converging on or deriving (a set of) common denominator(s) in function modelling, respectively, that could be used as vantage point for the development of a cross-disciplinary function modelling approach. Prominently, Erden et al. (2008), Garbacz et al. (2011), and Vermaas (2013) see this goal as unfulfilled so far and argue that the multiplicity and specificity of envisaged applications of function modelling prevent the targeted convergence. Thus, the plethora of models proposed in the literature prevails. Complementary research has taken a different direction, aimed at supporting communication and comprehension among designers in spite of this multiplicity in extant models and notions of function. Such research can be discerned in two main threads: linking and relating between contents and concepts addressed in disciplinary function modelling, on the one hand, and reducing ambiguity in what function and associated models semantically entail, on the other hand (Vermaas 2011). The former is predominantly focused on integrating information addressed in function modelling in different disciplines. Eventually, this should then lead to a comprehensive functional description of the system under development. Prominent examples are the works by Kruchten (2004) and Weilkiens (2008) based on UML/SysML, Hubka, and Eder (1988; Eder and Hosnedl 2008, as well as more recent extensions of this approach towards PSS by Matzen 2009), the SAPPhIRE model (see Chakrabarti et al. 2005) or the IFM framework (see Eisenbart et al. 2016).

The second thread of research mainly focuses on clarity in the conceptualisation and representation of functions by introducing formalisation and well-defined semantic distinctions. Typical examples are function ontologies.¹ Essentially, these discriminate clearly between different aspects entailed in or related to function as a concept, respectively, and typically employ function taxonomies.² Function taxonomies are “a standard language of function” (Ahmed and Wallace 2003, p. 1) which aim at providing clarity in the textual formulation of functions. In order words, by raising precision in what textual and appendant visual representations of function entail, comprehension and communication based on these in design teams are enhanced. Prominently, Kurfman et al. (2003), Kitamura and Mizogushi (2007), and Sen et al. (2010, 2013) have been able to show an increase in clarity and intelligibility through use of function taxonomies which substantiates the large potential that these approaches offer.

All these approaches have their particular benefits and shortcomings for application in design practice. Integrative approaches like SysML, for instance, despite seeing increasing application in practice, also met critical reception. Voiced criticism refers to it producing rather complex models that—due to their inherent formalisation—require a considerable learning effort and abstract thinking (Borches and Bonnema 2010). This has also been expressed as a difficulty concerning function taxonomies and ontologies as the vocabulary used in such approaches is fairly restrictive (see particularly Ahmed and Wallace 2003; van Eck 2010a, b; Aurisicchio et al. 2012). Kitamura and Mizogushi (2007) discuss such problems encountered while they implemented their ontology in practice as potential limitation.

More generally speaking, the interest in researching function modelling to support design is high and large potential from applying it is suggested in the literature. Yet, it seems the actual spread of function modelling in design practice is obscure. While there is a rather broad consensus that is quite regularly applied in, e.g. electrical engineering, software development, and systems engineering, there is a controversy to whether it is applied to a similar extent in mechanical engineering practice. Aurisicchio et al., for instance, suggest that “little use is made of such tools by engineering designers today” (Aurisicchio et al. 2012, p. 2; see also Araujo et al. 1996; López-Mesa and Bylund 2011). Wallace (2011) and Tomiyama et al. (2013) argue that this phenomenon is very likely to be related to little training on abstract thinking during mechanical engineering education. This adds to a particularly high inhibition threshold towards learning/applying it later, because the abstract nature of function modelling inherently makes it hard to see concrete benefit to organisational and monetary venturing of a company. The authors raise questions as to how function modelling can be advanced to provide a broad audience of designers with the support expected from it. Research suggests that different designers draw different benefit from specific models in concrete applications. This will be discussed in more detail in the following section.

2.4 Studies on function modelling in practice

Several scholars present research on practical application of function modelling. Blessing (1997, see also Blessing and Upton 1997), for instance, reports on experiences made by a group of researchers while generating function structures after Pahl et al. (2007) in a design project with an industrial partner. They state that the application of a systematic approach, especially the creation of function structures, encourages solution generation and is useful for original design problems.

Motivated by the observation that existing function modelling approaches usually lead to different results if different designers apply the same approach for the same modelling task, Kurfman et al. (2001, 2003) investigate the repeatability of the functional basis methodology proposed by Stone and Wood (2000). They express the expectation that repeatability is key to a more widespread uptake of function modelling as a common engineering tool. In their empirical study in a mechanical engineering context, they observed that a common vocabulary for articulating functions results in a reduced diversity of the used expressions, thus improving clarity in communicating product functionality.

Caldwell et al. (2011) analysed several function models (from a public available database of function models) that were created using the functional basis. They investigated which level of detail is appropriate and useful for applications in engineering design. They report that tertiary terms are inappropriate while secondary terms offer sufficient information to describe functions and are used most often in the analysed models. Their (Caldwell et al. 2011) study suggests that the functional basis vocabulary needs further development for a more detailed description of flows as the analysed models were created using additional terms and flow qualifiers that are not part of the original proposition.

In complementary research, Eckert and Alink (Alink et al. 2010; Eckert et al. 2010; Eckert 2013) carried out experiments and interviews with subjects from a mainly mechanical engineering background. In the experiments, participants were asked to generate a function model of a hydraulic pump they were presented with. Alink (2010) further analysed function modelling in design projects carried out with students but also in industry. Central findings reported in the studies are as follows:

• practicing designers inadvertently and subconsciously switch between applying different notions of function while reasoning about and modelling functions (Eckert 2013; Eckert et al. 2010; Alink et al. 2010; similar insights are reported by Tomiyama et al. 2013);

• solution-neutral function modelling (as often proposed in the literature) was perceived as obstacle rather than support by subjects as it was considered to be too abstract; instead, they felt more comfortable with being able to come up with potential solutions as they go and model functions accordingly in a highly iterative process (see also Visser 1991; Albers et al. 2010) .

Regarding the first aspect in particular, it is important to note that participants had been introduced to function and function modelling—as a kind of refreshment of what they learned during their education—by the experiment instructor right before they were asked to perform the function analysis of the pump. Still, they struggled in performing it rigorously. Interestingly, the notions of function that the participants used in the experiments and provided in the interviews by Eckert and Alink strongly correspond to the three archetypical notions of function derived from the literature by Vermaas (2009, see Sect. 2.1). Several participants switched unconsciously between different notions of function while they were modelling the functions of the hydraulic pump, and because of this switch, the modelled functions differed in their formulations. That is to say, the participants switched between analysing the pump’s functions based on inputs and outputs of the pump and its components, based on the transformations of operands that they thought would be taking place or based on the purposes they considered specific components to serve. The different authors conclude that designers need flexibility in modelling functions in order to support their reasoning concurrently. Based on own studies and a review of the research by Eckert and also Vermaas (2011, 2013), Goel (2013) provides compelling arguments emphasising that shared function modelling, hence, needs to be able to cope with different notions of function and flexible changes in the way functions of a system are reasoned about. A somewhat analogue argumentation is given by Buur (1990) and Lawson and Dorst (2009). It is quite intriguing to see that a similar observation, i.e. the occurrence of diversity when different designers model the functions of the same product, leads to very different conclusions by these scholars as compared to the research by Kurfman et al. (2001, 2003), discussed above.

2.5 Implications

Shared function modelling of designers from different disciplines seems confronted with difficulties, both from a theoretical and a practical point of view. On the one hand, function models and notions of function proposed in the literature are largely diverse which can create critical ambiguity in the exchange of information within and across disciplines (Vermaas 2013). This is considered one of the main causes why shared function modelling is hampered, particularly in interdisciplinary design (Chakrabarti and Bligh 2001; Chandrasekaran and Josephson 2000). Practicing designers, on the other hand, seem to prefer a large degree of freedom in modelling functions depending on their current strain of reasoning about a system and its components. And this tends to involve (unconscious) ambiguity in their notion of function. This natural tendency seems to create barriers for designers to use function ontologies and/or taxonomies stemming from research aiming to provide clarity in function modelling by advancing formalisation. This is substantiated by Booth et al. (2015) who found that, without substantial training, designers can experience very high cognitive loads during function modelling which then negatively affects rigorous execution. In extension, this makes it harder for such designers to apply more formalised modelling approaches. Conversely, discussed research by scholars like Kurfman et al. (2001, 2003) and others suggests that designers can draw substantial benefit from them. Hence, the use of finite vocabulary as offered by the functional basis (see Stone and Wood 2000) and similar function taxonomies for a final model can be expected to advance its clarity. Yet, designers may need to be able to remain flexible during the gradual generation of the function model. At the same time, it seems different groups of designers require different modelling tools and support depending on the envisaged application. This implies, when designers perform function modelling collaboratively, the particular model(s) used may need to be adaptable towards specific demands and preferences, that is to say, allowing more or less formalised modelling and flexible combination of contents. Many open questions remain as to how shared function modelling can be enhanced in practical design work. Deeper insight and improved comprehension of practice is considered imperative to advance existing support or develop new support for interdisciplinary function modelling, respectively. The research presented here strives to contribute to this area of research and to explore the actual application of function modelling within and across different disciplines. This includes investigation of experiences made as well as personal preferences and needs in relation to function modelling of practitioners active in the development of mechatronic systems and PSS.

3 Study design

The research presented here investigates experiences made with function modelling within and across disciplines typically involved in the development of interdisciplinary systems such as mechatronic products and/or PSS. To address the issues raised in the previous section, an explorative empirical study in ten companies was conducted. Using the insights obtained from the presented literature review, the study was guided by the following research questions:

• 1. What are different notions of function addressed by designers in the visited companies?

• 2. Which models are used for modelling functions and system functionality?

• 3. How are these models typically applied during conceptual design in the companies?

• 4. Which function modelling perspectives are prominently addressed in the function models applied by different disciplines in the companies?

• 5. What kind of experiences (good and bad) have been made with the different function models regarding

  • a. modelling in (interdisciplinary) design?

  • b. exchanging information with colleagues (from other disciplines)?

• 6. Which other function models are known but currently not used? What are specific reasons for not applying them?

• 7. What kinds of changes occurred if a new function model/modelling approach was introduced in the companies?

• 8. What kind of (abstract) representation/visualisation of functions is preferred by the participants?

• 9. What kind of support related to (interdisciplinary) function modelling is needed or considered useful by the participants?

Social sciences provide numerous methods to analyse human behaviours and perceptions, but also products resulting from human behaviour (Diekmann 2001; Bender et al. 2002). The aim of the presented study was to obtain insights into concrete experiences made with practically applying function models in different disciplines and design contexts. It was decided to use semi-structured interviews as these allow slight deviations and reformulation of individual questions if required to explore relevant aspects in more detail (see Patton 2002 and Blessing and Chakrabarti 2009). As the conducted study is explorative by nature, the possibility to do so was considered highly beneficial. Overall, the study comprised four phases: preparation, recruitment of participants, data collection, and analysis. The preparation phase included the generation of the question catalogue as well as a trial with two designers in industry to test and improve its intelligibility.

3.1 Participant recruitment and sample profile

Companies were recruited from a variety of market areas in order to gain broad insights from exploring interdisciplinary design practice. Nine visited companies have their headquarters in Europe, one in North America. Market areas covered include telecommunication (n = 1 company), consumer products (n = 1), aerospace (n = 2), as well as automotive (n = 3) and manufacturing machinery design (n = 3). Four companies are considered PSS developers as they combine the developed technical products with associated services. Company sizes vary between a small start-up company with 12 employees to a well-established vehicle design and manufacturing company with more than 275 thousand employees and an annual turnover of more than 100 billion € in 2015. The companies can be discerned into large- (number of designers employed in the company is higher than 250) or medium-sized companies (50–250 designers) with globally distributed design teams, as well as small-sized companies employing less than 50 designers located on one site. Table 3 collocates the companies’ profiles and the specific disciplines that are mainly involved in the specific development processes and projects that were addressed in the interviews.

Table 3 Overview of companies involved in the study

Individual participants in the companies have been collaborating with each other on a regular basis in current or past design projects. A total of 35 participants were recruited for the study. They comprise specialist designers (n = 18) involved in discipline-specific development in mechanical engineering, electrical engineering, software development, or service design. In addition, participants were recruited who are involved in system-level design (i.e. systems engineers or project leaders) and/or assume management positions (n = 17). Participants had an average of 14.1 years of professional experience, with a minimum of 4 years and a maximum of 33 years. The majority of participants (n = 25) possessed profound professional experience of 10 or more years. Due to the explorative nature of the study, participants mainly comprise “normal” designers to obtain insights from everyday business. Five participants, however, were specifically selected as they were or had been involved in developing and introducing function modelling across disciplines in their respective companies, which granted deeper insight. Table 4 illustrates the particular backgrounds and professional experiences of the participants (affiliation to individual companies has been omitted for confidentiality reasons).

Table 4 Overview of participants’ backgrounds and professional experiences

3.2 Data collection and analysis

Native languages of participants comprise Dutch, French, German, Italian, and Luxembourgish. Interviews were conducted in English or German. A brief preparatory discussion with a selected participant in each company (either a project manager or key designer) was used to obtain an overview of the developed system, design context, and typically applied design steps. The main interview study included all participants individually. The question catalogue that was used for guidance comprises 29 open-ended questions developed to answer Research Questions 1–9. Participants were encouraged to refer to both ongoing and past design projects that they had been involved in interviews were recorded whenever possible, but was not permitted in one company; in addition, the interviewer took notes. Provided paper sheets could be used by the participants or the interviewer for note-taking or sketching, respectively. Participants were asked to bring their laptops to the interview, in order to be able to show examples of used models. Interviews were typically conducted at the site of the company and in one case via telephone. The majority of interviews lasted between 60 and 90 min.

Analysis of the collected data started with the transcription of the collected audio recordings and notes taken. Answers from each participant were labelled in the transcripts according to which of the Research Questions they address. The given answers were analysed individually and across different interviews, in order to determine any types of concepts, themes, and opinions addressed by the participants. These were subsequently used to derive distinct categories for coding the answers, whenever sensible. Categories were formed based on the researcher’s interpretation of the answers.

4 Findings

In the following, Research Questions 1–9 are successively addressed in Sects. 4.1–4.9. As the findings are rather rich, some of the results for each research question are already complemented by an initial discussion section. Section 5 aggregates and discusses the main insights.

4.1 What are different notions of function addressed by designers in the visited companies?

Research Question 1 intends to explore different notions of function that can be found in interdisciplinary design practice. Answers from 33 participants could be evaluated. These range from rather formal definitions by 11 participants to four participants who used examples only to explain what they regarded a typical function. The remaining participants (n = 18) gave informal definitions, wherein they circumscribed their understanding of function. Table 5 presents a few exemplary quotes (Q) of formal and informal definitions provided.

Table 5 Examples of provided formal and informal definitions

Ten participants seemed to have difficulties answering the question. A few of them noticeably struggled finding the right words. One participant explicitly said that function can have different meanings depending on the particular context it is used in, thus making it difficult for him to provide an adequate definition.

Nine distinctly different notions of function could be identified from the given answers (see Table 6); four are particularly prominent and were addressed by numerous participants, whereas the remaining five notions were addressed only by single participants each. Which particular notion of function was addressed was not found to be specific to the participants’ disciplinary backgrounds.

Table 6 Notions of function provided by the interviewees

Overall, a majority of 20 participants described an understanding of function directly related to the notion of behaviour (see Fig. 1), which includes the notions of intended behaviour and perceivable behaviour. However, most participants (n = 12) did not differentiate between the two (n = 9) or addressed intended and perceivable behaviour in parallel (n = 3, see, e.g. Q1 in Table 5).

Fig. 1

Notions of function addressed in the provided answers from the participants

Six participants explicitly differentiated between alternative meanings of the term function depending on the situation it is used in. This concerns, on the one hand, hierarchical levels (n = 3), as well as, on the other hand, whether the concerned system is already existing or not (n = 3):

• Regarding the former, participants differentiated between “high-level” and “low-level” functions: For high-level functions, the notions of purpose (n = 2) or intended behaviour (n = 1) were used, respectively; for low-level functions, the notions of input/output relation (n = 2) or capabilities to show behaviour (n = 1) were addressed.

• An example of the latter can be found in Q2 (see Table 5), for instance, wherein functions are divided into “virtual” and “real” functions. Virtual functions refer to intended behaviour, whereas real functions refer to perceivable behaviour.

This case dependency concerning which notion of function is addressed is indicated in Fig. 1 by using different colours: red refers to notions of function which were case-independently addressed; green refers to those, which are case-dependently addressed by the six participants.

Discussion

Many participants were quite conscious about potential ambiguities of function as an abstract concept. The presented findings support the initial insights discussed in Sects. 2.1 and 2.4: Different notions of function indeed seem to exist side by side in practice, irrespective of particular disciplines. The four most prominent definitions, function as related to purpose, capacity to show behaviour, input/out relation, and behaviour, closely correspond to the archetypical notions of function proposed by Vermaas (see Sect. 2.1). Notions of function addressed only by single participants may be specific to the respective person’s field of work. The notion of function as related to the amount of selectable options for a system (see Table 6), for instance, was expressed by a product manager who has to decide which (new) functions will be implemented in a system to be developed and which will not. Similarly, the notion of function as features of the system that deliver value was addressed by a service designer who is responsible for calculating service-added value for the technical products designed and manufactured in the company he was working for.

Overall, the notion of function as related to behaviour was found to be the most central. Following the discussion in Sect. 2.1, it can be argued that the notion of function as input/output relation is in fact only a more abstract view on behaviour. In the light of these considerations, it can be concluded that 24 out of the total of 33 participants addressed notions of function which are directly related to a system’s (expected or perceivable) behaviour. Owing to this centrality, this notion of function might be suitable for establishing a common basis for the discussions about function in practice. This does not rectify the idea of different notions of function to exist side by side. It still will be useful for the individual designers to mentally explore functions of a system to be designed more flexibly as promoted by Vermaas and others (see Sect. 2.1). Also, the missing distinction between expected and perceivable behaviour in practice is to be noted, as it opposes more rigorous theoretical considerations by Ullman (2010) and others. Yet, the obtained insight suggests that it can be sensible as a vantage or reference point for joint discussion, respectively, seeing that most participants have a similar notion in their minds.

4.2 Which models are used for modelling functions and system functionality?

Participants were asked for examples of used function models (this section) as well as to explain their specific utilisation in a typical design project (which is described in Sect. 4.3). Participants referred to a total of 24 function models that they apply (see Table 7). Fourteen of these directly originate from or are adapted from established models from textbooks. Eight of the function models found in industry can be considered new models, which were developed in-house in different companies. Four of them are exemplarily presented in the following.

Table 7 Found function models

An example of an in-house developed function model is the so-called Function Cycle Breakdown (see Fig. 2). It is typically used as a reference model for different designers in Company J and, in particular, by software developers for design and parameterisation of the required control software system. It represents the sequence of specific functions (1 to n) in relation to the quantitative flow in time using a similar structure as a Gantt chart (see Gantt 1910).

Fig. 2

Schema of “Function Cycle Breakdown”

An example of a model addressing specific aspects of functionality in service development is the “Service Process Model” (see Fig. 3). Therein, service activities are sequentially modelled in the middle column. Each represented activity is complemented with information about involved technical means supporting service execution (such as telephone and software data storage) as well as involved stakeholders (such as the customer and the servicing staff). The model is typically generated during design of a service and used as a reference model later on during service execution.

Fig. 3

Example of “Service Process model” from Company J (excerpt)

A particularly prominent example of a function model used in the companies is a Function Flow Chart. Therein, functions are modelled related to their qualitative flow in time (sequential or parallel). A schema of a Function Flow Chart found in Company H is presented in Fig. 4. The model corresponds to a large extent, for instance, to use case activity flow diagrams used in software development or systems engineering (see, e.g. Kruchten 2004 or Weilkiens 2008). Similar models were found in six out of the ten visited companies. A more comprehensive version of such a flow model is Grafcet (see, e.g. VDE 2004) which illustrates the sequence of different technical processes and state changes. Grafcet is used in Companies A and B for modelling functions that are to be implemented through programming Programmable Logic Controllers (PLCs).

Fig. 4

Schema of a function flow chart

A particularly interesting example of a function model that was developed in one of the visited companies is the “Allocation Matrix” (see Fig. 5). The model uses a matrix representation for making explicit which sub-systems, alone or in combination with others, are foreseen for implementing the different functions that the system is expected to fulfil. In the application, the main system functions are derived from the requirements list and are subsequently decomposed into sub-functions. These are then allocated to the concrete sub-systems that are contributing to their fulfilment (indicated with an “X” in the figure). The model is intended to serve as a reference model on system level in Company E. Similar models were also used in Company F and elaborated for future application in Company H.

Fig. 5

Schema of “Allocation Matrix”

4.3 How are these models typically applied during conceptual design in the companies?

Two central factors were found to strongly influence the application of the function models in the companies: the level of participation in function modelling and the specific purposes it serves (individual) designers. These are elaborated on in the following sections.

4.3.1 Level of participation

Different levels of participation are derived from the typical involvement of designers in the generation and application of function models. Essentially, four distinct levels can be distinguished:

• Level 1—personal function modelling refers to function modelling by a single designer; the generated function model is not shared with others.

• Level 2—function modelling within one discipline typically involves modelling functions related to discipline-specific sub-systems. It may be performed collaboratively or individually by (a) designer(s) within a discipline and is shared within this discipline only.

• Level 3—function modelling between selected disciplines typically involves modelling functions in relation to sub-systems that involve two or more disciplines in their development. It is typically performed collaboratively by designers from the involved disciplines.

• Level 4—system-level function modelling involves modelling individual functions and/or overall functionality of a system including all relevant disciplines. It is typically performed collaboratively by system-level designers and/or key designers from the disciplines.

Four of the referenced function models were found to be applied on different levels of participation in different companies (n = 5, see also Sect. 4.5).

4.3.2 Different purposes for applying function models

Found function models usually serve one or more of the following purposes:

• Support the solution finding process Function models are used to support designers’ reasoning towards a potential solution, i.e. exploring and determining required functions and their mutual dependencies as well as analysing functionality provided by any already known solution elements, in order to select and design new elements appropriately.

• Support specification of sub-system requirements Function models are used to determine and make explicit which functions (and requirements) will be realised by which specific solution element(s), as already discussed in relation to Fig. 5. Based on a comprehensive model on system level, subsequently, sub-system requirements can be derived, including information about their mutual interfaces and eventual constraints. These specifications are then used to guide the separate development of each individual sub-system.

• Documentation of solution finding process Overall, conceptual design tends to cascade from requirements to required functions to determining solution elements (see Fig. 6). Some participants saw function modelling (pertaining to process or quality management) as a means for tracing the different performed steps in this process.

  Fig. 6

  

  Function modelling on different levels of participation during conceptual design; the scheme illustrates the most detailed flow found in Company F, other companies would use simpler variants, e.g. missing function modelling on level 4 of participation

• Consultation only Some participants explained that they would only use some of the existing function models to retrieve a specific piece of information which was required in another modelling or design step; they would not be involved in generating the concerned function models or be using them for any other purpose.

4.3.3 Application of function modelling in the course of the conceptual design stage

The concrete design and modelling steps used during conceptual design are specific for each visited company. However, some general steps could be identified as a recurring pattern. The starting point usually is a kind of requirements specification, typically a list. The design and modelling steps performed based on such a specification can be differentiated in the phases of system-level design and disciplinary design (see Fig. 6); therein

• system-level design encompasses determining an initial system structure and allocating requirements and functions to the specific sub-systems foreseen for their implementation;

• disciplinary design encompasses determining the solution concepts for each sub-system to be developed within the, respectively, responsible discipline(s).

Participants portrayed conceptual design to be progressing from general to concrete, i.e. moving from top to bottom in Fig. 6 in a usually highly iterative manner. In three companies, function modelling is applied already during system-level design; in six companies, it was only applied during disciplinary design; finally, one company (Company G) did not apply any function models.

During system-level design, in six companies, in an initial step, the specified requirements are sorted into functional and non-functional requirements, the first specifying expected and measurable behaviour, the latter focusing on specific constraints and target values (e.g. regarding performance, durability, and geometry), respectively. One expressed reason for this sorting step is to build an initial comprehension of the functionality expected from the system and to support subsequent function modelling. In the next step, requirements are allocated to the prospective sub-systems that they concern. The decomposition into sub-systems initially used in this step is usually taken from an already existing system structure.³ In the companies that use function modelling already during system-level design, this allocation step is explicitly facilitated using the generated system-level function models. System-level function modelling is performed on level 4 of participation (in Companies H and F) or level 3 (in Company E, see also Table 8). Based on these system-level function models, separate partial requirements specifications for (selected) sub-systems can be generated, as described before.

Table 8 Use of function models and types of design described in the companies

Disciplinary design focuses on determining solution concepts for individual sub-systems. In eight companies, a limited number of disciplines use a shared function model (level 3) to support joint solution finding. In most cases, this involves system-level designers, electrical engineering, software development, and also service development (if applicable). Mechanical engineering is rarely involved in level 3 function modelling in the visited companies. Discipline-specific conceptual design mostly involves function models either shared within one discipline (level 2) and/or personally used by individual designers (level 1). In this phase, disciplines may be working in parallel (n = 7 companies) or sequentially (n = 2); in one company, two disciplines were found to work parallel, whereas the other disciplines work sequentially. Table 8 collocates the discussed findings. In the table, companies are ordered from top to bottom according to the level of participation found.

Both phases typically involve further models addressing the solution, such as system structures and CAD data, which is gradually detailed. In seven companies, single disciplines do not use function models on a regular basis. In all but one case, this concerns mechanical engineering (see also Sect. 4.6).

Discussion

The applied development process and the particular use of certain function models during the conceptual design stage is largely dependent on the specific company and on the disciplines involved. Mechanical engineers were found to be using function models considerably less often than other disciplines. The differences also surface in terms of the level of participation of different disciplines in the generation and application of function models. At the same time, the level of participation on which function models are used seems corresponding to the specific purpose for which they are applied. This can be seen with respect to system-level function models (level 4 of participation): these mainly serve the purpose of supporting the allocation process of requirements and functions to the solution elements/sub-systems foreseen for their implementation. As can be expected, they are then developed involving less disciplines; that is to say, predominantly those that are responsible for them.

4.4 Which function modelling perspectives are prominently addressed in the function models applied by different disciplines in the companies?

This section presents the analysis of the used function models in relation to which function modelling perspectives and modelling morphologies they address. The analysis is based on examples or schemas of function models applied in the companies. These were either provided as printouts or sketched on paper during the interviews. For two out of the total of 24 applied models, no examples were disclosed to the researchers, which prevents detailed analysis. The remaining 22 function models were analysed and categorised by the researcher according to which specific modelling perspectives they address (i.e. which specific contents they represent, see Table 2) and how the represented information is structured (i.e. the morphologies used). Table 9 aggregates the results for each discipline. The allocation of models to disciplines was based on how the models were described to be used and who is predominantly involved in its creation (see also Tables 10 and 11 in the following section).

Table 9 Overview of function modelling perspectives and modelling morphologies prominent in the different disciplines and on system level

Table 10 Function models used on level 3 and level 4 of participation

Table 11 Function models used on level 1 and level 2 of participation

A particularly striking finding is the predominance of time flow-oriented representations of functions as transformation processes. Similar to the previously discussed literature review, transformation processes are by far the most prominent modelling perspective. Therein, mechanical engineering and electrical engineering focus on technical processes, whereas service development focuses on human processes. In software development, both types can be found and, depending on the specific disciplines involved, system-level function models address either technical processes or human processes or both. Overall, out of the total of 22 evaluated function models, 16 are based on a flow in time. Four function models were found to structure their representation of functions hierarchically and only in two models used in practice flows of operands are used. Overall, the particular application of the function models varies considerably between individual designers (using the same models) and the particular task at hand. This is not particularly surprising seeing that every design project entails unique challenges.

Another interesting finding concerns the effects perspective, which was only addressed in a single model, the Function Parameter Model, used in Company F. This specific model is used for detailed analysis of inputs and outputs of single functions, including impacts (can be as concrete as physiochemical effects) from the environment.

All contents and morphologies found in the literature (see Sect. 2.2) were also addressed in the models from practice. A novel addition to the contents found in textbooks are bilateral impacts and dependencies between solution elements, which were included as textual descriptions in two function models (Companies E and F). This addition is particularly interesting as it indicates needs of designers in practice that are not covered in function models from textbooks. Bilateral impacts specify the mutual exchanges between interacting solution elements (e.g. “send 12 Volts signal from A to B”), which are usually addressed in system structures or interface documentation, rather than function modelling.

Discussion

The findings strongly suggest that representations of functions as flows of processes in time are predominant in the companies. Considering that this coincides with the analysis of function models from literature, it seems this could serve as a reasonable starting point for the development of a support for interdisciplinary function modelling. The found wide negligence of the effects perspective is interesting as it is conversely addressed in numerous function models in the literature. A reason for this difference may be the limited application of classical function models from mechanical engineering (or adaptions of them) in the companies. These models mainly address the effect perspective (see Eisenbart et al. 2013a as well as Sects. 2.2 and 3.2.3). Overall, still, different combinations of all identified function modelling perspectives are addressed in the models applied in the companies and each function modelling perspectives and morphology is addressed by at least one function model found in practice. None of the function models used in the companies addresses all of these though. Ultimately, the described analysis supports the earlier discussions in Sect. 2.5, suggesting that integrated function modelling should be developed in a way which allows linking or combining all modelling perspectives, additional contents found and information about their interrelations (which are conveyed in the modelling morphologies). That way, it could accommodate for the diversity in what is needed by different designers in different design contexts.

4.5 What kind of experiences have been made with the different function models?

Participants were asked to describe and assess their experiences with utilising different function models, regarding

• the actual modelling in (interdisciplinary) design;

• as well as exchanging information with colleagues within or across disciplines (if applicable).

Thirty-two participants provided comprehensive descriptions and assessments of the applied function models, which could be analysed and coded. Coding comprises “+” for a positive, “0” for a neutral, and “–“for a negative assessment by the participants.⁴ Tables 10 and 11 collocate the categorisation for the referenced function models including the level of participation in the corresponding companies and disciplines.

The majority of function models applied in the companies (n = 17) is mainly used by the designers for the purpose of facilitating the solution finding process. This applies to designers from all disciplines, however, considerably less often to designers in mechanical engineering. Only a single mechanical engineer stated to use function modelling for this particular purpose (see Table 9). Other mechanical engineers were found to search function models for specific information (i.e. consultation only) if this information is required somewhere else. A similar pattern was not found in the other disciplines.

Participants reported on numerous strengths and weaknesses of the used models, which could be allocated in different categories discussed in the following. Overall, the majority of participants assessed the application of the used function models positively, and all participants who use function models regularly described them to be beneficial regarding the exchange of information with colleagues (across disciplines). Only in very few cases, participants said they experienced specific problems.

Expressed strengths cover the aspects of traceability, comprehension of the system context, and supporting collaboration:

• Traceability Here, traceability refers to making explicit which functions will be implemented by which solution element(s). It is enhanced by clearly graphically visualising the allocation of functions to specific sub-systems foreseen for their implementation (as already discussed in relation to the Allocation Matrix, see Fig. 5). It was described to be a central contributor to illustrating and clarifying functional dependencies between sub-systems.

• Comprehension of the system context Use case modelling is applied in three companies. All relevant participants described it to substantially support thoroughly understanding the system context, i.e. identifying peripheral technical (sub-)systems and stakeholders (such as users) as well as their interactions with the system under development.

• Support of (cross-disciplinary) collaboration Being aware of the links and dependencies between the system under consideration and its surrounding, as well as dependencies among its sub-systems, was described to support collaboration both within and across disciplines. This refers to being aware of potential effects of introduced design changes across functionally dependent sub-systems as well as of which departments are involved in the development.

One participant explained for a model similar to the Allocation Matrix (see Fig. 5) that (Q5) “the [model] forces you to deal with the [entire] system […]. Now you know much better who else is involved […] and who you need to talk to. […] The comprehension of the system has improved. […] If we get a new employee, e.g. fresh from the university, and want him to quickly understand the system we develop, we give him [this model]. It is the best way to quickly learn how the systems functions.”

Expressed weaknesses of used function models cover the issues of complexity and miscomprehension:

• Complexity Model complexity mainly refers to lengthy or not clearly structured models which were described to be hard to read and comprehend by a few participants, such problems were mentioned for the system function specification (Company F) and IDEF-0 (Company C).

• Miscomprehension Six participants from three companies (two large, one small) further expressed difficulties originating from miscomprehension of specific functions due to the way these were formulated in a model. Participants claimed that such difficulties resulted in additional efforts required for clarification of specific formulations and—in a few cases—even in design errors causing delays in a project.

In order to address the issue of miscomprehension, specific guidelines and in one case special training for the designers were introduced in the two large companies. These were aimed at enhancing the intelligibility of formulations in generated models to all involved designers. Participants from both companies claimed these measures to have helped reducing the problems to a certain extent (see also Sect. 4.7). Although miscomprehensions also occur in small companies, they were not necessarily considered a critical problem. Albeit they may cause irritation, the respective participants claimed they can usually clarify any miscomprehensions quickly through personal contact with their colleagues. By nature, this does not work as seamlessly in larger companies. From a risk management point of view, however, it is certainly preferable to avoid miscomprehensions entirely.

Discussion

Function modelling is typically proposed in the literature in order to support designers in the reasoning process towards a potential solution. The findings suggest that this is also the main reason for applying specific function models in the participating companies during disciplinary design. The models utilised for this purpose were assessed predominantly positively. A potential explanation for the positive assessments could be that only those function models have prevailed in the companies which can be conveniently applied and/or provide a benefit to the designers. In other words, people tend to use what they like to use.

On system level, function models are mainly used with the purpose of supporting the derivation and specification of sub-system requirements (see also Fig. 6). For these function models, the aspect of traceability between functions and solution elements was highlighted as a particular strength. Another benefit is the support of obtaining a thorough comprehension of the system under consideration, particularly regarding its context as well as involved sub-systems and their mutual dependencies in function fulfilment. These two aspects, traceability and an increased system comprehension, were expressed to provide a substantial benefit when it comes to supporting (cross-disciplinary) communication. The findings further suggest that, particularly in the large companies, something as simple as making explicit who to talk to regarding a specific sub-system can provide considerable support leading to a reduction of design errors and of iterations in the process.

Regarding the issue of miscomprehensions, it is to be noted that none of the companies used specific function taxonomies or similar approaches that were described briefly in Sect. 2.3, despite their large potential in supporting clarity and thus intelligibility of models. As will be discussed further in Sect. 4.7, the two companies that introduced the mentioned supporting measures tried to implement more formal modelling but met particular challenges. The eventually introduced guidelines are derivatives of extant formal approaches that had been adapted to ease practical application. They decreased issues of miscomprehension, yet some problems remained.

4.6 Which other function models are known but currently not used?

Participants were asked for any function models that they know but do not utilise and, if applicable, to explain their reasons for not using them. Twenty-four participants provided answers to this question referring to either specific function models (8 models, 11 participants) or to general types of function models (16 participants). Regarding the latter, participants would say, for instance, “such models like the one from VDI 2221.” The provided reasons can be distinguished in two groups:

• Group 1: Function model not considered useful, comprising

  • model considered to be too abstract,

  • model not considered to provide benefit,

  • solution concept is already known,

  • lack of time.

• Group 2: Function model considered less suitable compared to others, comprising

  • specific function model considered more complex than required,

  • other function models are considered better suited.

Table 12 shows the referenced function models included in the analysis with the specific reasons expressed by participants. In addition, Fig. 7 aggregates the findings with regard to whether the driving reasons provided by participants from the individual disciplines belong to Group 1 or 2.

Table 12 Known but not used function models

Fig. 7

Driving reasons (from Group 1 or 2) provided by participants from different disciplines

The reasons pertaining to Group 1 suggest a certain general reluctance of the respective participants to perform function modelling rather than an aversion against (a) specific model(s). These reasons were often expressed in combination. A mechanical engineer, for instance, explained (Q6) “these models are not used because the problem is usually essentially known, as is the decomposition into sub-systems with their respective central functions. […] You usually also don’t have the time to explore functions and solutions again.[…] It is in principle a nice idea but you usually lack time and then you […] already have some solution ideas and one does not see an additional benefit in moving back […]. Also, it can be difficult to [detach oneself] from an already known concept.” Difficulties with mentally detaching oneself were mentioned by four more participants. The argument seems closely related to remarks about specific function models being too abstract. One specific aspect that was criticised in this regard (n = 6 participants) is that many function models (particularly from mechanical engineering) often do not directly refer to a specific solution. Instead, an abstract, solution-neutral description of functions is requested (as discussed in Sect. 2.4). Participants criticised this characteristic as it is considered not to be leading towards a solution but in fact to be leading away from it.

Reasons comprised in Group 2, in contrast, suggest a more or less explicit, conscious decision against a specific function model. For instance, a designer typically involved in electrical engineering and software development in Company B explained concerning Petri Nets (Baumgarten 1996) that for (Q7) “the cyclic machining processes in a [Programmable Logic Controller], sequential models and representations […] are simply much closer to the concrete implementation. Something like [Petri Nets] simply doesn’t lend itself so much for this.” He uses Grafcet instead. Participants not using a specific model due to expected modelling efforts and complexity were primarily interested in a general overview of the expected functionality with few details. They mainly preferred (hierarchical) lists (n = 2 participants) or simple flow models (n = 4) over other function models they knew.

Discussion

Models rejected by some participants are still considered beneficial by others. For instance, finite state machines, morphological charts, or use case modelling, which are rejected by some of the participants (see Table 12), are applied and considered very beneficial by participants in other companies (in one case even in the same company, see Table 10). The concrete benefit that a specific model provides to a designers thus seems depending on the individual’s preferences and/or the context in which it is applied.

One aspect suggested in the findings is very noteworthy: 12 out of the 13 participants who do not use specific function models because of reasons belonging to Group 1 are either currently working in (n = 5) or have an educational background in (n = 7) mechanical engineering, respectively. The remaining participant is a senior software designer who mainly performs incremental adaptation of the existing software code with limited conceptual changes. The fact that participants consider function modelling to be some type of detour which diverts from an already existing idea of a potential solution was similarly found by Blessing and Upton (1997) in relation to function modelling after Pahl et al. (2007, see Sect. 2.4). These findings further substantiate research discussed in Sect. 2.3 (see, e.g. Aurisicchio et al. 2012), indicating that mechanical engineering designers tend to use function modelling much less compared to other disciplines and that they also have a relatively high inhibition threshold towards applying it. The findings further support Wallace (2011) and Tomiyama et al. (2013) saying that the underlying reason might be the limited, directly apparent benefit from using function models. The respective participants in the study presented here reported to not see added benefit in exploring the solution space in more detail particularly considering the shortage of time in typical design projects. It is interesting to see that other interviewees who collaborate with mechanical engineering see a lot of benefit. Maybe this can be a vantage point in the future to advance function modelling in mechanical engineering practice as well, given that interdisciplinary collaboration is becoming more and more vital. Concerted support for shared modelling is expected to be crucial to facilitate this process. In addition, the potential benefits need to be made more salient, probably already during university education.

4.7 What kinds of changes occurred if a new function model/modelling approach was introduced in the companies?

To address Research Question 7, participants were asked to describe the specific motivations and changes achieved by the introduction of (a) new function model(s) in a company (if applicable). Six companies had newly introduced function modelling across disciplines prior to the conducted study. In all six companies, the main motivation for implementing function modelling across disciplines stemmed from an increasing demand for integration of solutions developed in different departments. However, the particular purposes the companies had in mind for shared function modelling vary. Essentially, three different cases can be distinguished:

• Case 1—Supporting joint exploration of functions and solutions (Companies C and I)

  Introduced model: the concept of morphological charts (see Zwicky 1989) was applied (though without necessarily drawing up an actual matrix at all times) to a few central functions of selected sub-systems (in both companies on level 3 of participation).

• Case 2—Supporting function exploration and specification of the system context (Companies D and H)

  Introduced models: use case descriptions in combination with use case flow models (Company D, on level 2); use case schematics (Company H, on level 3).

• Case 3—Building a shared reference model (Companies E and F)

  Introduced models: “Function database” (Company E, on level 3); “System Function Specification” (Company F, on level 4).

In all three cases, introduction of new function models had been lanced by system-level design, electrical engineering, and/or software development, respectively. Experiences were shared by multiple participants in each of the six companies. From their descriptions, a set of additional aims for the introduction of new function models can be discerned:

• exploring and making explicit central aspects of system functionality across disciplines (Companies C, H, and I);

• establishing a more systematic approach during conceptual design (Companies C, D, and I);

• facilitating joint exploration and discussion of alternative solution concepts between involved disciplines and/or individual designers (Companies C, D, I, and H);

• exploring and making explicit context-related information, such as users and peripheral technical systems, and their respective interactions with the system under consideration (Companies D and H);

• supporting traceability of information related to functions and solutions (Companies E and F).

The aspect of traceability is particularly interesting. It includes top–down traceability (i.e. reproducible allocation of requirements and functions to the specific solution elements that—alone or in combination with others—contribute to function and requirements fulfilment) and bottom–up traceability (i.e. consistent specification of the interactions between solution elements to enable tracing effects of eventual changes made to one solution element to interfacing ones and to the fulfilment of functions they are involved in).

In all companies, the participants considered the introduction of the function models to have had positive effects on the collaboration between involved designers as well as the design process in general. In particular,

• despite initial reservations by a few designers, the conceptual design stage was described to have become more systematic (all companies) and more traceable (both top–down and bottom–up) making it easier to identify eventual incompatibilities between sub-systems early (mainly Case 3);

• introduction of use case modelling in Case 2 and the shared reference models in Case 3 were expressed to have improved the comprehension of the system and its context significantly;

• this improved comprehension, in addition, was found to considerably facilitate collaboration between designers as these now know who to talk to and are more aware of relevant interdependencies between all the elements in the system (mainly Case 3).

Establishing traceability of information is considered a key element in facilitating system comprehension. It was voiced as an aim primarily in the two large companies in Case 3; this, again, is comprehensible given that the size of the company and the complexity of the product entail particular challenges to design and quality management. A strategic manager from Company F claimed that the achieved improvements resulted in a considerable decrease in iterations during the design process because the amount of design errors is reduced significantly. This led to a reduction in the required development time for some highly interdisciplinary sub-systems by up to 30%. Company E similarly reported on a reduction in development time and design errors. Though this was not further quantified, Case 3 provides strong indications for the benefit of using shared function modelling in interdisciplinary design.

During the discussions, the main responsible manager from Company F revealed that they initially tried to have the designers use function taxonomies, based on approaches such as the functional basis by Stone and Wood (2000). This endeavour, however, was not continued, because many engineers refused to use them company-wide claiming that it was too abstract. They criticised that, in parts, the new formulations were perceived less comprehensible than formulations in natural language that they were used to, e.g. from requirements specifications. Company F then launched an iterative adaptation effort to compromise between formal and more natural formulations in function modelling. Company E, conversely, had contacted a consultancy to help them from early on with the issue of comprehensible function formulations. Interestingly, both companies independently, in the end, had similar measures in place to address the problem. Firstly, a clear definition of function was introduced for all designers to use. Again, independently from each other, the companies now use very similar definitions, which correspond to the “intended or already perceivable behaviour of a system” (see Sect. 4.1). In addition, designers are instructed to always formulate functions as if the particular behaviour was observed from an uninvolved on-looker. To give a fictive example, the main function of an automatic garage door would have to be formulated as “door opens when activated”. Finally, the designers were provided with training (particularly in Company F) and a set of guidelines (both companies) that they were asked to consult when creating functional descriptions. Participants from both companies claimed that these measures had helped reducing difficulties with miscomprehensions noticeably.

Discussion

The findings suggest that function modelling can provide companies with considerable support during the conceptual design stage, both regarding systematisation of design and modelling activities and supporting collaboration among involved designers within and across disciplines. The latter was mainly due to an increased comprehension of the system, its context (see Case 2), and in particular the establishment of traceability between functions and solution elements (see Case 3). These benefits were already briefly discussed in relation to the Allocation Matrix (see Fig. 5) as well as considering the particular strengths of similar models in Sect. 4.5. Ultimately, these findings strongly support the initial assumption that function modelling can foster a shared understanding among collaborating designers and eventually facilitate (cross-disciplinary) collaboration (see Sect. 1). Furthermore, the experiences made by Companies E and F support the earlier discussions that there is a gap between industrial practice (at least in the relevant companies in this study) and the rigour that function modelling proposed in the literature demands. This appears to translate particularly into the application of function taxonomies. Some designers seem to struggle to transfer information from natural language into formal expressions. Thorough training early during education might help to overcome this issue. Yet, the implemented compromise, i.e. training and guidelines, used in the two relevant companies already provides considerable support and might be inspirational for other companies as well.

4.8 What kind of (abstract) representation/visualisation of functions is preferred by the participants?

A total of 26 participants reported on their personal preferences regarding the representation/visualisation of function. Five answers could not be evaluated and were excluded. Seven participants referred to two (n = 5) or more (n = 2) ways of representing functions. Three participants explained not to have a specific preference, while two more explicitly asked not to be limited to one specific type of representation. Instead, the two preferred to be able to choose any type of representations they considered useful in a specific situation or to combine them flexibly, e.g. on a piece of paper.

From the provided answers, five preferred types of representations of functions can be distinguished (see Fig. 8): time flow-related representations, (hierarchical) lists, brief textual descriptions, matrices, and block diagrams. Time flow-related representations include sequence diagrams, flow charts, and Gantt charts (see, e.g. Fig. 2). Brief textual descriptions cover concise statements, e.g. using lists. Block diagrams refers to block representations using input/out relations. Expressed preferences were not found to be specific to the participants’ disciplinary backgrounds. The findings support the predominance of time flow-oriented representations of functions that was already suggested in the analysis of the function models that are currently used in the companies (see Sect. 4.4).

Fig. 8

Preferred representation of functions (n = 21)

4.9 What kind of support related to (interdisciplinary) function modelling is needed or considered useful by the participants?

Finally, participants were asked for the specific support they needed or would consider useful for (interdisciplinary) function modelling. Thirty-two participants provided answers that could be used to address this question. Seven participants expressed no need for further support. The remaining answers suggest several desired improvements of current function modelling practices as well as the (further) facilitation of interdisciplinary function modelling in the future. The desired support can essentially be distinguished in three groups:

• 1. Foster comprehensiveness of function modelling:

  • (a) introduction of an overall function model including all disciplines,

  • (b) establish top–down traceability and

  • (c) bottom–up traceability between functions and solution elements,

  • (d) linking function models with models from later design stages (e.g. CAD models and behaviour simulation);

• 2. Improve consistency of modelled content:

  • (a) support consistency of contents across different models,

  • (b) improve completeness of the generated function models;

• 3. Managing modelling efforts:

  • (a) support determining the adequate level of detail in function modelling,

  • (b) support delimitating the modelling scope.⁵

The distribution of which specific support was considered useful by designers in different companies is provided in Fig. 9. Therein, participants are differentiated between whether they come from a company already using cross-disciplinary function modelling or not. The first group is further differentiated into participants from companies already using a function model shared between all disciplines (level 4 of participation) or shared between selected disciplines only (level 3). As one can expect, aspects that are related to advancing system-level function modelling as such are more prominent in companies that are not fairly advanced in this matter yet. Conversely, an issue like linking function modelling with models from later design stages is suggested in companies that already have established system-level function modelling to begin with. Participants from four companies (currently using level 2 and 3 function modelling) expressed the desire to advance to a generally shared function model (i.e. level 4). The motivations they gave include

Fig. 9

Support considered useful in different companies

• supporting systematisation of the design process,

• facilitating a more thorough exploration of the solution space,

• and advancing integration of different disciplines in the early design stages.

In contrast, three other companies currently using level 3 function modelling expressed no desire for further advancing function modelling; participants seemed content with the current practices.

Discussion

The findings suggest that cross-disciplinary function modelling is generally widely desired in the visited companies. Out of the ten companies, six either already have introduced function modelling including all involved disciplines (n = 2) or expressed the desire to do so (n = 4). The expressed reasons correspond with those from the three cases described in Sect. 4.7, which led some companies to introduce new models already. The experiences from these cases suggest that the specific benefits expected from introducing shared function modelling can indeed be attained. As will be discussed in the next section, this has a few rather important implications.

In the three companies that did not express a desire for further integration of disciplines in function modelling (Companies A, B, and J), discipline-specific design is performed either sequentially or partly sequentially (see Table 8). A potential explanation why no desire for further integration in function modelling was expressed could thus be that consecutively involved disciplines can use the generated product models from preceding disciplines. Because such concrete information is then already available to the next designers, the need for shared abstract function modelling is reduced.

Again, the issue of traceability was mentioned. Here, it particularly referred to making relations between functions and solution elements explicit. Interestingly, three companies (E, F, and H) independently referred to matrix representations (similar to Fig. 7) as a promising option for achieving this goal based on the experiences they had made.

The findings further suggest a considerable desire for the support of consistency and completeness of modelled information. Consistency seems particularly important with respect to change management to avoid design errors (see also Sect. 4.6). Although Company F claims to have improved consistency substantially through the introduction of a function model on system level, participants still expressed a need for further support. A cause of these problems could be the current separation between models: system-level function models (if available), derived sub-system specifications, and function models on levels 2 and 3 of participation are currently widely disconnected in all the companies. Changes, therefore, have to be manually communicated each time. This disconnectedness poses a risk as some changes may be forgotten and not communicated properly.

The shortage of time in a typical design project requires the designers to work efficiently. Being able to focus on what is really needed in a design project would therefore be of large benefit and ought to be supported. Still, completeness and consistency of modelled information needs to be maintained. This tension field creates direct stimuli for future research.

5 Summary and discussion of the findings

5.1 Function and function reasoning in the companies

The conducted explorative interview study supports the observations of other scholars on the coexistence of different notions of function between which practitioners may switch (see Sect. 2.4). Deviant understandings of function as such, however, were not expressed to be a reason for difficulties in (cross-disciplinary) communication. Still, experiences in those companies that introduced a shared definition of function suggest that—while individual designers may still have different notions of function in their minds—having one shared definition to reference to during modelling or discussing with colleagues may reduce miscomprehensions. Particularly, the notion of function as intended or perceivable behaviour of a system seems already widely spread and may thus be suitable for this purpose.

Function modelling and reasoning during conceptual design in the visited companies is applied very flexibly and progresses iteratively from a requirements specification to different solution elements (see Sects. 4.3). This transition is typically facilitated by reusing an existing system structure as a starting point, which is gradually adapted towards the new requirements. In this process, practitioners evaluate function and requirements fulfilment by comparing the intended behaviour against the actual behaviour exhibited by the system (see Sect. 4.1). A similar pattern is described, for instance, in the function–behaviour–structure (FBS) framework after Gero (1990; Gero and Kannengiesser 2002) and similar approaches. It can therefore be argued that function modelling and system structural modelling should be linked to support this particular solution-oriented design approach and support the iterative synthesis and evaluation steps. At the same time, modelling the mutual impacts between selected solution elements as part of function modelling was found to support the overall system comprehension in relevant companies, thus further suggesting a combination of function and structural modelling to be valuable.

5.2 Interdisciplinary function modelling can support collaborative design

Experiences made in the studied companies (see particularly Sects. 4.5 and 4.7) suggest a large potential of shared function modelling to support cross-disciplinary, collaborative design. The suggested benefit is particularly high in large, distributed design teams working in parallel on complex design problems. The improvements achieved in the respective companies can be regarded a direct result of the reduction in inconsistencies between discipline-specific sub-systems and systematisation of the design process, but most importantly, the improved system comprehension enhancing collaboration between designers. The achieved improvements (particularly in Company F) are a strong indicator for the large potential of an adequate function modelling approach to improve interdisciplinary design in the early stages of system development. While the use or introduction of a shared function model cannot be seen as a guarantee for the improvement of cross-disciplinary collaboration, the claimed reduction of up to 30% in development time in one of the companies is particularly noteworthy and substantiates the potential that lies within supporting collaboration in the early design stages.

5.3 Further integration is expedient

The function models used on system level and those used within or between selected disciplines in the companies, thus far, were found to be widely disconnected from each other. The separation can be regarded as one of the main reasons for inconsistencies in their contents, which have repeatedly resulted in design errors and iterations in the design process. At the same time, used function models are often rather specific (despite the found predominance of process flows, see Sect. 4.4) in the involved disciplines. Finite state machines, function flow charts, or use case modelling, for instance, address fairly divergent sets of function modelling perspectives and are furthermore considerably different in their morphology. However, all of these are used and considered beneficial by some practitioners. This supports findings by Erden et al. (2008) and others that emphasise the diversity of function modelling applications. It further suggests that in order to facilitate integration in function modelling, an integrated function modelling approach should be able to allow consistent modelling from system level to (discipline-specific) sub-system level, and further ought to interlink or couple all found contents and morphologies. If this can be achieved, designers may be able to jointly contribute all the bits and pieces that are relevant to them and eventually arrive at a comprehensive function model of the system. In turn, this would then automatically link the information relevant to all involved designers.

5.4 Limitations

Limitations regarding the validity of the discussed results essentially concern the limited comparability between provided answers in semi-structured or guided interviews as well as a potential experimenter bias. Experimenter bias is an unintentional influence on an interviewee through the interviewer by implicitly communicating certain expectations regarding the answer to a posed question (Blessing and Chakrabarti 2009). To prevent or reduce experimenter bias, respectively, transcriptions were critically reviewed during data analysis and any potentially biased parts were strictly excluded; however, this was rarely necessary. Also, regarding both limitations, wherever sensible, provided answers from one participant were evaluated for consistency against answers from other participants from the same company. In addition, to verify specific issues, selected participants were contacted again after the interviews for clarification.

Another limiting factor is the sample size which prevents generalisation of the findings (see also Bender et al. 2002). The study is explorative and covers companies from a variety of market areas, all of which are involved in interdisciplinary system development. Recruitment of participants, data collection, and analysis consumed more time than was expected, which limited the realisable number of interviews and companies to be visited. However, the interviews provided very rich data. In the discussions, individual questions and answers could be extensively investigated, which conveyed compelling insights and eventually allowed a differentiated analysis of raised issues. Furthermore, central findings were independently found in different companies alike increasing the confidence in the discussed results and fostering the assumption that the findings may similarly apply to other companies involved in interdisciplinary system development.

6 Conclusions for integrated function modelling

This paper presents research into function modelling practices and the particular needs related to adequately supporting it in the development of interdisciplinary technical systems and/or PSS. The presented explorative interview study complements initial insights derived from the relevant literature with insights into the actual application of different function models in ten engineering companies. In contrast, the empirical studies briefly discussed in Sect. 2 that focus more on the acts of function modelling and reasoning, this article focuses on the utilisation of function models by individuals or in teams as a means to facilitate collaborative design work. The obtained findings suggest that different function models proposed in the literature or applied in the studied companies (by designers from different disciplines) are insufficiently interlinked, as they represent divergent sets of function modelling perspectives and use different modelling morphologies for structuring the represented information. Hence, a consistent exchange of information between designers is inadequately supported by these models and requires additional efforts. Shared reference models on system level, which were introduced in some companies, are capable of supporting the desired integration between disciplines noticeably. This is an essential finding as it supports the fundamental assumption this research is based on, namely that shared function modelling indeed can support interdisciplinary design. However, the system-level function models that were introduced in the visited companies were also found to cover only a rather limited set of modelling perspectives. As a consequence, specific function models remain to be used within the disciplines during sub-system development and these remain widely disconnected from one another.

Looking at the utilisation of function modelling in the companies, it seems it is performed in a highly flexible manner depending on the particular preferences of individual designers, the design task at hand, and the degree of novelty in a design project, i.e. it depends on how much can be reused from prior projects. While time flow-oriented representations of transformation and interaction processes may serve as a suitable basis in integrated function modelling, the discussed insights suggest that all other found modelling perspectives and morphologies will have to be coupled in an adaptable manner to support diverse application (see Sects. 2.2 and 4.4). In other words, designers require different combinations of the contents and the links between them found in the existing function models, which means that they need to be able to include or omit what is (not) needed in a specific situation. Apart from these fundamental considerations, further conclusions can be drawn regarding the specific characteristics and properties an integrated function modelling approach may need to possess to be capable of supporting cross-disciplinary conceptual design:

• Apart from the function modelling perspectives, all additional contents identified in the function models from the literature and used in the studied companies (see Sects. 2.2 and 4.4) should be integrated, particularly the bilateral impacts between solution elements; although this specific information is typically rather part of system structural modelling than function modelling, it was found very beneficial to facilitate traceability in modelling and system comprehension.

• An exceptional role applies to the effects perspective as it is only addressed in a single model found in one company facilitating the detailed analysis of individual functions (see Sect. 4.4); therefore, effects should be integrated in a way which particularly fosters function analysis.

• Designers need to be able to adapt modelled contents and the applied level of detail to the requirements of a design project in order to manage and delimitate modelling efforts (see Sects. 4.6 and 4.9).

Adequate implementation of all of these requirements poses a particular challenge to the development of an adequate support for interdisciplinary function modelling. These considerations suggest a new type of representation to be required which is able to address these issues (see also Sects. 4.8 and 4.9). Such a new representation might benefit from combining results from different research strands. Research on taxonomies and ontologies and research on flexible integrated function modelling approaches do not exclude each other. It is more likely that a combination of the research efforts in both areas might provide a vantage point for advancing function modelling. Standardised vocabulary, i.e. taxonomies, might contribute to reduce mental workload and variance in function models, thus miscommunication between designers, while integrated function modelling approaches increase consistency of modelling contents by enabling a reduction in the number partial function models created within a multidisciplinary design team. Succeeding in this endeavour may ultimately improve the designers’ understanding of function modelling and reasoning outside their own disciplines. Such an advancement of the available means to describe the contents and considerations in function modelling and the particular approaches associated with it, hence, may further positively influence collaboration in the early design stages. This would then ultimately be aspired to increase the general use of function modelling across disciplines in practice.