Available online at www.sciencedirect.

com

ScienceDirect
Procedia CIRP 100 (2021) 439–444
www.elsevier.com/locate/procedia

31st CIRP Design Conference 2021 (CIRP Design 2021)

Methodology for iterative system modeling in agile product development

Michael Riesenera, Christian Doellea, Stefan Peraua,*, Philipp Lossiea, Guenther Schuha
a
Laboratory for Machine tools and Production Engineering WZL at RWTH Aachen University,
Campus-Boulevard 30, 52074 Aachen, Germany

* Corresponding author. Tel.: +49-241-8020617; fax: +49-241-80620617. E-mail address: [email protected]

Abstract

Nowadays, manufacturing companies are challenged by dynamic market environments caused by increasing globalization, digitization and
climate change. Therefore, the ability to act with speed, flexibility and efficiency in product development becomes inevitable for success.
Moreover, various stakeholder requirements have to be considered and time to market has to be reduced. The development of complex
mechatronic systems also requires an interdisciplinary cooperation of various engineering domains, i.e. mechanics, electrical engineering and
computer science.
Agile product development addresses these challenges with its focus on the iterative development of functional system increments. As a result,
it enables to reduce time to market and improves handling of changing customer requirements. The model-based systems engineering (MBSE)
approach with its centralized system model serves as a single source of truth and data repository. Thereby, it enhances efficiency and transparency
along the product development process. The integration of MBSE into agile product development offers numerous opportunities, such as virtual
prototypes and the build-up of a product’s digital twin. As the design of a complete system model at the beginning of a development process
requires high temporary resources, an iterative approach should be applied to incrementally build the system model along the product development
process.
In this paper a methodology for the iterative system modeling in agile product development is presented. In each agile sprint, design parameters
based on a development question are elaborated. The information that supports answering the development questions is provided by the system
model. Since the system model itself can only provide but not process information it is necessary to select the best toolset to process the necessary
information. By transferring the information back to the system model, the elements of the system model itself are iteratively developed and
updated.
© 2021 The Authors. Published by Elsevier Ltd.
This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientific committee of the 31st CIRP Design Conference 2021.
Keywords: Agile Product Development; Model Based Systems Engineering; Digital Prototype

1. Motivation computer science. This leads to additional complexity through

increased interaction and communication among engineers [3].
Due to dynamic market environments caused by Agile product development addresses the need for shorter
globalization and digitization manufacturing companies have development cycles with its focus on the customers and the
to offer innovative products at competitive prices in shorter iterative development of functional system increments [4]. As
development cycles [1]. Moreover, diverse stakeholder a result, it enables to reduce time to market and improves
requirements with specific market needs have to be taken into handling of volatile customer requirements. The model-based
account in more complex products [2]. The development of systems engineering (MBSE) approach improves the handling
these complex products requires the cooperation of multiple of complexity within the development process through its
engineering domains, i.e. mechanics, electrical engineering and central system model. The system model, which serves as a
data backbone and single source of truth, increases

2212-8271 © 2021 The Authors. Published by Elsevier Ltd.

This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the scientific committee of the 31st CIRP Design Conference 2021.
10.1016/j.procir.2021.05.101

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.
 440 Michael Riesener et al. / Procedia CIRP 100 (2021) 439–444

