# Innovation Management Needs an Interoperable Requirements Management

Katja Landgraf, Roland Jochem

<figure><img src="image_1.png" /></figure>

## To cite this version:

Katja Landgraf, Roland Jochem. Innovation Management Needs an Interoperable Requirements Management. 4th International Working Conference on Enterprise Interoperability (IWEI), Sep 2012, Harbin, China. pp.5-19, 10.1007/978-3-642-33068-1_3. hal-01515731

HAL Id: hal-01515731

https://inria.hal.science/hal-01515731

Submitted on 28 Apr 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Innovation Management needs an interoperable Requirements Management

Dr.-Ing.; Dipl.-Wirtsch.-Ing. Katja Landgraf, Slitisa, Germany

Univ.-Prof. Dr.-Ing. Roland Jochem, Chair Quality Sciences, TU Berlin, Germany, Institute of Machine Tools and Factory Management (IWF)

## Abstract

In a world of fast changing environments for business, the need for innovation is one of the most stable items. On the other hand, innovation is influenced by more and more factors, like increasing products and service complexity or growing numbers of partners, involved into a single product innovation. This paper introduces interoperability problems related to simultaneous business and product development.

**Purpose** – This paper introduces the L-model[^1], an advancement of the V-model. Due to interoperability is essential during the product development process, overall aim of the L-model[^1] is to improve the quality and rate of innovation within complex systems during the early stages of a stable and simultaneously agile innovation process.

**Design/methodology/approach** – The basis of the L-model[^1] consists of the interoperability between the innovation process and the requirements management & engineering process (RM&E process) as well as the agile method Scrum. To link these processes, a best practice model inclusive a capability model and a performance measurement system has been developed.

**Findings** – An increase of innovation quality and innovation speed at complex systems during the early stage of a reliable and simultaneous agile innovation process.

**Originality/value** – The paper focuses on the innovation process during the product development and how to improve its quality.

**Keywords** – Interoperability, innovation management, requirements management & engineering process

**Paper type** – Research paper

## 1 Introduction

Innovations and their transformation into the product development process must be made comprehensible and assessable, in order to be able to minimize the associated risks. The planning of preventive quality measures to avoid unnecessary iterations and interface problems during the innovation and product development process are tasks, which shorten development times dramatically. There is no lack of innovative ideas, but their application and marketing in the form of innovative products, services and procedures. Thus for example each fourth patent of a patenting enterprise is not brought on the market in Germany - the German economy sits thereby on not realized assets of at least 8 billion Euros in terms of innovative products, services and procedures [8]. The consequences of a suboptimal innovation process can be dramatically: Who did not carry out innovations, is often to be found on the list of those ranges, which are dropped out of the market [4].
By modeling of business and product development processes the goal is pursued to increase clarity and comprehensibleness in the product development. Process admission, visualization and partially also simulation are state of the art. Today the problem is seen in the missing systematic connection between the business and the product development process, the associated models exists to a large extent independently and changes in one model are only comprehensible manually in another model. That leads to the fact that such models are not "living" and find no acceptance in the operational departments. Context and/or view-referred exchange of information and models are missing.

A substantial deficit of present processes is still the missing systematic continuity in communication between the specialized divisions and to the suppliers. System specifications during the collaborative product development process must be described more precisely, semantically clearly and above all computer-interpretable, in order to eliminate for example misunderstandings and to test the development results against the requirements.

## 2 Innovation Management

The innovation is the result of a process or even the process itself, all phases by the idea preparation over the idea conversion up to the idea utilization, or differently said to the introduction on the market and economic use. Innovation, and the scientific analysis of this area, is no new topic of the economy. Already in 1931 the Austrian political economist Alois Schumpeter has innovated an "Enforcement of new combinations", with which enterprises leave from pecuniary reward them, "reeled out courses of the static economy" [13]. The enforcement of new combinations Schumpeter refers to the production of a novel product or a new production method, the development of a new sales market or the reorganisation of an enterprise.

This traditional understanding of innovation has changed particularly in the last years. Besides the radical-revolutionary changes, as they are connected with the application of new active principles or a complete reorganization of processes and structures, also incremental evolutionary innovations have increasingly obtained attention, as for example the continuous improvement of single product or process parameter [10].

