ANFORDERUNGS-ENGINEERING IM BAUWESEN

DISS. ETH Nr. 19298 ANFORDERUNGS-ENGINEERING IM BAUWESEN ABHANDLUNG zur Erlangung des Titels DOKTOR DER WISSENSCHAFTEN der EIDGENÖSSISCHEN TECHNISCHEN HOCHSCHULE ZÜRICH vorgelegt von NILS KRÖNERT Dipl.-Ing. geboren am 28. Januar 1977 von Hannover, Bundesrepublik Deutschland Angenommen auf Antrag von Prof. Dr.-Ing. Gerhard Girmscheid Prof. Dr.-Ing. Christoph Motzko 2010

Vorwort Eine Dissertation bedeutet die intensive Auseinandersetzung mit einer spezifischen Thematik. Auch wenn der Fokus eines Doktorats immer auf den fachlichen Aspekten liegt, so muss der Doktorand neben der Kraft und Ausdauer zur Behandlung der gewählten Thematik auch die Fähigkeit zum wissenschaftlichen Arbeiten besitzen, um die Dissertation erfolgreich abschliessen zu können. In meinen Jahren an der ETH Zürich war es unter anderem diese Herangehensweise, die mich persönlich gefordert hat. Hierfür möchte ich vor allem meinem Doktorvater Professor Dr.-Ing. Gerhard Girmscheid danken, der mich stets gefordert und gefördert und auch trotz manch schwieriger Situation immer eine führende Position eingenommen hat. Er war es auch, der die grundlegende Idee zu der von mir betrachteten Thematik besessen hatte. Erst durch die vielen konstruktiven und ermutigenden Gespräche, wurde ich überhaupt in die Lage versetzt, diese Arbeit erfolgreich abzuschliessen. Im Zusammenhang mit dem gewählten Thema möchte ich auch der Firma HOCHTIEF, insbesondere Herrn Professor Dr.-Ing. Bernhard Bürklin, Herrn Wolfgang Katzer und Herrn Wolfgang Kölzer, für die Initiierung und Durchführung des Verbundforschungsprojekts, in dessen Rahmen diese Arbeit entstanden ist, danken. Im Rahmen des Verbundforschungsprojekts möchte ich auch Herrn Professor Dr.-Ing. Christoph Motzko, der sich auch bereit erklärt hat, das Korreferat zu übernehmen, und Herrn Professor Dr.-Ing. Peter Racky für die kritische Betrachtung der Arbeit im Rahmen des Forschungsprojekts meinen Dank aussprechen. Weiterhin möchte ich die ausgezeichnete Zusammenarbeit und gegenseitige Unterstützung im Rahmen des Verbundforschungsprojekts mit meinen HOCHTIEF- Kollegen Herrn Dr.-Ing. Ingo Giesa und Herrn Dr.-Ing. Philipp Stichnoth hervorheben. Auch die konstruktive Zusammenarbeit mit meinen Kollegen am Institut für Bauplanung und Baubetrieb der ETH Zürich bot mir eine umfangreiche Hilfestellung bei der Erstellung der Doktorarbeit. Mein abschliessender Dank gebührt meinen Eltern, die mich in meinen Entscheidungen immer unterstützt haben, und meiner Lebensgefährtin Anna, die in allen turbulenten Zeiten immer an meiner Seite stand. Zürich, im Oktober 2010 Nils Krönert

Seite 5 Inhaltsverzeichnis Inhaltsverzeichnis... 5 Abbildungsverzeichnis... 9 Tabellenverzeichnis... 11 Kurzfassung... 13 Abstract... 15 1. Problemstellung... 17 1.1. Hintergrund des Anforderungs-Engineerings... 17 1.2. Begriffsdefinition im Anforderungs-Engineering... 19 1.3. Strategische Bedeutung des Anforderungs-Engineerings... 23 1.4. Fragen der Praxis... 34 1.5. Aufbau der Arbeit... 34 2. Stand der Praxis und Forschung... 37 2.1. Definition des Anforderungs-Engineerings... 39 2.2. Anforderungsprozess... 45 2.2.1. Aufbau der Anforderungsspezifikation... 45 2.2.2. Eigenschaften von Anforderungen... 48 2.2.3. Anforderungsgewinnung... 51 2.2.4. Anforderungsdokumentation... 64 2.2.5. Validierung der Anforderungen... 68 2.2.6. Zusammenfassung... 70 2.3. Anforderungsmanagement... 72 2.3.1. Formalisierung von Anforderungen... 73 2.3.2. Priorisierung von Zielen und Anforderungen... 76 2.3.3. Relationen von Anforderungen... 78 2.3.4. Zusammenfassung... 88 2.4. Fazit... 89 3. Empirische Untersuchung zum Stand der Praxis... 93 3.1. Ziel der empirischen Studie... 93 3.2. Aufbau der empirischen Studie... 93 3.3. Auswahl der Untersuchungsobjekte... 94 3.4. Ergebnisse der empirischen Studie... 96 3.5. Vergleich der Ergebnisse mit dem Stand der Praxis... 97

Seite 6 4. Forschungslücke und Forschungsgegenstand... 99 4.1. Abgleich der Fragen der Praxis und des Stands der Praxis und Forschung sowie der empirischen Untersuchung... 99 4.2. Definition der Forschungslücke... 100 4.3. Forschungsgegenstand und Abgrenzung der Arbeit... 102 4.4. Forschungsfragen... 103 5. Forschungsmethodik... 105 5.1. Wissenschaftsverständnis der Baubetriebswissenschaft... 105 5.2. Forschungskonzeption... 114 5.3. Wahl und Beschreibung des theoretischen Bezugsrahmen... 121 5.3.1. Zielfunktion des Anforderungs-Engineering-Modells zur Wahl des theoretischen Bezugsrahmens... 122 5.3.2. Bezugsrahmen zur formalen Strukturierung... 124 5.3.2.1. Systemtheorie und Systembildung... 125 5.3.2.2. Kybernetischer Ansatz... 131 5.3.3. Bezugsrahmen zur inhaltlichen Ausgestaltung der Prozesse... 133 5.3.3.1. Principal-Agent-Theorie... 141 6. Entwicklung der Struktur und der Prozesse des Anforderungs-Engineerings 149 6.1. Denklogische Herleitung der systemtheoretischen Gliederung mittels theoretischem Bezugsrahmen... 149 6.2. Generisch-denklogische Herleitung der Prozess- und Managementdimension des Anforderungs-Engineerings auf Basis des kybernetischen Systemansatzes... 152 6.2.1. Bauprojektphasen... 153 6.2.2. Kybernetischer Anforderungsentwicklungsprozess... 162 6.2.3. Anforderungstypen... 165 6.2.4. Prozesssteuerung und Controlling... 168 6.2.5. Meilensteine... 176 6.3. Zusammenfassung der Struktur und Prozesse im Anforderungs-Engineering... 178