transparency in communication as well as efficiency along the answer the development question assigned to that sprint [11].
development process [5]. The integration of the customer within agile development
The integration of MBSE into agile product development approaches leads to a faster reaction towards changing market
offers advantages such as virtual prototypes in the context of requirements [12].
different technical domains. But to build a complete system
model at the beginning of the development process, the initial 2.2 Systems Engineering
time-investment is substantial [3]. Therefore, it is reasonable to
Systems Engineering (SE) is a multidisciplinary approach
transfer agile principles to system modeling in terms of
with the focus on the management of highly complex problems
incrementally building up the system model itself along the
[13]. INCOSE defines SE as “a transdisciplinary and
product development process. As the system model can only
integrative approach to enable the successful realization, use,
provide information to answer the development questions it is
and retirement of engineered systems, using systems principles
important to integrate a conveying layer that is able to process
and concepts, scientific, technological and management
the information in order to support answering the development
methods” [14].
question of a specific sprint. Therefore, it is relevant to
Thereby, SE unites all engineering domains in a team-based
systematically select the best toolset. The focus lies on the
approach by describing a structured process that includes the
integration of computer-aided development tools (CAx) CAD,
concept, production and usage of a system. It concentrates on
FEM, MKS and CFD as these are the most formalized tools and
economic as well as technical needs of all stakeholders with the
therefore are well suited to address questions within the
goal of providing a holistic perspective on the focused system
development of complex products.
[15]. The approach of SE is document-based, which implies
The paper focuses on the integration of MBSE into agile
that all development information is stored in textual
product development and especially the specific selection of
specifications and design documents [16]. The exchange of
development tools for the iterative development is addressed
these files results in a limitation of the approach, because it is
by the methodology of this paper. The paper is structured as
a significant challenge to keep the information across several
follows: After the introduction within the first section, the
documents up-to-date and consistent [16].
second and third section introduce the fundamentals and
existing research approaches as well as the addressed research
2.3 Model-based systems engineering
gap. The developed methodology is described in the fourth
section in detail. The last section gives a conclusion and Model-based systems engineering (MBSE) can be seen as
provides potential for further research. an evolution of SE that extends the discipline by a model-
driven approach [17]. INCOSE defines MBSE as "[…] the
2. Fundamentals formalized application of modeling to support systems
requirements, design, analysis, verification and validation
The following section presents the definitions and basics activities beginning in the conceptual design phase and
within the topics of agile product development, systems continuing throughout development and later lifecycle phases"
engineering and model-based systems engineering. [18]. Therefore, a central system model is used within the
development process for the documentation of all information
2.1 Agile product development [18]. This system model itself contains all informational
elements produced in the development process, called artifacts,
The procedural framework in product development is still
and their relations. This data repository is visualized by
dominated by traditional plan-driven approaches [6]. A
graphical modeling languages like SysML for example.
common method is the Stage-Gate-Process by COOPER. The
The modeling elements, called blocks, can be defined
development process is separated into three to six phases,
individually to represent all artifacts of the development
which are called stages. These phases are conducted
process [19]. While a block represents a class of artifacts,
sequentially and milestones, referred to as gates, act as decision
concrete artifacts are modeled by specified instances of the
and control points [7]. Current challenges in the context of
respective block [20]. While a block defines product elements
product development, like shorter development cycles and
in general, a specific instance of that block represents one
higher customer focus are not sufficiently addressed by
specific product element and therefore contains design
traditional approaches. Therefore, agile development process
parameters of an element. In order to deal with the complexity
are divided into multiple sub-processes that are conducted in
of the system model only an excerpt of the elements of the
parallel. One of the most commonly used agile methods is
system model, which is relevant to answer a research question
Scrum [8]. In Scrum, the development process is split into
can be visualized. This excerpt is called view [21]. Additional
iterative development cycles, which are called sprints. At the
computer-aided development tools (CAx) are not part of the
beginning of the development process, existing requirements
system model itself as the system model only stores and
and associated development questions are documented in a
provides information. However, these tools are needed to
product backlog. At the beginning of a sprint a set of prioritized
process the information like design parameters provided by the
requirements is transferred to the sprint backlog [9, 10]. In
system model in order to support answering development
contrast to traditional development approaches, the goal of
questions [22].
each sprint is to deliver and validate a product increment. This
According to FRIEDENTHAL ET AL., the use of MBSE leads
increment is called Minimal Viable Product (MVP) and is a
to an improvement of the communication among stakeholders
version of a product that consists of just enough features to

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.
 Michael Riesener et al. / Procedia CIRP 100 (2021) 439–444 441

within the development process. Furthermore, it improves the addresses the integration of agile principles into the design of a
ability to manage complex systems through the provision of system model.
selected views on parts of the system model. Moreover, it
enables to understand the implications of changes due to Objects Objectives

Question specific
facilitated traceability of requirements and information [16]. Legend:

Iterative system
Description of

Description of
Level of detail of

Agile product

integration of
development

development

development

development
engineering
examination

Technical

modelling
products

artefacts
Systems
3. Related Research

Product

MBSE

tools

tools
This section offers an overview of related research on agile RIESENER ET AL.
BÖHMER ET AL.
development and MBSE. Special attention is placed on KANTELBERG .
approaches that consider the integration of agile principles in SCHUH ET AL.

the system modeling.KANTELBERG defines an agile product EIGNER ET AL

POHL ET AL.
development process for technical products [23]. He deducts SALEHI UND W ANG
agile principles from software development and applies them DOUGLASS

to the development of technical products. Moreover RIESENER SCOTT UND LONG