Innovation management is understood as systematic planning, conversion and control of ideas in organizations. The management of innovations is part of the enterprise strategy and can refer to products, services, manufacturing processes, organisational structures or management processes. While product innovations usually aim at to satisfy the needs of customers better, process innovations are usually aligned to improvement of effectiveness and efficiency of procedures.

The continuously decreasing developmental periods, the increasing number of technologies and their system connections, the numerous global process interfaces during and besides the product engineering process, the extension of customer markets, increased expense pressure and much more – all this leads to a more and more complex innovation process which needs to be stably controlled [3, 6] and at the same time flexible and agile enough to fit changing circumstances (of customers, of markets, of laws, etc.).
The manufacturers along the value chain have to develop and produce more and more efficient and innovative products of higher quality, providing a large number of individual variants. [14] To develop innovative product in short clock cycles, interoperability between standards in quality and processes inside and outside the company is essential. Thereby it is a general rule to keep the balance between the required stability and needed process agility, operations and methods. The stability is primarily gained by the definition of standards in quality and processes. But what is the required level of standardization at a creative innovation process?

If the complex standards are completely realized and lived out within the process, the coefficients “time” and “expenses” get out of hand. Due to this, innovations might reach the market too late, possibly accompanied by significant expenses.

The target has to be the definition of a reliable standard in quality and processes and to simultaneously be flexible or agile enough to fit rapidly changing circumstances.

## 3 Basic Concept of the L-model<sup>Agile</sup>

The L-model<sup>Agile</sup> is concerned in detail with these early stages of the innovation process of complex systems at the vehicle industry with the target of securing and improving the innovation quality using the agile Scrum methods. The application of Scrum at the early stages of the innovation process shall enable a focused communication of the required inputs and outputs between all participants with the right quality, the respective expenses and at the scheduled time. Besides the application of Scrum for planning and controlling the innovation process, the requirements management & engineering (RM&E) plays another key role for the communication of quality requirements within the innovation process. By the interoperability of RM&E at the early stages of the innovation process a structured approach for identification, documentation and administration of relevant market, competition and customer requirements is given. This ensures the communication between all relevant quality requirements.

The L-model<sup>Agile</sup> consists of four parts. The first one is the so called innovation requirements process (IR process<sup>Agile</sup>). It includes a methods catalogue, process templates and a role model. For its execution are two essential documents provided, which enables a prototypical realization.

Second part of the L-model<sup>Agile</sup> is a catalogue of indication numbers which was developed to control and improve the process. The third part, the so called innovation requirements maturity model rates the execution of the L-model<sup>Agile</sup> and suggests actions for a continuous improvement.

Afterwards, as part four, the whole information is summarized into a web-based approach guideline.

The Structure and the four parts of the model are explained below.
The intention of the L-model^Agile^ is to build on existing and established research concepts. The V-model is already established at the whole vehicle industry, it was seen as a starting point for the L-model^Agile^.

The V-model is applied at almost every company of the vehicle industry. The name occurs from the V-shaped structure of the project elements. The “V-shape” expresses the equivalent verification and validation step at each conception step. The needed requirements on the developed system of the later user for instance are specified at a product requirement document or a requirements specification. The approach during the development is supported by concepts and proposals. [7, 11]

Another basis for the L-model’s structure besides the V-model is the interoperability of the RM&E and the innovation management with Scrum to a so called innovation requirements process^Agil^ (IR process^Agil^).

The created IR process^Agil^ illustrated that the V-model and in concrete the first element of the V-model, the “requirements identification and specification”, was not sufficient for the required context at a systematic analysis and valuation of ideas, resp. future innovations. Therefore the approach of the L-model^Agile^ is to expand the V-model by the context, resp. the stages of the idea development and thereby the fragmentation and specification of an idea.

The expansion consists of three elements:

* Element 1: Potential determination and first framework conditions

* Element 2: Idea determination, including first requirements

* Element 3: Idea release for execution

To keep the “symmetry” at the L-model, the elements of the V-model have been turned by 45° and expanded by the elements of idea fragmentation and specification.

The components of the V-model including the extensions build the structure of the L-model^Agile^ (Figure 1).

