Dokumentation von Anforderungen in der Produktentwicklung

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation und Zielsetzung
1.2 Struktureller Aufbau

2 Stand der Forschung
2.1 Einordnung des Anforderungsbegriffs in Vorgehensmodelle
2.1.1 Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte
2.1.2 Vorgehen entlang des V-Modells nach VDI-Richtlinie 2206
2.1.3 Münchener Vorgehensmodell
2.2 Modellierung von technischen Produkten und technischen Systemen
2.2.1 Grundlagen technischer Systeme
2.2.2 Modelle technischer Systeme und technischer Produkte
2.3 Abgrenzung des Anforderungsbegriffs
2.3.1 Definitionen des Anforderungsbegriffs
2.3.2 Merkmale zur Klassifizierung von Anforderungen
2.4 Theoretische Ansätze zur Dokumentation von Anforderungen
2.4.1 Der Dokumentationsbegriff
2.4.2 Dokumentation von Anforderungen nach EHRLENSPIEL/MEERKAMM
2.4.3 Dokumentation von Anforderungen nach LINDEMANN
2.4.4 Dokumentation von Anforderungen nach PAHL/BEITZ
2.4.5 Dokumentation von Anforderungen nach ULRICH/EPPINGER
2.4.6 Dokumentation von Anforderungen gemäß Automotive SPICE
2.4.7 Weitere Aspekte zur Anforderungsdokumentation
2.5 Fazit zum Stand der Forschung

3 Analyse der Anforderungsdokumentation in der Produktentwicklung
3.1 Die Bedeutung der Anforderungsdokumentation für die Transformation von Anforderungen in Soll-Eigenschaften
3.1.1 Die Schnittstelle zwischen Erfassungsprozess und Anforderungsraum
3.1.2 Die Anforderungsdokumentation von Anforderungen aus dem Anforderungsraum
3.1.3 Transformation von Anforderungen zu Soll-Eigenschaften
3.1.4 Zusammenfassung der Erkenntnisse für eine Anforderungsdokumentation zur Unterstützung des Transformationsprozesses
3.2 Anforderungsdokumentation innerhalb ausgewählter Vorgehensmodelle
3.2.1 Anforderungsdokumentation im Münchener Vorgehensmodell
3.2.2 Anforderungsdokumentation in Verbindung mit VDI-Richtlinie 2206
3.3 Analyse der Anforderungsdokumentation in der Praxis
3.3.1 Datenerhebung und Unternehmensprofile
3.3.2 Auswertung der Praxisbeispiele
3.3.3 Zusammenfassung der Erkenntnisse aus den Praxisbeispielen
3.4 Fazit der Analyse

4 Konzept einer neugestalteten Anforderungsdokumentation
4.1 Aufbau der neugestalteten Anforderungsdokumentation
4.2 Anwendungsbeispiel einer neugestalteten Anforderungsliste
4.2.1 Grundlagen und Kundenanforderungen der künstlichen Kletteranlagen
4.2.2 Erstellen der Anforderungsliste
4.2.3 Unterstützung des Transformationsprozesses durch die neugestaltete Anforderungsdokumentation
4.3 Kritische Würdigung der neugestalteten Anforderungsdokumentation

5 Zusammenfassung und Ausblick

Anhang A - Glossar

Anhang B - Weitere Definitionen des Anforderungsbegriffs

Anhang C - Auszug der Plane des Bauwerks

Anhang D - Auszug der Pläne der Stahlgalerie

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Aufbau der Arbeit

Abbildung 2: Systemtechnische Problemlösungszyklen

Abbildung 3: Generelles Vorgehen beim Entwickeln und Konstruieren

Abbildung 4: V-Modell als Makrozyklus

Abbildung 5: Mikrozyklus der Problemlösung

Abbildung 6: Münchner Vorgehensmodell

Abbildung 7: Darstellung eines Systems

Abbildung 8: Hierarchische Modellierung technischer System mittels Pyramidenmodell

Abbildung 9: Pyramidenmodell technischer Systeme nach SAUER

Abbildung 10: Münchner Produktkonkretisierungsmodell

Abbildung 11: Modelltheorie zur Transformation von Anforderungen in Produkteigenschaften

Abbildung 12: Unterscheidung nach qualitativen und quantitativen Anforderungen

Abbildung 13: Eigenschaftsklassen nach HUBKA/EDER

Abbildung 14: Übersicht der Hauptmerkmale nach PAHL/BEITZ

Abbildung 15: Übersicht der Anforderungsquellen

Abbildung 16: Zweistufige Priorisierung der Anforderungen nach PAHL/BEITZ

Abbildung 17: Elementare Anforderungstypen nach BIRKHOFER

Abbildung 18: Drei-stufige Priorisierung von Anforderungen nach ROTH

Abbildung 19: Gliederung nach Wichtigkeit der Anforderungen nach EHRLENSPIEL/MEERKAMM

Abbildung 20: Priorisierung von Kundenanforderungen nach KANO

Abbildung 21: Gewichtete Kundeanforderungen nach CROSTACK ET AL

Abbildung 22: Ableiten einer Anforderungsliste nach EHRLENSPIEL/MEERKAMM

Abbildung 23: Schematischer Aufbau einer Anforderungsliste nach EHRLENSPIEL/MEERKAMM

Abbildung 24: Schematischer Aufbau einer Anforderungsliste nach LINDEMANN

Abbildung 25: Ableiten von Anforderungslisten nach LINDEMANN

Abbildung 26: Ableiten der Anforderungsliste nach PAHL/BEITZ

Abbildung 27: Schematischer Aufbau einer Anforderungsliste nach PAHL/BEITZ

Abbildung 28: Entwicklung einer finalen Anforderungsdokumentation nach ULRICH/EPPINGER

Abbildung 29: Entwicklung der target specification nach ULRICH/EPPINGER

Abbildung 30: Entwicklung der final specification nach ULRICH/EPPINGER

Abbildung 31: Schematischer Aufbau einer Anforderungsliste nach ULRICH/EPPINGER

Abbildung 32: Anwendung von Automotive SPICE entlang des V-Modells

Abbildung 33: Schematischer Aufbau der Anforderungsdokumentation bei Automotive SPICE

Abbildung 34: Darstellung des Anforderungsraumes

Abbildung 35: Initiale Einordnung von Anforderungen in den Anforderungsraum

Abbildung 36: Zentrale Attribute zur Transformation einer Anforderung

Abbildung 37: Qualitative und quantitative Anforderungen im Anforderungsraum

Abbildung 38: Soll-Eigenschaftsnähe in Abhängigkeit der Anforderungspriorisierung

Abbildung 39: Wirkung von Anforderungsursprung und -Quelle auf die

Anforderungsfinalisierung innerhalb des Anforderungsraums

Abbildung 40: Auswirkung der Priorisierung auf Anforderungsraum und

Anforderungsdokumentation

Abbildung 41: Auswirkung der Anforderungsart nach PAHL/BEITZ auf den Anforderungsraum und die Anforderungsdokumentation

Abbildung 42: Identifikation von Redundanzen und Widersprüchen mittels Anforderungsliste

Abbildung 43: Übersicht zu den angefragten Unternehmen

Abbildung 44: Anforderungserfassung in Unternehmen B

Abbildung 45: Schematische Darstellung der Anforderungsliste von Unternehmen A

Abbildung 46: Schematische Darstellung der Anforderungsliste von Unternehmen B

Abbildung 47: Mögliche Barrieren der Anforderungsdokumentation

Abbildung 48: Schematische Darstellung des Umfangs der Unternehmensanforderungsdokumentation

Abbildung 49: Übersicht der Analyseergebnisse

Abbildung 50: Definierte Ableitung von Anforderungen

Abbildung 51: Schematischer Aufbau der ganzheitlichen Anforderungsdokumentation

Abbildung 52: Mögliche Integration der organisationale Elemente innerhalb der Anforderungsliste

Abbildung 53: Auszug der identifizierenden Attribute

Abbildung 54: Auszug der inhaltlichen Attribute

Abbildung 55: Auszug der nach- und rückverfolgenden Attribute

Abbildung 56: Einzuhaltenden Sturzräume einer künstlichen Kletterwand

Abbildung 57: Gebäude und Stahlgalerie ohne Kletterhalle

Abbildung 58: Entwicklung von Anforderungen aus Kundenanforderungen

Abbildung 59: Auszug der initialen Anforderungsliste

Abbildung 60: Auszug einer präzisierten Anforderungsliste

Abbildung 61: Transformation der Anforderungen der finalen und strukturierten Anforderungsliste

Abbildung 62: Auszug einer finalen und strukturierten Anforderungsliste mit SE-ID

Tabellenverzeichnis

Tabelle 1: Definitionen des Anforderungsbegriffs

Tabelle 2: Auszug aus Möglichkeiten zur Priorisierung von Anforderungen

Tabelle 3: Auszug der wesentlichen Elemente der jeweiligen konstruktionswissenschaftlichen Anforderungsdokumentation

Tabelle 4: Unterstützung der Zielplanung durch Anforderungsdokumentation

Tabelle 5: Ziele mittels Anforderungsdokumentation analysieren

Tabelle 6: Problemstrukturierung und Ermittlung von Lösungsideen mittels Anforderungsdokumentation

Tabelle 7: Übersicht der Anwendungsmöglichkeiten der Formen der

Anforderungsdokumentation im Münchner Vorgehensmodell

Tabelle 8: Organisationale Elemente der Anforderungsdokumentation

Tabelle 9: Identifizierende Attribute der Anforderungsdokumentation

Tabelle 10: Inhaltliche Attribute der Anforderungen

Tabelle 11: Nach- und rückverfolgende Attribute der Anforderungen

Tabelle 12: Weitere Anforderungsdefinitionen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation und Zielsetzung