ET AL. present an approach for the agile sprint planning by Fig.1: Framework of related research review
prioritizing and selecting technical design parameters for a
specific sprint. The design parameters are selected based on Especially the integration of a conveying tool layer
their ability to reduce uncertainty regarding a specific between the system model and the agile development activities
development question [24]. BÖHMER ET AL. [25] and SCHUH ET needs to be emphasized. Therefore, the information provided
AL. [26] highlight the importance of a centralized source of data by the system model in order to answer development questions
in an iterative and interdisciplinary development project. needs to be processed by a selection of tools. Additionally, it
Overall, the described approaches do not introduce a central has to be insured that all information can be modeled on an
system model to document the data. artifact level.
As part of the approaches for system modeling, EIGNER ET
AL. describe the general elements, which a system model in 4. Methodology for iterative system modeling in agile
product development should contain. Nevertheless, the authors product development
miss out on stating these informational artifacts explicitly [27].
Contrarily, POHL ET AL. give a specific description of the The main research question is: “How can a system model be
artifacts to be modeled but do not define specific blocks in a iteratively built along the agile product development process?”
graphical modeling language like SysML. Also, the approach In order to answer this research question, the methodology is
misses a clear focus on the development of technical products, structured in four phases.
as it addresses any complex physical system [28]. However, In the first phase of the methodology specific SysML blocks
none of the existing approaches shows a procedure and a are derived. In the second phase a description framework for
holistic description for building up a system model iteratively. development tools is developed. Based on the description
Correspondingly, integrated approaches of MBSE and agile framework a procedure for the selection of the best toolset to
development need to be considered. SALEHI AND WANG answer a development question is developed. In the last phase
introduce a methodology that all product life-cycle stages of the methodology a process model for iterative system
repeat in an infinity loop-like structure. They highlight the modeling in agile product development is defined. In the
potential of taking agile methods to the field of MBSE. following, the four phases of the methodology are described in
However, the approach does not focus on product development detail.
in particular [29]. DOUGLASS develops three different iteration
cycles based on the V-Model by VDI 2206. On a system model 4.1 First phase: Derivation of specific SysML blocks
level the author describes the modeling of requirements and the
functional structure of the product, but does not cover the The target of the first phase is the definition of specific
product development phase entirely [30]. LONG AND SCOTT SysML blocks in order to have the ability to model all
describe a layer-based approach including iterative system informational artifacts that are accumulated in the agile product
modeling that stops as soon as the necessary level of detail in development process. The specific SysML blocks are derived
development is reached. Since the approach is dedicated to the by following the heuristic screening approach by MAYERS [32].
development of any system, no modeling on the level of The screening consists of the steps collecting, structuring, and
concrete artifacts is described [31]. Overall, the integrated rating and the definition of basic types.
approaches do not consider the integration of development In the first step, 64 informational artifacts, i.e. “product
tools to answer development questions. Also, the approaches architecture” or “sprint backlog”, occurring in the agile product
do not describe how to iteratively build a system model through development process are collected in a longlist [6, 23, 33].
concrete blocks. Afterwards, the identified artifacts are operationalized for its
The analysis of related research (Figure 1), based on the use in MBSE by applying two premises. First, any artifact that
evaluation regarding their fulfillment of the objectives and only documents other artifacts is eliminated, since the
objects of the paper, illustrates the need for an approach that documentation will be exercised by the system model.
Secondly, artifacts have a result-orientated character. Artifacts
carrying relevant information for product development that is

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.
 442 Michael Riesener et al. / Procedia CIRP 100 (2021) 439–444