The elements of the structure of the L-model^Agile^ work as gates within the IR process^Agile^, illustrated by a traffic light. The elements of the left stem are, as at the V-model, validated with the requirements of the right stem. The first three elements are proven by identified lessons learned information from the whole supply chain and thereby the innovation process is continuously improved.
<figure><img src="image_3.png" /><figcaption>Fig. 1: structure of the L-model<sup>Agil</sup></figcaption></figure>

As shown in Figure 1, the IR process starts with the systematic generation of an idea – stage 0, the “problem and requirements identification”.

The stakeholder identification and the competitive intelligence at this stage should in concrete identify the heterogeneous customer wishes and the requirements of the market and the competition which are later integrated to stage 1, the “idea and requirements identification”. The gate between stage 0 and 1 is considered as a quality check for the collected information. The quality control ensures a qualitatively high level of information of each requirement, resp. information. This prevents misunderstandings by the systematic generation and collection of information and requirements.

Within the IR process<sup>Agile</sup> an idea can be generated systematically from the market (at stage 0) or “unsystematically”(without market research directly at stage 1), e.g. by employees in shape of lessons learned. Thereby an early requirements analysis and modeling (by UML/SysML/Swimlane) at stage 1, the “idea and requirements identification”, improves the quality of analysis and valuation of ideas already at the beginning and supports the decision makers at the valuation process. In turn this minimizes the miscalculations and improves the innovation quality. Using the model-based and systematic analysis and valuation helps to make out risks early. A gross valuation of the idea finishes stage 1.

At stage 2, the “idea analysis and valuation”, the analysis and valuation of an idea gets refined with support of the RM&E. By doing so, risks can be rated successively and measures can be initialized early. The development expenses and time can be minimized by early detection of risks and an exact, model-based specification. Afterwards the decision maker at the stage 2
gate decides about release and realization of the idea, another improvement loop or the abandonment.

When the decision is made to release the idea for realization, stage 3 begins - the idea specification and requirements v&v (verification and validation). Focus of stage 3 is the exact specification of the idea and the quality check of the requirements. In parallel a marketing concept is developed. By the support of the RM&E and the requirements structure from the systems engineering, the model-based idea specifications get a high level of information and reduce miscalculations. In addition these information can efficiently be forwarded to adjacent process interfaces, e.g. the product development (stage 4 of the "overall specification").

The respective subsystems as well as their architecture are further specified afterwards at stage 5 ("system architecture / specification") and stage 6 ("subsystem architecture / specification") before the realization, the implementation and the testing happen at stage 7. After the system tests are passed, series production happens at stage 8 with the following stage 9, the "market launch". The 10 stages are accompanied in parallel by the controlling and management.

The four elements of the L-model<sup>Agile</sup> are explained below.

## 4 Elements of the L-model<sup>Agile</sup>

As already introductorily mentioned, the four main elements of the L-model<sup>Agile</sup> are, besides the IR process<sup>Agile</sup> (element 1), a key figures catalogue for process controlling (element 2), a maturity level model for model realization valuation (element 3) and a web-based approach guideline which shows the whole information, including an implementation concept (element 4). These four elements are now introduced below. This paper focuses in concrete on the early stages of the innovation process, the so called idea development stages at the IR process<sup>Agile</sup>.

### 4.1 The Innovation Requirements Process at the L-model<sup>Agile</sup>

#### (Methods & Elements)

An innovation process has to continuously fit new framework conditions. Due to this time pressure, a substantial application of the processes isn't always possible. Additionally, especially at this stages of creativity, communication inside and outside the company are an important factor of success. Therefore the innovation process has to be agile. The agile approach within the L-model<sup>Agile</sup> is explained below.

Agile methods are based upon the four basic rules of the "agile manifest": [1]

* "Individuals and interactions over processes and tools

* Working software over comprehensive documentation

* Customer collaboration over contract negotiation

* Responding to change over following a plan"
An agile approach is especially defined by the great variance of methods, their appropriate choice, continuous valuation and their change of necessary. Agile means to choose the appropriate method out of an obviously endless amount of possibilities and to use & abuse it. [11] Scrum was chosen for the integration of an agile method into the model.

