In the development of mechatronic systems, risks are caused by changing requirements. In this pap er, an approach towards the assessment of such kind of risks is presented. Starting with the requirements list, inter actions between requirements are structured in the Requirements Structure Matrix (RSM) semi -automatically. In parallel, requirements are categorized according to their source (“influence area”) and prioritized. This priorization is based on the risk of change. It is charac- terised by the criteria “dynamics”, “uncertainty of knowledge base ” and “relevance for product development”. The ap- proach is validated by two approaches: structured interviews with project managers and developers a s well as a case study focusing on a pedelec. By application of the approach, cross -disciplinary relations o f requirements can be considered in order to reduce iterations in the development of mechatronic systems such as the pedelec. 1 Einleitung In der Entwicklung mechatronischer Systeme spielen An- forderungen aus verschiedenen Diszipl inen (Softwaretech- nik, Maschinenbau und Elektrotechnik ) eine zentrale Rolle. In der Regel muss eine große Anzahl von Anforde- rungen a) in Bezug auf alle beteiligten Disziplinen und b) auf allen Detaillierungsebenen des Systems erfasst und ge- handhab t werden [1]. Änderungen einzelner Anforderun- gen können Auswirkungen auf andere Anforderungen (auch disziplinübergreifend) implizieren [2]. Solche An- forderungsänderungen sind ein Hauptgrund für Iterationen und Verzögerungen in Produktentwicklungsprojekt en [3]. Ursache von Anforderungsänderungen können externe Einflüsse (z.B. zunehmende Präzision von Kunden wün- schen ) sein, vielfach führen jedoch auch interne Einflüsse (z.B. Konkretisierung, Ergänzung oder Korrektur von An- forderungen ) zu Anforderungsänderungen [4]. Anforde- rungsmanagement ist daher ein Erfolgsfaktor in Produkt- entwicklungsprojekten [5]. Dabei muss die Abhängigkeit von Anforderungen explizit beachtet werden [6]. Gleich- zeitig muss auch das den Anforderungen inhärente Verä n- derungsrisiko in die Betrachtung integriert werden [7]. Ziel dieses Beitrags ist daher die Beantwortung der folgenden Forschungsfragen: • Wie können Risiken von Anforderungsänderungen in in- terdisziplinären Produktentwicklungsprojekten erfasst und bewertet w erden? • Wie kann diese Betrachtung um die Wechselwirkungen der Anforderungen erweitert und zur Ableitung von Re- aktionsstrategien genutzt werden? In diesem Beitrag wird aufbauend auf einer Literaturstudie zum Anforderungsmanagement und dem Risikomanage- ment (Abschnitt 2) eine Methode zur Risikobewertung von Anforderungsänderungen in der Entwicklung mechatroni- scher Produkte vorgestellt (Abschnitt 3). Diese wurde für die Validierung in einem Software -Werkzeug implemen- tiert. Die Validierung erfolgt durch strukturierte Interviews mit Entwicklern und die Anwendung an einer Fallstudie der Entwicklung eines Pedelecs (Abschnitt 4). 2 Stand der Wissenschaft In diesem Kapitel werden die etablierten Ansätze des An- forderungs - und Risikomanagements erläutert, auf die sich diese Arbeit stützt. Außerdem werden Forschungsergeb- nisse zu Herausforderungen in der interdisziplinären Zu- sammenarbe it dargelegt und auf dieser Grundlage der Be- darf einer methodischen Unterstützung für mechatronische Entwicklungsvorhaben abgeleitet . 1 2.1 Anforderungsmanagement Die Erhebung, Festlegung, Dokumentation und Nachver- folgung der Anforderungen wird in der Entwi cklung me- chatronischer Systeme unter dem Begriff Requirements Engineering zusammengefasst [3]. Durch Dahlstedt wird in der Domäne Softwaretechnik ein Referenzmodell vor- gestellt, welches verschiedene Typen von Anforderungs- abhängigkeiten aufbauend auf dem Referenzmodell von Pohl (siehe [3]) beinhaltet [8]. Beide Referenzmodelle er- möglichen eine Strukt urierung der Anforderungen nach verschiedenen Kriterien wie etwa strukturellen Aspekten oder im Hinblick auf die Zielsetzung inner halb des Ent- wicklungsprojektes. Eben und Lindemann verwenden zur Strukturierung der Anforderungen die Wechselwirkungen zwisch en den An- forderungen auf Basis der Design Structure Matrix (DSM) [9]. Hierbei werden die Anforderungen im Hinblick auf ihre Aktivität, Passivität und Kritikalität innerhalb de s An- forderungsnetzwerkes bewertet [9]. Die teilautomatische Bewertung von Anforderungsabhän- gigkeiten wird durch Gräßler et al. [10] vorgeschlagen. Hierbei werden die Anforderungen auf Grundlage einer Regelbasis vernetzt. Ausgangspunkt sind die den einzelnen Anforderungen zugeordneten Hauptmerkmale. In der Domäne Softwaretechnik werden Requirements Traceability -Analyse n genutzt, um Wechselwirkungen der Anforderungen zu identifizieren . Hierbei ist die Nachver- folgbarkeit der Anforderungen (engl. Traceability) ent- scheidend für die Analyse von Wechselwirku ngen und An- forderungsänderungen. Auf Basis dieser kann die Stabilität von Anforderungen etwa durch R equirements Stability In- dices (RSIs) bewertet und Anforderungen priorisiert wer- den [11, 12] . Innerhalb der Change Propagation Method (CPM) werden Risiken du rch die Propagation von Ände- rungen in komplexen interdisziplinären Systemen bewertet [13]. Hierbei dient die DSM des Systems als Referenz . Auf Basis dieser Wechselwirkungen und des Veränderungsrisi- kos (ausgedrückt durch die Änderungswahrscheinlichkeit) können so die Auswirkungen von Änderungen erfasst wer- den [13]. Der Ansatz beruht hierbei auf den einzelnen Komponenten, nicht auf den Anforderungen als solches. 2.2 Interdisziplinäre Entwicklung Interdisziplinäre Teams haben vielfach Kommunikationss- chwierigkeiten . Diese können zu Ineffizienzen führen [14, 15] und effektive Entscheidungsfindung erschweren [15 ]. Dies führt bei Anforderungsänderungen zu dem Problem, dass die Änd erungspropagation innerhalb des Anforde- rungsnetzwerk aufgrund unzureichender Kommunikation der Disziplinen unberücksichtigt bleibt. Des Weiteren ha- ben Entwickler nur für die jeweils angestammte Disziplin bzw. den Fachbereich ein tiefgreifendes Verständnis des Systems . Da Anforderungsänderungen üblicherweise auf Grundlage von Erfahrungswerten antizipiert, bewertet und konsistent im gesamten Anforderungsset implementiert werden, geht mit einem eingeschränkten Systemverständnis häufig ei ne fehlerbehaftete Handhabung von disziplinüber-greifenden Anforderungsänderungen einher [13]. Insbeson- dere das Wissen über Disziplinen , die nicht in direkten Zu- sammenhang mit dem Aufgabenbereich eines Entwicklers stehen, werden zumeist kaum in die Überlegu ngen einbezo- gen [13]. 2.3 Risikomanagement Für die Entscheidung über die Implementierung einer An- forderung sänderung ist es notwendig, das damit verbundene Risiko zu handhaben . Risikomanagement ist ein immanen- ter Bestandteil der Unternehmensführung und ist dadurch bedingt, dass Entscheidungen unter Unsicherheit getroffen werden müssen [16]. Solche Entscheidungen sind sowohl mit negativen als auch mit positiven Effekten verbunden. Der Fokus des Risikomanagements liegt aber zumeist auf den negativen Effekten [17]. Ein elementares Ziel des Risi- komanagements ist es , die Risikokosten zu senken oder zu vermeiden [16, 18] . Dafür werden kontinuierlich relevante Risiken identifiziert und bewertet. Die Beurteilung erfolgt üblicherweise anhand der Eintrittswahrscheinlichkeit und des prognostizierten Schadensausmaßes ; sie wird a nhand dieser Kennwerte in ein Risikoportfolio eingeordnet [16, 17]. Poten zielle Maßnahmen zur Steuerung des Risikos werden aus der Risikoklassifizierung abgeleitet und sind die Risikovermeidung, -verminderung, -begrenzung, -überwäl- zung und -akzeptanz [16]. 2.4 Handlungsbedarf Voraussetzung für die Initiierung geeigneter Risikosteue- rungsmaßnahmen im Kontext von Anforderungsänderun- gen ist eine umfassende und hochwerti ge Datengrundlage . Der bisherige Umgang mit Anforderungsänderungen ist methodisch unzureichend unterstützt und vielfach zu sehr auf ein e Disziplin ausgerichtet. Für eine effektive und effi- ziente Handhabung von Anforderungsänderungen als Er- folgsfaktor muss das Wissen über Anforderungs abhängig- keiten aller Disziplinen gebündelt und geeignete Maßnah- men zur methodischen und informationstechnischen Unter- stützung abgeleitet werden. 3 Methode zur Priorisierung von Anforderungen in der Entwick- lung mechatronischer Pr odukte In diesem Abschnitt wird die Methode zur Priorisierung von Anforderungen in der Entwicklung mechatronischer Produkte dargestellt. Die Methode baut hierbei auf den Vorarbeiten zur teilautomatischen Vernetzung (siehe [10]) und der Priorisierung von Anforderungen (siehe [7]) auf. Die Methode ist in Abbildung 1 dargestellt. Ausgangs- punkt der Methode sind die erfassten und dokumentierten Anforderungen an das mechatronische Produkt in einer Anforderungsliste. Die Anforderungen werden dann paral- lel im Hi nblick auf ihre Vernetzung (Abschnitt 3.1) und ihre Priorisierung (Abschnitt 3.2) analysiert . Die Ergeb- nisse werden anschließend in der Risikoklassifizierung (Abschnitt 3.3) zusammengeführt. 2 3.1 Vernetzung Die Anforderungen werden zur Analyse der Vernetzu ng in einer Requirements Structure Matrix (RSM) erfasst. In die- ser werden die Abhängigkeiten der Anforderungen unter- einander abgebildet [19]. Die RSM ist gerichtet und ge- wichtet, so dass Wirkrichtungen von propagierenden An- forderungsänderungen ebenso erfasst werden wie die Stärke der Einflüsse. Die Ableitung der RSM stellt hierbei einen großen Aufwand in der Entwicklung dar [10]. Zur Reduktion des Aufwandes wird der Ansatz der teilautoma- tischen Ableitung der RSM nach Gräßler et al. [10] zum Aufstellen der RSM verwendet. Den Anforderungen wer- den hierzu Hauptmerkmale (analog zu den Hauptmerkma- len nach Pahl/Beitz [20]) zugeordnet. Für diese Haupt- merkmale sind die generischen Abhängigk eiten auf Basis einer Literaturstudie durch Gräßler et al. [10] modelliert worden. Auf Basis de s generischen Abhängigkeitsmodells und der spezifisch den Anforderungen zugeordneten Hauptmerkmale wird die RSM teil automatisch abgeleitet. Anwender können d ie resultierende RSM gegebenenfalls auf der Grundlage von Erfahrungswissen anpass en. 3.2 Priorisierung Die Priorisierung der Anforderungen wird parallel zur Ver- netzung durchgeführt. I m ersten Schritt durch die Erfas- sung der Einflüsse, welche innerhalb der Produktentwick- lung Anforderungsänderungen hervorrufen können. Die Identifikation dieser Einflüsse erfolgt hierbei unterneh- mens - und produktspezifisch (siehe [7]). Zur Reduktion des Aufwandes werden die Einflüsse in Einflussbereiche gegliedert (bspw. Kunden, rechtliche Rahmenbedingun- gen, Produktionsrestriktionen, …) , welche anschließend im Hinblick auf ihr Veränderungsrisiko bewertet werden. Die Bewertung ist d abei an die in der industriellen Praxis verbreitete Methode der Fehlermöglichkeits - und Einfluss- analyse (FMEA) angelehnt (siehe [7]). Diese Bewertung erfolgt auf Basis der Kriterien „Unsicherheit “, „Dynamik “ und „Relevanz “ (vgl. [7]). Die Kriterien bilden dabei die Unsicherheit der Anforderungen (in Bezug auf die Voll- ständigkeit und die explizite Erfassung dieser), die Dyna- mik (als Einschätzung der Häufigkeit von Anforderungs- änderungen und dere n Intensität) sowie der Relevanz (in Bezug auf die Realisierbark eit von Anforderungsänderun- gen und de ren Umfang) ab. Aus der Bewertung dieser drei Kriterien wird analog zur FMEA ein Prioritäts -Score (PS) durch Multiplikation der drei Zahlenwerte (Skala 1 – 10) berechnet. 3.3 Risikoklassifizierung Die klassische Risiko klassifizierung stützt sich auf die Be- urteilung der Eintrittswahrscheinlichkeit und des Scha- densausmaßes [16]. Auch die in dieser Arbeit vorgestellte Methode erfasst alle dafür relevanten Einflussgrößen, unter- scheidet aber nicht strikt nach den beiden genannten Fakto- ren. Die Eintrittswahrscheinlich lässt sich aus der Passiv - Summe, der Unsicherheit und Dynamik ableiten, während das Schadensausmaß aus der Aktiv -Summe und der Rele- vanz resultiert. Ein Grund für die abweichende Zuordnung im Risikoportfolio ist die Dimensionalität der Kennwerte und die damit einhergehende Unschärfe bei einer Verrech- nung . Während di e Priorisierungskennwerte (Dyna mik, Un- sicherheit, Relevanz) auf einer standardisierten Skala erfasst werden, sind die Abhängig keiten (Aktiv -/ Passivsumme) absolute Werte , die vom untersuchten Anforderungsset ab- hängen . Ein weiterer Grund ist das Ziel einer intuitiven An- wendbarkeit für den Entwickler . Durch die Strukturierung der Ergebnisse entsprechend des Vorgehen der Datenerfas- sung (Prior isierung und Vernetzung) soll en Anwender die Einflüsse der Kennwertgrößen und etwaiger Veränderun- gen besser nachvollziehen und interpretieren können. Die Intensität der Vernetzung wird in die Kategorien „Hoch“, „Mittel“ und „Gering“ (vgl. Systemgrid nach Reib- nitz [21]). Darin ist die Aktivsumme der Anforderungen hö- her gewichtet als die Passivsumme . Grund dafür ist, dass ri- sikoorientierte Maßnahmen insb esondere bei Anforderun- gen wirken, die einen starken Änderungsimpuls in das Netz- werk init iieren (hohe Aktivsumme) . Der Grad der Beein- flussung durch andere Anforderungen (Passiv -Summe) ist wesentlich schwerer durch Maßnahmen zu beeinflussen (siehe auch Abschnitt 3.4). Die Einordnung der Anforderungen in Prioritätskategorien kann an die situativen Bedarfe angepasst werden. In diesem Fall werden analog zur Vernetzung die drei Kategorien „Hoch“ (PS > 400) , „Mittel“ (400 ≤ PS ≥ 100) und „Gering“ (100 > PS) unterschieden. Das Ergebnis der Analyse von Vernetzung und Priori sierung der Anforderung en wird in ei- nem Risikoportfolio mit den Achsen „Prioritäts -Score“ und „Vernetzungs -Score“ dargestellt. Insgesamt resultieren d ar- aus drei Klassen zur Darstellung des Änderungsrisikos von Anforderungen : „Kritisch“, “Relevant“ und „Unkritisch“. Abbildung 1 Methode zur Priorisierung von Anf orderungen in der Entwicklung mechatronischer Produkte 3 3.4 Risikoportfolio In einem Risikoportfolio werden alle Anforderungen und deren zweidimensionale Risikobewertung visualisiert . Hilf- reich ist die Information über das Anforderungsänderungs- risiko bereits in den frühen Phasen einer Entwicklung me- chatronischer Produkte. Sobald das zu entwickelnde Pro- dukt durch ein initiales Anforderungsset (z.B. Lastenheft) beschrieben ist, kann ein e Vorabanalyse durchgeführt wer- den. Diese kann sowohl den Konkretisierungsbedarf des Anforderungssets aufzeigen als auch eine genauere Zeit - und Kostenkalkulation ermöglichen. Bis zur Einigung auf ein Pflichtenheft können sehr wirksame Risikosteuerungs- maßn ahmen initiiert werden, die das spätere Projektrisiko deutlich beeinflussen. Im weiteren Verlauf des Entwicklungsprojekts kann das kontinuierlich angewandte Risikoportfolio die Identifika- tion und Handhabung änderungskritischer Anforderungen optimieren. Dies schließt die konsistente Umsetzung und Dokumentation einer Änderungskaskade mit ein. Auch nach der Festlegung der Produktgestalt („Design Freeze“), können zur Fehlerkorrektur oder durch den Kunden Ände- rungen erforderlich werden. In solchen Phasen wird insbe- sondere die Entscheidung über den Implementierungsgrad von Änderungsimpulsen unterstützt. Abhängig von dem Entwicklungsvorhaben können unter- schiedliche M aßnahmen zur aktiven Steuerung des Risikos von Anforderungsänderungen umgesetzt werden. Diese können sowohl präventiv als auch reaktiv sein. Für eine Re- duzierung der Priorität sind die drei Faktoren Unsicherheit, Dynamik und Relevanz entscheidend. Die Unsicherheit repräsentiert das Wissen über den Ein- flussbereich und kann somit durch Maßnahmen zur Infor- mationsgewinnung vermindert werden . Beispielsweise kön- nen eine Stakeholderanalyse ( vgl. [22]), zusätzliche Gesprä- che mit den Stakeholdern oder auch Marktanalysen die Wis- sensgrundlage aufwerten und eine vollständige und korrekte Definition von Anforderungen begünstigen. Die Dynamik einer A nforderung ist schwieriger zu beein- flussen, da der Anzahl und Intensität von Änderungen einer Anforderung häufig kausale Zusammenhänge zugrunde lie- gen. Dies bezieht sich jedoch nur auf erforderliche Ände- rungen. Eine Sensibilisierung der Stakeholder und die be- reits erläuterte Aufwertung der Wissensgrundlage sind wirksame Maßnahmen, um nicht zwingend erforderliche Änderungsimpulse zu reduzi eren. Dem können auch Maß- nahmen zur Risikoüberwälzung förderlich sein, bei denen der Änderungsaufwand beispielsweise durch eine entspre- chende Gestaltung des Pflichtenhefts oder anderer Verträge vom Stakeholder zu tragen ist. Die Relevanz von Anforderungen kann beispielsweise durch das vorsorgliche Integrieren von Änderungsspielräu- men reduziert werden. Eine weitere Möglichkeit ist die An- passung der Produktkonzeption (z.B. Modularisierung oder alternatives Lösungsprinzip) mit dem Ziel, dass besonders änderun gskritische Anforderungen weniger bedeutsam für den Projekterfolg werden oder leichter zu realisieren sind. Außerdem kann eine wiederholte Evaluation der Anforde- rungs verbindlichkeit (Wunsch vs. Forderung) auf Grund- lage der Risikoinformationen angestrebt we rden. All diese Faktoren zielen auf eine Verschiebung der Anfor- derungen entlang der X -Achse (PS) ab. Eine Verschiebung entlang der Y -Achse (VS) ist durch das Entwicklungsteam schwieriger umzusetzen, da für die Vernetzungsintensität vor allem unbeeinflussb are physikalische Wirkprinzipien ausgewertet werden. Aktiv k önnte beispielsweise durch Modularisierung die Schnittstelle (n) zwischen vernetzten Teilsystemen beeinflu sst werden. Aufgrund des großen Aufwands und einer entsprechend hohen Anzahl an neuen Änder ungsimpulsen sind Maßnahmen zur Reduzierung der Priorität und einem risikosensiblen Umgang mit stark ver- netzen Anforderungen in vielen Fällen vorteilhafter. Ein schematisches Risikoportfolio mit den Effekten von Risi- kosteuerungsmaßnahmen wird in Abbildung 2 dargestellt . 4 Validierung Die Validierung der Methode zur Priorisierung der Anfor- derungen in der Entwicklung mechatronischer Systeme er- folgt in zwei Schritten: In einem ersten Schritt wird die Me- thode in strukturierten Interviews mit Fachexperten vali- diert (Abschnitt 4.1). In einem zweiten Schr itt erfolgt die Anwendung auf die Fallstudie eines Pedelecs als mechat- ronisches System (Abschnitt 4.2). 4.1 Interviews mit Anwendern Die semi -strukturierten Interviews wurden mit Projekt - und Entwicklungsingenieuren sowie -leitern aus verschie- denen Branchen wie der Automobil -, Umform - und Bäcke- reitechnik geführt. Der prinzipielle Nutzen der Methode in der Entwicklung mechatronischer Systeme wird dabei als hoch eingeordnet. Der Ansatz einer Kombination aus teil automatische r Ver- netzung und Priorisierung mittels des FMEA -analogen Pri- oritäts -Scores wird von den Anwendern positiv bewertet , da zwar durch die Verallgemeinerung von Anforder ungs- eigenschaften die Genauigkeit der Bewertung reduziert wird, aber im Gegenzug der Anwendungsaufwand sinkt und damit die Anwendbarkeit für umfangreiche Anforde- rungslisten gefördert wird. Die Ergebnisgüte der Methode Abbi ldung 2 Anforderungsänderungs -Risikoportfolio zur Ableitung von Steuerungsmaßnahmen Hoch Mittel Gering Gering Mittel HochAnforderungVernetzungs -Score Prioritäts -ScoreKritisch Relevant Unkritisch Risikosteuerung 4 und die Wirksamkeit der darauf basiere nden Risikosteue- rungsinstrumente kann noch nicht ausreichend bewertet werden. Erste Pilotanwendungen werden aber als vielver- sprechend bezüglich der Erkennung von Anforderun gsän- derungen, ihrer Propagation und der inhärenten Risiken eingeschätzt. Anwender sehen die Vorteile insbesondere bei der Sensibilisierung für interdisziplinäre Auswirkun- gen von Anforderungsänderungen und der Absicherung von erfahrungsgestützten Einschätzungen. Kritikpunkte an der Methode adressieren unter anderem die Abhängig keit von der subjektiven Bewertung der Priorität sowie die Sen- sitivität der Ergebnisse in Bezug auf die zu Grunde lie- gende Vernetzung der Anforderungen. Die Portfolio -Dar- stellung stellt für die Anwender einen hohen Nutzen in Be- zug auf die Klassifizierung d er Anforderungen dar. 4.2 Fallstudie – Pedelec Die Methode wurde zudem durch eine Fallstudie validiert, deren Betrachtungsgegenstand durch ein Pedelec festge- legt war . Die Anforderungsliste enthält Anforderungen aus den Domänen Softwaretechnik, Maschinenbau und Elekt- rotechnik. Die Anforderungen wurden mittels der teil auto- matischen Erkennung von Anforderungsabhängigkeiten auf Basis der Hauptmerkmale in eine RSM überführt. Pa- rallel wurden die Einflus sbereiche analysiert. Hierbei sind insbesondere die Anforderungen aus den Einflussberei- chen „Endkunde“ und „Batteriezulieferer“ hoch priorisiert. Das Portfolio zur Klassifizierung für einen Auszug aus der insgesamt 80 Elemente umfassenden Anforderungslist e ist in Abbildung 3 dargestellt. 3 2 1 100 400 10001 2, 4 378 9Vernetzungs -Score Prioritäts -Score5, 6 Abbildung 3 Portfolio zur Klassifizierung der Anforderungen für das Pedelec (grün: unkritisch, gelb: relevant, rot: kritisch) Als kritisch werden dabei Anforderungen an Rad- und Rahmengröße (1), Moto rdrehmoment (2), Gesamtmasse (3) sowi e Anforderungen an den Akku (4, 5, 6 ) (Energie- dichte, Nennspannung und Ladestrom) klassifiziert. Diese stammen e inerseits aus den hoch priorisierten Einflussbe- reichen, sind aber andererseits auch stark mit anderen An- forderungen vernetzt. Änderungen an diesen Anforderun- gen können daher propagierende Anforderungsänderungen verknüpfter Anforderungen, etwa der Masse des Akkus (7) oder der Dauerleistung des Pedelec (8) hervorrufen. Die Anforderung an die Traglast des Gepäckträgers (9) wurde hingegen als unkritisch eingestuft, da diese einem gering priorisierten Einflussbereich zugeordnet wurden und gleichzeitig nur in geringem Maße mit den anderen Anfor- derungen vernetzt ist. Die Methodenanwendung war dabei in zweierlei Hinsicht hilfreich. Einerseits deckten sich zahlreiche Vorabeinschätzungen der Anwender mit den Analysee rgebnissen. Dies lässt darauf schließen, dass die erfahrungsbasierte Beurteilung hochwertige Ergebnisse liefert. Die Methode leistet in diesem Fall eine Rückbestä- tigung und Absicherung. Andererseits werden dem An- wender aber auch bisher unberücksichtigte Anforderungen aufgezeigt. Eine Sensibilisierung und Ausweitung der Per- spektive findet statt. Das bezog sich in der Fallstudie zu- meist auf Anforderungen der Risikoklasse „Relevant“ , des- sen Bewertung zudem häufig auf interdisziplinär wirkende Abhängigkeiten zurückzuführen war. Eine E rklärung könnte sein, dass bei einer unstrukturierten Beurteilung vorwiegend kritische Anforderungen in den Fokus rücken. Die Vielzahl an zunächst unwichtig erscheinenden Anfor- derungen wird nur unzureichend betrachtet . Genau bei sol- chen Anforderungen leistet die Methode eine Sensibilisie- rung der Anwender und zeigt die Risikoeffekte komplexer Zusammenhänge auf. Diese sind bei genauerer Analyse durchaus nachvollziehbar, werden bei einer oberflächli- chen Betrach tung und disziplinspezifischen Überlegungen aber häufig unterbewertet. 5 Zusammenfassung In diesem Beitrag wurde eine Methode vorgestellt, die die Erfassung und Bewertung von Anforderungsänderungen in interdisziplinären Entwicklungsprojekten ermöglicht. Dies bezieht die Wechselwirkungen zwischen Anforderungen ein und führt dadurch zu einer ganzheitliche n Beurteilung. Durch die steigende Komplexität und Interdisziplinarität werden insb esondere die Abhängigkeiten zwischen den Anforderungen und die Änderungspropagation in Zukunft an Bedeutung gewinne n. Zudem wird durch das resultie- rende Risikoportfolio die Ableitung geeigneter Risikosteu- erungsmaßnahmen erleichtert und anhand exemplarische r Vorgehensweise erläutert . Auf Grundlage dieser Informa- tionen können Ineffizienzen bei der Handhabung von dis- ziplinübergreifenden Anforderungsänderungen verringert werden . Die Validierung durch Anwender -Interviews und die Fall- studie am Beispiel des Pedelec s zeigen, dass die Methode die Möglichkeit en einer rationalen Entscheidungsfindung erweitert und dadurch die erfolgreiche Entwicklung me- chatronischer Systeme unterstützt. Neben dem aktuell noch hohen initialen Einführungsaufwand der Methode stellt auch die zum Teil unstrukturierte Dokumentation der An- forderungen in Industrieunternehmen ein Hindernis für die Anwendung dar. Außerdem sind die Risikosteuerungs- maßnahmen zu erweitern und hinsichtlich Wirksamkeit zu analysieren . Dies soll durch die kontinuierliche Anwen- dung in unterschiedlichen Entwicklungsprojekten mecha - tronischer Systeme umgesetzt werden. Danksagung Das Forschungs - und Entwicklungsprojekt „OptiAMix“ wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Programm „Additive Fertigung – Individualisierte Produkte, komplexe Massenprodukt e, in- novative Materialen (ProMat_3D)“ gefördert. 5 Literatur [1] Weber, M.; Weisbrod, J.: “Requirements engineer- ing in automotive development. Experiences and challenges ”. In: IEEE Software 20 (2003) 1, S. 16–24. [2] Pohl, K.; Rupp, C.: “Requirements enginee ring fundamentals ”. Rocky Nook, Santa Barbara, CA, 2015. [3] Pohl, K.: “Requirements engineering. Fundamen- tals, principles, and techniques ”. Springer, New York, 2010. [4] Fernandes, J.; Henriques, E.; Silva, A.; Moss, M. A.: “Requirements change in complex technical systems. An empirical study of root causes ”. In: Research in Engineering Design 26 (2015) 1, S. 37–55. [5] Brauns, C.: „Requirements Engineering und Ma- nagement in der wehrtechnischen Beschaffung. Empirische Bestandsaufnahme, Konzeptentwick- lung, Evaluation “.Dissertation, Hamburg, 2016. [6] Scholle, P.; Song, Y. -W.; Herzog, M.; Bender, B.; Gräßler, I.: „Methoden der Anforderungsstruktu- rierung zur Steuerung von Produktentwicklungs- prozessen “. In: Krause, D.; Paetzold, K.; Wart- zack, S. (Hrsg.) Design for X. Beiträge zum 26. DfX Symposium. Hamburg, 2015, S. 121 –132. [7] Gräßler, I.; Oleff, C.; Scholle, P.: „Methode zur Bewertung von Anforderungsänderungen additiv gefertigter Produkte. “. In: Krause, D.; Paetzold, K.; Wartzack, S. (Hrsg.) Design for X. Be iträge zum 29. DfX-Symposium. Hamburg, 2018, S. 333–344. [8] Dahlstedt, Å. G.; Persson, A .: “Requirements In- terdependencies: State of the Art and Future Chal- lenges ”. In: Aurum, A.; Wohlin, C. (Hrsg.) Engi- neering and Managing Software Requirements. Berlin, Heidelberg, 2005, S. 95 –116. [9] Eben, K. G. M.; Lindemann, U.: “Structural Anal- ysis of Requirements. Interpretation of structural criterions ” 12th International Dependency and Structure Modelling Conference DSM ‘10, 2010, S. 249 –261. [10] Gräßler, I.; Sch olle, P.; Hentze, J.; Oleff, C.: “Semi -Automatized Assessment of Requirement In- terrelations ”. In: Marjanović, D.; Storga, M.; Pav- kovic, N.; Bojcetic, N.; Škec, S. (Hrsg.) Proceed- ings of the DESIGN 2018 15th International De- sign Conference, 2018, S. 325 –334. [11] Shao, F.; Peng, R.; Lai, H.; Wang, B.: “DRank: A semi-automated requirements prioritization method based on p