Produktentwicklungen, von der einfachen Anpassungsentwicklung bis hin zur Produktinnovation, können nur dann am Markt erfolgreich sein, wenn diese von Selbigem akzeptiert werden und den Erwartungen und den Bedürfnissen der Kunden gerecht werden. Zugleich müssen die Entwicklungen den Ansprüchen weiterer, unternehmensinterner und -externer Anspruchsgruppen genügen. Nur wenn die späteren Produkteigenschaften in diesem Spannungsfeld bestehen, kann auch für das entwickelnde Unternehmen ein wirtschaftlicher Mehrwert entstehen. Anforderungen an das zu entwickelnde Produkt spielen hierbei für die Entwicklung eine zentrale Rolle, da sie die erfassten und vage formulierten Vorstellungen des Kunden im Sprachgebrauch des Entwicklers widerspiegeln und zur sukzessiven Konkretisierung der Produkteigenschaften erforderlich sind. Nur wenn die Anforderungen in der frühen Phase der Entwicklung vorliegen, ist eine ebenso frühe Festlegung der Produkteigenschaften möglich. Dies beeinflusst nicht nur die Entwicklungsdauer positiv, sondern reduziert auch die Kosten durch Vermeidung späterer Änderungen, da unnötige Iterationsschleifen in der Entwicklung ausbleiben.¹

Die Dokumentation dieser Anforderungen spielt dabei im Projektdefinitionsprozess eine entscheidende Rolle und unterstützt den systematischen Umgang mit Anforderungen. Zum einen soll sie dazu beitragen die erfassten und übersetzten Ansprüche der Stakeholder zu strukturieren und somit die Komplexität beherrschbarer zu gestalten. Zum anderen bildet sie bereits im Projektdefinitionsprozess die Informationsbasis und einen Referenzpunkt für die nachgelagerten Prozesse der Entwicklung.

Trotz dieser elementaren Rolle der Anforderungsdokumentation für den Entwicklungsprozess und ihrer zentralen Rolle als ein wesentlicher Erfolgsfaktor zeigt sich, dass unterschiedliche Formen der Anforderungsdokumentation existieren, welche sich teilweise erheblich in ihrem Umfang, in ihrem Inhalt, der Zweck sowie der zugrunde gelegten Anforderungsdefinition unterscheiden. Dies erschwert zum einen das Verständnis der jeweiligen Dokumentation und führt zum anderen dazu, dass die jeweiligen Anforderungsdokumentationen den Entwicklungsprozess in unterschiedlichem Ausmaß und Umfang unterstützen. Hierdurch entstehen für zahlreiche Anforderungsdokumentationen Ausnutzungsdefizite ihrer Potentiale, welche zugleich Möglichkeiten zur Optimierung der Anforderungsdokumentation vermuten lassen.

Das Ziel dieser Arbeit ist daher die Entwicklung einer Anforderungsdokumentation, welche grundsätzlich notwendige und vielversprechende Elemente und Attribute, für den praxisnahen und transformations-effizienten Einsatz, beinhaltet. Hierdurch soll ein systematischer und praxisrelevanter Rahmen geschaffen werden. Darüber hinaus sollen die wesentlichen Unterstützungspotentiale vorhandener Dokumentationsformen für die Transformation von Anforderun- gen zu Soll-Eigenschaften und Vorgehensmodelle erarbeitet und analysiert werden. Diese Erkenntnisse sollen ebenfalls dazu beitragen, dass die neugestaltete Anforderungsdokumentation ganzheitlich einsetzbar ist.

Grundlage zur Zielerreichung ist eine fundierte Einordnung der Anforderungsdokumentation in den wissenschaftlichen und praktischen Kontext. Dies erfolgt, neben einer fundierten Einordnung zum Stand der Forschung, durch:

- die Strukturierung der bisherig eingesetzten, wissenschaftlichen und praktischen Anfor derungsdokumentationen zur Identifikation der bereits gegebenen Möglichkeiten,
- die Definition einer eindeutigen Schnittstelle zur Ableitung der zu erfassenden Anfor derungen, welche durch die Anforderungsdokumentation festgehalten werden sollen,
- die Extraktion von verbindlichen und optionalen Elementen und Attributen für die An forderungsdokumentation mit einer entsprechenden Betrachtung des jeweiligen Nutzen und dem daraus resultierenden Mehrwert,
- die Strukturierung der Elemente und Attribute zu inhaltlich systematisierten Bereichen der Dokumentation und
- die Demonstration und Verifizierung der gewonnenen Erkenntnisse am Beispiel der An forderungsliste für eine künstliche Kletteranlage.

1.2 Struktureller Aufbau

Die vorliegende Arbeit gliedert sich in drei inhaltliche Teile. Diese sind eine fundierte Betrachtung und Auswertung des Standes der Forschung, die Auswertung von Praxisbeispielen sowie die Entwicklung eines Anwendungsrahmens für die Anforderungsdokumentation (vgl. Abbildung 1).

Zunächst wird in Kapitel 2 der Stand der Forschung aufgearbeitet. Hierfür werden in Abschnitt 2.1 die methodischen Grundlagen der konstruktionswissenschaftlichen Vorgehensmodelle beleuchtet. Stellvertretend für diese werden einschlägige VDI-Richtlinien und das Münchner Vorgehensmodell angeführt. In Abschnitt 2.2 wird auf die Modellierung technischer Produkte und Systeme als weitere Grundlage eingegangen. Abschnitt 2.3 stellt unterschiedliche Definitionen des Anforderungsbegriffs und Merkmale zur Klassifizierung von Anforderungen vor. Des Weiteren werden in Abschnitt 2.4 einzelne, relevante Ansätze und Möglichkeiten zur Anforderungsdokumentation vorgestellt, welche auf ihren strukturellen Aufbau hinsichtlich der zugrundeliegenden Anforderungsdokumentation untersucht werden.

Auf Basis des Forschungsstandes wird in Kapitel 3 eine umfassende Analyse der Anforderungsdokumentation vorgenommen. Hierzu werden in einem ersten Schritt die Einsatzmöglichkeiten der Anforderungsdokumentation im Zusammenhang mit dem Transformationsmodell betrachtet. In Abschnitt 3.2 wird analysiert inwiefern die Anforderungsdokumentationen das Vorgehen nach VDI-Richtlinie 2206 und dem Münchner Vorgehensmodell unterstützen. Abschließend werden in Abschnitt 3.3 unterschiedliche Anforderungsdokumentation analysiert, welche in der

Praxis eingesetzt werden, sodass im Nachgang ein Vergleich zwischen den Dokumentationen aus Praxis und Konstruktionswissenschaft vorgenommen werden kann.

Kapitel 4 stellt eine neugestaltete Anforderungsdokumentation vor, welche auf den zuvor erlangten Erkenntnissen aufbaut. Hierfür werden in Abschnitt 4.1 die notwendigen und vielversprechenden Attribute sowie Elemente einer praxisrelevanten und transformations-effizienten Dokumentation vorgestellt. Des Weiteren wird die Entstehung der Anforderungsliste definiert und ein struktureller Rahmen für das Dokument aufgezeigt. Zur Veranschaulichung zeigt Abschnitt 4.2, am Beispiel einer künstlichen Kletteranlage, Auszüge aus dem Umgang mit der neugestalteten Anforderungsdokumentation.

Kapitel 5 fasst die wesentlichen Erkenntnisse dieser Arbeit zusammen, zeigt den Nutzen der erzielten Ergebnisse, hebt die zentralen Implikationen für die Praxis hervor und gibt einen Ausblick für die weitere Forschung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau der Arbeit

2 Stand der Forschung

Im nachfolgenden Abschnitt wird der Stand der Forschung betrachtet. Hierbei handelt es sich zunächst um die Einordnung von Anforderungen und Anforderungsdokumentation in den Gesamtkontext des Produktentwicklungsprozesses sowie um die Betrachtung von Anforderungsrelevanten Modellen aus der Wissenschaft. In einem zweiten Schritt werden unterschiedliche Definitionen des Anforderungsbegriffs und unterschiedliche Möglichkeiten zur Klassifizierung von Anforderungen vorgestellt. Abschließend werden unterschiedliche Formen der Dokumentation von Anforderungen betrachtet.

2.1 Einordnung des Anforderungsbegriffs in Vorgehensmodelle

In diesem Abschnitt werden die Dokumentation von Anforderungen sowie der Anforderungsbegriff in unterschiedliche Vorgehensmodelle der Produktentwicklung eingeordnet. Es soll aufgezeigt werden, welche Bedeutung Anforderungen und deren Dokumentation im Entwicklungsprozess besitzen. Exemplarisch werden hierfür die Vorgehensweisen nach VDI-Richtlinie 2221 und VDI-Richtlinie 2206 sowie das Münchner Vorgehensmodell (MVM) betrachtet.

2.1.1 Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte

Bei VDI-Richtlinie 2221, einem klassischen Vorgehensmodell der Produktentwicklung, handelt es sich um eine Norm zum Konstruieren und Entwickeln technischer Systeme und Produkte, die eine allgemeingültige Basis, unabhängig von der Branche des entwickelnden Unternehmens, bieten soll. Ziel dieser Richtlinie ist es, den Entwicklungsprozess möglichst kosteneffizient zu gestalten, mögliche Wege der Datenverarbeitung aufzuzeigen und die Marktfähigkeit der Produkte sicherzustellen.²

Grundlage der beschriebenen Methodik ist ein Problemlösungsprozess über die jeweiligen Lebensphasen eines Systems.³ Die einzelnen Schritte können sowohl zyklisch als auch iterativ durchlaufen werden, um so die Informationsdichte zu erhöhen (vgl. Abbildung 2). Je nach Komplexität des Produktes kann es zielführend sein, Gesamtprobleme in Teil- und Einzelprobleme zu überführen, diese dann auf Einzelproblemebene zu lösen und anschließend, über die Teillösungsebene, zu einer Gesamtlösung zu synthetisieren.⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Systemtechnische Problemlösungszyklen Quelle: In Anlehnung an VDI-Richtlinie 2221 (1993) S. 4.