Scrum shows rules for the planning and controlling of projects. A Scrum project consists of several iterations (sprints) which are supported by team conferences (sprint meetings). Responsibilities, deadlines and results are clearly defined by sprints. Thanks to scrum, the IR process<sup>Agile</sup> consists of a clearly structured approach and due to this it is easily and systematically realizable. The sprints are determined by the stages of the IR process. A sprint lasts approx. 30 days, but its duration is company-dependent and is therefore defined as a "time box" at the L-model<sup>Agile</sup> (see Figure. 2). [12]

Before each spring information is taken from a pool, the so called product backlog, and afterwards processed by the scrum team. Depending on the stage, this can be a pool of requirements, potentials, frame conditions or ideas. [15]

Before a sprint can start, the sprint result or output is exactly defined. During the sprint, the scrum master cares for the scrum team not to be interrupted or disturbed in developing the sprint output. The team acts selforganizingly and comes together in sprint meeting during the sprint which happen daily or in larger periods. Questions on the development side, the product owner, can be cleared and problems can be discussed by the scrum master moderated meetings. The product owner in this case represents the technical commission side. [12]

The defined sprint results are presented to the product owner (or in case to the customer) at the sprint review to obtain a recent feedback. Every sprint review is defined by the gates of the L-model<sup>Agile</sup>. At the review the decision is made whether the predefined sprint output has been reached or not. If not, either the specific sprint has to be repeated or the product backlog has to be updated. The following sprint retrospective meeting contains the continuous improvement and lessons learned at the process. Supported by the innovation maturity level, potentials can be identified and realized at this point to rise in efficiency and effectiveness. [12]

The approach of the agile methods at the IR process<sup>Agile</sup> is introduced below by reference of the stages 0-3.
<figure><img src="image_4.png" /><figcaption>Fig. 2: Scrum at the L-model<sup>Agile</sup></figcaption></figure>

Deadlines, responsibilities and the result to be developed can be clearly defined and realized for each stage by scum. Due to this, decisions can quickly be made and aren't placed on hold if the scum rules are attended.

## 4.2 The Process Templates

At the L-model<sup>Agile</sup>, the model merely serves as reference book which consists of four additional process templates besides the IR process<sup>Agile</sup>, which show the IR process without the scrum support and separately illustrates the innovation and RM&E process. The fifth process template consists of the innovation requirements process especially for the generation and implementation of innovations in process, socials and organization, because the IR process moreover focuses on the product innovations.

## 4.3 The Methods Catalogue

The provided methods catalogue consists of valuation, quality and risk management methods, determination techniques and modeling models which support the process for an improvement of innovation quality at the vehicle construction. The exact and process-oriented assignment of methods enables a context- and company-dependent choice of the methods per process. The methods catalogue provides overall 106 methods and model diagrams (e.g. UML/SysML diagrams or a feasibility and economy) which are available to the involved persons.
## The Role Model

The IR process<sup>Agile</sup> consists of six roles at the stages 0-3 (see Figure 3).

<figure><img src="image_5.png" /><figcaption>**Fig. 3:** role model of the L-model<sup>Agile</sup></figcaption></figure>

Due to the role description of the L-model, personal tasks, the requirements on a role occupant, the competences and duties are exactly defined. All roles of the model permanently have to stay in contact to each other to be able to efficiently and effectively analyze and rate an idea.

As communication media and checklist, the involved persons are supported in the process by two central documents, the idea description and the requirements chart. Each role has access to these documents to write down their knowledge, resp. their results. With this systematic and transparent collection of information and requirements, the flood of documents and the search for the location of a specific information for an idea shall be minimized.

## The Central Documents

There are two key documents at the L-model<sup>Agile</sup>, the idea description and the requirements chart, which ensure communication between quality criteria.

The idea description displays all relevant information about an idea. Here, all required information of each stage and process, including the responsibilities, are illustrated in the form of a checklist. In parallel, the required input and output are necessary as well as the applicable methods are shown for each process in a table.

The second key document at the IR process<sup>Agile</sup> is the requirements chart. All existing requirements, framework conditions, and others belonging to the idea are collected here and assigned to a system structure. The existing requirements, including the attributes, the system
elements of the system requirements and, if possible, up to the component requirements are
honed down thereby.