Seite 7 7. Inhaltliche Ausgestaltung der Prozesse im Anforderungs-Engineering... 183 7.1. Festlegung der systemtheoretischen Strukturierung der inhaltlichen Ausgestaltung... 183 7.2. Modellaufbau zur inhaltlichen Ausgestaltung der Prozesse... 185 7.3. Hauptprozess Strategische Planung... 189 7.3.1. Modulprozess Nutzeridentifikation... 192 7.3.2. Modulprozess Zieldefinition... 193 7.3.3. Modulprozess Rahmenbedingungen/ Projektrandbedingungen... 197 7.4. Hauptprozess Projektentwicklung... 198 7.4.1. Modulprozess 1 Ermittlung der Anforderungen... 199 7.4.2. Modulprozess 2 Systemintegration... 200 7.4.3. Modulprozess 3 Kostenerfassung... 201 7.4.4. Modulprozess 4 Optimierung... 202 7.4.5. Modulprozess 5 Zielprüfung... 202 7.5. Hauptprozessphase Vorplanung... 204 7.5.1. Modulprozess 1 Ermittlung der Anforderungen... 205 7.5.2. Modulprozess 2 Systemintegration... 207 7.5.3. Modulprozess 3 Kostenerfassung... 209 7.5.4. Modulprozess 4 Optimierung... 209 7.5.5. Modulprozess 5 Zielprüfung... 210 7.6. Hauptprozessphase Entwurfs-/ Genehmigungsplanung... 211 7.6.1. Modulprozess 1 Ermittlung der Anforderungen... 212 7.6.2. Modulprozess 2 Systemintegration... 213 7.6.3. Modulprozess 3 Kostenerfassung... 215 7.6.4. Modulprozess 4 Optimierung... 216 7.6.5. Modulprozess 5 Zielprüfung... 217 7.7. Hauptprozessphase Ausführungsplanung... 218 7.7.1. Modulprozess 1 Ermittlung der Anforderungen... 219 7.7.2. Modulprozess 2 Systemintegration... 220 7.7.3. Modulprozess 3 Kostenerfassung... 222 7.7.4. Modulprozess 4 Optimierung... 223 7.7.5. Modulprozess 5 Zielprüfung... 223 7.8. Zusammenfassung der inhaltlichen Ausgestaltung der Prozesse im Anforderungs-Engineering... 224

Seite 8 8. Theoriegeleitete Begründung... 235 8.1. Ableitung von Bedingungsgrössen... 235 8.2. Nachweis der Viabilität und Validität des Prozessmodells in Bezug auf die Bedingungsgrössen... 236 9. Realisierbarkeitstest... 241 9.1. Begründung und Aufbau des Realisierbarkeitstests... 241 9.2. Realisierbarkeitstest bezüglich der Modulprozesskette... 243 9.2.1. Realisierbarkeitstest bezüglich des Modulprozesses 1 Ermittlung der Anforderungen... 243 9.2.2. Realisierbarkeitstest bezüglich des Modulprozesses 2 Systemintegration... 245 9.2.3. Realisierbarkeitstest bezüglich des Modulprozesses 3 Kostenerfassung... 246 9.2.4. Realisierbarkeitstest bezüglich des Modulprozesses 4 Optimierung... 248 9.2.5. Realisierbarkeitstest bezüglich des Modulprozesses 5 Zielprüfung... 249 9.3. Realisierbarkeitstest bezüglich der Hauptprozesse... 250 9.3.1. Realisierbarkeitstest bezüglich des Hauptprozesses Strategische Planung... 251 9.3.2. Realisierbarkeitstest bezüglich der Hauptprozesse Projektentwicklung, Vorplanung, Entwurfs-/ Genehmigungsplanung und Ausführungsplanung... 253 9.4. Ergebnis des Realisierbarkeitstest... 254 10. Zusammenfassende Beurteilung und weiterer Forschungsbedarf... 255 10.1. Zusammenfassende Beurteilung... 255 10.2. Weiterer Forschungsbedarf und Ausblick... 257 11. Literaturverzeichnis... 259

Seite 9 Abbildungsverzeichnis Bild 1: Kybernetischer Kreislauf der Anforderungen, Ziele und Entscheidungen... 23 Bild 2: Kostenentwicklung der Änderungskosten über die Projektlaufzeit von Softwareprojekten... 24 Bild 3: Einbettung des Anforderungs-Engineerings ins Projektmanagement... 27 Bild 4: Prozesse in einem Bauunternehmen... 32 Bild 5: Prozesse in einem Bauunternehmen mit Einordnung des Anforderungs-Engineerings... 33 Bild 6: Aufbau der Arbeit und Kapitelstruktur... 35 Bild 7: Vorteile der vorgelagerten Entwurfsbetrachtung im Bauprozess... 37 Bild 8: Gliederung des Anforderungs-Engineering... 40 Bild 9: Entwicklungsprozess für ein Anforderungsspezifikation... 47 Bild 10: Prototypstruktur für den Aufbau einer Anforderungsspezifikation nach IEEE 830 (1998)... 50 Bild 11: Darstellung des Systemkontexts... 53 Bild 12: Kano-Modell Kundenzufriedenheit in Abhängigkeit des Erfüllungsgrads der Anforderungen... 57 Bild 13: Interaktionsbeziehung der Anforderungskategorien... 60 Bild 14: Gewinnungstechniken im Bezug zur Projektrealität... 61 Bild 15: Beispiel für die Strukturierung von Anforderungsattributen... 67 Bild 16: Strukturierung der Validierung von Anforderungen... 69 Bild 17: Entity-Relationship-Modell der Monohierarchie... 80 Bild 18: Prinzip monohierarchischer Strukturen... 80 Bild 19: Entity-Relationship-Modell der Polyhierarchie... 81 Bild 20: Prinzip polyhierarchischer Strukturen... 82 Bild 21: Abhängigkeitsliste... 85 Bild 22: Abhängigkeitsmatrix... 86 Bild 23: Kategoriensystem der Auswertung... 96 Bild 24: Gliederung der Forschungslücke für das Anforderungs-Engineering im Bauwesen... 102 Bild 25: Wissenschaftssystematik und Einordnung der Baubetriebswissenschaften... 106 Bild 26: Verknüpfungen zwischen den drei Welten... 109 Bild 27: Weltbild der Erkenntnistheorie in Anlehnung an POPPER (2002) und PLESSNER (1975) sowie forschungsmethodische Konsequenzen... 110 Bild 28: Forschungsprozess zur Entwicklung des Anforderungs-Engineerings als konstruktivistisches Gestaltungsmodell... 115 Bild 29: Phasen im Forschungsprozess... 116 Bild 30: Güteprüfung durch Triangulation in der Baubetriebswissenschaft... 118 Bild 31: Kybernetisch-systemorientiere Modellbildung in der Baubetriebswissenschaft... 124 Bild 32: Konstellation in der Principal-Agent-Theorie... 143 Bild 33: Wechsel der Akteure im Anforderungs-Engineering... 149 Bild 34: Sphären der systemtheoretischen Gliederung... 150