Basierend auf diesem Verständnis wird ein generelles Vorgehensmodell entwickelt, das sich aus sieben Arbeitsschritten mit den entsprechenden, dokumentierten Arbeitsergebnissen zusammensetzt. Diese Arbeitsschritte lassen sich insgesamt vier Prozessphasen zuordnen und können durch iteratives Vor- und Rückspringen mehrfach durchlaufen werden (vgl. Abbildung 3).⁵ Zugleich lassen sie sich auf eine rechnergestützte Entwicklung übertragen und um die erforderlichen Softwarekomponenten erweitern.⁶

Ausgehend von der Entwicklungsaufgabe folgt der erste Arbeitsschritt. Dieser dient unmittelbar zum Präzisieren und Klären der Aufgabenstellung mit den Kunden und der Produktentwicklung, sodass die nötigen Anforderungen ermittelt werden können. Zusätzlich können weitere Anforderungen externer Stakeholder aufgegriffen werden, um ein möglichst umfassendes Bild des zu entwickelnden, technischen Produkts zu erhalten. Das dokumentierte Ergebnis liegt dann in Form der Anforderungsliste vor, die den weiteren Schritten als initiale und essentielle Informationsbasis dient. Ausgehend von diesem Dokument, können entlang des gesamten Prozesses Anpassungen und Ergänzungen der Anforderungen erfolgen. Diese Informationsbrücke zwischen der Anforderungsliste und den weiteren Schritten ermöglicht, dass sich die Anforderungen auch unter einer veränderten Aufgabenstellung oder sich wandelnden Rahmenbedingungen angepasst werden und somit zur Erfüllung des Entwicklungsziels beitragen können.⁷ Dem ersten Arbeitsschritt nachgelagert, schließen sich der Konzept- und der Entwurfsprozess an. Im Zuge der weiteren sechs Arbeitsschritte werden Funktionsstruktur, prinzipielle Lösungen, modulare Strukturen, Vorentwürfe, Gesamtentwürfe und die finale Produktdokumentation erarbeitet.⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Generelles Vorgehen beim Entwickeln und Konstruieren Quelle: In Anlehnung an VDI-Richtlinie 2221 (1993) S. 9.

Die frühe Reflektion des Anforderungsbegriffs zeigen PAHL/BEITZ, in dem Sie diesen nicht nur als Ausgangspunkt für VDI-Richtlinie 2221 sondern auch als Endpunkt der Produktplanung, gemäß VDI-Richtlinie 2220, einordnen.⁹ Zentrales Element dieses Planungsprozesses ist, nach VDI-Richtlinie 2220, die Produktideenfindung, aus der eine Produktdefinition resultiert, die bei positiver Entscheidung in einen Entwicklungsauftrag mündet, bevor sie in die Entwicklung und Konstruktion übergeht.¹⁰ Sie schaffen somit nicht nur eine Brücke zwischen zwei Richtlinien aus der Richtliniensammlung des VDI. Sie zeigen vielmehr, dass Anforderungen und deren Dokumentation bereits in der frühen Phasen der Produktentstehung eine erhebliche Rolle spielen und dies seinen Niederschlag auf der strategischen und operativen Ebene findet.

2.1.2 Vorgehen entlang des V-Modells nach VDI-Richtlinie 2206

Bei der Entwicklungsmethodik für mechatronische Systeme nach VDI-Richtlinie 2206 handelt es sich um ein integriertes Vorgehensmodell. Im Vergleich zu den klassischen Modellen zeichnen sich diese durch ihre holistische Sichtweise aus. Die Betrachtung der einzelnen Phasen erfolgt nicht voneinander isoliert, sondern phasenübergreifen.¹¹ VDI-Richtlinie 2206 ist als Ergänzung zu VDI-Richtlinie 2221 und VDI-Richtlinie 2422 zu sehen und richtet sich v. a. an Entwickler mechatronischer Systeme.¹² Hierbei handelt es sich um komplexe Systeme, die das Zusammenwirken einer Vielzahl von Subsystemen aus dem Maschinenbau, der Elektrotechnik und der Informationstechnik beschreiben.¹³ Das Beherrschen der Komplexität wird im Besonderen durch eine präzisierte Aufgabenstellung und über differenziert berücksichtigte Anforderungen in allen Entwicklungsphasen ermöglicht.¹⁴

Die Richtlinie gründet ihr flexibles Vorgehen auf drei Säulen: der allgemeine Problemlösungszyklus auf Mikroebene, das V-Modell auf Makroebene und vordefinierte Prozessbausteine für die Bearbeitung von wiederkehrenden Arbeitsschritten.¹⁵

Der übergeordnete Rahmen der Entwicklung nach VDI-Richtlinie 2206 wird durch das V-Modell gebildet (vgl. Abbildung 4), das seinen Ursprung in der Softwareentwicklung hat.¹⁶ Dieses generische Vorgehen wurde an die Rahmenbedingungen zur Entwicklung von mechatronischen Systeme angepasst. In der Softwareentwicklung findet dieses Vorgehen bspw. im Rahmen von Automotive SPICE Anwendung.¹⁷ Ausgangspunkt sind auch in diesem Vorgehensmodell Anforderungen. Sie können sich sowohl auf das zu entwickelnde Produkt als auch auf das zu entwickelnde Produktionssystem beziehen.¹⁸ Die Anforderungen werden sukzessive, mit zunehmender Konkretisierung, zu den gewünschten Soll-Eigenschaften des Systems bzw. der jeweiligen Subsysteme überführt. Diese Phase wird als Systementwurf bezeichnet. Gleichzeitig dienen die Anforderungen als Maßstab für das zu entwickelnde System, wenn das System und seine Subsysteme durch schrittweise Integration zu einem Produkt aufgebaut werden. Die Zusammenführung der einzelnen Subsysteme zu einem Produkt wird Systemintegration genannt. Die

Durchführung des jeweiligen Entwicklungskerns findet, zwischen dem Systementwurf und der Systemintegration, im domänenspezifischen Entwurf statt.¹⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: V-Modell als Makrozyklus

Quelle: In Anlehnung an VDI-Richtlinie 2206 (2004), S. 30.

Der V-förmige Aufbau des Vorgehensmodells verdeutlicht hierbei, dass nicht nur vor- und nachgelagerte Arbeitsschritte iterativ miteinander verbunden sind, sondern auch gleichgelagerte Schritte aus Systementwurf und Integration miteinander kommunizieren können und somit eine Absicherung der Eigenschaften anhand der Anforderungen stattfindet.²⁰ Die Eigenschaftsabsicherung ist eines der wesentlichen Merkmale der Entwicklung nach dem V-Modell und dient zur Sicherstellung der Qualität. Es ist somit möglich die Erfüllung von Anforderungen zu validieren und zu verifizieren. Auf diese Weise wird gewährleistet, dass die Gesamtheit der geforderten Merkmale, gemäß ihrer Eignung, erfüllt wird.²¹ Dies erlaubt Rückschlüsse auf die Effektivität und die Effizienz des Produktes gegenüber dem Einsatzzweck und gegenüber der Spezifikation.²²

Das Gesamtvorgehen nach VDI-Richtlinie 2206 entlang des V-Modells kann mehrfach durchlaufen werden. Es kann sowohl sequentiell als auch parallel erfolgen. Die Parallelisierung ermöglicht hierbei die Umsetzung von verschiedenen Subsystemen. Durch die sequentielle Wie- derholung von Makrozyklen ist eine enge Abstimmung zwischen Produkt- und Produktionssystementwurf möglich, sodass der Reifegrad der Prozesse und des Produkts zwischen den jeweiligen Makrozyklen zunehmend gesteigert werden kann.²³

Das zweite, zentrale Element der Entwicklung nach VDI-Richtlinie 2206 sind die Mikrozyklen zur Problemlösung. Diese bieten einen allgemeinen und flexiblen Rahmen bei der Lösung von vorhersehbaren und unvorhergesehenen Problemen zu verschiedenen Zeitpunkten im Makrozyklus.²⁴ Ausgehend von einem gewünschten Soll- oder gegebenen Ist-Zustand lassen sich Ziele oder Szenarien ableiten, die anschließend mittels eines Syntheseschritts zur Erarbeitung möglicher Lösungen herangezogen werden. Die entwickelten Lösungsansätze werden im Weiteren analysiert und bewertet, sodass eine viel versprechende Lösungsalternative ausgewählt werden kann. Im letzten Schritt wird die Umsetzung der Lösung in Form einer Planung durchgeführt.²⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Mikrozyklus der Problemlösung

Quelle: In Anlehnung an VDI-Richtlinie 2206 (2004), S. 28.

Zur Beschreibung von wiederkehrenden Prozessschritten werden vordefinierte Prozesse eingesetzt, die als Prozessbausteine die dritte Säule des Vorgehensmodells bilden. Die wichtigsten

Prozessbausteine zeigen sich bereits im V-Modell als Systementwurf, domänenspezifischer Entwurf, Systemintegration und Eigenschaftsabsicherung. Durch die Prozessbausteine ergibt sich ein detailliertes Vorgehensschema für das Gesamtmodell. Dieses ermöglicht es, ausgehend von einer geplanten und geklärten Aufgabenstellung sowie der Anforderungsliste konkrete Lösungskonzepte zu erarbeiten, die anschließend im domänenspezifischen Entwurf umgesetzt werden.²⁶ Die Systemintegration erfolgt durch modulare oder räumliche Integration bzw. durch die Integration verteilter Komponenten.²⁷

Insgesamt ist die VDI-Richtlinie 2206 ein ganzheitlicher Ansatz zur Entwicklung von komplexen Systemen. Anforderungen spielen in diesem Vorgehensmodell eine wichtige Rolle, da sie den Ausgangspunkt für die einzelnen Makrozyklen bilden. Aufgrund der hohen Flexibilität des Vorgehens, der Vielschichtigkeit der einzelnen Prozesse der möglichen Iteration und der Eigenschaftsabsicherung müssen Anforderungen sowie deren Dokumentation der Dynamik und den Ansprüchen des Modells gerecht werden können.