By means of the idea description and the requirements chart, the ideas are continuously
refined and specified from stage to stage. Due to this, the collected information can be
delivered to the product development process afterwards in a transparent and systematic way.

The connection between the idea description and the requirements chart ensures a continuous
information flow and by association a communication between quality criteria within the IR
process at stages 0 to 3. Figure 4 illustrates through an example the flow of methods and
information. In this case exemplary with the methods QFD and FMEA.

<figure><img src="image_6.png" /><figcaption>**Fig. 4:** Connection between requirements and methods from the IR process<sup>Agil</sup> – here exemplary with the methods QFD and FMEA</figcaption></figure>

The Figure 4 illustrates that at stage 0 the detection of first customer requirements into a
requirements chart and thereby a direct assignment into the process structure can be done. A
Transformation of customer requirements into system requirements as well as the integration
of lessons learned at previous projects happens at stage 1, the determination of ideas and
requirements. For example, the requirement/features, the requirement title as well as possible
stakeholders and the originator of the requirement are rudimentarily specified at this point.

Basing on this information, requirements can now be technically prioritized by the QFD at
stage 2 (analysis and valuation of ideas), as well as malfunctions and prevention actions can
be generated for the product development with the aid of FMEA.

Stage 3 completes the requirements chart by filling out the relevant attributes of each idea. Among the specification of stage 3 is the verification and validation of the requirements. Only if verification and validation are passed successfully, the idea description and the requirements chart can be forwarded to the product development, resp. stage 4 of the IR process<sup>Agile</sup>. In this case, the verification and validation ensure a high standard in quality of the relevant information of an idea and a high level of communication between quality requirements.

The introduced methods and elements are the first part of the L-model<sup>Agile</sup>. The following chapter shows the three other elements of the L-model<sup>Agile</sup>.

## 4.4 The Key Figure Catalogue at the L-model<sup>Agile</sup>

Elementary for the consequent controlling of the process is the definition and detection of key figures. The L-model<sup>Agile</sup> got a key figure catalogue, consisting overall 80 key figures and metrics, e.g. the number of ideas or the productivity at the IR process<sup>Agile</sup>.

Thereby the key figure categories are organized in four organization fields. The organization fields are in a complex correspondence with each other. [15] They are deducted basing on specific (corresponding to the process field) and generic targets (process overlapping) and their critical success factors and (time) drivers.

<figure><img src="image_7.png" /><figcaption>**Fig. 5:** organization fields of the key figure system</figcaption></figure>

Among the process controlling, the valuation of the process realization is appreciable for the
continuous improvement. A specific maturity model, the so called innovation requirements
maturity level model, which is explained below, has been developed for the IR process at
stages 0 to 3.
4.5 The Maturity Model of the L-model<sup>Agile</sup>

The application of the innovation requirements maturity model refers to the stages 0 to 3 of the IR process at the vehicle construction. Thereby it does not only consider the realization of the early stages of the innovation process at complex systems, it also considers the implementation of RM&E at these stages up to the product development process.

The IRM refers on the four organization fields of the key figure development. At the IRM one can choose of two valuation schemes. Thereby a distinction is made between the determination of the maturity level and the determination of the ability level.

• Valuation procedure 1: This procedure identifies the maturity level of the innovation requirement. Thereby the abilities of the organization [9] referring to the thematic of the L-model<sup>Agile</sup> based on the four organization fields are rated.

• Valuation procedure 2: Procedure 2 is used to identify the ability level of a process field. [9] The valuation of the IR ability bases on the “IR process” organization field. Within this organization field, the process field innovation management, RM&E, risk management, quality management and idea-development/product-development process interface are rated.

Depending on the chosen valuation procedure, follows an actual-theoretical comparison on basis of interviews, respectively metrics, identification of the maturity level, respectively the ability level, and the identification of recommendations and improvements to obtain the next level. The following Figure 6 once again shows the two valuation procedures and their points of maturity level identification, respectively ability level identification.

<figure><img src="image_8.png" /><figcaption>Fig. 6: Valuation approaches at the innovation requirements maturity model</figcaption></figure>
Basing on a valuation scale, the characteristics of organization fields can be measured and
then be used for action advices to reach the next level. The results of these valuations can be
categorized in 5 maturity levels.