Seite 10 Bild 35: Modellebenen der Prozess- und Managementdimension des Anforderungs-Engineerings im Bauwesen... 153 Bild 36: Leistungsphasen nach der HOAI... 154 Bild 37: Leistungsmodell nach der SIA 112... 155 Bild 38: Vergleich der Phasen nach HOAI und SIA 112... 155 Bild 39: AHO-Phasenmodell für das Projektmanagement... 156 Bild 40: Lebensphasen eines Systems... 157 Bild 41: Lineare Gestaltung eines Projektlebenszyklus... 157 Bild 42: Lebenszyklusphasen für ein Bauprojekt... 158 Bild 43: Entwicklung der Bauprojektphasen im Anforderungs-Engineering... 159 Bild 44: Kybernetischer Anforderungsentwicklungsprozess für das Anforderungs-Engineering... 163 Bild 45: Modelldimension der Anforderungstypen für die formale Strukturierung des Anforderungs-Engineerings... 168 Bild 46: Meilensteingruppen der einzelnen Bauprojektphasen für das Anforderungs-Engineering... 178 Bild 47: Gesamtübersicht über die Modelldimension und deren Elemente der Struktur und Prozesse des Anforderungs-Engineerings Teil 1... 180 Bild 48: Gesamtübersicht über die Modelldimension und deren Elemente der Struktur und Prozesse des Anforderungs-Engineerings Teil 2... 181 Bild 49: Schema der hierarchischen Strukturierung der Prozesse durch Haupt- und Modulprozesse... 184 Bild 50: Phasen-und Aufgabendimension des Anforderungs-Engieerings... 185 Bild 51: Beispiel für eine relative Gewichtungsmatrix der Ziele... 191 Bild 52: Gebäudebaumstruktur nach der Systemintegration innerhalb der Vorplanungsphase... 208 Bild 53: Konkretisierung der Hauptgewerke in Elementgruppen in der Entwurfs-/ Genehmigungsplanung... 214 Bild 54: Planungselemente der Systemintegration in der Ausführungsplanung... 221 Bild 55: Modulprozesse innerhalb der Bauprojektphase der Strategischen Planung... 225 Bild 56: Phasenübergreifende Darstellung des Modulprozesses 1 Ermittlung der Anforderungen... 226 Bild 57: Phasenübergreifende Darstellung des Modulprozesses 2 Systemintegration... 227 Bild 58: Phasenübergreifende Darstellung des Modulprozesses 3 Kostenerfassung... 228 Bild 59: Phasenübergreifende Darstellung des Modulprozesses 4 Optimierung... 228 Bild 60: Entscheidungselement des Modulprozesses 5 Zielprüfung... 229 Bild 61: Zielerreichungselement des Modulprozesses 5 Zielprüfung... 230 Bild 62: Zielüberprüfungselement des Modulprozesses 5 Zielprüfung... 231 Bild 63: Phasenübergreifende Darstellung des Modulprozesses 5 Zielprüfung... 232 Bild 64: Gesamtdarstellung der inhaltlichen Ausgestaltung der Prozesse im Anforderungs-Engineering... 233

Seite 11 Tabellenverzeichnis Tabelle 1: Zusammenfassung der Anforderungsgewinnungselemente für die Einbindung in das Anforderungs-Engineering im Bauwesen... 63 Tabelle 2: Zusammenfassung der Elemente des Anforderungsprozesses für die Einbindung in das Anforderungs-Engineering im Bauwesen... 71 Tabelle 3: Zusammenfassung der Elemente des Anforderungsmanagements für die Einbindung in das Anforderungs-Engineering im Bauwesen... 88 Tabelle 4: Zusammenfassung der wesentlichen Literatur für das Anforderungs-Engineering... 90 Tabelle 5: POPPERS Trialismus der Welt und PLESSNERS anthropologische Dreiteilung der Welt... 108 Tabelle 6: Erfüllung der Eignungskriterien durch die Systemtheorie... 130 Tabelle 7: Erfüllung der Eignungskriterien durch die Kybernetik... 133 Tabelle 8: Erfüllung der inhaltlichen Kriterien der betrachteten sozial-wissenschaftlichen Theorien... 140 Tabelle 9: Erfüllung der Eignungskriterien durch die Principal-Agent-Theorie... 148 Tabelle 10: Übersicht der Mechanismen zur Prozesssteuerung und zum Controlling... 173 Tabelle 11: Beispiele für projektspezifische Key Result Areas (KRAs) und dazugehörige Key Performance Indicators (KPIs)... 175 Tabelle 12: Beispiele für die Ableitung der KRAs und KPIs aus den festgelegten Projektzielen... 196

Seite 13 Kurzfassung In der heutigen Finanzsituation ist es für die Investoren sehr wichtig, dass die geplante Rendite möglichst frühzeitig erzielt werden kann. Um die Rendite des Investors zu sichern, ist es auch wichtig, dass das Bauprojekt für alle Beteiligten sich zu einer Win-Win-Situation entwickelt. Allerdings zeigen aktuelle Betrachtungen, dass dies eher der seltene Fall ist. Der fehlende Erfolg von Projekten kann vorwiegend durch das unvollständige Bausoll, die mangelhafte Einbindung der relevanten Stakeholder und die häufigen Änderungen am Bausoll in den späten Projektphasen begründet werden. Ein Grund hierfür ist, dass im Bauwesen oftmals nicht die notwendigen Anforderungen rechtzeitig an das Bauwerk formuliert werden. Aufbauend auf dieser Problematik wurde ein Forschungsvorhaben der Firma HOCHTIEF und des Instituts für Bauplanung und Baubetrieb der ETH Zürich ins Leben gerufen, durch welches die vorliegende Arbeit entstand. Dabei sollte grundsätzlich untersucht werden, ob und wie ein Anforderungs-Engineering im Bauwesen zu implementieren ist. Die Untersuchungen innerhalb des Forschungsvorhabens haben gezeigt, dass in anderen Branchen, vorwiegend in der Softwareentwicklung, ein Anforderungs- Engineering konsequent angewendet wird. So führt die vorliegende Dissertation auch eine umfangreiche Analyse des Vorgehens in anderen Branchen durch und überprüft deren Anwendbarkeit im Bauwesen. Ausgehend von dieser Analyse konnte ein Prozessmodell für das Anforderungs-Engineering im Bauwesen entwickelt werden, welches vor allem die frühen Bauprojektphasen betrachtet. Da in der Baupraxis derzeit kein Anforderungs-Engineering existiert, wurde als wissenschaftstheoretischer Ansatz das generisch-denklogische-deduktive Vorgehen gewählt. Zur Absicherung dieses Vorgehens erfolgen eine theoriegeleitete Begründung sowie ein Realisierbarkeitstest. Mittels dieser Triangulation wird die wissenschaftliche Güte der Arbeit sichergestellt. Um die Komplexität des Modells zu verringern und die Anwendbarkeit zu gewährleisten, wird das Prozessmodell auf Basis der Systemtheorie und Kybernetik strukturiert. Weiterhin erfolgt die inhaltliche Ausgestaltung unter Berücksichtigung der Elemente und Erkenntnisse der Principal-Agent-Theorie. Durch die Anwendung dieser wissenschaftlichen Methoden wird für das Prozessmodell der theoretische Bezugsrahmen aufgespannt und somit im Rahmen des Begründungszusammenhangs die Gültigkeit des Modells unterstützt. Durch die beschriebene Forschungsmethodik konnte ein Prozessmodell für das Anforderungs-Engineering im Bauwesen entwickelt werden, welches auf Basis des wissenschaftlichen Vorgehens einen viablen Handlungsleitfaden für die Praxis liefert.

Seite 15 Abstract In today's financial situation, it is more important for investors that the proposed rate of return can be achieved as early as possible. In order to secure the return of the investment, it is also important that the construction project develops a win-win situation for all involved. However, recent observations show that this is rather a rare case. The lack of success of projects may be primarily by the incomplete construction target definition, the lack of involvement of relevant stakeholders and the frequent changes based on construction target definition in the late phases of the project. The arguments show that in the construction industry the necessary requirements are often not formulated in the early phases of the project. Based on this issue, a research project was started of the company HOCHTIEF and the Institute of Construction Engineering and Management at the ETH Zurich, from which the present work origins. The target of the research was to determine if and how a requirements engineering in construction can be implemented. The studies within the research project have shown that in other industries, primarily in software development, requirements engineering is consistently applied. Thus, the present thesis fulfills an extensive analysis of the approach in other industries and is examining their applicability in the construction industry. Based on this analysis a process model for requirements engineering in the construction industry will be developed, which considered mainly the early development phases. Since at present time there is no requirements engineering in the construction industry, the generic-logically-deductive approach was chosen as an epistemological approach. For the validation of this approach a theory-based justification and a realizability test is chosen. Using this triangulation will ensure the scientific quality of the work. To reduce the complexity of the model and to ensure the applicability the process model is structured on systems theory and cybernetics. Furthermore, the content design is developed in consideration of the elements and findings of the principalagent theory. The application of these scientific methods frames the theoretical framework of the process model and supports the validity of the model. With the described research methodology, a process model for requirements engineering in the construction industry will be developed, which provides a viable guideline for practice based on the scientific approach.