2.1.3 Münchener Vorgehensmodell

Die Produktentwicklung mit Hilfe der vorgestellten Normen setzt i. d. R. einen Entwicklungsauftrag oder eine Aufgabenstellung voraus.²⁸ Das Münchner Vorgehensmodell (MVM) bildet den Ansatz ab, dass die Produktentwicklung in unterschiedlichen Phasen, auf unterschiedlicher Basis, ansetzen kann. Dies ist auch der Grund, weshalb sich das MVM von einer linearen Struktur abwendet und als Netzwerk dargestellt wird. Das Modell besteht insgesamt aus sieben Knotenpunkten. Diese sind Ziele planen, Ziele analysieren, Probleme strukturieren, Lösungsideen ermitteln, Eigenschaften ermitteln, Entscheidungen herbeiführen und Zielerreichung absichern (vgl. Abbildung 6).²⁹ Mittels dieser Schritte lassen sich Ziele und Probleme einer Produktentwicklung klären, Lösungsalternativen generieren und konkrete Entscheidungen für die Entwicklung herbeiführen.³⁰

Die einzelnen Elemente sind untereinander verbunden. Eine Abgrenzung zwischen den Elementen ist nicht immer eindeutig möglich. Dies wird durch die Schnittmenge der Kreise verdeutlicht.³¹ Durch die Vielzahl der Verbindungen zwischen den einzelnen Elementen unterstreicht das Modell zusätzlich den iterativen Charakter und die Anpassung an die individuellen Bedürfnisse des jeweiligen Entwicklungsprozesses. Trotz des hohen Grads an Individualität bietet das Modell durch ein Standardvorgehen auch für weniger erfahrene Entwickler einen konkreten Leitfaden zur Entwicklung von neuen Produkten.³²

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Münchner Vorgehensmodell

Quelle: In Anlehnung an Lindemann (2009), S. 51

Einen besonderen Anforderungsbezug weisen die ersten Schritte des Standardvorgehens auf. Während der Planung der Ziele, dem ersten Schritt, werden übergeordnete Merkmale strukturiert und die Auswirkungen von Veränderungen dieser Merkmale analysiert.³³ Der zweite Arbeitsschritt, das Analysieren von Zielen, bezieht sich explizit auf den Umgang mit den Anforderungen an das zu entwickelnde Produkt Im Zuge des Vorgehens kommt es zunächst zu einer Sammlung aller Anforderungen.³⁴ Damit Anforderungen in einer verwertbaren Form vorliegen und somit zur Ermittlung von Eigenschaften herangezogen werden können, sollten diese in einer Anforderungsliste dokumentiert werden.³⁵ Hierfür sollten Anforderungen bei der Zieldefinition auf Inkonsistenz und Redundanz untersucht werden. Außerdem sollte eine detaillierte Strukturierung und Gewichtung der Anforderungen erfolgen.³⁶ In der nachfolgenden Strukturierung der Probleme findet zusätzlich eine Verknüpfung der technischen Entwicklungsziele, die sich u. a. über die Anforderungen definieren, mit den Lösungsmerkmalen des Produktes statt. Ebenso werden Stärken und Schwächen analysiert. Am Ende dieses Vorgehens soll ein Entwicklungsschwerpunkt aus der Analyse hervorgehen.³⁷ Im vierten Schritt des Standardvorgehens kommt es zur Ermittlung der eigentlichen Lösungsideen. Hierfür wird entweder auf bereits existierende Lösung oder zur Entwicklung neuer Ideen zurückgegriffen.³⁸ Ist eine Anforderungsliste erstellt kann diese auch im weiteren Vorgehen unterstützend eingesetzt werden. Bei der Ermittlung der Eigenschaften, kann eine Anforderungsliste eine Möglichkeit zu Ableitung der relevanten Merkmale des Produkts dienen und eine Referenz zwischen Soll-Eigenschaften und Anforderungen darstellen(Vgl. Abschnitt 2.2.1).³⁹ Ebenso lassen sich beispielsweise Bewertungskriterien und deren Maßstab aus der Anforderungsliste ableiten.⁴⁰

Das MVM stellt somit ein Vorgehensmodell dar, das die Erfassung und Dokumentation von Anforderungen nicht zwingend voraussetzt, aber dennoch einen hohen Bezug zu diesen aufweist. Durch dokumentierte Anforderungen lassen sich zahlreiche Schritte entlang des gesamten Vorgehens vereinfachen und für den Anwender nachvollziehbarer und effizienter gestalten. Dies zeigt, dass Anforderungen und deren Dokumentation auch im MVM eine tragende Rolle innehaben.

2.2 Modellierung von technischen Produkten und technischen Systemen

Zum Verständnis der Anforderungsdokumentation und der besseren Einordnung des Anforderungsbegriffs in den Entwicklungsrahmen, werden nachfolgend die Modelle technischer Produkte und technischer Systeme dargestellt. Diese Modelle zeigen Anforderungen, Eigenschaften und Soll-Eigenschaften sowie derer Zusammenhänge.

2.2.1 Grundlagen technischer Systeme

Um die Modellierung von technischen Systemen und somit auch von Produkten zu verstehen, ist es zunächst wichtig das technische System genauer zu betrachten. Technische Produkte werden von technischen Systemen umfasst.⁴¹ Technische Systeme grenzen sich sozialen und ideellen Systemen durch ihre Elemente und Teilsysteme ab. Diese sind Objekte wie bspw. mehrgliedrige Erzeugnisse, Maschinen oder Regelkreise.⁴² „Technische Systeme sind künstlich erzeugte geometrisch-stoffliche Gebilde, die einen bestimmten Zweck (Funktion) erfüllen, also Operationen (physikalische, chemische, biologische Prozesse) bewirken.“⁴³ Liegt der Kern der Betrachtung vornehmlich auf dem benannten Gebilde und nicht auf dem System, so handelt es sich um ein technisches Produkt.⁴⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Darstellung eines Systems

Quelle: In Anlehnung an Ehrlenspiel/Meerkamm (2013), S. 22.

Wie alle Systeme setzen sich auch technische Systeme aus unterschiedlichen Bestandteilen zusammen (vgl. Abbildung 7). Von außen betrachtet erscheinen funktionale Systeme als eine Black Box, die sich durch die gewünschten und unerwünschten Ein- und Ausgangsgrößen definieren lässt und durch die Systemgrenzen eingefasst wird. Innerhalb dieser Systemgrenzen setzt sich ein System jedoch aus einer Vielfalt von verschiedenen Elementen zusammen, wobei die einzelnen Elemente untergeordnete Teilsysteme sein können, die sich wiederum in weitere Elemente aufteilen lassen. Sowohl das System als auch die Teilsysteme lassen sich durch die Systemgrenze von der Systemumgebung oder der nächst höheren Systemebene abgrenzen. Die einzelnen Elemente eines Systems sind über Relationen zueinander oder mit der Systemumgebung verbunden und stehen mit diesen in verschiedentlichen Beziehungen.⁴⁵ Systeme die in Interaktion mit dem Menschen stehen werden als sozio-technische Systeme bezeichnet.⁴⁶

Jedes technischen Systems lässt sich durch Eigenschaften, die dieses genauer spezifizieren, beschreiben. „Eine Eigenschaft ist alles, was durch Beobachtungen, Messergebnisse, allgemein akzeptierte Aussagen usw. von einem Gegenstand festgestellt werden kann. […] Eigenschaften […] haben eine Bedeutung (Semantik, Qualität) und eine evtl. zahlenmäßige Ausprägung (Quantität).“⁴⁷ Soll-Eigenschaften nehmen hierbei eine besondere Rolle ein. Sie beschreiben das zu entwickelnde Produkt nicht in seinem Ist-Zustand. Sie repräsentieren die Summe aller geforderten und gewünschten Eigenschaften eines zu entwickelnden Produktes.⁴⁸ Diese müssen dann durch weitere Konstruktionsschritte in Produkteigenschaften überführt werden.

2.2.2 Modelle technischer Systeme und technischer Produkte

Eines der bekanntesten Modelle ist das Pyramidenmodell zur Produktkonkretisierung nach EHRLENSPIEL/MEERKAMM (vgl. Abbildung 8). Gemäß dieses Modells wird ein Produkt über vier Ebenen modelliert. Die Ebenen sind hierarchisch-deterministisch miteinander verbunden. Auf jeder Ebene werden mehrere Lösungsmöglichkeiten erarbeitet, von denen jeweils eine zur Weiterentwicklung auf der nächsten Ebene ausgewählt wird. Auf erster Ebene erfolgt die Auswahl auf Basis der funktionellen Lösungsmöglichkeiten, die anschließend über prinzipielle physikalische, gestalterische und stoffliche bis hin zu fertigungs- und montagetechnischen Lösungsmöglichkeiten verfeinert werden. Aus der Menge der fertigungs- und montagetechnischen Lösungsmöglichkeiten wird letztlich das Produkt ausgewählt.⁴⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Hierarchische Modellierung technischer System mittels Pyramidenmodell Quelle: Ehrlenspiel/Meerkamm (2013), S. 39.

Die hierarchische Ausrichtung des Modells zeigt sich in Form einer Pyramide mit der verbundenen Leserichtung von oben nach unten. Dies unterstreicht, dass höher gelegene Ebenen (z. B. funktionelle Ebene) einen deutlich größeren Einfluss auf die Lösungsmöglichkeiten in den tiefer gelegenen Ebenen (z. B. stoffliche und gestalterische Ebene) nehmen. Zusätzlich zeigt sich in diesem Modell die Bedeutung der Entwicklung vom Abstrakten zum Konkreten für den gesamten Prozess.⁵⁰

