Research in Engineering Design (2022) 33:129–159

[Link]

ORIGINAL PAPER

What distinguishes a model of systems engineering from other

models of designing? An ontological, data‑driven analysis
Udo Kannengiesser1 · John S. Gero2

Received: 4 February 2021 / Revised: 7 December 2021 / Accepted: 13 December 2021 / Published online: 15 January 2022
© The Author(s) 2022

Abstract
This paper investigates how the core technical processes of the INCOSE model of systems engineering differ from other
models of designing used in the domains of mechanical engineering, software engineering and service design. The study
is based on fine-grained datasets produced using mappings of the different models onto the function-behaviour-structure
(FBS) ontology. By representing every model uniformly, the same statistical analyses can be carried out independently of
the domain of the model. Results of correspondence analysis, cumulative occurrence analysis and Markov model analysis
show that the INCOSE model differs from the other models in its increased emphasis on requirements and on behaviours
derived from structure, in the uniqueness of its verification and validation phases, and in some patterns related to the temporal
development and frequency distributions of FBS design issues.

Keywords Systems Engineering · Mechanical Engineering · Software Engineering · Service Design · Function-Behaviour-
Structure (FBS) Ontology

1 Introduction 2020): systemic and systematic thinking. Systemic thinking

is generally viewed as the opposite of reductionism: Rather
The analysis and design of systems, which are the subject than reducing a system into a set of components that are
of systems thinking and systems engineering, have a long studied in isolation, systemic thinking looks at the system
tradition in research and practice. More recently, this field of as a whole, in terms of the interactions of components and
science has gained renewed attention, driven by technologi- their emergent effects. This often leads to viewing a system
cal advances leading to complex, engineered systems such as a subsystem of a larger system, thus allowing to under-
as cyber-physical systems (CPS). Generally, the notion of a stand or explain it based on its role within that system. This
system is increasingly used when objects or processes are “bigger picture” can potentially reveal new insights, which
examined with respect to their interactions with other objects may open up new ways of framing analysis or design issues
or processes in their natural or socio-technical environment. for the system.
A system is viewed as a set of elements that interact in a Systematic thinking aims to break a complex issue down
way to realise a defined objective (von Bertalanffy 1968). A into smaller issues to be addressed in a methodical, stepwise
system may itself be an element of a larger system. Thus, a manner. In this respect, this type of thinking can be viewed
system may encompass several hierarchical levels. Systems as reductionist. On the other hand, in systematic thinking
composed of large numbers of hierarchical levels are com- the results obtained at the component level are integrated to
monly referred to as systems of systems (Maier 1998). form the overall solution to the original problem.
System hierarchies provide the basis for systems think- Systems engineering is closely connected to systematic
ing. Specifically, systems thinking has two aspects (Kasser thinking, as it follows the basic decomposition—recomposi-
tion approach: requirements are broken down at consecutive
levels in the system hierarchy and transformed into design
* Udo Kannengiesser components. These components are then composed into
[Link]@[Link] subsystems and finally the overall system. The effects of
1
Johannes Kepler University Linz, Linz, Austria the composition, at every system level, are validated and
2 verified. Such a systematic approach aims to reduce the
University of North Carolina at Charlotte, Charlotte, USA

13
Vol.:(0123456789)
130 Research in Engineering Design (2022) 33:129–159

likelihood of errors and flaws in the system’s design and is engineering, especially with respect to those in design think-
often used for systems that are safety–critical or have long ing (Greene et al. 2019; Li 2002; Patel and Mehta 2017;
life cycles. Pourdehnad et al. 2011). Yet, there has not been any detailed
Engineering design and systems engineering are seen to comparison of the process models used in the different
share similar goals and methods (Finkelstein et al. 1989). domains, except for a few hypothesised mappings between
This is not surprising, since systems engineering approaches process phases across different models on a high level. For
were originally developed by (mostly mechanical and elec- example, Chang et al. (2008) present a simplified model
trical) engineers in military and aeronautics (Chang et al. of systems engineering consisting of iterative “functional
2008; Honour 2018). Systems are seen as particular types of analysis”, “synthesis” and “evaluation and decision” phases
products that are large and complex (Finkelstein et al. 1989). that correspond to Asimov’s (1962) phases of designing.
Therefore, one may view systems engineering as a subdis- The aim of this paper is to investigate how a process
cipline of engineering design. On the other hand, systems model of systems engineering is different from other design
often involve heterogeneous technologies that require exper- domains that cover only partial aspects of what constitutes
tise from multiple engineering disciplines. These disciplines typical systems: mechanical engineering, software engi-
“fall into categories in descending degrees of abstraction neering and service design. In particular, the core technical
beneath [systems engineering]” (Finkelstein et al. 1989). processes of systems engineering described in the Systems
For example, mechatronic systems engineering encompasses Engineering Handbook published by INCOSE (2015) are
mechanical engineering, electrical engineering and infor- compared with Pahl and Beitz’ (2007) Systematic Approach
mation technology as subdisciplines (VDI 2004). Systems in mechanical engineering, the Rational Unified Process
engineering is viewed as a high-level framework or “macro- (RUP) in software engineering (Kruchten 2004), and Design
level” model (Wynn and Clarkson 2018) that includes pro- for Six Sigma (DFSS) in service design (El-Haik and Roy
ject structures and contextual aspects such as organisational 2005). This comparison is part of a larger research project
and managerial issues. that investigates systems engineering from theoretical and
While the beginnings of the systems engineering field empirical perspectives, to provide a better understanding
were mainly influenced by traditional engineering design, of systems engineering as a basis for the development of
in the 1990s there was a significant shift towards adopting improved tools and education. The model described by
concepts from software engineering (Honour 2018). This INCOSE has been chosen because it is one of the most com-
was a result of the increasing importance of software being prehensive, detailed and widely known models of systems
embedded in technical systems throughout the 1980s (God- engineering.
frey 1990). A number of international standards such as In this study, the function-behaviour-structure (FBS)
ISO/IEC/IEEE (2011, 2015, 2018) were defined aiming at schema (Gero 1990; Gero and Kannengiesser 2004, 2014)
the uniform development of systems and software using the serves as the uniform representation needed for comparing
same models and methods. the four models of the design process. This approach is simi-
A more recent trend in systems engineering is the addi- lar to the idea of using a common ontological representa-
tion of services to result in product-service systems (PSS) tion for knowledge sharing (Gruber 1995), referring to the
(Cavalieri and Pezzotta 2012; Hein et al. 2018). PSS com- meaning of ontology in computer science rather than phi-
bine tangible products with intangible services to produce losophy. Hence, we will refer to the FBS schema as the FBS
value for the customer. An example is Rolls-Royce’s ‘power- ontology. The FBS ontology provides a representation that
by-the-hour’ concept that provides gas turbines (the product) is not only more abstract but also more fine-grained than the
bundled with services including maintenance and improve- four domain-specific models examined (Wynn and Clarkson
ments so that customers pay for operating hours rather than 2018). A similar approach is the theory-based analysis pro-
just for the physical product (Baines et al. 2007). The notion posed by Reich et al. (2012) who use C-K theory as a com-
of PSS has gained further interest with the development of mon representation for comparing different design methods.
smart services enabled by cyber-physical systems, leading to In our approach, once the models of designing are brought
complex software-product-service systems (Mikusz 2014). into a common format, statistical analyses are used as a basis
Although systems engineering has matured as a proper for data-driven comparisons. Specifically, the distribution
design discipline with its own specialised tools and and evolution of FBS design issues across the different pro-
approaches (MIT 2003), its grounding in design theory cess models is examined using a set of statistical analyses,
has been insufficiently established. In particular, there is a including correspondence analysis, cumulative occurrence
scarcity of research examining the commonalities and dif- analysis and Markov model analysis. The FBS ontology was
ferences between the systems engineering process and mod- already used by Kannengiesser and Gero (2015) for com-
els of designing in other disciplines. Existing studies focus paring Pahl/Beitz, RUP and DFSS-ICOV models, and is a
on the unique skills and competences required in systems well-established coding schema for analysing empirical data.

13
Research in Engineering Design (2022) 33:129–159 131

Fig. 1  The INCOSE model of

systems engineering and other
models of designing are brought
into a common representation
that is used as input for statisti-
cal analyses and inter-model
comparisons

The basic approach of this paper is shown conceptually standards including ISO/IEC 15288, ISO/IEC/IEEE 29148
in Fig. 1. and ISO/IEC/IEEE 42010:2011. Based on its fine-grained
The paper has the following structure: Sect. 2 presents level of detail and strong foundations in the existing body
the INCOSE model of systems engineering. Section 3 is of knowledge, we selected the INCOSE model to represent
an initial approach to comparing INCOSE with the other systems engineering in our analysis.
models of designing based on hypothesised mappings A fundamental idea in INCOSE and various other models
between process phases. Section 4 introduces the FBS onto- of systems engineering (VDI 2004; NASA 2007; ISO/IEC/
logical schema, explains the coding of the models using that IEEE 2015, 2018; INCOSE 2015) is the assumption of a
schema, and presents the statistical analyses applied to the “Vee model” (Forsberg and Mooz 1991) shown in Fig. 2. In
coded models. Section 5 includes the results of the analyses, the Vee model, the system to be designed is first decomposed
which are then discussed in Sect. 6. Section 7 concludes the into subsystems and components, which are then realised
paper with a summary of the contributions and an outlook and integrated back into subsystems and finally the overall
on future research. system.
The INCOSE model adopts the generic system life cycle
stages defined in ISO/IEC/IEEE (2015). They include Con-
2 The INCOSE model of systems engineering cept, Development, Production, Utilization, Support and
Retirement (INCOSE 2015, p. 28). Each of these stages
2.1 Overview contains one or several Vee models according to particular
engineering concerns to be addressed using decomposition
One of the most detailed models of systems engineering and recomposition; for example, the Development stage may
is described in the Systems Engineering Handbook pub- include two Vee models: one for developing (de- and recom-
lished by the International Council on Systems Engineering posing) a system prototype and one for developing (de- and
(INCOSE 2015). It covers a broad range of system life cycle recomposing) a pre-production prototype (ISO/IEC 2002,
processes including technical processes, technical manage- p. 40).
ment processes, agreement processes, and organizational The INCOSE model defines 14 technical processes rep-
project-enabling processes. In this paper, we will refer to this resenting the core activities in systems engineering, from
model as the INCOSE model. It is the result of synthesising business analysis and requirements definition to production,
and detailing a number of international systems engineering usage and disposal:

13
132 Research in Engineering Design (2022) 33:129–159

Fig. 2  The Vee model (based on Forsberg and Mooz (1991))

1. Business or mission analysis compare the INCOSE model with experimental studies of
2. Stakeholder needs and requirements definition systems engineers. In these studies, the designers are already
3. System requirements definition provided with a set of requirements.
4. Architecture definition The scope of analysis also needs to be restricted at the
5. Design definition other end of the systems engineering process. Other models
6. System analysis of designing as well as experiments commonly terminate
7. Implementation when a description of a design structure has been produced,
8. Integration assessed and finalised. The subsequent use of that descrip-
9. Verification tion for manufacturing, physical installation, operation,
10. Transition etc., is not considered. Accordingly, the INCOSE processes
11. Validation of transition, operation, maintenance and disposal are
12. Operation disregarded.
13. Maintenance Another INCOSE process, namely system analysis, has
14. Disposal been omitted in our study. It is described in INCOSE (2015,
p. 74) as a supporting process that can be used by several
2.2 Scoping and assumptions of the other technical processes, including system require-
ments definition, architecture definition, design definition,
For the purposes of this paper, only a subset of the technical integration, verification and validation. Yet, in the detailed
processes is considered: those having a similar scope as the description of these processes no exact location is provided
models of designing in other domains. In such models, the where the system analysis process shall be invoked. In addi-
elicitation of requirements is typically not part of the scope, tion, many of the steps defined in system analysis resemble
as designing is viewed as commencing with an initial set of or are identical with the steps already defined in the other
given requirements. Therefore, for reasons of comparability processes.
across different models, the two elicitation processes defined Given these scope restrictions, the INCOSE technical
in INCOSE—business or mission analysis and stakeholder processes taken into account include:
needs and requirements definition—are not within the scope
of our analysis. The first INCOSE process taken into account 1. System requirements definition (shorthand: Sys Req
is system requirements definition, which aims to “transform Def)
the stakeholder, user-oriented view of desired capabilities 2. Architecture definition (shorthand: Arch Def)
into a technical view of a solution that meets the opera- 3. Design definition (shorthand: Design Def)
tional needs of the user” (INCOSE 2015, p. 57). Restricting 4. Implementation (shorthand: Impl)
our scope of analysis in this way is also based on the larger 5. Integration
project in which this study is embedded, where the aim is to 6. Verification

13
Research in Engineering Design (2022) 33:129–159 133

7. Validation

For reasons of presentational simplicity, we will keep

referring to this subset as the “INCOSE model”, being aware
a few of its technical processes are omitted in our study.
Processes 1–3 are located at the downward side of the
Vee, process 4 at the base, and processes 5–7 at the upward
side. According to INCOSE (2015), they are executed in
sequence but using iteration and recursion. Iteration is
defined as “the repeated application of and interaction
between two or more processes at a given level in the system
structure or hierarchy” and recursion as “the repeated appli-
cation of and interaction of processes at successive levels
in the system structure” (INCOSE 2015, p. 32). Based on
ISO/IEC (2002), recursion occurs when going downward
Fig. 4  Two generic patterns of iteration explored in this study: a cas-
and upward along the Vee. The base of the Vee represents cading, and b figure-of-eight
the lowest level in the system hierarchy and therefore does
not include any recursion. The overall sequence of INCOSE
processes including the resulting recursions (which are a 3 Qualitative comparison with models
function of the number of system levels) is shown in Fig. 3. in other domains
The exact sequence of technical processes within an
iteration is not clearly specified in the INCOSE model. In this section, a first attempt is made to relate the INCOSE
The iterations shown in Fig. 3 are simplified to represent model with models of designing in other domains, based on
a circular sequence, for the purpose of locating them in the a qualitative comparison. Such a comparison has already
Vee model and distinguishing them from recursion. How- been carried out by Kannengiesser and Gero (2015) for
ever, the INCOSE model suggests more complex iterations Pahl and Beitz’ (2007) Systematic Approach, the Rational
based on various interactions between the processes involved Unified Process (RUP) (Kruchten 2004), and the Identify-
(INCOSE 2015, p. 33). We explore two variants of iteration Conceptualize-Optimize-Validate variant of Design for Six
shown conceptually in Fig. 4 for three generic processes A, Sigma (DFSS/ICOV) (El-Haik and Roy 2005). We will first
B and C. These generic processes are placeholders for either review the similarities among these models before relating
System Requirements Definition, Architecture Definition the INCOSE model to them.
and Design Definition (i.e., iteration at the downward side As shown by Kannengiesser and Gero (2015), all three
of the Vee), or for Integration, Verification and Validation models suggest a four-phase process. While their domains
(i.e., iteration at the upward side of the Vee). and terminologies are different, the phases can clearly be
mapped onto one another as they share common overall

Fig. 3  Iteration and recursion in the INCOSE model: Iterations occur within every system hierarchy level (1 to N) along the downward and
upward sides of the Vee. Recursions (­ R1 to ­RN-1) occur when transitioning across adjacent system hierarchy levels via repeated process cycles

13
134 Research in Engineering Design (2022) 33:129–159

goals. The goal of the first phase can be viewed as under- 4.1 Uniform representation based on the FBS
standing and defining the design problem. This is done in all ontology
three models by collecting, analysing and documenting the
requirements and scope of the design. The second phase is For the transformation of domain-specific models of design-
concerned with generating a conceptual structure. This is a ing into a canonical format, two mappings are needed (Kan-
common goal of all three models, despite their focus on dif- nengiesser and Gero 2015). Firstly, a mapping of the specific
ferent kinds of structure according to their specific domains concepts and terms used in the different models onto FBS
(i.e., mechanical structure, software architecture and service design issues, and secondly, a mapping of the design steps
structure). The same holds true for the third phase: It gener- described in each model onto the situated FBS framework
ates a concrete solution structure, using the different types as a basis for a simulation model.
of components and materials of the specific design domains The FBS design issue schema allows generalising the spe-
(e.g., physical layout, software components and service con- cifics of domains into a generic representation in terms of six
figurations). The fourth phase aims to finalise and deliver the classes of concepts: requirements (R), function (F), expected
design solution. The particular emphasis of this phase may behaviour (Be), behaviour derived from structure (Bs) (or,
vary among the models, but they all include some form of shorthand, structure behaviour), structure (S), and descrip-
refinements, quality checks and documentation. tion (D). Here, we will provide an overview of how the
Some of the technical processes—from now on called concepts of INCOSE were mapped onto FBS. For the FBS
“phases”—in the INCOSE model appear to naturally fit with mappings of Pahl/Beitz, RUP and DFSS/ICOV, readers may
these mappings. Specifically, it is hypothesized that System refer to Kannengiesser and Gero (2015). The terminology
Requirements Definition, Architecture Definition, Design used for describing the FBS schema in this paper is taken
Definition and Implementation can be mapped onto the four from Gero and Kannengiesser (2014) and Kannengiesser
design phases in the other models, as shown in Table 1. and Gero (2015).
Three of the seven phases of the INCOSE model—Inte- Requirements (R): include articulated customer or market
gration, Verification and Validation—do not fit into this needs, demands, wishes and constraints, explicitly provided
four-phase process structure. This indicates that, while there at the outset of a design task. In INCOSE, requirement issues
is some similarity between INCOSE and the other models, comprise concepts such as “stakeholder requirements”,
there is also some difference. This qualitative assessment “system requirements”, and “interactions of the system
will be examined quantitatively in the remainder of this with systems external to the system boundary” and other
paper. “constraints” stated as input to the design process (INCOSE
2015, p. 59).
Functions (F): include articulations of intent related to the
4 Methodology artefact. They are not externally provided (otherwise they
would be requirements) but are generated by the designer.
The methodology for this research follows the approach pre- Function issues in INCOSE comprise “system functions”,
sented in Fig. 1, consisting of two phases: (1) bringing the “critical quality characteristics” (e.g., “safety, security, reli-
different models of designing into a single, uniform repre- ability, supportability”) and other teleological aspects of a
sentation based on the FBS ontology, and (2) running a set system (ibid, p. 59).
of statistical analyses on these representations. This section Expected behaviour (Be): includes attributes describing
describes the two phases in more detail. the artefact’s expected interaction with the environment, pro-
viding measurable assessment criteria for design candidates.

Table 1  Hypothesised mappings between the design phases in INCOSE, Pahl/Beitz, RUP and DFSS/ICOV (based on Kannengiesser and Gero
(2015))
Mapping No INCOSE Pahl/Beitz RUP DFSS/ICOV Overall goal

1 Sys Req Def Task Inception Identify Understanding and defining the design problem
Clarification
2 Arch Def Conceptual Elaboration Conceptualize Generating a concept structure
Design
3 Des Def Embodiment Construction Optimize Generating a solution structure
Design
4 Impl Detail Transition Validate Finalising and delivering the design solution
Design

13
Research in Engineering Design (2022) 33:129–159 135

Expected behaviour issues in INCOSE comprise “opera- the operational scenarios and expected system behaviors”
tional scenarios and expected system behaviours” (ibid, p. (INCOSE 2015, p. 59), which can be mapped onto the con-
66), “architecture evaluation criteria” (ibid, p. 67) and “per- struction of expected behaviour (Be) (process 5 in sFBS).
formance characteristics” (ibid, p. 84). This activity also includes the identification of “expected
Structure behaviour (Bs) (or “Behaviour derived from interactions of the system with systems external to the sys-
Structure”): includes attributes that are measured, calculated tem (control) boundary as defined in negotiated interface
or derived from observation of a specific design solution control documents (ICDs)” (ibid, p. 59) that are part of the
and its interaction with the environment. The comparison external requirements (R) on behaviour (process 2 in sFBS).
of structure behaviour and expected behaviour is the basis The following INCOSE activity is to “define system require-
for evaluating design solutions. Structure behaviour issues ments”, which begins with “identify[ing] and defin[ing] the
cover the same concepts in INCOSE as outlined for expected required system functions” (ibid, p. 59). This is mapped onto
behaviour issues. the interpretation of requirements (R) related to function
Structure (S): includes the components of an artefact and (process 1 in sFBS) and the construction of further func-
their relationships. Structure can exist on a conceptual and tions (F) (process 4 in sFBS). In addition, “system behavior
a more detailed level. In INCOSE, structure issues comprise characteristics” (ibid, p. 59), i.e., expected behaviours (Be),
concepts such as “system elements”, “physical interfaces” are constructed (process 5 in sFBS). Finally, after a few steps
and other “architectural entities” (ibid, p. 66) that are defined similar to the ones already described (and thus omitted in
or implemented. Table 3), system requirements are specified that include
Description (D): includes any form of external design rep- “stakeholder requirements, functional boundaries, functions,
resentations produced during the design process. Description constraints, critical performance measures, critical quality
issues in INCOSE comprise all forms of “outputs” defined characteristics” (ibid, p. 59). They are defined as the output
for the different technical processes. For example, the out- of the System Requirements Definition phase (ibid, p. 58) and
puts of Design Definition include “system design descrip- therefore viewed as external descriptions (D) of function and
tion”, “system design rationale”, “interface definition” and behaviour (processes 18 and 17 in sFBS).
others (ibid, p. 71). The complete set of mappings of all INCOSE phases onto
Bringing the different models of designing into a com- sFBS and FBS design issues are depicted in the Appendix.
mon, procedural representation requires mapping the steps For the mappings of Pahl/Beitz, RUP and DFSS/ICOV
specified in each model onto the 20 processes defined in the onto FBS, readers are referred to Kannengiesser and Gero
situated FBS (sFBS) framework (Kannengiesser and Gero (2015). All FBS coding was carried out by the two authors
2015). This allows viewing them as part of the interaction of this study, who are experts in the FBS ontology. The FBS
between a design agent and the design situation, resulting in ontology-based coding scheme has been used by multiple
simulation models of the respective design processes. The researchers across multiple domains (Bott et al. 2019; Cas-
design situation is defined as the interaction between three cini et al. 2012; Pauwels et al. 2015; Song 2014; Hamraz and
“worlds”: The external world contains objects and represen- Clarkson 2015; SAE 1999).
tations in the environment of the designer. The interpreted For completing the simulation models, three assump-
world contains experiences, percepts and concepts produced tions are made for all four models of designing: (1) every
by the designer’s interactions with the external world. The elementary design step occurs only once within the same
expected world contains the designer’s hypotheses, goals and iteration (as we abstract from the instance level to a generic
expected results of actions. The sFBS framework and rules model level), (2) both generic patterns (i.e., “cascading” and
for mapping the 20 sFBS processes onto the six basic FBS “figure-of-eight”) described in Sect. 2 are explored as two
design issues are shown in Fig. 5 and Table 2, respectively. separate variants, and (3) the number of iterations is set to
The approach can be illustrated using the initial design one (i.e., a single execution of a generic pattern). An addi-
activities in the INCOSE System Requirements Definition tional assumption applies exclusively for INCOSE, setting
phase, shown in Table 3. The first activity within this phase the number of hierarchy levels (N) to 3, leading to two (N–1)
is to “prepare for system requirements definition” (INCOSE recursions (cf. Figure 3). Setting the number of hierarchy
2015, p. 59). One of the inputs defined for System Require- levels to 3 in the INCOSE modelling matches the coding of
ments Definition are “stakeholder requirements” (ibid, p. the empirical data. The other three models do not need such
58) related to functions, constraints and interactions (ibid, an assumption as they do not have the notion of hierarchy
p. 54). As they can be assumed to be provided externally levels.
to the systems engineer, they are interpreted as require- Based on the mappings and assumptions detailed above,
ments (R) via processes 1 and 2 in the sFBS framework. the four models of designing are brought into uniform rep-
The requirements are then complemented by determining resentations with the following number of steps: INCOSE:
“the system boundary, including the interfaces, that reflects 1573, Pahl/Beitz: 185, RUP: 224, DFSS/ICOV: 77. An

13
136 Research in Engineering Design (2022) 33:129–159

Fig. 5  The situated FBS framework (Gero and Kannengiesser 2004, 2014)

overview of how the numbers of steps were calculated for to categories. In this research, the two types of categories
INCOSE is provided in Table 4. The numbers for Pahl/Beitz, analysed are the set of models of designing (and the phases
RUP and DFSS/ICOV are taken from Kannengiesser and within these models) and the set of design issues. The CA
Gero (2015). plot then allows visually interpreting the relationships
between the different models and between the models and
4.2 Statistical analyses the design issues.
Cumulative occurrence analysis aggregates the occur-
Three types of statistical analysis can now be carried out rence of a design issue overall design steps in a model to
on the common representations: correspondence analysis, derive a set of measures characterising the resulting curve
cumulative occurrence analysis and Markov model analysis. (shown conceptually in Fig. 6). The following measures have
Correspondence analysis (CA) is a technique for reducing been used in previous work (Kannengiesser and Gero 2015):
the dimensionality of categorical data and visualising the
results on a two-dimensional plot (Benzecri 2019; Greena- • Regression line: includes first-order (linear) and second-
cre 2017). The axes of the plot do not have a meaning other order polynomials, where the latter are characterised as
than capturing the highest variance of the data. CA is con- either concave (i.e., the graph is flattening over time) or
ceptually similar to principal components analysis applied convex (i.e., the graph is rising over time). This allows

13
Research in Engineering Design (2022) 33:129–159 137

Table 2  Mapping of sFBS processes to FBS design issues Markov model analysis is based on the probabilities of
sFBS process FBS design issue
moving from one state to another (Meyn and Tweedie 2009).
Applied to models of designing, it captures the transition
1 R probabilities between FBS design issues (Kan and Gero
2 R 2009). It increases understanding of the interrelationships of
3 R the six design issues in the different models of designing. In
4 F this research, we use first-order Markov models that capture
5 Be or Bs (*) the transition probability to a future design issue depending
6 S only on the current design issue without considering any
7 F past design issues. The models can be produced using the
8 Be or Bs (*) LINKODER tool that outputs a probability matrix for the
9 S six design issues.
10 Be
11 S
12 D 5 Results
13 S
14 Bs 5.1 Correspondence analysis
15 – (**)
16 F Correspondence analyses (CA) were carried out based on
17 D the numbers of design issues (here called frequency dis-
18 D tributions) in different design models and design phases.
19 Be or Bs (*) For these analyses, no iterations in the models were taken
20 F into account. This is because frequency distributions repre-
*Depending on whether the behaviour produced in these processes is sent the total numbers of design issues per model or design
interpreted as expected/desired or “actual”/emerging phase, and are independent of variations in their accumula-
**This process produces no design issue tion over the course of designing.
The results of the CA for the four models from a global
perspective are shown in Fig. 7. Firstly, we look only at the
making statements about how the focus on each design location of the four models (in blue colour) on the biplot.
issue changes over the course of designing. Each of the models is positioned in a separate quadrant,
• Slope: represents the rate at which design issues are gen- except for Pahl/Beitz and DFSS/ICOV that are at almost
erated, using the assumption that the graph is linear. identical locations within the same quadrant. On the verti-
• First occurrence at start: indicates whether design issues cal axis (Dim2), INCOSE sits in the middle between RUP
first occur near the start of designing or at a later stage. and Pahl/Beitz/DFSS/ICOV. However, on the horizontal axis
This is based on past observations in other models of (Dim1), which accounts for 85.6% of the variance in the
designing that some design issues do not start occurring data, INCOSE sits almost at the opposite end from RUP,
until later in the design process (Kannengiesser and Gero Pahl/Beitz and DFSS/ICOV. This indicates that INCOSE
2015). is quite different from the other models from a categorial
perspective.

Table 3  Example of the Step INCOSE activity Process in sFBS (label) FBS issue
mappings of the INCOSE
system requirements definition 1 Prepare for system require- Interpret requirements on function (1) and behaviour (2) R
phase onto the sFBS framework ments definition
2 Construct expected behaviours not explicitly stated (5) Be
and the FBS design issue
system 3 Interpret requirements on behaviour (2) R
4 Define system requirements Interpret requirements on function (1) R
5 Construct functions not explicitly stated (4) F
6 Construct expected behaviours not explicitly stated (5) Be
… … …
13 Produce external representations of function (18) and D
behaviour (17)
… … … …

13
138 Research in Engineering Design (2022) 33:129–159

Table 4  Calculation of the total number of steps of the coded there is a strong association between Validation and struc-
INCOSE modele behaviour (Bs) ture behaviour (Bs), and, slightly less, between Verification
Phase Steps per phase Recursions Iterative Total and Bs. No other phases in any of the models exhibit these
repetitions per associations with Bs. System Requirements Definition and
recursion Architecture Definition sit in the first quadrant, and so do
Sys Req Def 28 2x 2x 112 Task Clarification (Pahl/Beitz), Inception (RUP) and Iden-
Arch Def 88 2x 3x 528 tify (DFSS/ICOV). Design Definition, Implementation and
Design Def 44 2x 2x 176 Integration are located in the second quadrant, which they
Implementa- 33 1x 1x 33 share only with Conceptual Design of Pahl/Beitz. The third
tion quadrant is where all the remaining phases of Pahl/Beitz,
Integration 36 2x 2x 144 RUP and DFSS/ICOV are located, and none of INCOSE.
Verification 60 2x 3x 360 These results provide only partial confirmation of the map-
Validation 55 2x 2x 220 pings identified qualitatively between the phases across
Grand total 344 1573 the different models (see Table 1). However, the overall
sequence of the phases in each model is roughly mirrored
by their clockwise positioning from the first to the fourth
(for INCOSE and RUP) or third (for the other models) quad-
rants. A similar pattern can be discerned from the clock-
wise positioning of the six design issues that roughly follows
their expected ordering according to the FBS framework:
R → F → Be → S → Bs → D (with the exception that in the
plot D comes before Bs).

5.2 Cumulative occurrence analysis

In this section the cumulative occurrence graphs of the four

models (INCOSE, Pahl/Beitz, RUP and DFSS/ICOV) are
Fig. 6  Conceptual graph showing the cumulative occurrence of a
design issue
presented and compared. The graphs for cascading and fig-
ure-of-eight iterations are shown in Figs. 9 and 10, respec-
tively, for readers to appreciate the variability of the data.
Secondly, we look at the relationships between the four Regression lines were calculated for the cumulative
models of designing (blue colour) and the six design issues occurrence graphs using standard spreadsheet software.
(red colour). We do this by imagining lines connecting the The shapes of the graphs are characterised in Tables 5 and
models or design issues with the origin of the biplot. The 6 for the two iteration types as either linear (i.e., constant),
longer the line connecting a model and the line connecting concave (i.e., flattening) or convex (i.e., rising). They can
a design issue, and the smaller the angle between the two be used as a measure for the similarities and differences
lines, the stronger the association between the model and the between INCOSE and the other models, independently of
design issue (cf. Greenacre (2017)). Thus, from Fig. 7 we the type of iteration used. The similarities include linear
can infer a moderate to strong association between INCOSE requirements (R) and structure (S) (except for DFSS/ICOV
and requirements (R) and structure behaviour (Bs). In con- (cascading iterations) that has a convex curve), and con-
trast, RUP is negatively associated with R, and Pahl/Beitz cave function (F) and expected behaviour (Be) (except for
and DFSS/ICOV are negatively associated with Bs, based RUP that has linear F and Be (figure-of-eight iterations)).
on their location at opposite sides of the origin (i.e., angle INCOSE differs from the other models in the convexity of
of 180º). These negative associations are quite significant, structure behaviour (Bs) and description (D) (except for RUP
as the respective locations on the biplot are a long way from that has a linear curve for Bs (figure-of-eight iterations)). To
the origin. In other words, INCOSE makes use of require- summarise, as the design process proceeds, INCOSE gen-
ments (R) and structure behaviour (Bs) much more than the erates more structure behaviour (Bs) and description (D)
other models do. issues at the expense of function (F) and expected behaviour
The results of CA for the individual phases in INCOSE (Be) issues. The other models absorb the decreasing produc-
and those in Pahl/Beitz, RUP and DFSS/ICOV are shown in tion of F and Be issues more equally within the remaining
Fig. 8. The phases of INCOSE that clearly stand out are Ver- design issues, leading to no significant increase in Bs and
ification and Validation, as they are the only ones located in D issues.
the fourth quadrant apart from RUP’s Transition. In addition,

13
Research in Engineering Design (2022) 33:129–159 139

Fig. 7  Correspondence analysis of the models and design issues

The convexity of structure behaviour (Bs) and descrip- The first occurrence of design issues near the start of the
tion (D) in INCOSE emerges from a change in the shape of models is shown in Table 7. It is based on whether the design
the corresponding graphs occurring after a little more than issue occurs in the first phase of the model, which is inde-
half of the design steps. This is where the INCOSE process pendent of the iteration type. In all four models, structure
enters the final phases of Integration, Verification and Vali- behavior (Bs) and structure (S) do not occur near the start,
dation (from step 850). If these phases were not considered whereas the other design issues do.
in calculating the regression lines, Bs and D would be linear
just like in the other models of designing. 5.3 Markov model analysis
The slopes of the cumulative occurrences can be inter-
preted as showing their relative importance within a model. First-order Markov models have been established for
They are depicted graphically in Fig. 11 for the two iteration INCOSE, Pahl/Beitz, RUP and DFSS/ICOV (covering cas-
types, using the simplifying assumption that all regression cading and figure-of-eight iterations). The dominant state
lines are linear. With respect to the other models, in INCOSE transitions in every model—i.e., those transitions with the
the slopes are higher for requirements (R) and structure highest likelihood of all other transitions from a given design
behavior (Bs), while they are slightly lower for function (F) issue—are represented graphically in Fig. 12.
and description (D). The slope is also lower for structure (S) A number of similarities and differences between
in case of cascading iterations. Overall, it can therefore be INCOSE and the other models can be identified by com-
stated that INCOSE emphasizes R and Bs issues more than paring their dominant state transitions, as summarised
the other models do. in Table 8. INCOSE is similar to all other models in the

13
140 Research in Engineering Design (2022) 33:129–159

Fig. 8  Correspondence analysis of all phases in INCOSE, Pahl/Beitz (shorthand: PB), RUP and DFSS/ICOV (shorthand: DFSS)

transitions from requirements (R) (to function (F)), struc- is that the first phase of every model is located in the same
ture behaviour (Bs) (to structure (S)) and description (D) quadrant of the CA plot. This confirms the hypothesised
(to structure (S)). It is partially similar to the other models mapping between these phases laid out in Table 1. However,
in that it shares with Pahl/Beitz and DFSS/ICOV the domi- the other mappings from that Table are not confirmed by
nant transition from function (F) to expected behaviour (Be), the CA.
and with Pahl/Beitz and RUP the transition from expected One of the similarities identified through cumulative
behaviour (Be) to structure (S). It differs from all other mod- occurrence analysis is that structure (S) is generated at a
els in its dominant transition from structure (S) to structure. constant rate in both INCOSE and the other models (with the
exception of one configuration of the DFSS/ICOV model).
Problem-related issues (i.e., F and Be) are generated more
6 Discussion at the beginning and less towards the end in INCOSE and
most of the models (except in RUP where they are constantly
The results of the statistical analyses show that there are both generated). The solution-related issues of S and Bs do not
similarities and differences between INCOSE and the other occur at the beginning of any of the models. Taken together,
models of designing. these similarities indicate that INCOSE follows the general
When comparing the overall models and their phases by “problem to solution” pattern in design, characterised by a
reducing the dimensionality of the data (using CA), only a shift in focus from problem-oriented (F, Be) towards solu-
small number of similarities can be observed. One similarity tion-oriented issues (Bs) during the course of design.

13
Research in Engineering Design (2022) 33:129–159 141

Fig. 9  Cumulative occurrence of design issues for cascading iterations

Fig. 10  Cumulative occurrence of design issues for figure-of-eight iterations

13
142 Research in Engineering Design (2022) 33:129–159

In terms of the transition probabilities of individual which seems unique when visually inspecting the other
design issues, INCOSE shares with the other models that graphs; however, it should be noted that those other graphs
the dominant transition from R is to F, from Bs is to S and lack sufficient data to support this statement. The compari-
from D is to S. It shares with two of the other models that son of the slopes of the different graphs has shown that the
the dominant transition from F is to Be and from Be is to importance of R and Bs issues is slightly emphasised in
S. This means that five out of the six FBS design issues in INCOSE.
INCOSE have the same dominant transitions as in (most Despite the strong similarity related to transition prob-
of) the other models of designing, which indicates quite a abilities, INCOSE differs in one aspect: It is the only model
strong similarity. that has a dominant state transition from structure (S) to
On the other hand, the statistical analyses reveal a number structure behaviour (Bs). A look at the raw data (i.e., the
of distinct characteristics of INCOSE that cannot be found coded INCOSE model, see Appendix) shows that this tran-
in the other models. sition occurs most often within the phases of Verification
One result of CA is that the Verification and Validation and Validation. It confirms the findings from CA that these
phases are clearly set apart from all others and strongly asso- phases are quite different from other phases within INCOSE
ciated with structure behaviour (Bs). The CA of the overall and from phases within other models of designing.
models of designing also shows a moderate to strong connec- Finally, two limitations of this study should be stated:
tion between INCOSE and Bs issues in addition to R issues, firstly, the INCOSE model was reduced to those technical
which supports the conclusions drawn from the comparison processes transforming stakeholder requirements into docu-
of slopes of the cumulative occurrence graphs. Overall, the ments of the system designed, to align its scope with other
results indicate a fundamental difference between INCOSE models and most empirical design sessions (see Sect. 2.2).
and the other models, as they are located at different ends of The INCOSE processes of business or mission analysis
the major dimension (Dim1) in the CA plot. and stakeholder needs and requirements definition were
The accumulation of structure behaviour (Bs) and design thus ignored. Being mainly concerned with the elicitation
description (D) issues in INCOSE is convex, i.e., increasing of requirements, their inclusion in the statistical analysis
over time. This is different from the other models where would probably have led to similar results in terms of the
these issues are generated linearly (with the exception of INCOSE’s strong emphasis on R issues. Secondly, this study
one configuration of RUP where the Bs issues also increase). explored only two types of iteration of the individual pro-
The cumulative occurrence of R issues in INCOSE is linear, cesses within INCOSE. Yet, the results are rather insensitive

Table 5  Regression lines of the R F Be Bs S D

cumulative occurrence graphs
(cascading iterations) INCOSE Linear Concave Concave Convex Linear Convex
Pahl/Beitz Linear* Concave Concave Linear Linear Linear
RUP –** Concave Linear Convex Linear Linear
DFSS/ICOV –** Concave Concave –** Convex Linear

*Calculated based on only nine occurrences

**Not calculated due to less than nine occurrences

Table 6  Regression lines of the R F Be Bs S D

cumulative occurrence graphs
(figure-of-eight iterations) INCOSE Linear Concave Concave Convex Linear Convex
Pahl/Beitz Linear* Concave Concave Linear Linear Linear
RUP –** Linear Linear Linear Linear Linear
DFSS/ICOV –** Concave Concave –** Linear Linear

*Calculated based on only nine occurrences

**Not calculated due to less than nine occurrences

13
Research in Engineering Design (2022) 33:129–159 143

Fig. 11  Graphical comparison of slopes of the cumulative occurrence graphs

Table 7  First occurrence at start R F Be Bs S D

INCOSE Yes Yes Yes No No Yes

Pahl/Beitz Yes Yes Yes No No Yes
RUP Yes Yes Yes No No Yes
DFSS/ICOV Yes Yes Yes No No Yes

as to whether “cascading” or “figure-of-eight” iterations 7 Conclusion

were used.
This paper investigated the question whether a model of
systems engineering (INCOSE) is different to models of

13
144 Research in Engineering Design (2022) 33:129–159

Fig. 12  Graphical representation of the dominant state transitions in the Markov models of INCOSE, Pahl/Beitz, RUP and DFSS/ICOV

Table 8  Summary of the similarities and differences between and differences between them, not based on qualitative
INCOSE and the other models with respect to the dominant state judgements but on quantitative analyses using statistical
transitions
methods. The approach is possible because it increases both
INCOSE Pahl/Beitz RUP DFSS/ICOV the level of detail and the level of abstraction: the models of
designing are broken down into sequences of fine-grained
From: To:
steps according to the sFBS framework and coded uniformly
R F F F F
using the FBS design issue schema. The resulting sets of
F Be Be F Be
code are used as datasets on which multiple statistical analy-
Be S S S F, D
ses are run, allowing for data-driven formation and testing
Bs S S S S
of hypotheses about the models. The same approach was
S Bs D D S
used by Kannengiesser and Gero (2015) but has not been
D S S S S
applied to the INCOSE model and used only cumulative
Deviations of the other models with respect to INCOSE are high- occurrence analysis.
lighted The combination of multiple types of statistical analysis
provides detailed insights in the INCOSE model. The main
engineering design (Pahl/Beitz), software design (RUP) and similarities with other models of designing that were identi-
service design (DFSS/ICOV). It revealed both similarities fied include:

13
Research in Engineering Design (2022) 33:129–159 145

• the initial phase of understanding and defining the design across several domains (Gero et al. 2014; Kannengiesser
problem, whose design steps are quite distinct from other and Gero 2015).
phases, The insights gained in this paper can lay the foundations
• the shift in focus during the design process from the for better understanding of systems engineering and the
design problem to possible solutions, INCOSE model, especially by positioning it in the land-
• the constant generation of solution structures (S), and scape of other models from various design disciplines that
• the same dominant state transitions for the majority of may have influenced the development of INCOSE. This may
design issues. contribute to efforts in building a theory of systems engi-
neering. In addition to principles and hypotheses derived
However, INCOSE also has a set of unique features that from sources within the systems engineering discipline
make it fundamentally different from the other models. They (Watson 2019), such a theory would incorporate insights
include: based on an external, comparative view. Comparisons may
include not only conceptual models from the literature, but
• a stronger association of the overall model with require- also empirical studies. The approach presented in this paper
ments (R) and structure behaviour (Bs), can accommodate both, as was shown by Kannengiesser and
• Verification and Validation phases whose design steps Gero (2017) who compared Pahl/Beitz’ model with design
are fundamentally different from all others, sessions involving mechanical engineering students. A com-
• the increased generation of structure behaviour (Bs) and parison of the INCOSE model with empirical data from sys-
design descriptions (D) towards the end of the design tems engineering design sessions is currently under way.
process, and Knowing where the INCOSE model differs from other
• the dominant state transition from structure (S) to struc- models of designing can guide future developments in sys-
ture behaviour (Bs). tems engineering methods. The abstract representation of
differences in terms of FBS facilitates the retrieval and trans-
Requirements (R) keep occurring in most INCOSE fer of methods from other domains. For example, service
phases, whereas in the other models of designing they occur walkthroughs to increase understanding of user experience
much less frequently and almost only in the initial phases. A when interacting with a system (Blomkvist 2016) may be
large number of structure behaviours (Bs) are produced in a useful addition to common validation techniques in sys-
INCOSE’s Verification and Validation—first-class phases tems engineering. They may be found based on their sup-
of design analysis that Pahl/Beitz and RUP subsume as port for S-to-Bs transitions that have been found important
sub-activities. DFSS/ICOV does have an explicit validation in INCOSE. Product-service system design, which brings
phase but is not very detailed compared to INCOSE. together two disparate design disciplines, can be analysed
Many of the similarities and differences are not surpris- using this INCOSE model. PSS design activity can be com-
ing with respect to commonly known qualitative views of pared with that for product design to determine whether it
systems engineering, including its strong focus on require- is different and, if so, whether different design support tools
ments definition, on verification and validation, and on doc- need to be developed for it.
umentation. These activities are grounded in the inherent
complexity of engineered systems and in the origin of sys-
tems engineering in safety–critical domains. However, the Appendix A
analysis in this paper reveals insights beyond these general
views. For example, the hypothesized mappings between
the phases across the models (see Table 1) were only par-
tially supported by the data. This does not mean that they Coding of the INCOSE model
are not associated by common goals—which can only be
interpreted qualitatively, not statistically. The mappings See Tables 9, 10, 11, 12, 13, 14, 15.
may still be valid teleologically, but they are not based on
structural similarity of the phases mapped. Other character-
istics of INCOSE have been identified that cannot be derived Appendix B
from current literature on systems engineering. In particu-
lar, the constant generation of solution structures during the
INCOSE process has not previously been stated. Further
Contingency tables used as input
studies may shed more light on this phenomenon, which
for correspondence analysis
has been observed in experiments and models of designing
See Tables 16 and 17.

13
146 Research in Engineering Design (2022) 33:129–159

Table 9  System requirements definition (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

1.1 Prepare for system require- R 1, 2 -Requirements are used as input (see Fig. 1); they include func-
ments definition tions, interactions and constraints (p. 54)
N/A N/A -establish the approach used for defining requirements (p.59)
Be 5 -determine “the system boundary, including the interfaces, that
R 2 reflects the operational scenarios and expected system behaviors”
(p. 59); also includes expected interactions of the system with
systems external to the system boundary (as defined in interface
control documents (ICDs))
1.2 Define system requirements R, F 1, 4 -identify and define required system functions; also, include the
Be 5 system behavior characteristics (p. 59)
R, F, Be, F, Be 1, 2, 4, 5, 7, 8 -identify requirements that impose unavoidable constraints (p. 59)
F 4 -identify critical quality characteristics (e.g., safety, security, reli-
ability, supportability) (p. 59)
N/A N/A -identify technical risks
D 18, 17 - “specify system requirements, consistent with stakeholder
requirements, functional boundaries, functions, constraints, criti-
cal performance measures, critical quality characteristics, and
risks” (p. 59); specification as a document (SyRS) (p. 59)
1.3 Analyze system requirements F, Be, F, Be 20, 19, 4, 5 - “analyze the integrity of the system requirements” (p. 59)
D 18, 17 - “provide analysis results to applicable stakeholders” (p. 59)
N/A N/A -negotiate modifications to resolve issues (p. 59)
Be 10 - “define verification criteria – critical performance measures that
enable the assessment of technical achievement” (p. 59)
D 17 -verification criteria are used as output (see Fig. 1)
1.4 Manage system requirements N/A N/A -ensure agreement among key stakeholders, establish and maintain
traceability, … (p. 59)
R, F, Be, F, Be, F, Be, D 1, 20, 2, 19, - “Establish and maintain traceability between the system require-
4, 5, 7, 8, ments and the relevant elements of the system definition (e.g.,
18, 17 stakeholder requirements, […]” (p. 59); “traceability” is captured
in the “updated RVTM” which is documented as an external
output (see Fig. 1)

13
Research in Engineering Design (2022) 33:129–159 147

Table 10  Architecture Definition (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

2.1 Prepare for architecture definition R, F, Be 1, 2, 4, 5 - “Identify and analyze relevant market, industry,
stakeholder, organizational, business, operations,
mission, legal, and other information that will help
to understand the perspectives that will guide the
development […]” (p. 65)
F, Be 20, 19 - “[…] analyze the system requirements […] as well
as life cycle constraints” (p. 66)
R, F, Be 1, 2, 7, 8 - “Capture stakeholder concerns related to archi-
tecture. Usually, the stakeholder concerns focus
on expectations or constraints that span one or
more system life cycle stages.” (p. 66); “life cycle
constraints” are among the external inputs to the
process (see Figs. 1 and 2)
Be, S 8, 11 - “Establish the approach for defining the archi-
Bs 14, 15 tecture. […] The approach should also include
the process requirements (e.g., measurement
D 17, 12
approach and methods), evaluation (e.g., reviews
and criteria) and necessary coordination. Capture
the evaluation criteria.” (p. 66) This approach is
part of the “architecture definition strategy” (see
Fig. 2) =  > external output
2.2 Develop architecture viewpoints R, F, Be, S, F, Be, S 1, 2, 4, 5, 6, 7, 8, 9 “Based on the identified stakeholder concerns,
establish or identify the associated architecture
viewpoints, the supporting kinds of models that
facilitate the analysis and understanding of the
viewpoint, and relevant architecture frameworks
to support the development of the models and
views.” (p. 66) “Architecture viewpoints” and
“model kinds” are defined in ISO/IEC/IEEE
(2011) that is referenced in INCOSE:
-Viewpoint = “work product establishing the conven-
tions for the construction, interpretation and use
of architecture views to frame specific system
concerns” (ISO/IEC/IEEE 2011, p. 2)
-Model kind = “conventions for a type of modelling;
Examples of model kinds include data flow dia-
grams, class diagrams, Petri nets, balance sheets,
organization charts and state transition models”
(ISO/IEC/IEEE 2011, p. 2)

13
148 Research in Engineering Design (2022) 33:129–159

Table 10  (continued)
INCOSE activity FBS code sFBS step Comments

2.3 Develop models and views of R, Be, S 2, 5, 6 - “In conjunction with the system requirements defi-
candidate architectures nition process, determine the system context (i.e.,
how the SOI fits into the external environment)
and boundary, including the interfaces, that reflect
the operational scenarios and expected system
behaviors.” (p. 66)
F, Be, S 7, 8, 9 - “Determine which architectural entities (e.g.,
functions, input/output flows, system elements,
physical interfaces, architectural characteristics,
information/data elements, containers, nodes,
links, communication resources, etc.) address the
highest priority requirements” (p. 66)
F, Be, S 7, 8, 9 - “Allocate concepts, properties, characteristics,
behaviors, functions, and/or constraints that are
significant to architecture decisions of the system
to architectural entities.” (p. 66)
R, F, Be, S, F, Be, S, Be, S, D 1, 2, 4, 5, 6, 7, 8, -Select, adapt, or develop models of the candidate
9, 10, 11, 18, architectures of the system, such as logical and
17, 12 physical models.” “The models to be used are
those that best address key stakeholder concerns.
Logical models may include functional, behav-
ioral, or temporal models; physical models may
include structural blocks, mass, layout, and other
physical models” (p. 66)
F, Be, S, F, Be, S 4, 5, 6, 7 - “Determine need for derived system requirements
8, 9 induced by necessary added architectural entities
(e.g., functions, interfaces) and by structural
dispositions (e.g., constraints, operational condi-
tions)” (p. 66)
R, F, Bs, S 1, 2, 20, 19, 13 - “Compose views from the models of the architec-
ture candidates. The views are intended to ensure
that the stakeholder concerns and critical require-
ments have been addressed.” (p. 66)
N/A N/A - “For each system element […] develop require-
ments corresponding to allocation, alignment, and
partitioning of architectural entities and system
requirements to system elements.” (p. 66)
F, Bs, S 4, 5, 6 - “Analyze the architecture models and views for
consistency and resolve any issues identified.” (p.
67)
D, S, Bs, Bs 12, 17, 18, 13, 19, - “Verify and validate the models by execution
14, 15 or simulation […] and with traceability matrix
of OpsCon. Where possible, use design tools to
check their feasibility and validity.” (p. 67)

13
Research in Engineering Design (2022) 33:129–159 149

Table 10  (continued)
INCOSE activity FBS code sFBS step Comments

2.4 Relate the architecture to design S, S 6,9 - “Determine the system elements that reflect the
architectural entities.” (p. 67)
D 18, 17, 12 - “Establish allocation matrices between architec-
tural entities using their relationships.” (p. 67)
“Architectural entities” can relate to F, B and S
(see 2.3 above); “matrices” are external descrip-
tions
Be, S, Be, S 5, 6, 8, 9 - “Perform interface definition” (p. 67) “Preliminary
D 17, 12 interface definition” is part of the output (see
Fig. 2)
S 11 - “Determine the design characteristics that relate to
the system elements and their architectural enti-
ties” (p. 67)
F, Be, S, F, 4, 5, 6, 7 - “Determine need for derived system requirements
induced by necessary added architectural entities
Be, S 8, 9 (e.g., functions, interfaces) and by structural
dispositions (e.g., constraints, operational condi-
tions)” (p. 67)
N/A N/A - “For each system element […] develop require-
ments corresponding to allocation, alignment, and
partitioning of architectural entities and system
requirements to system elements.” (p. 67)
2.5 Access architecture candidates Be 19 - “Using the architecture evaluation criteria, assess
S, Bs 13, 14, 15 the candidate architectures by applying the system
analysis, measurement, and risk management
processes” (p. 67)
D 15, 12, 17 - “Select the preferred architecture(s). This is done
by applying the decision management process.”
(p. 67) The “decision management process” (p.
111/112) includes producing a record of the deci-
sion and supporting documentation (p. 112)
2.6 Manage the selected architecture D 18, 17, 12 - “Capture and maintain the rationale for all selec-
tions among alternatives and decisions for the
architecture […]” (p. 67)
F, Bs, S, F, Be, S 20, 19, 13, 7, 8, 9 - “Manage the maintenance and evolution of the
architecture” (p. 67) Involves analyzing impacts of
context changes to the architecture, using alloca-
tion and traceability matrices (p. 67)
N/A N/A - “Establish a means for the governance of the
architecture” (p. 67)
R, F, Bs, S, F, Be, S 1, 2, 4, 5, 6, 7, 8, 9 - “Coordinate review of the architecture to achieve
stakeholder agreement. The stakeholder require-
ments and system requirements can serve as refer-
ences.” (p. 67)

13
150 Research in Engineering Design (2022) 33:129–159

Table 11  Design Definition (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

3.1 Prepare for design definition Be, Be, S 10, 5, 6 - “Plan for technology management. Iden-
tify the technologies needed to achieve
the design objectives for the system and
its system elements.” (p. 72) Examples
for “technologies” include mechanics,
electronics, software, chemistry, human
operations, and services (p. 71)
S 6 - “Identify the applicable types of design
characteristics for each system element
[…].” (p. 72)
Be, S, S, D 8, 9, 11, 12, 17 - “Define and document the design defini-
tion strategy, including the need for and
requirements of any enabling systems,
products, or services.” (p. 72)
3.2 Establish design characteristics and R, F, Be, Be, S 1, 2, 7, 8, 10, 6 - “Perform requirements allocation to
design enablers related to each system system elements […].” (p. 72)
element Be, S, D, S, Bs 10, 11, 12, 13, 14, 15 - “Define the design characteristics relating
to the architectural characteristics for the
architectural entities, and ensure that the
design characteristics are feasible. Use
design enablers such as models (physical
and analytical), design heuristics, etc.”
(p. 72) “design characteristics” include S
(e.g., shape, p. 73) and B (e.g., resistance
to forces, p. 73)
Be, S, Be, S, D 5, 6, 8, 9, 17, 12 -Perform interface definition; includes both
internal and external interfaces (p. 72)
D 12, 17 - “Capture the design characteristics of
each system element.” (p. 72)
D 12, 17, 18 - “Provide rationale about selection of
major implementation options and ena-
blers.” (p. 72)
3.3 Assess alternatives for obtaining S, Bs 6, 14 - “Identify existing implemented elements
system elements [including COTS or reused system ele-
ments]. Alternatives for new system ele-
ments to be developed may be studied.”
(p. 72)
N/A 15 - “Assess options for the system element
[including the COTS elements, reused
elements and new elements] using the
selection criteria […].” (p. 72)
S 11 - “Select the most appropriate alterna-
tives.” (p. 72)
N/A N/A -IF: decision is made to develop the
system element CONTINUE; ELSE:
Use acquisition process (chp. 6.1) (p. 72)
We assume here that the decision is to
develop the element

13
Research in Engineering Design (2022) 33:129–159 151

Table 11  (continued)
INCOSE activity FBS code sFBS step Comments

3.4 Manage the design D 12, 17, 18 -Capture and maintain the rationale for
all selections among alternatives […]”
(p. 72)
F, Bs, S, F, Be, S 20, 19, 13, 7, 8, 9 - “Manage the maintenance and evolution
of the design” (p. 72)
R, F, Be, S, F, Be, S, D 1, 2, 4, 5, 6, 7, 8, 9, 18, 17, 12 - “Establish and maintain bidirectional
traceability between the architecture enti-
ties […] to the stakeholder requirements
and concerns […]” (p. 72)
D 12, 17 - “Provide baseline information for con-
figuration management” (p. 73)
N/A N/A - “Maintain the design baseline and the
design definition strategy” (p. 73)

13
152 Research in Engineering Design (2022) 33:129–159

Table 12  Implementation (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

5.1 Prepare for implementation S, S, Be, Be, D 13, 6, 5, 8, 12, 17 - “Define fabrication/coding procedures, tools and equip-
ment to be used, implementation tolerances, and the means
and criteria for auditing configuration of resulting ele-
ments to the detailed design documentation.” (p. 78) Input
includes the system design description (p. 77)
R, Be, S, D 2, 3, 8, 9, 17, 12 - “Elicit from stakeholders, developers and teammates
any constraints imposed by implementation technology,
strategy, or implementation enabling systems. Record
the constraints for consideration in the definition of the
requirements, architecture, and design” (p. 78)
Be, S, Be, S, D 5, 6, 8, 9, 17, 12 - “Document the plan for acquiring or gaining access to
resources needed during implementation. The planning
includes the identification of requirements and interfaces
for the enabling system.” (p. 78)
5.2 Perform implementation Be, Be 5, 8 - “Develop data for training users on correct and safe pro-
cedures for operating and maintaining that element […].”
(p. 78)
D 12, 17 - “Complete detailed product, process, material specifica-
tions (“build-to” or “code-to” documents), and corre-
sponding analyses.” (p. 78)
S, Bs, D 13, 14, 15, 17 - “Ensure the realization of the system elements per the
detailed product, process, material specifications and
produce documented evidence of implementation compli-
ance […].” “Conduct peer reviews and testing”, “Conduct
hardware conformation audits” (p. 78)
D 17 - “Prepare initial training capability and draft training docu-
mentation […].” (p. 78)
D 12 - “Prepare a hazardous materials log, if applicable.” (p. 78)
Be, Be 5, 8 - “Determine the packaging and storage requirements for the
system element […].” (p. 78)
5.3 Manage results of implementation D 12, 17 - “Identify and record implementation results.” (p. 78)
D 15, 17 - “Record any anomalies encountered during the implemen-
tation process, and analyze and resolve the anomalies […]
using the quality assurance process.” (p. 78)
R, Be, S, Be, S, D 2, 3, 5, 6, 8, 9, 17, 12 - “Establish and maintain traceability of the implemented
system elements with the system architecture, design,
and system and interface requirements that are needed for
implementation.” (p. 78)
D 12, 17 - “Provide baseline information for configuration manage-
ment.” (p. 78)

13
Research in Engineering Design (2022) 33:129–159 153

Table 13  Integration (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

6.1 Prepare for integration S, Be, F, S, Be, F 6, 5, 4, 9, 8, 7 - “Define critical checkpoints to provide assurance of
the correct behavior and operation of interfaces and
functions of the system elements.” (p. 79)
S, Be, S, Be, D 6, 5, 9, 8, 6, 5, 12, 17 - “Establish the integration strategy that minimizes
integration time, costs, and risks.” (p. 79) Integration
strategy is among the outputs of the process (p. 80)
F, Be, S, F, Be, S, D 16, 5, 6, 7, 8, 9, 18, 17, 12 - “Identify integration constraints on the SOI, arising
from the integration strategy, to be incorporated in
the system requirements, architecture, and design
[…].” (p. 80) E.g., accessibility, safety for integra-
tors, required interconnections of set of system ele-
ments (p. 80) Integration constraints are among the
outputs of the process (p. 80)
N/A N/A - “The acquisition of the enablers can be done through
various ways […].” (p. 80)
6.2 Perform integration S, Be, S 13, 19, 6 - “Assemble the verified and validated system elements
to form the incremental aggregate using the defined
assembly procedures, the related integration enabling
systems, and the interface control definitions.” (p. 80)
Bs, F 14, 15, 16 - “Invoke the system V&V processes, as needed, to
check the correct implementation of architectural
characteristics and design properties and to check
that the individual system elements provide the func-
tions intended.” (p. 80)
6.3 Manage results of integration D, R, Be, S, Be, S, D 12, 17, 2, 3, 5, 6, 8, 9, 17, 12 - “Identify and record the results of integration.
Maintain bidirectional traceability of the updated
integrated system elements with the updated system
architecture, design, and system and interface
requirements. Maintain the records, including con-
figuration updates […].” (p. 80)
D 15, 17 - “Record anomalies observed during the integration
process […], and resolve them using the quality
assurance process […].” (p. 80)
S, Be, S, Be, D 6, 5, 9, 8 - “Update the integration strategy and schedule accord-
12, 17 ing to the progress of the project; in particular, the
order of system elements assembly can be redefined
or rescheduled because of unexpected events or una-
vailability of system elements as planned.” (p. 81)
N/A N/A - “Coordinate integration activities with the project
manager […].” (p. 81)

13
154 Research in Engineering Design (2022) 33:129–159

Table 14  Verification (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

7.1 Prepare for verifica- N/A N/A - “Develop a strategy that prioritizes the verification actions
tion to minimize costs and risks while maximizing operational
coverage of system behaviors:” (p. 83)
R, S 1, 2, 13 - “Establish a list of the items for verification, including
Bs, S, Bs, D, Be, D 14, 9, 8, 12, 17, 10, 17 requirements, architectural characteristics, or design proper-
ties, and define the corresponding verification actions.” (p.
83/84); “The approach to verification should be identified
and documented […] to ensure that the requirement as
written is indeed verifiable. This may require restating a
requirement or decomposing it into several verifiable state-
ments” (p. 84)
R, F, Be, S, F, Be, S, D 2, 4, 5, 6, 7, 8, 9, 18, 17, 12 - “Establish a list of verification constraints that need to be
considered” (p. 84); They include “contractual constraints,
limitations due to regulatory requirements […]”; “Verifica-
tion constraints” are among the outputs of the process (p. 83)
F, Be, S, Bs 20, 19, 13, 14 - “Considering the constraints, plan for the methods or tech-
niques that will be applied” (p. 84)
S, Bs 6, 5 - “Establish the scope of the verification. […] The selection of
S, Bs, D 9, 8, 12, 17 what must be verified should be made according to the type
of system, the objectives of the project, and the acceptable
risks […]” (p. 84) “Scope” is part of the strategy that is an
external output of Verification (p. 83)
S, Bs, S, Bs 6, 5, 9, 8 - “Develop the verification procedures that support the verifi-
cation actions. Schedule the execution of verification actions
in the project steps and define the configuration of submitted
items to verification actions.” (p. 84)
D 12, 17 “Verification procedure” is among the outputs of the process
(p. 83)
Be, S, Be, S 5, 6, 8, 9 - “Identify verification constraints on the system or system
D 17, 12 elements […]. Typical constraints include performance
characteristics, accessibility, and interface characteristics.
Provide the constraint information for consideration in the
system requirements definition, architecture definition, and
design definition process.” (p. 84)
N/A N/A - “Ensure that the necessary enabling systems […] are avail-
able.” (p. 84)
7.2 Perform verification D 12, 17 - “Implement the verification plan […]. That plan includes
detailed descriptions for the selected verification actions”
(p. 84)
S, Be, Bs, Bs, D 13, 19, 19, 14, 17 - “Using the verification procedures [including the items to
be verified, expected results/criteria, verification method],
execute the verification actions and record the results.” (p.
84)
N/A 15 - “Analyze the verification results against any established
expectations and success criteria” (p. 84)

13
Research in Engineering Design (2022) 33:129–159 155

Table 14  (continued)
INCOSE activity FBS code sFBS step Comments

7.3 Manage results of R, S, Bs, D 1, 2, 9, 8, 12, 17 - “Identify and record verification results and enter data in
verification the Requirements Verification and Traceability Matrix
(RVTM)” (p. 84)
D, Bs, Bs 17, 19, 5 - “Record anomalies observed during the verification process,
and analyze and resolve the anomalies (corrective actions
and improvements) […]” (p. 84)
R, Bs, S, Bs, S, D 2, 5, 6, 8, 9, 17, 12 - “Establish and maintain bidirectional traceability of the veri-
fied system elements with the system architecture, design,
and system and interface requirements that are needed for
verification.” (p. 84)
D 12, 17 - “Provide baseline information for configuration manage-
ment.” (p. 84)
S, Bs, S, Bs, D 6, 5, 9, 8, 12, 17 - “Update the verification strategy and schedule according to
the progress of the project; in particular, planned verifica-
tion actions can be redefined or rescheduled as necessary.”
(p. 85)
N/A N/A - “Coordinate verification activities with the project manager
[…]” (p. 85)

13
156 Research in Engineering Design (2022) 33:129–159

Table 15  Validation (numbers refer to sFBS process labels; page numbers refer to INCOSE (2015))
INCOSE activity FBS code sFBS step Comments

8.1 Prepare for validation N/A N/A - “Establish the validation strategy […] including:
-Identify the stakeholders” (p. 90)
S, Bs, D 9, 8, 12, 17 - “The scope of the validation plan [relating to] the
full system, a system element, or an artefact […]
in addition to the delivered system.” (p. 90)
R, F, Be, S, F, Be, S, D
­ F, D 2, 4, 5, 6, 7, 8, 9, 18, 17, 12 - “Establish a list of validation constraints that
need to be considered. The constraints […]
include contractual constraints, limitations due to
regulatory requirements […]” (p. 90); Validation
constraints are among the outputs of the process
(p. 90)
F, Be, S, Bs 20, 19, 13, 14 - “With appropriate consideration to the con-
straints, select suitable validation approach” (p.
90)
S, Bs 9, 8 - “It may be necessary to prioritize the validation
actions […] against constraints, risks, type of
system, project objectives, and other relevant
criteria” (p. 91)
F 16 - “Determine if there are any validation gaps and
that the resulting validation actions will provide
an acceptable level of confidence that the system
or system element will meet the identified
needs.” (p. 91)
R, F, Bs, S 1, 7, 8, 9 - “Ensure appropriate scheduling” (p. 91)
N/A N/A - “Define the configuration of submitted items to
validation actions.” (p. 91)
R, S, Bs, S, Bs 2, 13, 19, 6, 5 - “Identify validation constraints on the system,
arising from the validation strategy, to be incor-
porated in the stakeholder requirements.” (p. 91)
N/A N/A - “Ensure that the necessary enabling systems […]
are available” (p. 91)
8.2 Perform validation S, Bs, S, Bs, D 6, 5, 9, 8, 12, 17 - “Develop the validation procedures that support
the validation actions.” (p. 91) Validation proce-
dure is among the outputs of the process (p. 90)
N/A N/A - “Ensure readiness to conduct validation” (p. 91)
S, Bs, Bs, D 13, 19, 14, 17 - “Conduct validation actions in accordance with
the procedures. […] During the conduct of vali-
dation actions, record the results […]” (p. 91)

13
Research in Engineering Design (2022) 33:129–159 157

Table 15  (continued)
INCOSE activity FBS code sFBS step Comments

8.3 Manage results of validation R, S, Bs, ­DS 1, 2, 9, 8, 12, 17 - “Identify and record validation results and enter
data in the validation report (including any neces-
sary updates to the RVTM)” (p. 91)
D, Bs, Bs 17, 19, 5 - “Record anomalies observed during the validation
process, and analyze and resolve the anomalies
(corrective actions and improvements) […]” (p.
91)
N/A 15 - “Compare the obtained results with the expected
results” (p. 91)
N/A 15 - “Obtain acquirer (or other authorized stakehold-
ers) acceptance of validation results” (p. 91)
R, Bs, S, Bs, S, D 1, 2, 5, 6, 8, 9, 17, 12 - “Maintain bidirectional traceability of the
validated system elements with the validation
strategy, business/mission analysis, stakeholder
requirements, system architecture, design, and
system requirements.” (p. 91)
D 12, 17 - “Provide baseline information for configuration
management.” (p. 91)
S, Bs, S, Bs, D 6, 5, 9, 8, 12, 17 - “Update the validation strategy and schedule
according to the progress of the project; in
particular, planned validation actions can be
redefined or rescheduled as necessary.” (p. 91)

Table 16  Models of designing R F Be Bs S D

and design issues
Pahl/Beitz 4 11 17 5 27 17
INCOSE 50 92 137 91 180 105
RUP 2 13 15 10 31 22
DFSS/ICOV 4 11 17 5 27 17

13
158 Research in Engineering Design (2022) 33:129–159

Table 17  Design phases and R F Be Bs S D

design issues
PB—Task clarification 2 4 5 0 0 5
PB—Conceptual design 1 5 10 2 9 2
PB—Embodiment design 1 2 2 2 16 7
PB—Detail design 0 0 0 1 2 3
RUP—Inception 2 4 3 0 0 3
RUP—Elaboration 0 8 5 4 17 9
RUP—Construction 0 1 7 5 13 7
RUP—Transition 0 0 0 1 1 3
DFSS—Identify 2 4 3 0 0 1
DFSS—Conceptualize 0 2 3 1 6 2
DFSS—Optimize 0 0 0 1 2 2
DFSS—Validate 0 0 0 1 2 2
INCOSE—SysReq Def 5 9 10 0 0 4
INCOSE—Arch Def 7 19 21 8 26 7
INCOSE—Design Def 2 5 11 3 15 8
INCOSE—Implementation 2 0 11 1 8 11
INCOSE—Integration 1 5 11 1 12 6
INCOSE—Verification 4 3 7 16 17 13
INCOSE—Validation 5 5 3 17 16 9

Acknowledgements This research is supported by a grant from the Cascini G, Fantoni G, Montagna F (2012) Situating needs and require-
US National Science Foundation, grant number CMMI-1762415. Any ments in the FBS framework. Des Stud 34(5):636–662
opinions, findings and conclusions or recommendations expressed in Cavalieri S, Pezzotta G (2012) Product-service systems engineer-
this material are those of the authors and do not necessarily reflect the ing: state of the art and research challenges. Comput Ind
views of the National Science Foundation. 63(4):278–288
Chang G-S, Perng H-L, Juang J-N (2008) A review of systems engi-
Funding Open access funding provided by Johannes Kepler University neering standards and processes. J Biomechatron Eng 1(1):71–85
Linz. El-Haik B, Roy DM (2005) Service design for six sigma: a roadmap
for excellence. John Wiley & Sons, Hoboken
Finkelstein L, Archer B, Schwarz KK, Constable GEP (1989) The
Open Access This article is licensed under a Creative Commons Attri-
inter-relationship between systems engineering and engineer-
bution 4.0 International License, which permits use, sharing, adapta-
ing design. IEE Procd A Phys Sci Measure Instrum Manage Edu
tion, distribution and reproduction in any medium or format, as long
136(3):159–164
as you give appropriate credit to the original author(s) and the source,
Forsberg K and Mooz H (1991) The relationship of system engineering to
provide a link to the Creative Commons licence, and indicate if changes
the project cycle, Proceedings of the National Council for Systems
were made. The images or other third party material in this article are
Engineering (NCOSE) Conference, Chattanooga, TN, pp. 57–65.
included in the article's Creative Commons licence, unless indicated
Gero JS (1990) Design prototypes: a knowledge representation schema
otherwise in a credit line to the material. If material is not included in
for design. AI Mag 11(4):26–36
the article's Creative Commons licence and your intended use is not
Gero JS, Kannengiesser U (2004) The situated function-behaviour-
permitted by statutory regulation or exceeds the permitted use, you will
structure framework. Des Stud 25(4):373–391
need to obtain permission directly from the copyright holder. To view a
Gero JS, Kannengiesser U (2014) The function-behaviour-structure
copy of this licence, visit [Link]
ontology of design. In: Chakrabarti A, Blessing LTM (eds) An
anthology of theories and models of design. Springer, pp 263–283
Gero JS, Kannengiesser U, Pourmohamadi M (2014) Commonalities
References across designing: empirical results. In: Gero JS (ed) Design com-
puting and cognition’12. Springer, pp 285–302
Godfrey RM (1990) Some thoughts on engineering systems devel-
Asimov W (1962) Introduction to design. Prentice-Hall
opment. IEE Procd A Phys Sci Measure Instrum Manage Edu
Baines TS et al (2007) State-of-the-art in product-service systems.
137(5):302–308
Procd Instit Mech Eng Part b J Eng Manuf 221(10):1543–1552
Greenacre M (2017) Correspondence analysis in practice, 3rd edn.
Benzecri J-P (2019) Correspondence analysis handbook. Routledge,
CRC Press, Boca Raton
Oxfordshire
Greene MT, Gonzales R and Papalambros PY (2019) Measuring sys-
Blomkvist J (2016) Benefits of service level prototyping. Des J
tems engineering and design thinking attitudes, Proceedings of the
19(4):545–564
22nd International Conference on Engineering Design (ICED19),
Bott MJ, Mesmer B (2019) Determination of function-behavior-struc-
Delft, The Netherlands
ture model transition probabilities from real-world data. AIAA
Gruber TR (1995) Toward principles for the design of ontologies used
Scitech 2019 Forum, San Diego
for knowledge sharing. Int J Hum Comput Stud 43(5–6):907–928

13
Research in Engineering Design (2022) 33:129–159 159

Hamraz B, Clarkson PJ (2015) Industrial evaluation of FBS Linkage— Mikusz M (2014) Towards an understanding of cyber-physical sys-
a method to support engineering change management. J Eng Des tems as industrial software-product-service systems. Procedia
26(1–3):24–47 CIRP 16:385–389
Hein AM, Poulain B, Jankovic M, Chazal Y and Fakhfakh S (2018) MIT (2003) ESD Symposium Committee Overview: Engineering Sys-
Product service system design in a system of systems context: A tems Research and Practice, Working Paper ESD-WP-2003–01.20,
literature survey, Proceedings of the DESIGN 2018 ­15th Interna- Massachusetts Institute of Technology, Engineering Systems Divi-
tional Design Conference, The Design Society, pp. 2891–2902 sion, Massachusetts, MA.
Honour EC (2018) A historical perspective on systems engineering. NASA (2007) Systems Engineering Handbook, NASA/SP-2007-6105
Syst Eng 21(3):148–151 Rev1. National Aeronautics and Space Administration, Washing-
INCOSE (2015) Systems engineering handbook: a guide for system ton DC
life cycle processes and activities, fourth edition, INCOSE- Pahl G, Beitz W (2007) Engineering design: a systematic approach.
TP-2003–002–04. International Council on Systems Engineering Springer, Berlin
(INCOSE), San Diego Patel S, Mehta K (2017) Systems, design, and entrepreneurial thinking:
ISO/IEC (2002) PDTR 19760 Systems Engineering – Guide for ISO/ comparative frameworks. Syst Pract Act Res 30:515–533
IEC 15288 (System Life Cycle Processes), ISO/IEC JTC1/SC7 Pauwels P, Strobbe T, De Meyer R (2015) Analysing how constraints
N2683, Technical Report impact architectural decision-making. Int J Design Sci Technol
ISO/IEC/IEEE (2011) Systems and Software Engineering – Architec- 21(1):83–111
ture Description, ISO/IEC/IEEE 42010:2011(E) Pourdehnad J, Wexler ER and Wilson DV (2011) Systems and design
ISO/IEC/IEEE (2015) Systems and Software Engineering – System Life thinking: a conceptual framework for their integration, Proceed-
Cycle Processes, ISO/IEC/IEEE 15288:2015(E) ings of the 55th Annual Meeting of the ISSS, July 17–22, 2011,
ISO/IEC/IEEE (2018) Systems and Software Engineering – Life Hull, UK
Cycle Processes – Requirements Engineering, ISO/IEC/IEEE Reich Y, Hatchuel A, Shai O, Subrahmanian E (2012) A theoretical
29148:2018(E) analysis of creativity methods in engineering design: casting and
Kan JWT, Gero JS (2009) Using the FBS ontology to capture semantic improving ASIT within C-K theory. J Eng Des 23(2):137–158
design information in design protocol studies. In: McDonnell J, SAE (1999) Processes for Engineering a System, EIA-632, SAE
Lloyd P (eds) About designing: analysing design meetings. Taylor International
and Francis, New York, pp 213–229 Song T (2014) Expert Vs. Novice: Problem Decomposition/Recompo-
Kannengiesser U, Gero JS (2015) Is designing independent of domain? sition in Engineering Design, PhD Thesis, Utah State University,
Comparing models of engineering, software and service design. Logan, Utah
Res Eng Design 26(3):253–275 VDI (2004) Design methodology for mechatronic systems, VDI 2206.
Kannengiesser U, Gero JS (2017) Can Pahl and Beitz‘ systematic Verein Deutscher Ingenieure, Düsseldorf
approach be a predictive model of designing? Design Science von Bertalanffy L (1968) General system theory: foundations, develop-
3:E24 ment, applications. Braziller, New York
Kasser JE (2020) Systems engineering: a systemic and systematic Watson MD (2019) Systems engineering principles and hypotheses.
methodology for solving complex problems. CRC Press, Boca Insight 22(1):18–28
Raton Wynn DC, Clarkson PJ (2018) Process models in design and develop-
Kruchten P (2004) The rational unified process: an introduction. Addi- ment. Res Eng Design 29(2):161–202
son-Wesley, Upper Saddle River
Li M (2002) Fostering design culture through cultivating the user- Publisher's Note Springer Nature remains neutral with regard to
designers’ design thinking and systems thinking. Syst Pract Act jurisdictional claims in published maps and institutional affiliations.
Res 15:385–410
Maier MW (1998) Architecting principles for systems-of-systems. Syst
Eng 1(4):267–284
Meyn SP, Tweedie RL (2009) Markov chains and stochastic stability.
Cambridge University Press, New York, Cambridge

13