already expressed by other artifacts are merged. For example, The ability of a tool to process a characteristic is defined as
the artifact “market segments” is merged with “user stories” characteristic value (CV) and the ability of a tool to process a
since the information of the market segments is already property as property value (PV). A four-step scale in analogy
included in the artifact “user stories”. to VDI 2225 [37] will be used for operationalization of the
In the next step, dependencies between the operationalized characteristic value and property value (from 0 = insufficient
artifacts are uncovered using a Design Structure Matrix by to 4 = very well). In Addition to characteristic and property
BROWNING [34]. Dependencies in this context mean that an value, another dimension is added that considers the fact that
artifact is essentially comprised by other artifacts, i.e. the some tools can only be applied at a later stage in the product
artifact “product backlog” is comprised by several development process. They need more characteristics that have
“requirement” artifacts. The result is an extraction of core already been defined to function. For example, the deflection
artifacts, which are independent and thus not comprised of of a metal beam can only be calculated through an FEM tool,
multiple other artifacts. Therefore, the core artifacts can be if characteristics like length, depth and material are already
used as basic building elements to represent any other artifact, defined. Consequently, the dimension degree of product
e.g. the artifact “product structure” can be represented by maturity represents the share of a product’s design parameters
several “component” artifacts. that have already been defined in the development process (low
The last step defines SysML blocks based on the four 0%; medium 50%; high > 90%).
identified core artifacts: requirement, function, component and Figure 2 shows the tool description framework. Each
user story card. Each SysML block includes attributes, which computer-aided development tool can be formally described
document any kind of information related to its type (i.e. along the dimensions displayed. The assigned values need to
requirement block with attributes like origin or description). be defined by designers and developers according to their
The identified block types requirement, function and specific industry and product.
component coincide with already used SysML blocks in
practice. The additional block user story card originates in the 4 3
CV
2 1 0
Tool
0 1
PV
2 3 4
early emphasis on customer focus in agile product Component Structure CAD Functional Properties
development. Furthermore, the user story card could be used to
Strength/Stability Prop.
incorporate elements, which are usually shown isolated in a Position/Orientation
Safety/Reliability Prop.
use-case diagram, with other system elements in an internal Geometry/Topology
block diagram. Material and Surface
Ergonomic Properties

As a result of the first phase, it is ensured that informational Required Degree

Aesthetic Properties

artifact in the agile product development process can be Color of Product Maturity Spatial Prop./Weight
modeled through one or more instances of the defined SysML Internal Relations Manfct./Ass./Test Prop.
low medium high
blocks. Instances of the SysML blocks can thus be used to
incrementally build the system model. Fig. 2: Tool description framework

4.2 Second phase: Development of a description framework As a result of this phase, the development tools are
for development tools characterized through a formal description framework. This
enables the evaluation and provides the basis for the selection
The system model can only deliver and store the information of the development tools in the next phase of methodology.
to answer development questions. Therefore, an information
processing instance is needed. This instance is established by 4.3 Third phase: Development of a procedure for the selection
computer-aided development tools (CAx) since they are able to of question-specific tools
formally support to answer specific development questions.
Multi-physical simulation systems like Matlab are excluded on The target of the third phase of the methodology is to select
purpose as they can solve mathematical problems in any the most efficient combination of tools suited to answer a
context and not specifically for technical product development. specific development question within a sprint of the agile
The tools need to be systematically incorporated as a conveying product development process.
layer between agile product development and system For this reason, the question has to be broken down into
modeling. To integrate these tools, the target of the second affected design parameters. After that, the variety of design
phase is the definition of a description framework for parameters has to be assigned to one of the defined categories
computer-aided development tools. of characteristics in order to enable a connection to the tools
In general, tools can be formally described by their input and that were described on the level of design parameters. The
output as they take existing information and process it to approach by SCHLOESSER [38] is used to derive a prioritized set
generate new insights. The product development process can of design parameters from a development question. Thereby,
be defined according to WEBER as the process of determining the approach selects design parameters by their ability to
properties of a product by defining its characteristics [35]. reduce the uncertainty related to a specific question within the
Therefore, tools can be formally described by the product development process. After that, the design parameters
characteristics as input and the properties they are able to derive are assigned to the predefined categories of characteristics by
as output [36]. To cope with the variety of many different using a Domain Mapping Matrix by EPPINGER AND BROWNING
characteristics and properties, they are grouped into categories [39]. The inner dependencies between the design parameters
of characteristics (CoC) and categories of properties (CoP). also have to be considered while allocating them to a category

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.
 Michael Riesener et al. / Procedia CIRP 100 (2021) 439–444 443