Besides the already shown parts of the L-model^Agile, comes up a fourth part now, the web-
based approach guideline.

4.6 Web-based Approach Guideline of the L-model^Agile

The approach guideline is meant to support the vehicle construction companies at the
introduction and realization of the L-model^Agile. The process-oriented approach guideline can
be used to look up in which order the processes at the L-model, respectively the IR process,
are run through, which methods can be applied and which information is required for a
specific result. After the adoption on the respective company, the approach guideline is
primary suitable as a job instruction and a reference book, or secondarily as an addition to
schoolings on the model. Due to the html format, the user can obtain information on each
process, data or the roles at the model by the data structure of directly process-oriented. The
Figure 7 illustrates that html format.

<figure><img src="image_9.png" /><figcaption>Fig. 7: web-based approach guideline</figcaption></figure>

The web-based approach guideline is the fourth part at the L-modelAgil. The main parts of
the L-model^Agil are once again represented in summary below.
# 5 Summary of the L-model<sup>Agile</sup>

Until now the knowledge in innovation and engineering processes, for example why the approach to a solution was dropped or followed up at the concept phase, usually just remains at the constructers and the developers. A whole view about the product and the experiences made during the development is limited to the parties concerned to the project.

How far the knowledge is going to be shared and used for new developments just depends on the communication and informal networks of the employees within the company. Because of this, the goal is to optimize the innovation realization process to raise the innovation-tempo and quality by model based consistent systems engineering at the product development process. Thereby innovations have got to describe formal and systematic. The degree of performance (maturity) along the product development process has to become measurable. Therewith it is possible to achieve an essential part to the input of innovation quality and to the decrease of costs (for example by discontinuation of additionally prototypes by using documented experiences at the model) (see [2, 5]).

The L-model<sup>Agile</sup> provides an approach for increasing the innovation quality and communication at the early stages of vehicle construction. The L-model<sup>Agile</sup> exhibits a standardized process (IR process<sup>Agile</sup>) with methods, procedures and checklists, which enables the formal and systematic description and valuation of ideas and due to this, it simplifies the communication between quality criteria. Ideas can systematically be created, referring to the innovation strategy and the ideas identified at the market research. The preventive application of methods reduces needless iterations and interface problems during the IR process (stages 0 to 3) right up to the product creation process interface. Innovations and their realization at the product development process are reconstructable and valuable in order to reduce risks.

Thereby the description and valuation of ideas is done by two key documents, the idea description and the requirements chart. By doing so, the whole information of an idea is described by to documents or at least by multiple documents referring to them. Due to this, the information collected at the innovation process can be used systematically.

The realization of the process can be controlled using the second part of the L-model<sup>Agile</sup>, the key figures.

The realization of the L-model<sup>Agile</sup> can be valued by the maturity model afterwards to generate a guideline for a continuous improvement.

The four parts of the L-model<sup>Agile</sup> can be provided to the vehicle industry by a web-based approach guideline.

The L-model<sup>Agile</sup> is a reference book and offers an agile but although stable approach in quality communication to quickly obtain first successes in increasing quality and rate of innovation with minimal bureaucracy and maximum discretionary.
## 6 References