Ebenfalls in Pyramidenform ist das Modell nach SAUER aufgebaut. Auch bei SAUER verdeutlicht die Pyramidenform das schrittweise Konkretisieren bei der Lösungsfindung. Im Vergleich zu EHRLENSPIEL/MEERKAMM, erweitert SAUER das Pyramidenmodell sowohl um Prozess- als auch um Verfahrensgrößen. Neben der Verfahrensebene beinhaltet das Modell weitere Ebenen, in den Bereichen der Funktionen, Effekte, Wirkprinzipien und Gestalt. Es besteht somit aus fünf Entwicklungsebenen. Zusätzlich wird das Pyramidenmodell um den Bereich der Anforderungen ergänzt, welcher sich unmittelbar auf die Prozessgrößen sowie die Entwicklungsebenen auswirkt (vgl. Abbildung 9).⁵¹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Pyramidenmodell technischer Systeme nach SAUER Quelle: In Anlehnung Sauer (2006), S. 68.

Ein weiteres Produktmodell wird von PONN/LINDEMANN beschrieben. Bei dem sog. Münchner Produktkonkretisierungsmodell (MKM) wird die besondere Rolle der Anforderungen für die Entwicklung betont. Übergeordnet lässt sich das Modell in den Anforderungsraum und den Lösungsraum unterteilen. Während im Anforderungsraum die Klärung der Entwicklungsziele zu Beginn stattfindet, werden im Lösungsraum konkrete Lösungsmöglichkeiten erarbeitet. Der Lösungsraum kann weiterhin in drei Ebenen unterteilt werden. Diese sind die Funktions-, Wirkund Bauebene (vgl. Abbildung 10).⁵²

Die Funktionsebene dient hierbei zur zweckorientierten Beschreibung der Funktionen des Produktes und seiner Bestandteile auf einer abstrahierten Ebene.⁵³ Auf der Wirkebene werden prinzipielle Lösungsmöglichkeiten mittels der Wirkprinzipien und einer Wirkstruktur dargestellt. Diese werden auf der Bauebene zu einem konkreten und herstellbaren Produkt weiterverarbeitet und resultieren somit in einem Baumodell, bestehend aus Bauteilen, Baugruppen und einer Baustruktur. Auf dem Weg von der abstrakten Idee hin zur konkreten Lösung bewegt sich der Produktentwickler entlang der Dimensionen Konkretisierungsgrad, Zerlegungsgrad und Variationsgrad. Das letztliche Produkt entsteht durch Konkretisierung, Abstraktion, Zerlegung, Zusammenfügen, Einschränken und Variieren entlang dieser Dimensionen innerhalb des Lösungsraums (Abbildung 10).⁵⁴ Im Anforderungsraum werden die Anforderung von außen kommend strukturiert, analysiert und priorisiert und anschließend kontinuierliche über alle Ebenen des Lösungsraums eingearbeitet.⁵⁵ Eine Anforderungsdokumentation muss demnach in der Lage sein diese Schritte abbilden zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Münchner Produktkonkretisierungsmodell Quelle: Ponn/Lindemann (2013), S. 28

Während die vorhergehenden Modelle die Anforderungen nur teilweise oder gar nicht einbeziehen, erarbeitet MATTMANN erstmalig eine Modelltheorie, welche die Transformation von Marktanforderungen bis hin zu den konkreten Produkteigenschaften beschreibt. Hierbei werden die Anforderungen ebenfalls im Anforderungsraum gesammelt, aber auch strukturiert. Mittels einer Projektionsebene, welche die Anforderungen zu Soll-Eigenschaften transformiert, werden diese im Weiteren in eine Kombination aus Lösungs- und Eigenschaftsraum überführt. Innerhalb des Lösungsraums findet die Konkretisierung bis zu den Produkteigenschaften statt.⁵⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Modelltheorie zur Transformation von Anforderungen in Produkteigenschaften Quelle: Mattmann (2014), S. 104.

Die beschriebenen Zusammenhänge belegt MATTMANN auf Basis von acht Thesen. Mit Hilfe dieser Thesen weißt er nach, dass:

- ein Lösungsraum eines zu entwickelnden, technischen Produkts in einem Vier-Ebenen Pyramidenmodell (Produktfunktions-, Effekt-, Wirk- und Gestaltmodell) existiert,⁵⁷
- ein Eigenschaftsraum existiert, in dem ein Produkt auf unterschiedlich abstrakten Ebe nen (Funktionale Produkt-, Effekt-, Wirkprinzip- und Gestaltungseigenschaften) be schrieben werden kann und dieser mit dem Lösungsraum verbunden ist,⁵⁸
- ein Anforderungsraum existiert, der die Gesamtheit aller Anforderungen und Anforde rungsarten beinhaltet,⁵⁹
- es einen Erfassungsprozess gibt, über den die Anforderungen unterschiedlichster Anfor derungsquellen in den Anforderungsraum transformiert werden,⁶⁰
- die erfassten Anforderungen im Anforderungsraum auf unterschiedlichen Ebenen vor liegen, wobei die Zahl der Ebenen des Anforderungsraums größer ist als die Zahl der Ebenen des Lösungsraums,⁶¹
- die Anforderungen der verschiedenen Ebenen des Anforderungsraums mit den Produkt modelleigenschaften des Produktmodells korrelieren,⁶²
- Anforderungen über die Transformation in Soll-Eigenschaften auf einer Projektions-/ Zielebene in den Lösungsraum überführt werden können und dieser Lösungsraum die Struktur des Eigenschaftsraums aufgreift und⁶³
- weitere Anforderungen aus den Produkteigenschaften resultieren können.⁶⁴

MATTMANN liefert mit diesem Modell zur Transformation einen ganzheitlichen Überblick über die Entwicklung von Kundenwünschen und Anforderungen bis zum Produktmodell. Er gibt eine klare Einordnung und Abgrenzung von Anforderungen, Soll-Eigenschaften und Produkteigenschaften. Durch die exakte Beschreibung der Überführung von Anforderungen in Produkteigenschaften schließt er die Lücke zur systematischen Abbildung von Anforderungen in Produkteigenschaften.

Innerhalb des Anforderungsraums werden die Erwartungen von Stakeholdern des Produkts zunächst auf Anforderungslevel weiterentwickelt. Durch Präzisieren, Detaillieren und Aggregieren können die existierenden Anforderungen inhaltlich und formal verfeinert und in der Anzahl reduziert oder ausgebaut werden. Die Überführung der von Anforderungen zu Soll-Eigenschaften erfolgt mittels einer Transformation. Da sich aus dem nachfolgenden Konstruktionsschritt weitere Soll-Eigenschaften ergeben können, ist die Transformation nicht zwingend unidirektional. Es kommt vielmehr zu einem zyklischen Prozess, bei dem Anforderungen durch Transformation und Konstruktion in Produkteigenschaften überführt werden. In entgegengesetzter Richtung lassen sich aus den Produkteigenschaften weitere Soll-Eigenschaften ableiten, die wiederum durch rückwirkendes Konstruieren und Transformieren, in zusätzliche Anforderungen münden.⁶⁵

Das Transformationsmodell bildet somit einen ganzheitlichen Rahmen für die Überführung von Kundenwünschen und Bedürfnissen in Anforderungen und Produkteigenschaften. Es schafft eine Struktur, welche die durchgängige Nachverfolgung dieser erlaubt. Durch die Projektionsebene zeigt MATTMANN wie sich aus den Anforderungen die konkreten Produkteigenschaften einer Lösungsalternative entwickeln. Die Arbeit von SPIES vertieft diesen Ansatz und beleuchtet v. a. die Wechselbeziehungen innerhalb der unterschiedlichen Stadien von Anforderungen, Soll-Eigenschaften und Produkteigenschaft. Dabei wird davon ausgegangen, dass Zielkonflikte und Redundanz vornehmlich im Anforderungsraum gelöst werden.

2.3 Abgrenzung des Anforderungsbegriffs

Um die Dokumentation von Anforderungen untersuchen zu können, ist es sinnvoll den Begriff der Anforderung besser zu verstehen. Der Nachfolgende Abschnitt stellt daher unterschiedliche Definitionen des Anforderungsbegriffs vor. Ebenso werden im weiteren Verlauf unterschiedliche Merkmale zur Klassifikation und Unterscheidung von Anforderungen vorgestellt.

2.3.1 Definitionen des Anforderungsbegriffs

Der Begriff der Anforderung ist im konstruktionswissenschaftlichen Kontext von zentraler Bedeutung. In der Literatur ist der Anforderungsbegriff demnach in unterschiedlichen Ausprägungen wiederzufinden. Wie nachfolgend aufgezeigt, kann die Bedeutung des Begriffs jedoch teilweise in Perspektive und Verständnis variieren. Zusätzlich erschwert wird die Definition des Anforderungsbegriffs durch die Verwendung ähnlicher Begriffe wie z. B. Forderung, Wunsch, Spezifikation, Erwartung, Rahmenbedingung oder Grenzen bzw. Restriktion mit synonymem Charakter oder auch die wenig einheitliche Verwendung der Übersetzung aus dem und in das Englische, das requirement.⁶⁶ Die Nähe zwischen den unterschiedlichen Begrifflichkeit führt in der englischsprachigen Literatur soweit, dass SUDIN/AHMED-KRISTENSEN die Substituierbarkeit von den Begriffen Anforderung und Spezifikation postulieren.⁶⁷ Im Folgenden wird auf die Besonderheiten der jeweiligen Definitionen eingegangen, um ein grundsätzliches Verständnis der unterschiedlichen Definition erlangen zu können.

Tabelle 1 bietet eine Übersicht der unterschiedlichen Definitionen des Anforderungsbegriffs aus der Fachliteratur und Standardwerken der Konstruktionswissenschaft. Im Folgenden wird auf die Besonderheiten der jeweiligen Definitionen eingegangen, um ein grundsätzliches Verständnis der unterschiedlichen Definition erlangen zu können.

Tabelle 1: Definitionen des Anforderungsbegriffs

Abbildung in dieser Leseprobe nicht enthalten