of characteristics. Thereafter, the selection of the required tools itself needs to be incrementally built-up. The aim is to realize a
is made. Therefore, a procedure algorithm is developed to Minimal Viable System Model (MVSM).
select the set of tools that can most effectively process the In the following, the systematic structure of the process
combination of categories of characteristics that the design model for the iterative system modeling is described. At the
parameters of the present sprint were allocated to. The beginning of the development requirements are extracted from
algorithm ensures that several conditions are met. Firstly, only the user story. They are documented as instances of user story
tools meeting the boundary condition set by the degree of card and requirement blocks and connected to each other.
product maturity must be considered. Secondly, every category Thereafter, the development questions that arise due to
of characteristics, to which one or more design parameters in uncertainties of incomplete requirements are collected in the
the current sprint were assigned, must be covered by at least product backlog in prioritized order. The questions are then
one tool with a characteristic value of i.e. ≥ 2 (depends on assigned to a sprint.
desired level of fit). At the beginning of each sprint, the informational set of
Also, the number of tools used in a sprint need to be minimized design parameters, which need to be defined in order to answer
to optimize efficiency. In addition, the share of design the question, are identified. After that, on the model layer the
parameters that were already displayed in a tool in previous informational set is compared to the information contained by
sprints is represented by the implementation share (IS). This is the system model. Therefore, only the relevant block instances
an additional decision support as a high implementation share of the system model are displayed in a view. Some block
correlates with a low implementation effort if a tool was instances of components or functions already contain design
selected. However, the primary decision which tool should be parameters that are part of the required informational set. For
selected is based on the absolute ability of a tool to process the still undefined design parameters a set of tools has to be
design parameters addressed in the respective sprint. In the selected on the tool layer. Therefore, the design parameters are
example illustrated in Figure 2 the CAD tool would be selected mapped to the corresponding categories of characteristics. The
first as it has the highest absolute ability to process the
selection of the best toolset for the categories of characteristics
categories of characteristics in the current sprint. This absolute
of the respective question is made using the described selection
ability relates the sum of characteristic values by a tool to the
maximum sum of CVs possible. The set is completed by the algorithm.
FEM tool as it covers CoC3 more sufficiently than the MKS After the data has been processed by the tool and new
tool. Also, the implementation effort of the FEM tool is lower insights were generated to answer the question, the new
due to a higher IS. information is returned to the system model. For this purpose,
Classes of Characteristics CoCm
the now defined design parameters are added to the system
IS addressed by question model. They can either be added to corresponding instances of
CoC1 CoC2 CoC3 function or component blocks that already exist in the system
CAD 0.7 3 3 0 0.5 model or new block instances have to be modeled. The view on
Tooli

FEM 0.2 0 0 4 0.33 the system model now contains the complete informational set
MKS 0.1 0 0 3 0.25
of design parameters related to the development question.
IS: share of DPs CVmi: value for ability of Absolute ability of a tool
displayed by a tool in Tooli to process CoCm; to process DPs in the Conclusively, the development question can be answered on
previous sprints CVmax=4 current sprint; ∈ [0;1] the product layer with the provided information in the system
Fig. 3: Toolset selection algorithm model. The described process is repeated in the subsequent
sprints. Thereby, the system model serves as a single source of
As a result of that methodological step, an optimized set of
Sprint n Sprint n+1 Final result
tools can be used to address specific development questions.
The integration of the tool selection into the iterative system
Product layer

Development ? Development ? Developed

modeling is described in the following phase. questions questions product

4.4 Fourth Phase: Definition of a process model for iterative

Tool layer

• CAD • MKS • MKS

Custom
system modeling in agile product development Toolset • FEM > Toolset • CFD >
toolsets
• CFD
• …
• … • …

The target of the fourth phase is to define a process model

to build up the system model incrementally along the agile •
<<blockProperty>>
Function A

Attributes
Description •
<<blockProperty>>
Function A

Attributes
Description
•
•
•
<<blockProperty>>
Function B

Attributes
Description
Design parameter
Domain
<<blockProperty>>
Component B
Model layer

Built system
Attributes
• Design parameter • Design parameter • … • Description
• Domain • Domain • Design parameter

product development process. The process model is based on

• … • … • Domain
• …

<<blockProperty>> <<blockProperty>>
Requirement A Requirement A

model
Attributes Attributes
• Origin / Stakeholder • Origin / Stakeholder
• Description • Description
<<blockProperty>>
• Design parameter • Design parameter
• Domain • Domain Function C
<<blockProperty>> <<blockProperty>>
• … Component A • … Component A Attributes
• Description

three levels: product layer, tool layer and model layer. On the
Attributes Attributes • Design parameter <<blockProperty>>
• Description • Description • Domain Requirement B
• Design parameter • Design parameter • …
• Domain • Domain Attributes
• … • … • Origin / Stakeholder
• Description
• Design parameter
• Domain
• …