Seite 17 1. Problemstellung Mit ihrer Investitionsentscheidung zu einem Bauprojekt wollen die Investoren bzw. die Kunden eine schnelle und erfolgreiche Abwicklung des Projekts, um frühzeitig die maximal zu erzielenden Rendite zu erlangen. Allerdings vermindert sich diese Rendite im Laufe der Projekte durch mögliche Änderungen. Dies führt zu notwendigen Massnahmen wie das Nachtragsmanagement, wodurch weitere zusätzliche Kosten entstehen, die die Rendite verringern. Um Bauprojekte langfristig für alle Beteiligten in eine Win-Win-Situation zu überführen, muss die Anzahl der nachträglichen Änderungen verringert werden. Hierzu ist es notwendig eine systematische Strukturierung und Gestaltung der Planungsprozesse, die auf die Investoren- und Kundenziele ausgerichtet sind, anzuwenden. In anderen Branchen wird zur Strukturierung der Planung ein Anforderungs-Engineering verwendet. Dabei werden frühzeitig die Ziele des Investors bzw. Kunden identifiziert und die sich daraus ergebenden Anforderungen erfasst. Mit Hilfe der erfassten Anforderungen kann der Planungs- und auch später der Ausführungsprozess zielgerichtet geplant, notwendige Entscheidungen getroffen sowie die Fortschritte kontrolliert werden. Untersuchungen von HOOKS (2004) im Bereich der Softwareentwicklung haben gezeigt, dass durch die Anwendung eines Anforderungs-Engineerings der Projekterfolg nachhaltig gesteigert werden kann 1. Aus diesem Grund soll im Folgenden untersucht werden, ob und wie ein Anforderungs-Engineering zur erfolgreichen Projektabwicklung auch im Bauwesen beitragen kann. 1.1. Hintergrund des Anforderungs-Engineerings Um ein Anforderungs-Engineering im Bauwesen einführen zu können, soll kurz auf wichtige Änderungen in der Projektabwicklung von Bauprojekten über die letzten Jahre eingegangen werden. Ein wichtiger Punkt dabei ist die technologische Weiterentwicklung der Bauobjekte, die abgewickelt werden sollen, im Vergleich zu Objekten in der Vergangenheit. Durch den allgemeinen technischen Fortschritt sind auch die Bauobjekte in den letzten Jahren immer komplexer und hochtechnologisierter geworden. So ist die Anzahl der zu berücksichtigenden technischen Spezifikationen beispielsweise in der Gebäudeautomatisierung sehr stark angestiegen. Auch besitzen viele Bauwerke beispielsweise einen immer grösser werdenden Anspruch an die architektonische Gestaltung, um sich von anderen Bauwerken abzugrenzen. Gleichzeitig sollen auch die Realisierungszeiten, also die Zeiten von der Projektidee bis zum Bezug der Immobilie, verkürzt werden. Der Grund hierfür ist, dass im Wirtschaftsbau die Immobilie als eine Investition angesehen wird, die möglichst frühzeitig das gewünschte Renditepotenzial erzielen soll ( time-to-market ) 2. Die so entstehenden Projekte werden Fast-Track-Projects genannt, die sich durch die kurze Realisierungszeit auszeichnen. 1 Vgl. I.F. HOOKS (Managing Requirements 2004), S.3ff. 2 GIRMSCHEID, G. (GAAM 2007), S. 10

Seite 18 Neben den projektspezifischen Veränderungen in den letzten Jahren sind auch grosse Veränderungen in den Bauunternehmen durch die dynamische Veränderung des wirtschaftlichen Umfelds zu beobachten 3. So wird nicht mehr eine reine kurzfristige Gewinnmaximierung gewünscht, sondern die Optimierung der langfristigen Rendite über den Lebenszyklus. Durch diese Vorgaben haben sich die Bauunternehmen mittels neuer Leistungsangebote zu ganzheitlichen Baudienstleistern entwickelt, die ihre Angebotspalette durch die Zusammenführung von Entwicklung, Planung, Ausführung und Betrieb umfassend erweitert haben. Diese Erweiterung ihres Angebotsportfolios kommt auch dem entstandenen Kundenwunsch einer life-cycle-orientierten Baulösung entgegen 4, die in naher Zukunft einen immer grösser werdenden Marktanteil besitzen wird. Ein Beispiel für die in der Problemstellung beschriebenen kurzfristigen und einseitigen Massnahmen ist das Nachtragsmanagement. Der Grundgedanke des Nachtragsmanagements war die zielorientierte Bearbeitung von nachträglichen Änderungen an der Immobilie. Allerdings wird das Nachtragsmanagement oftmals als Ausgleich für den Preiswettbewerb und zur Steigerung der geringen Gewinnaussichten missbraucht 5. Dies führt im Allgemeinen dazu, dass die festgelegte Bausumme und somit die Kosten überschritten werden. Einhergehend mit der Kostenüberschreitung steigen auch die Unzufriedenheit des Kunden. Diese Entwicklung führt dazu, dass das Nachtragsmanagement im Allgemeinen als negativ empfunden wird und wenig zu einer Win-Win-Situation beiträgt. Um dem Nachtragsmanagement entgegen zu wirken und zu analysieren, ob das Anforderungsmanagement dazu eine Hilfestellung sein kann, muss betrachtet werden, was die Begründungen für die Änderungen sind, die durch das Nachtragsmanagement bearbeitet werden. Dabei zeigt sich, dass die Änderungen oft auf Unvollständiger Planung Unzureichender Einbeziehung des Bauherrn in die Planung Änderung der Nutzungsanforderungen während der Planung und Ausführung beruhen 6. Das Bausoll wird also meist nicht umfassend festgelegt und nicht von allen Seiten einvernehmlich verstanden, wodurch es dann nach Vertragsschluss zu der Aufstellung von Nachträgen kommt. Zusammenfassend lässt sich sagen, dass die Bauwirtschaft durch die Entwicklung in den letzten Jahren inzwischen folgenden Problemen bzw. Veränderungen begegnen muss: Komplexere Bauten Schnellere Projektabwicklung Neue Geschäftsmodelle 3 GIRMSCHEID, G. (Projektabwicklung 2007), S. 1 4 GIRMSCHEID, G. (Projektabwicklung 2007), S. 2 5 GIRMSCHEID, G., et al. (Nachtragsmanagement 2008), S. 2 6 GIRMSCHEID, G., et al. (Nachtragsmanagement 2008), S. 2