Der Anforderungsbegriff nach PAHL/BEITZ orientiert sich im Wesentlichen stark an der Definition von KICKERMANN. Gemäß KICKERMANN beinhaltet der Anforderungsbegriff Vorgaben, sowohl an die Eigenschaften eines zu beschreibendes Produkts als auch zielgerichtete Erwartungen des Konstruktionsprozesses.⁶⁸ Durch das Verständnis der Anforderung als Vorgabe unterstreicht er die Bedeutung der Anforderungen für die frühe Phase der Entwicklung. Hieraus geht hervor, dass Anforderungen die Basis für die nachfolgenden Schritte im Produktentwicklungsprozess bilden. Das Verständnis der Anforderung als Vorgabe drückt allerdings zugleich den wenig verbindlichen Charakter der Anforderungen für mögliche Soll- oder Produkteigenschaften aus. Die Anforderung selbst beschreibt einen sog. Anforderungsgegenstand, durch dessen Ausprägung mit seinem spezifischen Wert.⁶⁹ Besonders letzterer Aspekt zeigt einen expliziten Bezug zwischen der Anforderung auf inhaltlicher Ebene und dem vorliegenden Verständnis von Soll- und Produkteigenschaften. Ergänzend hierzu definieren Anforderungen nach PAHL/BEITZ Restriktionen, sog. Gerechtheiten, für den Entwicklungsprozess.⁷⁰ Diese bilden den Rahmen der Entwicklung und führen dazu, dass sich der Lösungsraum im Laufe des Entwicklungsprozesses immer weiter konkretisieren lässt, sodass am Ende ein fertiges Produkt das Resultat des Vorgehens darstellt. Dies hat zur Folge, dass Anforderungen einen erheblichen Einfluss auf die spätere Gestalt des Produktes nehmen. Zur Identifikation der Anforderungen werden dabei alle Phasen des Produktlebenszyklus betrachtet.

BIRKHOFER legt dar, dass die Anforderungen eines Produktes den Soll-Eigenschaften dieses Produkts entsprechen und schafft so einen unmittelbaren Zusammenhang wischen Anforderungen und Soll-Eigenschaften. Anforderungen setzen sich gemäß seiner Definition aus einem Merkmal mit einem zugehörigen Wert zusammen. Ebenso verdeutlich er, dass sich Anforderungen, im Vergleich zu Eigenschaften, auf hypothetische Objekte und nicht auf reale Produkte beziehen. Dies impliziert gleichzeitig, dass die Anforderungen den Raum aller hypothetischen Produktlösungen darstellen können.⁷¹ Eine Existenz einer Anforderung, die rein aus einem Merkmal oder einem Wert besteht, ist nicht möglich. Im ersteren Fall spricht BIRKHOFER von einer unvollständigen Anforderung.⁷²

Ebenso wie BIRKHOFER verstehen EHRLENSPIEL/MEERKAMM unter Anforderungen die Soll-Eigenschaften eines Produktes. Sie gehen allerdings implizit davon aus, dass die Gesamtheit der Anforderungen und nicht nur der momentane Wissenstands zu erfassen sind. Die Summe aller Anforderungen spiegelt somit eine erste, abstrakte Lösung eines konstruktionswissenschaftlichen Problems wieder. Davon ausgehend, dass sich das entwickelte, reale Produkt durch seine Ist-Eigenschaften beschreiben lässt, bietet diese Perspektive zusätzlich die Möglichkeit zur Überprüfung der Zielerreichung der Entwicklungsaktivitäten. EHRLENSPIEL/MEERKAMM postulieren des Weiteren, dass die Formulierung der Anforderungen durch Kürze und Präzision gekennzeichnet sein sollten. Die kommunikative Grundlage bildet die Sprache des Konstrukteurs.⁷³

LINDEMANN beschreibt Anforderungen als konkretes Entwicklungsziel und die Repräsentation von Eigenschaften, die von einem Produkt erwünscht sind. Aus seiner Sicht sind Anforderungen für den Entwicklungsprozess von besonderer Bedeutung, da sie bereits früh im Entwicklungsprozess den Raum für mögliche Lösungen definieren.⁷⁴ Dies wird von LINDEMANN zusätzlich unterstrichen, in dem er Anforderungen eine verpflichtende Natur zugesteht. Dies hat zur Folge, dass ein Produkt erst als abgeschlossen entwickelt betrachtet werden kann, wenn alle Anforderungen eingeflossen bzw. umgesetzt worden sind. Die Nichterfüllung einer Anforderung führt, aufgrund der hohen Bedeutung der Zielerfüllung bei dieser Betrachtungsweise, zu einem zu verbessernden Produkt.⁷⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Unterscheidung nach qualitativen und quantitativen Anforderungen Quelle: Eigene Darstellung nach Ponn/Lindemann (2011), S. 39

Diese Sichtweise wird durch PONN/LINDEMANN verstärkt, indem Anforderungen mit Forderungen, z. B. des Kunden, an die Eigenschaft eines Produktes oder eines Entwicklungsprozesses eng verknüpft werden. Zusätzlich werden die formalen Bestandteile einer Anforderung definiert. Diese sind Merkmal und Ausprägung. Während sich das Merkmal auf das Bezugsobjekt bezieht, definiert die Ausprägung den entsprechenden Soll-Wert einer Anforderung. Dieser SollWert kann sowohl quantitativen als auch qualitativen sein.⁷⁶ Der intensivierte Bezug von Anforderungen und geforderten Eigenschaften zeigt, dass bei dieser Sichtweise die Anforderungen, ähnlich eines Mappings, näher an die Soll-Eigenschaften rücken als bei vorherigen Ansätze. Diese werden als Repräsentant von Soll-Eigenschaften verstanden werden. Die Unterscheidung von qualitativen und quantitativen Anforderungen könnte, beispielhaft betrachtet, das Merkmal der Abmessungen eines Bauteils sein (vgl. Abbildung 12). Qualitative Ausprägungen wäre „ermöglichen die Integration des Bauteils in das Gehäuse“. Quantitative Ausprägungen wäre hingegen „betragen an der Außenkante in der Breite 200 mm, in der Höhe 75 mm und in der Tiefe 100 mm“.

In der VDI-Richtlinie 2221 werden Anforderungen ebenfalls mit requirements gleichgesetzt. Im Wesentlichen beschreiben sie die Eigenschaften bzw. die Bedingungen für einen Produkt. Wie bei EHRLENSPIEL/MEERKAMM weist auch die VDI-Richtlinie einen Eigenschaftsbezug auf. Allerdings dienen diese Eigenschaften zur Definition qualitativer und quantitativer Anforderungen und nicht zur Zieldefinition. Die Unterscheidung von Anforderungen nach qualitativem und quantitativem Charakter ist der Auffassung von PONN/LINDEMANN ähnlich. In der Definition nach VDI-Richtlinie 2221 wird darüber hinaus ein besonderes Augenmerk auf die Gewichtung der Anforderungen gelegt. Diese schafft die Möglichkeit zur Priorisierung der unterschiedlichen Anforderungen zueinander.⁷⁷ Hierdurch wird ebenfalls gezeigt, dass Anforderungen nicht nur die Bestandteile von Soll-Eigenschaften widerspiegeln, sondern auch darüber hinaus Information für den Entwickler liefern können.

Eine Betrachtung des Anforderungsbegriffs aus Sicht der Softwareentwicklung liefert der IEEE Standard 610. Anforderungen werden hierbei als gewünschte, zu erfüllende Eigenschaften, aufgefasst, welche dem Anwender bei der Lösung eines Problems oder der Erreichung von Zielen behilflich sein sollen. Die entsprechende Anforderung wird hierbei einem speziellen System oder einem Element eines Systems eindeutig zugeordnet und dient zur Erfüllung eines übergeordneten Entwicklungsziels. Zusätzlich lassen sich die Anforderungen aus gesetzlichen und normativen Texten sowie anderen formalisierten Dokumenten ableiten.⁷⁸

Auch AHRENS greift die Definition von KICKERMANN auf.⁷⁹ Er zeigt jedoch auch, dass Anforderungen oftmals nicht ausreichend sind, um unmittelbar im Konstruktionsprozess umgesetzt zu werden. Neben der vollständigen Ermittlung dieser Anforderungen stellt für ihn der Transformationsprozess eine besondere Bedeutung dar, da im Zuge dessen aus unterschiedlich konkreten Anforderungen in technische Anforderungen überführt werden können.⁸⁰ Technische Anforderungen entstammen hierbei dem Verständnis von ULRICH/EPPINGER und umfassen sowohl skalierbare Anforderungen als auch die Restriktionen des zu entwickelnden Produkts, sodass dieses in einem exakten Soll-Zustand beschrieben werden kann. Die Ermittlung der technischen Anforderungen, dem Verständnisses von AHRENS entsprechend, erfolgt durch die Transformation der Kundenanforderungen, durch den Entwickler oder ein Team mit einer interdisziplinären Zusammensetzung.⁸¹

Eine ausführliche Definition des Anforderungsbegriffs wird von GRAMLICH vorgenommen. Dieser versteht unter den Anforderungen sowohl qualifizierte als auch quantifizierte Repräsentation von Soll-Eigenschaften eines technischen Produkts. Er postuliert, dass Anforderungen einen Bezug zu Wirk-und Prozessgrößen darstellen können. Zudem stellt er fest, dass diese Soll-

Eigenschaften auch Bereiche bzw. Wertemengen verkörpern können. Aus der Summe aller SollEigenschaften resultieren die Alternativen von hypothetischen Produkten.⁸²

Ebenfalls eine besonders umfassende Definition des Anforderungsbegriffs liefert MATTMANN. Auch er versteht unter Anforderungen an technische Produkte das Umfassen von Soll-Eigenschaften eines technischen Produktes, welches es noch zu entwickeln gilt. Er erweitert den Anforderungsbegriff nach GRAMLICH um die Repräsentation komparative Soll-Eigenschaften. Er legt des Weiteren fest, dass Anforderungen in Anforderungslisten zu dokumentieren sind.⁸³ Die Definition der Anforderungen an das technische Produkt beinhaltet, dass es sich bei Anforderungen um Eigenschaften eines hypothetischen, nicht realen Produktes handeln kann, welches es zunächst noch zu entwickeln gilt.⁸⁴