product layer, the system model must support the agile System model (tn) System model (tn+1)
development activities, which aim to answer a development truth and is able to provide more information to answer the
question by realizing a Minimal Viable Product (MVP) in each development questions as it is iteratively updated and extended
sprint. The tool layer supports to answer development after each sprint. Figure 4 presents the described process
questions with the information provided by the system model. model.
Afterwards, the generated insights by using the specific tools Fig. 4: Incremental system modelling during agile sprints after initiation
are led back to the system model. Thereby, the tool layer itself
fulfills agile criteria since only the best suited tools are used in As a result the fourth phase of the methodology a process
each sprint. But also, on the model layer, the system model model is defined that provides an initial procedure of how to

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.
 444 Michael Riesener et al. / Procedia CIRP 100 (2021) 439–444

incrementally build up a system model incrementally along the guide for the perplexed. Addison-Wesley, Boston.
[13] Abele, T., Editor, 2016. Die frühe Phase des Innovationsprozesses:
agile product development process. Neue, praxiserprobte Methoden und Ansätze. Springer Gabler.
[14] Sillitto, H., Martin, J., McKinney, D., Griego, R., Dori, D., Krob, D.,
5. Summary and Conclusion Godfrey, P., Arnold, E., Jackson, S., 2019. Systems Engineering and
Systems Definitions.
[15] Walden, D.D., Roedler, G.J., Forsberg, K., Hamelin, R.D., Shortell,
The methodology introduced in this paper enables the T.M., Kaffenberger, R., Editors, 2017. INCOSE Systems Engineering
iterative system modeling in agile product development. For Handbuch: Ein Leitfaden für Systemlebenszyklus-Prozesse und -
this purpose, specific SysML blocks are defined in order to Aktivitäten. GfSE e.V.
[16] Friedenthal, S., 2015. A practical guide to SysML: The systems
model all informational artifacts within the agile product modeling language. Morgan Kaufman, Waltham, USA.
development. A tool description framework and a procedure [17] Estefan, J., 2008. Survey of Model-Based Systems Engineering
for the selection of the best suited combination of development (MBSE) Methodologies.
[18] INCOSE, 2007. Systems Engineering Vision 2020: INCOSE-TP-2004-
tools to answer a specific question within a sprint of agile 004-02.
product development process has been developed. In [19] Eigner, M., Roubanov, D., Zafirov, R., Editors, 2014. Modellbasierte
conclusion a process model for the iterative system modeling virtuelle Produktentwicklung. Springer Verlag.
[20] Alt, O., 2012. Modellbasierte Systementwicklung mit SysML. Carl
in agile product development has been presented. The process Hanser Fachbuchverlag, München.
model defines the interrelation between the product layer, the [21] Huth, T., Vietor, T., 2020. Systems Engineering in der
system layer and the required development tools. Produktentwicklung: Verständnis, Theorie und Praxis aus
However, there are still research limitations. Further ingenieurswissenschaftlicher Sicht 51, p. 125.
[22] Vajna, S., Weber, C., Zeman, K., Hehenberger, P., Gerhard, D.,
research has to focus on the specification of the process model Wartzack, S., 2018. CAx für Ingenieure: Eine praxisbezogene
and the systematic development of the system model as well as Einführung, 3rd edn. Springer Vieweg, Berlin.
the validation of the methodology within a case study. The [23] Kantelberg, J., 2018. Gestaltung agiler Entwicklungsprozesse
technischer Produkte, 1st edn.
validation and further investigation of the presented [24] Riesener, M., Doelle, C., Schloesser, S., Schuh, G., 2019. Prototype
methodology is currently part of the research activities of the Design in Agile Product Development Processes for Technical
authors in the department of Innovation Management at the Systems, in Volume 7: 31st International Conference on Design
Theory and Methodology, American Society of Mechanical Engineers.
Laboratory for Machine Tools and Production Engineering [25] Böhmer, A.I., Hofstetter, R., Richter, C., Lindemann, U. et al., 2018.
WZL. Especially the application of the concept will be a main Towards agile product development - the role of prototyping, in
activity within the research environment of the Cluster of Design methods and tools, Curran Associates Inc, Red Hook, NY, p.
1.
Excellence “Internet of Production”.
[26] Schuh, G., Gartzen, T., Soucy-Bouchard, S., Basse, F., 2017. Enabling
Agility in Product Development through an Adaptive Engineering
Acknowledgement Change Management 63, p. 342.
[27] Eigner, M., Dickopf, T., Huwig, C., 2016. An Interdisciplinary Model
Funded by the Deutsche Forschungsgemeinschaft (DFG, Based Design Approach for Developing Cybertronic Systems, in The
German Research Foundation) under Germany ́s Excellence Design Society: DS 84: Proceedings of the DESIGN 2016 14th
International Design Conference., p. 1647.
Strategy – EXC-2023 Internet of Production – 390621612. [28] Pohl, K., Hönninger, H., Achatz, R., Broy, M., 2012. Model-Based
Engineering of Embedded Systems: The SPES 2020 Methodology.
References Springer, Berlin, Heidelberg.
[29] Salehi, V., Wang, S., 2019. Munich Agile MBSE Concept (MAGIC)
[1] Schuh, G., 2012. Innovationsmanagement: Handbuch Produktion und 1, p. 3701.
Management 3, 2nd edn. Springer, Berlin, Heidelberg. [30] Douglass, B.P., 2016. Agile systems engineering. Morgan Kaufmann,
[2] Schuh, G., Riesener, M., 2017. Produktkomplexität managen: Waltham, USA.
Strategien - Methoden - Tools, 3rd edn. Hanser, München. [31] Long, D.A., Scott, Z.B., 2011. A primer for model-based systems
[3] Toepfer, F., Naumann, T., 2017. Parameter Management, a Novel engineering. Vitech, Blacksburg, USA.
Approach in Systems Engineering, in Research into design for [32] Mayers, B., 1997. Prozeß- und Produktoptimierung mit Hilfe der
communities: Proceedings of ICoRD 2017, Springer, Singapore, p. statistischen Versuchsmethodik. Shaker, Aachen.
383. [33] Ehrlenspiel, K., Meerkamm, H., 2013. Integrierte
[4] Schwerak, J. Sicherheit durch Agile, in Der F&E Manager, p. 24. Produktentwicklung: Denkabläufe, Methodeneinsatz,
[5] Kleiner, S., Husung, S., 2016. Model Based Systems Engineering: Zusammenarbeit, 5th edn. Hanser, München.
Prinzipen, Anwendung, Beispiele, Erfahrung und Nutzen aus [34] Browning, T.R., 2001. Applying the design structure matrix to system
Praxissicht, in Tag des Systems Engineering, Carl Hanser Verlag decomposition and integration problems: a review and new directions
GmbH & Co. KG, München, p. 13. 48, p. 292.
[6] VDI - Verein Deutscher Ingenieure. Entwicklung technischer Produkte [35] Weber, C., 2007. Looking at “DFX” and “Product Maturity” from the
und Systeme Modell der Produktentwicklung, Berlin. Beuth Verlag, Perspective of a New Approach to Modelling Product and Product
2019(VDI 2221). Development Processes, in The Future of Product Development,
[7] Cooper, R.G., 1990. Stage-gate systems: A new tool for managing Springer Berlin Heidelberg, Berlin, Heidelberg, p. 85.
new products 33, p. 44. [36] Weber, C., Werner, H., 2000. Klassifizierung von CAx-Werkzeugen für
[8] Schwaber, K., 1997. Srum Development Process, in Business Object die Produktentwicklung auf der Basis eines neuartigen Produkt- und
Design and Implementation, Springer London, London, p. 117. Prozessmodells. Universität des Saarlandes.
[9] Schuh, G., Diels, F., Ortlieb, C., Riesener, M. et al., 2017. Agile [37] VDI - Verein Deutscher Ingenieure. Konstruktionsmethodik
Produktentwicklung, in Internet of Production für agile Unternehmen, Technisch-wirtschaftliches Konstruieren, Berlin. Beuth Verlag,
Apprimus Verlag, Aachen, p. 29. 1998(VDI 2225 Blatt 3).
[10] Gabrysiak, G., Edelmann, J., Giese, H., Seibel, A., 2010. How [38] Schloesser, S., 2020. Auslegung prototypischer Produktinkremente im
Tangible can Virtual Prototypes be?, in Proceedings of the 8 th design Kontext agiler Entwicklungsprojekte, Aachen.
thinking research symposium, p. 163. [39] Eppinger, S.D., Browning, T.R., 2012. Design structure matrix
[11] Kniberg, H., 2013. How Spotify builds products. methods and applications. MIT Press, Cambridge.
[12] Boehm, B.W., Turner, R., 2004. Balancing agility and discipline: A

This is a resupply of March 2023 as the template used in the publication of the original article contained errors. The content of the article has remained unaffected.