Seite 19 Höhere Änderungsraten/-wünsche Fehlendes Erkennen des Bausolls Aus dieser Problematik hat sich bei Bauunternehmen, die eine starke Kundenorientierung besitzen, der Wunsch nach Instrumentarien zur frühzeitigen und systematischen Identifikation der Kundenziele gebildet, um so phasenbezogen und der Planungstiefe entsprechend die Anforderungen im Entscheidungsprozess mit dem Bauherrn zu definieren und das Gebäudesystem stufenweise zu konkretisieren. GIRMSCHEID (2007) beschreibt einen Ansatz für Fast-Track-Projekte mit Hilfe des generisch, axiomatischen Anforderungsmanagements der Planung. Wichtigste Ziele dieses Ansatzes sind 7 : Die Bildung von Prioritäten der Planungsabläufe Die Offenlegung der Abhängigkeiten der Abläufe Die Beschleunigung der Planungs- und Bauprozesse durch weitestgehende Parallelisierung Die Verhinderung von Wiederholungen von Aktivitäten aufgrund unzureichender Vorgänger- und Nachfolgerbetrachtung sowie Parallelbeziehungen Bevor das Anforderungs-Engineering in die Prozessabläufe des Bauwesens eingeordnet werden kann, muss eine grundlegende Begriffsdefinition erfolgen, damit die Einordnung des Anforderungs-Engineerings eindeutig vorgenommen werden kann und mehrdeutige Ansätze ausgeschlossen werden. 1.2. Begriffsdefinition im Anforderungs-Engineering Wie GIRMSCHEID (2007) zeigt, kann den grundsätzlichen Problemen und Veränderungen der letzten Jahre in der Praxis, wie schnellere Projektabwicklung und gesteigerte Komplexität, durch die Anwendung des Anforderungsmanagements begegnet werden. Um aus diesen Problemen und Veränderungen für das Forschungsvorhaben konkrete Fragen der Praxis ableiten zu können, werden im Folgenden die wichtigsten Begrifflichkeiten des Anforderungs-Engineerings betrachtet. Die Ermittlung und Erfassung der Anforderungen für das Bauprojekt erfolgt aus den Zielen des Inverstors bzw. Kunden in Kombination mit extern einwirkenden Anforderungen. Allgemein werden Anforderungen als Beschaffenheit oder Fähigkeit definiert, die ein System oder eine Person zur Erreichung eines Ziels benötigt. Aus dieser Betrachtung zeigt sich, dass Anforderungen und Ziele in einer Korrelation stehen, die gegebenenfalls zu falscher Anwendung der Begriffe führen kann, so dass hier eine Abgrenzung der beiden Begrifflichkeiten notwendig ist. 7 GIRMSCHEID, G. (GAAM 2007), S. 10

Seite 20 Ziel Die Definitionen für den Begriff Ziel ist in der Literatur sehr unterschiedlich. So wird im Bereich der Normen der Begriff des Projektziels durch die DIN 69901 (08-1987) Projektmanagement Begriffe wie folgt definiert 8 : Nachzuweisendes Ergebnis und vorgegebene Realisierungsbedingungen der Gesamtaufgabe des Projektes. Die Definition nach der DIN 69901 (08-1987) stellt nur eine sehr rudimentäre und unzureichende Beschreibung des Begriffs Ziel dar, da die Definition eher ein Ergebnis als ein Ziel beschreibt. Aus diesem Grund soll im Folgenden die Definitionen des Begriffs Ziel in der das Anforderungs-Engineering betrachtenden Literatur untersucht werden. POHL (2007) definiert den Begriff Ziel wie folgt 9 : Ein Ziel ist die intentionale Beschreibung eines charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprozesses. Weiterhin stellen nach POHL (2007) Ziele Verfeinerungen von Visionen dar 10. Auch hier wird das Ziel als ein beabsichtigter Zustand beschrieben. Allerdings bezieht sich dieser Zustand nicht nur auf das System, sondern auch auf die Randbedingungen. Eine weitere Definition liefern GERNERT und AHREND (2002) 11 : Unter einem Ziel wird ein erstrebenswerter Zustand verstanden, der in der Zukunft liegt und dessen Eintritt von bestimmten Handlungen bzw. Unterlassungen abhängig ist. Auch diese Definition zeigt, dass es sich bei einem Ziel um einen zu erlangenden Zustand handelt. Jedoch wird bei dieser Definition davon ausgegangen, dass das Ziel nur durch Tätigkeiten bzw. Unterlassungen erreicht werden kann. Eine ähnliche Auffassung wie der erste Teil von GERNERT und AHREND (2002) vertritt auch GLINZ (2008) als Definition für ein Ziel: Ein Ziel ist ein erwünschter Zustand, den jemand erreichen möchte. Als Grundlage für diese Arbeit wird die Definition von GLINZ (2008) bzw. der erste Teil von GERNERT und AHREND (2002) verwendet, da diese Definitionen weitestgehend unabhängig von möglichen Vorgehensweisen sind. Ein Ziel ist ein erstrebenswerter Zustand, der zu erreichen ist. 8 DEUTSCHES INSTITUT FÜR NORMUNG E.V. (DIN 69901 08-1987), S. 3 9 POHL, K. (Requirements Engineering 2007), S. 91 10 POHL, K. (Requirements Engineering 2007), S. 91 11 GERNERT, C., AHREND, N. (System statt Chaos 2002)