2.3.2 Merkmale zur Klassifizierung von Anforderungen

Mit Hinblick auf die weitere Arbeit und die Analyse unterschiedlicher Anforderungsdokumentationen sollen im Nachfolgenden verschiede Klassifizierungsmerkmale aufgezeigt werden, die dazu dienen, Anforderungen voneinander abgrenzen und strukturieren zu können.

2.3.2.1 Inhaltliche Ebene der Anforderungen

Eine zentrale Möglichkeit zur Klassifizierung stellt die Zuordnung der Anforderungen zu inhaltlichen Merkmalen dar.⁸⁵ Diese Systematisierung bietet in frühen Entwicklungsphasen einen besonderen Mehrwert. Sie unterstützt die Dekomposition und Analyse des Produktes und bietet einen zusätzlichen Mehrwert durch die Klassifizierung einer möglichen Dokumentation.⁸⁶ Die Anzahl der inhaltlichen Kriterien kann je nach gewähltem Schema stark variieren.⁸⁷

EHRLENSPIEL/MEERKAMM unterscheiden in ihrer Unterteilung zunächst zwischen zwei Hauptkategorien. Diese sind organisatorische und technisch-wirtschaftliche Anforderungen. Die organisatorischen Anforderungen beziehen sich dabei im Schwerpunkt auf die zeitlichen und personellen Ressourcen sowie die eingesetzten Hilfsmittel. Auf Seite der technisch-wirtschaftlichen Anforderungen ist eine weitere Untergliederung nach rein technischen Anforderungen, Schnittstellen zur technischen Umgebung und der Umwelt, Kosten sowie Gesetzen, Normen, Patenten und Garantien möglich. Ziel dieser Checklisten-basierten Kriterien ist eine vollständige Erfassung aller relevanten Anforderungen.⁸⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Eigenschaftsklassen nach HUBKA/EDER Quelle: In Anlehnung an Hubka (1992), S. 96.

Auch HUBKA/EDER bieten eine solche Einteilung. Gemäß ihrer konstruktionswissenschaftlichen Perspektive genügen zwölf Eigenschaftsklassen zur vollständigen Deckung und inhaltlichen Klassifizierung eines technischen Systems. Diese lassen sich zweckbezogenen, auf Lebensphasen bezogenen, auf den Mensch und die Gesellschaft bezogenen sowie konstruktionsbezogenen Hauptklassen zuordnen (vgl. Abbildung 13).⁸⁹ Jede dieser einzelnen Eigenschaftsklassen erfasst sowohl die inneren als auch die äußeren Eigenschaften eines technischen Systems.⁹⁰

Auch CROSTACK ET AL. liefern eine Möglichkeit zur Klassifizierung der Anforderungen an ein Produkt. Das von ihnen entwickelte Modell dient dabei nicht nur zur inhaltlichen Klassifizierung der Anforderungen. Es versteht sich als ganzheitlichen Ansatz. Auf inhaltlicher Ebene differenziert das Modell zwischen Verbindlichkeiten und Verpflichtungen (bspw. gegenüber Gesetzen und kulturellen Bedürfnissen), der Umwelt, wirtschaftlichen und informationellen Aspekten sowie technisch-funktionalen Gesichtspunkten.⁹¹ Diese Dimensionen werden gemäß deren Anforderungsverständnis mit einer qualitativen Dimension überlagt, die eine Bewertung der jeweiligen Eigenschaften der Dimensionen sicherstellen soll.⁹² Die inhaltliche Ebene wird durch drei weitere Felder, zur gegenseitigen Referenzierung der Eigenschaften, zur Bewertung der Eigenschaften und zur zeitlichen Klassifizierung von Eigenschaften ergänzt, um so dem ganzheitlichen Anspruch des Modells gerecht werden zu können.⁹³ Diese Form der inhaltlichen Klassifizierung geht somit über einen rein inhaltlichen Horizont hinaus.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Übersicht der Hauptmerkmale nach PAHL/BEITZ Quelle: In Anlehnung an Feldhusen et al. (2013b), S. 331.

Eine vierte und sehr umfassende, inhaltliche Unterteilung der Anforderungen wird durch die Hauptmerkmale nach PAHL/BEITZ vorgenommen, diese werden in der Anforderungsliste als Art der Anforderung erfasst.⁹⁴ Die Hauptmerkmale die zur Erfassung aller relevanten Rahmenbedingungen sowie der Funktional- und Qualitätsanforderungen, also den Anforderungsarten, dienen.⁹⁵ Hierfür lassen sich die Hauptmerkmale in die Kategorien Konzept, Produktlebensphase und Organisation einteilen. Jede dieser Kategorien besitzt weitere Unterkategorien, denen eine nochmalige Untergliederung folgt, sodass die Anforderungen an Produkte möglichst genau definiert werden können. Die Kategorie Konzept lässt sich z. B. nach Stoff, Energie, Signal, Geometrie Mechanik, Elektrik/Elektronik, Software, Sicherheit, Ergonomie und Industrial Design weiter aufteilen. Die Produktlebensphasen besitzen acht und die Organisation drei weitere Unterkategorien (vgl. Abbildung 14).⁹⁶ Der Fokus der Hauptmerkmale aus dem Konzeptbereich liegt dabei auf der Beschreibung von direkten Anforderungen an das Produkt und steht teilweise in enger Wechselwirkung mit den Anforderungen des Produktlebenszyklus. Die Hauptmerkmale des Produktlebenszyklus definieren primär die Gerechtigkeiten und Restriktionen die den Produktentwicklungsprozess einschränken können. Die organisatorischen Hauptmerkmale haben einen koordinativen Hintergrund und sollen die Durchführbarkeit des Entwicklungsprozess sicherstellen.⁹⁷

Mattmann schafft bei der Unterteilung der Anforderungen ein neues und klar definiertes Verständnis indem er die Anforderungen nach Anforderungen an das technische Produkt, aus den technischen Prozessen des Produktlebenslaufs und aus den nicht-technischen Prozessen des Produktlebenszyklus aufteilt.⁹⁸ Diese Sichtweise ermöglicht eine klare Abgrenzung der Anforderungen und hilft die Anforderungen über unterschiedliche funktionale, technische, nichttechnische, restringierende und beeinflussende Charakteristika abzugrenzen.

In der Literatur können weitere Kategorisierungen für Anforderungen identifiziert werden. Diese lassen sich allerdings nur sehr bedingt einer inhaltlichen Klassifizierung von Anforderungen zuordnen und finden deshalb in diesem Kontext keine weitere Beachtung.⁹⁹ Dennoch sei angemerkt, dass auch andere Unterteilungen von Anforderung denkbar und sinnvoll sein können.

2.3.2.2 Quellen der Anforderungen

Die Anforderungen nach ihren Quellen zu unterscheiden ist von wesentlicher Bedeutung, da Anforderungen in einer permanenten, bidirektionalen Wechselbeziehung mit ihrem Ursprung stehen und es somit im Laufe des Entwicklungsprozess möglich sein kann, dass auf die ursprüngliche Quelle einer Anforderung zurückgegriffen werden muss.¹⁰⁰

Anforderungen lassen sich aus einer beliebig großen Menge an Quellen ermitteln, die immer dann in den Produktentwicklungsprozess einbezogen werden, wenn die entsprechende Quelle für den Entwicklungsprozess von Relevanz ist. Hierfür lassen sich Anforderungsquellen in drei Gruppen unterteilen. Diese sind Dokumente, Produkte und Personen (vgl. Abbildung 15). Als Personen werden alle internen und externen Stakeholder erfasst, die aktiv, mündlich oder schriftlich in den Entwicklungsprozess einbezogen werden.¹⁰¹ Hierbei werden Personen innerhalb einer Unternehmung als firmeninterne Stakeholder angesehen und alle Personen außerhalb der Unternehmensgrenze als unternehmensexterne Stakeholder bezeichnet. Firmeninterne Stakeholder sind bspw. Entwickler, Vertriebsmitarbeiter oder Projektmanager innerhalb des Unternehmens. Von externen Stakeholder ist z. B. bei (End-)Kunden und Zulieferern.¹⁰² Im Zuge der stärkeren Service-Orientierung von Prozessen, auch innerhalb der Unternehmensgrenzen, werden interne Stakeholder immer öfter als interne Kunden bezeichnet. Dies unterstreicht, dass internen wie auch externen Anforderungen die gleiche Bedeutung beigemessen werden muss. Während externe Stakeholder, durch ihre Rolle als Bedürfnisträger, tendenziell die Anforderungen formulieren, schaffen die internen Stakeholder meist den Rahmen, innerhalb dem sich die Anforderungen bewegen können.¹⁰³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Übersicht der Anforderungsquellen

Quelle: In Anlehnung an Feldhusen et al. (2013b), S. 328.

Eine der wichtigsten, personellen Quellen von Anforderungen sind die Kunden, da ohne diese die Notwendigkeit einer Produktentwicklung nicht gegeben wäre. Der Kunde ist in diesem Zusammenhang ein Nachfrager seitens des Marktes. Kunden können sowohl bekannt als auch anonym sein. Die Entwicklung erfolgt basierend auf einem konkreten Wunsch oder einer Produktvorstellung. Alternativ wird sie durch technologische Entwicklung bedingt bzw. auf die Bedürfnisse des Marktes entwickelt.¹⁰⁴ In beiden Fällen hängt der Erfolg des Produktes in entscheidendem Maße von der Qualität der Erfassung der Anforderungen ab. Nur wenn die Produktanforderungen vollständig und ganzheitlich erfasst sind, ist die Akzeptanz des Produktes seitens des Marktes möglich.¹⁰⁵

Eine weitere Gruppe von Anforderungsquellen setzt sich aus Produkten zusammen. Hierbei können nicht nur eigene Produkte und Technologie als Quelle für marktgerechte Produktentwicklungen dienen. Auch der Blick auf externe Produkte, die sich in Form von Konkurrenzprodukten oder Trends präsentieren können, bietet die Möglichkeit zur Inspiration von Produktanforderungen.¹⁰⁶