[1] Agile Alliance, 2001, Manifesto for Agile Software Development (Online available at http://agilemanifesto.org, last update 2001, last check 11.10.2010).

[2] Ahlemann, F., Schroeder, C., Teuteberg, F.: Kompetenz- und Reifegradmodelle für das Projektmanagement - Grundlagen, Vergleich und Einsatz, ISPRI-Arbeitsbericht Nr. 01/2005. (2005)

[3] Becker, H.: Phänomen Toyota, Erfolgsfaktor Ethik, Springer-Verlag, Berlin Heidelberg. (2006)

[4] Bericht zur technologischen Leistungsfähigkeit Deutschlands, BMBF. (2005)

[5] Carnegie Mellon University Software Engineering Institute (SEI): CMMI-DEV, V1.2.

[6] Doppler, K. Lauterburg, C.: Change Management, den Unternehmenswandel gestalten, Campus Verlag, Frankfurt. (2002)

[7] Ebert, C.: Systematisches Requirements-Engineering und Management. Anforderungen ermitteln, spezifizieren, analysieren und verwalten. 2., aktualisierte und erw. Aufl., dpunkt-Verlag, Heidelberg. (2008)

[8] Institut der deutschen Wirtschaft Köln (IW): Das Innovationsverhalten der technikaffinen Branchen. (Gutachten) Studie im Auftrag des Vereins Deutscher Ingenieure (VDI). (2006)

[9] Liggesmeyer P.: Software-Qualität – Testen, Analysieren und Verifizieren von Software; 2. Auflage, Spektrum Akademischer Verlag, Heideberg. (2009)

[10] Pleschak, F./ Sabisch, H.: Innovationsmanagement, Stuttgart, S.6. (1996)

[11] Rupp, C., Die Sophisten: Requirements-Engineering und -Management. Professionelle, iterative Anforderungsanalyse für die Praxis. 4., aktualisierte und erw. Aufl., Carl Hanser Verlag, München. (2007)

[12] Rupp, C.; Hruschka, P.; Starke, G.: Agility kompakt; Spektrum Akademischer Verlag, Heidelberg. (2009)

[13] Schumpeter, J. A.: Theorie der wirtschaftlichen Entwicklung, in Vahs, D./ Burmester, R.: Innovationsmanagement, S. 3, Stuttgart. (1999)

[14] Siemens AG: Transformation des Innovationsprozesses in der Kraftfahrzeugindustrie, Siemens Product Lifecycle Management. (2008)

[15] Spath, D.; Wagner, K.; Aslanidis S.; Bannert M.; Rogowski, T.; Paukert M.; Ardilio A.: Die Innovationsfähigkeit des Unternehmens gezielt steigern. In: Bullinger, Hans Jörg (Hg.): Fokus Innovation. Kräfte bündeln – Prozesse beschleunigen, Carl Hanser Verlag, München, p. 41-109. (2006)
# 7 About the Author

Prof. Dr.-Ing. Roland Jochem

Head of Chair Quality Management, Berlin Institute of Technology, Germany

Division Director for Research Area Quality Management of Fraunhofer Institute for
Production Systems and Design Technology, IPK Berlin

Extraordinary professorship for Quality Management, Stellenbosch University, RSA

PhD from Technical University Berlin, Institute for Machine Tools and Factory Management

Prof. Dr.-Ing. Roland Jochem studied Mechanical Engineering and received his PhD from Technical University of Berlin. He worked several years with Fraunhofer Institute for Production Systems and Design Technology and with Bosch and Siemens Home Appliances.

His Key Qualifications are Business Process Management (Project management of more than 20 industrial projects), Modeling methodologies (Development of a new object oriented methodology for enterprise modeling), Modeling tools (Development of a tool supporting object oriented methodology for enterprise modelling), Quality management (Model based Quality Management; Quality oriented business process management), Standardization (Working in ISOTC184/SC5/WG1 “Framework for Enterprise Modeling”, ISO TC184/SC4/WG8 “Resource Usage Management” and CEN TC310/WG1: CIM System Architecture). He is author of 9 books and more than 70 articles published in Journals, Conference Proceedings or Edited Books.

## Contact:

Prof. Dr.-Ing. Roland Jochem,
Berlin Institute of Technology
Institute of Machine Tools and Factory Management
Chair Quality Management
Pascalstr. 8-9
10587 Berlin
Germany
roland.jochem@tu-berlin.de
Dr.-Ing.; Dipl.-Wirtsch.-Ing. Katja Landgraf
Slitisa Inc., Germany

Dipl.-Wirtsch.-Ing. Katja Landgraf studied industrial engineering at the University of Kassel.
Since 2008 she was research associate at the Chair Quality Management of the University of
Kassel. In addition to the doctorate, she taught at several institutions and has numerous
publications. Their research and consulting focus as Quality Systems Manager and Certified
Professional CPREF requirements engineer is within the field of process and quality
management, innovation management and requirements management & engineering.

Contact:

Dr. Ing.; Dipl.-Wirtsch.-Ing. Katja Landgraf
Slitisa Inc.
Schwarzer Stock 8
36110 Schlitz
Germany
landgraf@slitisa.de