Seite 21 In der festgelegten Definition besitzt der Begriff Ziel einen umfassenden und begründenden Sinn und nicht einen konkreten auf bestimmte Einzelheiten bezogenen Sinn 12. Das Ziel liefert somit den Bezugsrahmen für die Umsetzung von Anforderungen. Eine Anforderung hingegen beschreibt eine Eigenschaft und ist daher meistens konkret. Weiterhin beschreibt eine Anforderung eine notwendige Eigenschaft bzw. Bedingung, um ein Ziel zu erreichen. Anforderung Wie im vorherigen Abschnitt soll als Definitionsgrundlage eine bestehende und weitverbreitete Norm betrachtet werden. In der DIN EN ISO 9000 (12-2005) Qualitätsmanagementsysteme wird eine Anforderung wie folgt definiert: 13 Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist. Auch diese Definition innerhalb einer Norm stellt nur eine unzureichende Beschreibung des Begriffs der Anforderungen dar. Im internationalen Bereich werden durch das Institute of Electrical and Electronics Engineers (IEEE) wichtige Normen vor allem für den Bereich der Computerwissenschaften und Elektrotechnik festgelegt. Diese Standards werden weltweit als anerkannte Standards verwendet. Für den Bereich der Informationstechnologie hat die IEEE durch das IEEE STANDARD GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY IEEE 610.12 (1990) eine Vielzahl von Begriffsdefinitionen festgelegt. Den Begriff der requirement definiert die IEEE wie folgt 14 : (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents (3) A documented representation of a condition or capability as in (1) or (2). Ähnlich wie bei der DIN EN ISO 9000 (12-2005) sind Anforderungen nach der IEEE 610.12 (1990) eine Beschaffenheit oder Fähigkeit, die eine Sache besitzen muss, um bestimmte Ziele zu erreichen. Zum einen kann diese Sache eine Person sein, so dass die Person betreffende Voraussetzungen oder Eigenschaften in sich vereinen muss, damit bestimmte Probleme gelöst oder bestimmte Ziele erreicht werden können. Dies bedeutet, dass die Anforderungen an die Person gestellt werden und somit Charaktereigenschaften der Person darstellen. Zum anderen kann diese Beschaffenheit oder Fähigkeit auch eine Forderung an ein System oder an Teile eines Systems sein, damit bestimmte Ziele erlangt werden können. Die Beschreibung der Anforderungen erfolgt dann in der Form eines Vertrages, einer 12 GLINZ, M. (Requirements Engineering I 2008) 13 DEUTSCHES INSTITUT FÜR NORMUNG E.V. (DIN EN ISO 9000 12-2005), S. 19 14 IEEE (IEEE 610.12 1990), S. 62

Seite 22 Norm, einer Spezifikation oder anderer formeller Dokumente. Die Anforderungen und damit das Systems müssen die Beschreibung der Dokumente erfüllen. Als dritte Möglichkeit der Definition für den Begriff der Anforderung beschreibt die IEEE 610.12 (1990) die dokumentierte Darstellung der Anforderungen selbst, damit die Ziele umgesetzt werden können. Hiermit ist nicht die Beschaffenheit oder Fähigkeit einer Sache, sondern die Dokumentation dieser Eigenschaften gemeint. Durch die verschiedenartigen Definitionen kann es daher bei der Verwendung des Begriffs Anforderung zu Verwechslungen kommen. Weiterhin zeigen diese unterschiedlichen Definitionen, dass auch die Ausarbeitung eines Anforderungs- Engineerings eine spezielle Eindeutigkeit des Begriffs der Anforderungen verwenden muss. Für diese Arbeit wird daher die Definition gemäss Punkt (2) der IEEE 610.12 (1990) verwendet, worin vor allem die Systemeigenschaften bzw. -fähigkeiten berücksichtigt werden, die zur Erfüllung der Ziele notwendig sind. Eine Anforderung ist Beschaffenheit oder Fähigkeit eines Systems oder einer Systemkomponenten, die erfüllt werden muss, damit ein Vertrag, eine Norm, eine Beschreibung oder andere formelle Dokumente (Ziele) erfüllt werden können. Mittels der beschriebenen Definitionen für Ziele und Anforderungen wird deutlich, dass Anforderungen aus Zielen entwickelt werden, da sie ein Erfordernis für die Zielerreichung sind. Zur Erreichung der Ziele können aus den verschiedenen Anforderungen unterschiedliche Lösungsansätze erarbeitet werden. Für ein zielorientiertes Vorgehen müssen die Lösungsansätze durch rechtzeitige Entscheidungen in das Projektmanagement eingebunden werden 15. Somit stellen die Anforderungen und Ziele die Grundlage für mögliche Entscheidungen im Bauprozess dar. Aus diesem Grund ist auch der Begriff der Entscheidung ein zentraler Bestandteil des Anforderungs-Engineerings. Entscheidung Für den Begriff der Entscheidung existiert keine einheitliche Definition in einer Norm. Aus diesem Grund wird eine lexikalische Definition als Ausgangsdefinition verwendet 16 : Eine Entscheidung bezeichnet die Möglichkeit und die Notwendigkeit, eine Auswahl zwischen (zwei oder mehreren) unterschiedlichen nicht gleichzeitig zu verwirklichenden Alternativen zu treffen. Die Definition zeigt, dass es sich bei einer Entscheidung um die Festlegung auf eine vordefinierte Möglichkeit handelt. Um eine Entscheidung fällen zu können, müssen Alternativen zur Verfügung stehen. Im Anforderungs-Engineering ist dies die Auswahl zwischen verschiedenen Lösungsansätzen zur Erreichung der Ziele. Diese Betrachtung zeigt, dass die Ziele, die Anforderungen und auch die Entscheidungen einen kybernetischen Kreislauf bilden, der in Bild 1 dargestellt ist. 15 Vgl. DIEDERICHS, C. J., PREUSS, N. (Entscheidungsprozesse 2003) 16 SCHUBERT, K., KLEIN, M. (Politiklexikon 2006)

Seite 23 Der Ausgangspunkt sind die festgelegten Ziele aus denen die Anforderungen an das Projekt abgeleitet werden. Zusätzlich zu den abgeleiteten Anforderungen müssen auch externe Anforderungen in die Betrachtungsweise einbezogen werden. Aus der Vielfalt der abgeleiteten Anforderungen muss eine eindeutige und widerspruchsfreie Gesamtheit von Anforderungen geschaffen werden. Dies kann nur mittels der Aufdeckung von Widersprüchen erfolgen, die in Zusammenarbeit mit den Projektbeteiligten, insbesondere dem Kunden, entschieden werden müssen. Für die Gesamtheit der Anforderungen gilt es nun ein oder mehrere Lösungsansätze zur Erfüllung der Anforderungen und damit der Ziele zu entwickeln. Mit der Entwicklung von Lösungsansätzen entstehen verschiedene Planungs- und Ausführungsalternativen, aus denen durch zielorientierte Entscheidungen ein zu verfolgender Lösungsansatz bestimmt werden muss. Theoretisch ist es möglich, dass durch die Entscheidungen, obwohl sie zielorientiert erfolgen sollten, die Ziele nicht vollständig erfüllt werden. Gegebenenfalls können auch keine Lösungsansätze gefunden werden, die die Ziele vollständig erfüllen. Aus diesem Grund besteht die Möglichkeit, dass durch die getroffenen Entscheidungen die Ziele überprüft und angepasst werden müssen, so dass die Entscheidungen einen Einfluss auf die Ziele bekommen, wodurch der kybernetische Kreislauf geschlossen wird. Die Aufgabe des Anforderungs-Engineering ist es nun, diesen kybernetischen Kreislauf erfolgsorientiert zu steuern und zu erfüllen. Ziel Anforderung Entscheidung Bild 1: Kybernetischer Kreislauf der Anforderungen, Ziele und Entscheidungen Eine genaue Definition des Anforderungs-Engineerings erfolgt in Kapitel 2.1 durch die Betrachtung des branchenübergreifenden Verständnisses. Im Folgenden soll das Anforderungs-Engineering kurz in die unternehmerische Ausrichtung eingeordnet und ein grundlegender Ansatz beschrieben werden, um die Fragen der Praxis konkretisieren zu können. 1.3. Strategische Bedeutung des Anforderungs-Engineerings In Kapitel 1.2 wurden die grundlegende Systematik und notwendigen Definitionen für die wichtigsten Inhalte des Anforderungs-Engineerings entwickelt und beschrieben. Hierauf aufbauend sollen in diesem Kapitel eine Beschreibung der strategischen

Seite 24 Bedeutung des Anforderungs-Engineerings und die Einordnung in die Handlungsebenen des Bauunternehmensmanagements erfolgen. Das Bauunternehmensmanagement besteht aus verschiedenen interagierenden Managementprozessen 17. Mit dem Aufbau und der Implementierung eines Anforderungs-Engineerings im Bauwesen kann daher gleichzeitig die Kritik an einem zusätzlichen Managementprozess zur Steuerung des Leistungserstellungsprozesses aufkommen. Aus diesem Grund muss untersucht werden, warum die Notwendigkeit für ein Anforderungs-Engineering besteht, welche Synergieeffekte durch die Verwendung eines Anforderungs-Engineerings entstehen und inwiefern das Anforderungs-Engineering in bestehende Managementprozesse eingebettet werden kann. Zur Begründung für die sinnvolle Verwendung des Anforderungs-Engineering im Bauwesen sollen zunächst durchgeführte Untersuchungen von anderen Branchen betrachtet werden. Wie in Kapitel 1.1 beschrieben, soll das Anforderungs- Engineering den hohen Änderungswünschen entgegen wirken und das Bausoll frühzeitig beschreiben. HOOKS (2004) hat für den Bereich der Softwareentwicklung eine Analyse (Bild 2) gemacht, wie sich Kosten für nachträgliche Änderungen entwickeln. Dabei zeigt sich, dass die Änderungskosten mit der Projektlaufzeit annähernd exponentiell zunehmen. 1.000 70 60 50 40 30 20 10 Design Phase Coding Phase Test Entwicklung Anforderungsphase Benutzungstest Einsatz Bild 2: Kostenentwicklung der Änderungskosten über die Projektlaufzeit von Softwareprojekten 18 Neben der Betrachtung der Kostenentwicklung wurde von der STANDISH GROUP (1995) ein Umfrage durchgeführt, die die Gründe für fehlgeschlagene bzw. kritisch verlaufende Projekte im Softwarebereich untersucht 19. Dabei wurden als wichtigster Grund für den komplizierten Projektverlauf mit etwa 40% der fehlende Input der Kunden bzw. die unvollständigen und sich ändernden Anforderungen von den 17 Siehe auch Bild 4 auf Seite 32 18 I.F. HOOKS (Managing Requirements 2004) 19 THE STANDISH GROUP (Chaos 1995)

Seite 25 befragten Projektleitern angegeben. Für die fehlgeschlagenen bzw. gestoppten Projekte wurden ähnliche Werte ermittelt. Beide Aspekte zeigen die Wichtigkeit eines zielorientierten Anforderungs- Engineerings. Da eine solche Untersuchung im Bauwesen noch nicht erfolgt ist, muss die Übertragbarkeit der Ergebnisse auf das Bauwesen geprüft werden. Durch die Änderungen des Bausolls entstehen bei Bauprojekten Nachträge im Rahmen von 10 bis 40% 20. Betrachtet man die Auslöser für die Nachträge, so sind das mit mehr als 70% Leistungsänderungen und Zusatzleistungen 21. Je nach Fortschritt der Planung und Ausführung müssen zur Leistungserfüllung mehrere Arbeitsschritte, wie Planänderungen und ggf. sogar Rückbau durchgeführt werden, so dass davon auszugehen ist, dass auch die Kosten für Änderungen im Bauwesen mit dem Baufortschritt exponentiell ansteigen. Diese Betrachtung stellt nur einen qualitativen Nachweis für die Bedeutung und die entstehenden Möglichkeiten dar, die durch ein zielorientiertes Anforderungs-Engineerings mit der frühzeitigen Festlegung des Bausolls und der Steuerung des Planungsablaufs entstehen können. Ein weiterer Ansatz für die Verwendung eines zielorientierten Anforderungs- Engineerings ist die im Bauwesen entstandene Betrachtung der Lebenszykluskosten. Wie GIRMSCHEID und LUNZE (2008) aufzeigen, steigen die Gesamtkosten für ein Gebäude über den gesamten Lebenszyklus des Gebäudes stark an 22. Aus diesem Grund ist es wichtig, dass schon frühzeitig mögliche Auswirkungen des gewünschten Bausolls offengelegt werden. Hierzu ist es hilfreich, wenn die möglichen Konsequenzen bestimmten Zielen und Anforderungen zugeordnet werden. Durch diese Korrelation der Konsequenzen mit den Zielen und Anforderungen kann schon in den frühen Projektphasen untersucht und ermittelt werden, wie sich die lebenszyklusorientierten Auswirkungen gestalten. Auch dieser Ansatz kann mit Hilfe des zielorientierten Anforderungs-Engineerings erfüllt werden. Zusammenfassend zeigt sich, dass durch die Verwendung des Anforderungs- Engineerings die aufgeworfenen Probleme der Praxis gelöst werden können. Die Durchführung des Anforderungs-Engineering selbst kann dabei durch verschiedene Beteiligte erfolgen. Da derzeit noch keine Erfahrungen mit der Anwendung des Anforderungs-Engineerings im Bauwesen bestehen, kann auch noch kein Best- Practice für die möglichen Akteure bestimmt werden. Prinzipiell stellt das Anforderungs-Engineering ein Hilfsmittel zur erfolgreichen Projektabwicklung und somit zum Projektmanagement im Bauwesen dar. Die Umsetzung der Ziele in Anforderungen kann daher durch verschiedene Beteiligte erfolgen. So besteht die Möglichkeit, dass der Projektentwickler, der Projektsteuerer, der Architekt, der Bauherr selbst oder eine neue Berufsgruppe, die sich auf die Gestaltung und Steuerung der Projektplanung und der Planungsprozesse in Hinblick auf die Anforderungen an das Bauwerk spezialisiert, das Anforderungs-Engineering anwendet. Das Anforderungs-Engineering stellt dann für die Projektbeteiligten ein 20 Vgl. BLECKEN, U., GRALLA, M. (Entwicklungstendenzen 1998) 21 GIRMSCHEID, G., et al. (Nachtragsmanagement 2008), S. 16 22 GIRMSCHEID, G., LUNZE, D. (Lebenszyklusleistungen 2008), S. 90

Seite 26 eigenständiges Hilfsmittel im Projektmanagement dar 23. Weiterhin ist es aber auch denkbar, dass das Anforderungs-Engineering durch das auszuführende Bauunternehmen im Rahmen seiner Projektabwicklung durchgeführt wird. Der Vorteil bei der Anwendung des Anforderungs-Engineerings durch ein Bauunternehmen ist ein möglicher Know-How-Transfer von den notwendigen Bedingungen der Ausführung in die Planungsentwicklung und -gestaltung. Auch kann das Anforderungs-Engineering innerhalb des Projektmanagements durch verschiedene Projektbeteiligte nacheinander wahrgenommen werden. So kann beispielsweise zu Beginn des Projektmanagements das Anforderungs-Engineering durch einen Projektentwickler oder Projektsteurer angewendet werden, während es dann in der Planungs- oder Ausführungsphase an das Bauunternehmen übergeben wird. Grundsätzlich ist das Anforderungs-Engineering aber ein Bestandteil des Projektmanagements, so dass im Folgenden die Einbettung des Anforderungs- Engineerings in das Projektmanagement beschrieben werden soll. Um das Anforderungs-Engineering innerhalb eines Bauunternehmens durchführen zu können, erfolgt anschliessend eine Beschreibung des Unternehmensmanagements, um die Voraussetzungen für die Durchführung des Anforderungs-Engineerings von einem Bauunternehmen aufzuzeigen. Einbettung in das Projektmanagement Das Projektmanagement ist ein Werkzeug für die Projektgestaltung durch die Projektbeteiligten. Nach GIRMSCHEID (2007) lässt sich das Projektmanagement wie folgt definieren 24 : Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projekts Das Projektmanagement bildet somit den gestalterischen Rahmen für ein Bauprojekt. Die wichtigsten Elemente des Managements sind nach ULRICH (1984) 25 : Entwickeln Entscheiden Ingangsetzen Kontrollieren Im Projektmanagement soll das Anforderungs-Engineering diese Tätigkeiten unterstützen, so dass das Anforderungs-Engineering als Führungsmittel bzw. -technik und somit als ein Projektprozess im Projektmanagement (Bild 3) angesehen werden kann. 23 Vgl. GIRMSCHEID, G. (AEP - Anforderungsentwicklungsprozess 2010) 24 GIRMSCHEID, G. (Projektabwicklung 2007), S. 44 25 Vgl. ULRICH, H. (Management 1984); WÖHE, G., DÖRING, U. (Betriebswirtschaftslehre 2002), S. 85; MÜLLER-STEWENS, G., LECHNER, C. (Strategisches Management 2005); oder PEAK = Planen, Entscheiden, Anordnen, Kontrollieren

Seite 27 Entwickeln Projektmanagement Kontrollieren Strategische Planung Projektentwicklung Vorplanung Entwurfs-/ Genehmigungsplanung Ausführungsplanung/ Vergabephase Anforderungs-Engineering Organisation Controlling Ausführungsphase/Objektüberwachung Projektabschluss Entscheiden Ingangsetzen Bild 3: Einbettung des Anforderungs-Engineerings ins Projektmanagement Durch die Einbettung des Anforderungs-Engineerings in das Projektmanagement muss das Anforderungs-Engineering in seiner Gestaltung die Phasen des Projektmanagements und somit die Phasen des Projekts berücksichtigen. Einbettung in das Unternehmensmanagement Damit das Anforderungs-Engineering im Projektmanagement und somit von einem Projektbeteiligten umgesetzt werden kann, muss das Unternehmen des Projektbeteiligten (Bauunternehmen, Architekturbüro, Ingenieurbüro, etc.) die notwendigen unternehmerischen Voraussetzungen zur Durchführung des Anforderungs-Engineerings besitzen. In Anlehnung an die Betriebswissenschaften hat GIRMSCHEID (2006) die Handlungsebenen des Managements auch auf das Bauwesen übertragen. Nach diesem Ansatz kann man bei einem Unternehmen im Bauwesen das Management in drei Handlungsebenen unterscheiden 26 : Normatives Management Strategisches Management Operatives Management Auch wenn die Anwendung und Durchführung des Anforderungs-Engineerings vor allem auf der Ebene des operativen Managements anzusiedeln ist, so muss der Prozessansatz auch in das strategische und normative Management eingebettet werden. Die oberste Denk- und Entscheidungsebene des Unternehmensmanagements ist das normative Management 27. Innerhalb des normativen Managements werden die übergeordneten Unternehmensvisionen und -ziele festgelegt. Das normative Management ist im Kontext mit der Politik, Wissenschaft, Wirtschaft und der öffentlichen Meinung zu sehen. Um das Anforderungs-Engineering erfolgreich im Unternehmen implementieren zu können, muss das Unternehmen auf der 26 GIRMSCHEID, G. (Bauunternehmensmanagement 2006), S. 5 27 GIRMSCHEID, G. (Bauunternehmensmanagement 2006), S. 8

Seite 28 normativen Ebene als Baudienstleistungsunternehmen ausgerichtet werden, da das Anforderungs-Engineering eine Dienstleistung für den Kunden darstellt. Weiterhin muss zur Berücksichtigung des Lebenszyklus eine gesamtheitliche Ausrichtung des Unternehmens auf normativer Ebene erfolgen. Unterhalb der Ebene des normativen Managements befindet sich das strategische Management. Ziel des strategischen Managements ist der Aufbau, die Pflege, die Anwendung und die Steuerung strategischer Erfolgspotenziale. Dazu unterteilt sich das strategische Management in die Aufgaben 28 : Strategische Planung Umsetzung der Strategie Strategisches und operatives Controlling Anpassung der Strategie Um das Anforderungs-Engineering im Unternehmen implementieren zu können, muss dies schon in der strategischen Planung berücksichtigt werden. So ist bei der Entwicklung möglicher Unternehmens- und Geschäftsfeldstrategien die Berücksichtigung der kundenorientierten Ziel- und Anforderungserfassung zur Durchführung eines zielorientierten Anforderungs-Engineerings notwendig. Auch bei der strategischen Umsetzung müssen die notwendigen Voraussetzungen, wie z.b. die Eingliederung der Prozesse und die Bereitstellung der Ressourcen, für das Anforderungs-Engineering gegeben sein. Die eigentliche Umsetzung des Anforderungs-Engineerings erfolgt auf der Ebene des operativen Managements. Allgemein übernimmt das operative Management die Organisation und Lenkung der laufenden Aktivitäten des Unternehmens, um die Bauleistung zu erstellen 29. Um die Bauprojekte effektiv und effizient durchführen zu können, ist ein optimaler Leistungserstellungsprozess aller Beteiligten notwendig. Allgemein können die Bauleistungen durch verschiedene Projektabwicklungsformen erstellt werden. Je nach gewählter Projektabwicklungsform nehmen verschiedene Leistungsanbieter in verschiedenen Projektphasen am Bauprozess teil. Im Folgenden sollen die unterschiedlichen Projektabwicklungsformen betrachtet werden und dabei die Eignung der Projektabwicklungsform für das Anforderungs- Engineering bzw. die möglichen Akteure in der jeweiligen Projektabwicklungsform identifiziert werden. 28 GIRMSCHEID, G. (Bauunternehmensmanagement 2006), S. 9 29 GIRMSCHEID, G. (Bauunternehmensmanagement 2006), S. 13

Seite 29 Einbettung in die verschiedenen Projektabwicklungsformen GIRMSCHEID (2007) strukturiert die verschiedenen Projektabwicklungsformen in Bezug auf die Einbindung der Leistungsträger wie folgt 30 : Einzelleistungsträger Generalleistungsträger Totalleistungsträger Systemanbieter Construction Management Die Projektabwicklungsform mit Einzelleistungsträgern wird als traditioneller Bauprozess angesehen. Dabei wird vom Bauherrn die Planung und Ausführung mittels individuell beauftragten Einzelplanern und Einzelunternehmen durchgeführt 31. Die Hauptaufgaben und auch die Gesamtverantwortung liegen bei dieser Abwicklungsform beim Bauherrn bzw. seinen beauftragten Vertretern. Die Ausführung erfolgt dabei nach der festgelegten Ausschreibung des Bauherrn. Die Einbindung des Know-Hows der Bauunternehmen in die Ausführung oder sogar in die Planung findet in dieser Projektabwicklungsform nicht statt. Diese Form der Projektabwicklung ist für das Anforderungs-Engineering nur bedingt geeignet, da über die gesamte Projektlaufzeit nur der Bauherr bzw. seine Vertreter konstant in den Bauprozess eingebunden sind. Zwar kann das Anforderungs-Engineering von den Planungsbeteiligten wie Architekt oder Fachplaner aufgebaut oder verwendet werden, allerdings ist die Anwendung des Anforderungs-Engineering über alle Projektphasen nicht gewährleistet, da durch die Übergabe des Anforderungs- Engineerings an Dritte mit einem Schnittstellenproblem und damit mit einem Informationsverlust zu rechnen ist. Zwar kann das Anforderungs-Engineerings auch in der Projektabwicklungsform der Einzelleistungsträger, z.b. von den Bauherrn oder seinen Vertretern, angewendet werden, muss aber aufgrund der wechselnden Beteiligten und der fehlenden Einbindung des Know-Hows in der Ausführung als nur bedingt geeignet angesehen werden. Bei den Generalleistungsträgern wird für die Leistungserstellung nochmals zwischen dem Generalplaner und dem Generalunternehmer unterschieden 32. Die Generalleistungsträger erhalten vom Bauherrn jeweils den Auftrag zur Erstellung einer Komplettleistung für die Planung bzw. die Ausführung. So obliegt dem Generalplaner die Gesamtkoordination der Aktivitäten und Prozesse für die Planung. Der Generalunternehmer hingegen ist alleinverantwortlich für die vertragskonforme Erstellung des Bauwerks. Durch die Bündelung der Planung bzw. Ausführung auf einen Vertragspartner ist die Verwendung eines Anforderungs-Engineerings besser anwendbar, da mit der Kontinuität der Vertragspartner auch der Nutzen und die Effektivität des Anforderungs-Engineerings steigen. Der Nachteil dieser Projektabwicklungsform ist, dass mögliches Know-How aus der Ausführung nicht in das Anforderungs-Engineering des Generalplaners eingebunden wird, da es nicht 30 GIRMSCHEID, G. (Projektabwicklung 2007), S. 76 31 GIRMSCHEID, G. (Projektabwicklung 2007), S. 155 32 GIRMSCHEID, G. (Projektabwicklung 2007), S. 161ff.