Als dritte Form der Anforderungsquelle lassen sich Dokumente identifizieren. Unternehmensintern bietet sich hier die Möglichkeit neben bereits eingesetzten und bekannten Anforderungen generische Anforderungen zu verwenden.¹⁰⁷ Zusätzlich bietet sich die Möglichkeit auf unter- nehmensinterne Normen sowie das Produktberichtswesen zurückzugreifen. Unternehmensextern zählen klassischer Weise Gesetze, Normen und Richtlinien zu den berücksichtigten Anforderungsquellen.¹⁰⁸

2.3.2.3 Priorisierung von Anforderungen

Eine weitere Möglichkeit zur Differenzierung von Anforderungen stellt die Priorisierung dieser dar. Im Vergleich zu den vorherigen Klassifizierungsmerkmalen dient die Priorisierung jedoch nicht nur zur Einteilung der Anforderungen in gleiche bzw. ähnliche Gruppen. Die Priorisierung dient vielmehr zur Abgrenzung der Anforderungen zueinander, hinsichtlich ihrer Bedeutung für das Entwicklungsziel.¹⁰⁹

Tabelle 2: Auszug aus Möglichkeiten zur Priorisierung von Anforderungen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2 bietet einen zusammenfassenden Überblick über die Möglichkeiten zur Priorisierung von Anforderungen. Sie zeigt die einzelnen Varianten nach aufsteigender Anzahl Priorisierungskategorien unterteilt. Bei den hier gezeigten Varianten handelt es sich um eine zwei-stufige, drei drei-stufige, eine vier-stufige sowie einer sechs-stufigen Unterteilung zur Anforderungspriorisierung. Dabei steigt mit der Anzahl der Priorisierungsstufen die Detailschärfe der Priorisierung.

[...]

---

¹ Vgl. Lindemann (2009), S. 159, vgl. Szeghö et al. (2008), S. 510.

² Vgl. VDI-Richtlinie VDI 2221 (1993), S. 2.

³ Vgl. ebenda (1993), S. 3.

⁴ Vgl. ebenda (1993), S. 3-5.

⁵ Vgl. VDI-Richtlinie VDI 2221 (1993), S. 9.

⁶ Vgl. ebenda (1993), S. 13-16.

⁷ Vgl. ebenda (1993), S.9-10.

⁸ Vgl. VDI-Richtlinie VDI 2221 (1993), S. 10-11.

⁹ Vgl. Feldhusen et al. (2013b), S. 304.

¹⁰ Vgl. VDI-Richtlinie VDI 2220 (1980), S. 3.

¹¹ Vgl. Mattmann (2014), S. 49.

¹² Vgl. VDI-Richtlinie VDI 2206 (2004), S. 8.

¹³ Vgl. ebenda (2004), S. 14.

¹⁴ Vgl. ebenda (2004), S. 23.

¹⁵ Vgl. ebenda (2004), S. 26.

¹⁶ Vgl. ebenda (2004), S. 26.

¹⁷ Vgl. Automotive SPICE PAM 2.5 (2010), S. 15.

¹⁸ Vgl. VDI-Richtlinie VDI 2206 (2004), S. 44.

¹⁹ Vgl. VDI-Richtlinie VDI 2206 (2004), S. 29.

²⁰ Vgl. ebenda (2004), S. 29-30.

²¹ Vgl. ebenda (2004), S. 113.

²² Vgl. ebenda (2004), S. 117.

²³ Vgl. VDI-Richtlinie VDI 2206 (2004), S. 30-31, vgl. VDI-Richtlinie VDI 2206 (2004), S. 44-45,

²⁴ Vgl. VDI-Richtlinie VDI 2206 (2004), S. 26.

²⁵ Vgl. ebenda (2004), S. 27-29.

²⁶ Vgl. VDI-Richtlinie VDI 2206 (2004), S. 32.

²⁷ Vgl. ebenda (2004), S. 35-36.

²⁸ Vgl. bspw. VDI-Richtlinie VDI 2221 (1993), S. 4.

²⁹ Vgl. Lindemann (2009), S. 47.

³⁰ Vgl. ebenda (2009), S. 46.

³¹ Vgl. Ponn/Lindemann (2011), S. 19.

³² Vgl. Lindemann (2009), S. 50-51.

³³ Vgl. ebenda, S. 73-74.

³⁴ Vgl. ebenda, S. 94-96.

³⁵ Vgl. ebenda, S. 108.

³⁶ Vgl. ebenda, S. 102-105.

³⁷ Vgl. Lindemann (2009), S. 123.

³⁸ Vgl. ebenda, S. 139-141.

³⁹ Vgl. ebenda, S. 160-165.

⁴⁰ Vgl. ebenda, S. 182- 187.

⁴¹ Unter Produkten werden im weiteren Verlauf technische Produkte verstanden. Dienstleistungen und Product Service System werden hierbei nicht inbegriffen.

⁴² Vgl. Ehrlenspiel/Meerkamm (2013), S. 26.

⁴³ Ehrlenspiel/Meerkamm (2013), S. 27

⁴⁴ Vgl. Ehrlenspiel/Meerkamm (2013), S. 28.

⁴⁵ Vgl. ebenda, S. 22-24.

⁴⁶ Vgl. ebenda, S. 25.

⁴⁷ Vgl. ebenda, S. 30.

⁴⁸ Vgl. Mattmann (2014), S. 71.

⁴⁹ Vgl. Ehrlenspiel/Meerkamm (2013), S. 39-40.

⁵⁰ Vgl. Ehrlenspiel/Meerkamm (2013), S. 40.

⁵¹ Vgl. Sauer (2006), S. 67-68.

⁵² Vgl. Ponn/Lindemann (2011), S. 26-27.

⁵³ Vgl. Ponn/Lindemann (2011), S. 26.

⁵⁴ Vgl. ebenda, S. 27-28.

⁵⁵ Vgl. ebenda, S. 39.

⁵⁶ Vgl. Mattmann (2014), S. 104-105.

⁵⁷ Vgl. Mattmann (2014), S. 86-88.

⁵⁸ Vgl. ebenda, S. 88-90.

⁵⁹ Vgl. ebenda, S. 90-92.

⁶⁰ Vgl. ebenda, S. 92-94

⁶¹ Vgl. Mattmann (2014), S. 95-96.

⁶² Vgl. ebenda, S. 96-99.

⁶³ Vgl. ebenda, S. 99-101.

⁶⁴ Vgl. ebenda, S. 101-103.

⁶⁵ Vgl. Spies (2014), S. 31-32, vgl. Mattmann (2014), S. 104-106.

⁶⁶ Vgl. Sudin/Ahmed-Kristensen (2011b) S. 43; vgl. Ulrich/Eppinger (2008), S. 72.

⁶⁷ Vgl. Sudin/Ahmed-Kristensen (2011b)S. 43.

⁶⁸ Vgl. Kickermann (1995), S. 23.

⁶⁹ Vgl. ebenda, S. 25.

⁷⁰ Vgl. Feldhusen et al. (2013b), S. 330.

⁷¹ Vgl. Birkhofer (1980), S. 8.

⁷² Vgl. ebenda, S. 12.

⁷³ Vgl. Ehrlenspiel/Meerkamm (2013), S. 394.

⁷⁴ Vgl. Lindemann (2009), S. 44-45.

⁷⁵ Vgl. Ebenda, S. 96.

⁷⁶ Vgl. Ponn/Lindemann (2011), S. 39

⁷⁷ Vgl. VDI-Richtlinie VDI 2221 (1993), S. 39.

⁷⁸ Vgl. IEEE Standard 610.12 (1990), S. 172. Vgl. Ahrens (2000), S. 213.

⁷⁹ Vgl. ebenda, S. 14.

⁸⁰ Vgl. ebenda, S. 221.

⁸¹ Vgl. Gramlich (2013), S. 119.

⁸² Vgl. Mattmann (2014) S. 71.

⁸³ Vgl. Birkhofer (1980), S. 8.

⁸⁴ Vgl. Crostack et al. (2011), S. 656.

⁸⁵ Vgl. Brace/Cheutet (2012), S. 877.

⁸⁶ Vgl. Crostack et al. (2011), S. 656.

⁸⁷ Vgl. Ehrlenspiel/Meerkamm (2013), S. 399-400.

⁸⁸ Vgl. Hubka/Eder (1992), S. 96.

⁸⁹ Vgl. ebenda, S. 97.

⁹⁰ Vgl. Crostack et al. (2011), S. 659-662.

⁹¹ Vgl. ebenda, S. 665.

⁹² Vgl. ebenda, S. 658.

⁹³ Vgl. Brace/Cheutet (2012), S. 877.

⁹⁴ Vgl. Feldhusen et al. (2013b), S. 323.

⁹⁵ Vgl. ebenda, S. 331.

⁹⁶ Vgl. ebenda, S. 330.

⁹⁷ Vgl. Mattmann (2014), S. 70-74.

⁹⁸ Vgl. Crostack et al. (2011), S. 878,

⁹⁹ vgl. Brace/Cheutet (2012), S. 657.

¹⁰⁰ Vgl. Salinas et al. (2008), S. 128.

¹⁰¹ Vgl. Feldhusen et al. (2013b), S. 327.

¹⁰² Vgl. Sudin/Ahmed-Kristensen (2011), S. 204.

¹⁰³ Vgl. Salinas et al. (2008), S. 128.

¹⁰⁴ Vgl. Feldhusen et al. (2013b), S. 328-329.

¹⁰⁵ Vgl. Ahrens (2000), S. 7.

¹⁰⁶ Vgl. Feldhusen et al. (2013b), S. 327.

¹⁰⁷ Vgl. Orawski et al. (2013), S. 350.

¹⁰⁸ Vgl. Feldhusen et al. (2013b), S. 327.

¹⁰⁹ Vgl. Ponn/Lindemann (2011), S. 50.