Hood / Wiebel Optimieren von Requirements Management & Engineering

Mit dem HOOD Capability Model
1. Auflage 2005
ISBN: 978-3-540-27311-0
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 248 Seiten

Reihe: Xpert.press

Es war mir eine große Freude, zusammen mit meinem Freund Colin Hood dieses Buch zu schreiben. Seine reichhaltigen Erfahrungen aus sehr vielen unterschiedlichen Industriezweigen, auf unterschied- chen Ebenen und in verschiedenen Entwicklungsabteilungen geben tiefe Einblicke in die unterschiedlichsten Unternehmenskulturen. Um das oft als sehr trocken angesehene Thema des Requirements Management und Engineerings spannend zu gestalten, haben wir Teile dieser Erfahrung an Hand von Stories von Colin Hood in die einzelnen Kapitel des Buches eingestreut. Diese Stories sind gr- tenteils authentisch, manchmal auch aus mehreren Gegebenheiten konstruiert. Der Begriff Requirements Management begleitet mein Berufs- ben nun seit 1991. Damals, als Informatiker der bereits einige Erf- rung in der Softwareentwicklung und Durchführung von Softwa- projekten sammeln konnte, war mir bereits bei der ersten Beschäf- gung mit diesem Thema klar, dass hier einiges an Potential brach liegt. In dieser Zeit Information über Requirements Management und Engineering zu bekommen, war nicht ganz einfach; Bücher darüber gab es kaum. Bei Organisationen wie IEE, IEEE und NCSE (aus der dann später die INCOSE entstand) beschäftigten sich aber bereits Arbeitsgruppen mit Requirements Management oder mit Requirements Engineering (wir machen uns im Verlauf des Buches noch Gedanken zu diesen und ähnlichen Begriffen).

Colin Hood hat seit 1977 die Evolution der Steuerungssysteme von relaisgestützten Systemen über Programmierbare Logische Controller (PLCs) bis hin zu modernen softwaregesteuerten Systemen begleitet. In verschiedenen Tätigkeitsfeldern war er verantwortlich für Analyse, Design, Implementierung, Test und Auslieferung komplexer Softwaresysteme. Der Einsatz von Requirements Management & Engineering war von jeher die Methodik, die seinen Erfolg bei Firmen wie Alcatel, BMW, DaimlerChrysler, Hella oder Miele begründet hat. Seine Spezialität ist neben der Verbesserung der Prozesse in Entwicklungsabteilungen die Unterstützung des Veränderungsprozesses bei Einführung neuer Methoden und Werkzeuge, was in der Regel eine Kulturänderung in den betroffenen Unternehmen auslöst. Nach dem Studium der Diplom Informatik leitete Rupert Wiebel verschiedene Projekte im Telekommunikationsbereich (bis 1991), um dann zwischen 1991 und 1997 als Berater im CASE- und Requirements Management & Engineering tätig zu sein. Danach baute er die deutsche Niederlassung des RM-Tool Herstellers QSS (DOORS) auf. In dieser Zeit entwickelte sich DOORS zum marktführenden RM-Werkzeug in Deutschland. Nach der Übernahme von QSS durch Telelogic (2001) gründete Wiebel zusammen mit Colin Hood die HOOD Group, ein unabhängiges Beratungsunternehmen auf dem Gebiet des Requirements Management & Engineering.     

Autoren/Hrsg.

Hood, Colin

Wiebel, Rupert

Inhaltsverzeichnis

1;Widmungen;6
2;Vorwort;7
3;Inhaltsverzeichnis;9
4;Abschnitt 1: Warum sind Anforderungen so wichtig?;13
4.1;1 Einleitung;15
4.1.1;1.1 Ziel dieses Buches;15
4.1.2;1.2 Nutzen dieses Buches;15
4.1.3;1.3 Begriffsdefinition RM&E;16
4.1.4;1.4 Struktur dieses Buches;17
4.1.5;1.5 Wie dieses Buch zu lesen ist;19
4.2;2 Wie kann Requirements Management & Engineering helfen?;21
4.2.1;2.1 Einführung;21
4.2.2;2.2 Kommunikation und Fokus;23
4.2.3;2.3 Durch RM&E den Gewinn erhöhen;25
4.2.4;2.4 Mit dem aktuellen Projekt Geld sparen;31
4.2.5;2.5 Mit dem nächsten Projekt Geld sparen;35
4.2.6;2.6 Wie schnell amortisiert sich die Investition in RM&E?;40
4.3;3 Überblick zu Prozesse und Methoden im RM&E;45
4.3.1;3.1 Einführung;45
4.3.2;3.2 Historie;45
4.3.3;3.3 Strukturierte Requirements;50
4.3.4;3.4 Prozessmodelle und RM&E;51
4.3.5;3.5 RM&E in Prozessverbesserungs- und Reifegradmodellen;57
5;Abschnitt 2: Was ist Requirements Management & Engineering?;61
5.1;4 Requirements Management & Engineering;63
5.1.1;4.1 Einführung;63
5.1.2;4.2 Begriffsfindung;63
5.1.3;4.3 Requirements Management;65
5.1.4;4.4 Requirements Definition;68
5.1.5;4.5 Das Informationsmodell: Das Tor zu RM;70
5.2;5 Der HOOD Requirements Definitionsprozess;81
5.2.1;5.1 Ziel und Struktur des Kapitels;81
5.2.2;5.2 Einführung in Prozesse, Aktivitäten, Methoden und Werkzeuge;82
5.2.3;5.3 Einführung in den HOOD Requirements Definitionsprozess;86
5.2.4;5.4 Iterationen bei Requirements Definition;92
5.2.5;5.5 Definieren des Scopes und identifizieren der Stakeholder;95
5.2.6;5.6 Erhebung: Verführen und Jagen;98
5.2.7;5.7 Spezifikation;104
5.2.8;5.8 Analyse und Reviews;118
5.2.9;5.9 Modellierung;122
5.3;6 RM als guter Geist des Produktlebenszyklus;141
5.3.1;6.1 Einführung in Requirements Management;141
5.3.2;6.2 Requirements Management;142
5.3.3;6.3 Requirements Development;153
5.3.4;6.4 Änderungsmanagement;154
5.3.5;6.5 Projektmanagement;159
5.3.6;6.6 Versions- und Variantenmanagement;165
5.3.7;6.7 Verifikation;166
5.3.8;6.8 Zusammenfassung;167
6;Abschnitt 3: Wie kann Requirements Management & Engineering im Unternehmen optimiert werden?;170
6.1;7 Optimieren von RM&E in einer Organisation;171
6.1.1;7.1 Einführung;171
6.1.2;7.2 Struktur des Veränderungsprozesses;174
6.1.3;7.3 HOOD Capability Model für Requirements Definition;182
6.1.4;7.4 Etablieren von RM&E in einer Organisation;198
6.1.5;7.5 Fazit;226
6.2;8 Requirements Management Werkzeuge;229
6.2.1;8.1 Einführung in Requirements Management Werkzeuge;229
6.2.2;8.2 Benutzeranforderungen für ein RM-Werkzeug;230
6.2.3;8.3 Marktüberblick;238
6.2.4;8.4 Zusammenfassung;239
7;Die Autoren;241
8;Literaturverzeichnis;243
9;Webseiten zu RM&E;249
10;Abkürzungsverzeichnis;251
11;Synonyme;253
12;Index;255

Leseproben

5 Der HOOD Requirements Definitionsprozess Ein iteratives Vorgehen um Anforderungen auf allen Ebenen zu erfassen. (S. 69-70)

5.1 Ziel und Struktur des Kapitels
Ziel des Kapitels ist es, Prozesse zu definieren und den HOOD Requirements Definitionsprozess vorzustellen. Dieser Prozess besteht aus Einzelaktivitäten, die im Detail besprochen werden. Weiterhin werden Methoden zu den einzelnen Aktivitäten vorgeschlagen. Es gibt sehr viele Methoden. Es ist jedoch nicht das Ziel dieses Buches, Sie zum Experten in all diesen Methoden auszubilden. Sie sollen vielmehr in die Lage versetzt werden, die richtigen Fragen zu stellen, um heraus zu bekommen was in Ihrem Umfeld Sinn macht. Dadurch werden Sie aus verschiedenen Lösungen die für Sie richtigen auswählen können. Jede Organisation ist anders, und auch Ihre eigene wird sich von anderen Organisationen unterscheiden. Wir helfen Ihnen, Requirements Management &, Engineering zielgerichtet an Ihre Organisation anzupassen. Zuerst werden Prozesse, Aktivitäten und Methoden allgemein im Kapitel 5.2, und dann speziell der HOOD Requirements Definitionsprozess in Kapitel 5.3 eingeführt. Danach empfehlen wir die Anwendung einer iterativen Vorgehensweise in Kapitel 5.4. Die Aktivitäten des HOOD Definitionsprozess werden in den Kapiteln 5.5 bis 5.9 vorgestellt.

Das Definieren von Umfang und Gültig keitsbereich inklusive der Identifikation der Stakeholder wird in Kapitel 5.5 beschrieben. Der Rest der Aktivitäten wird einzeln betrachtet. Erhebung ist in Kapitel 5.6 zu finden, Spezifikation in Kapitel 5.7, Analyse und Reviews in Kapitel 5.8. Modellierung, die Aktivität, die alle anderen Aktivitäten unterstützt ist in Kapitel 5.9 beschrieben. Die Erstellung von Dokumenten wird zwar in Kapitel 5.7.2.2 erwähnt, sehr viel detaillierter aber in Kapitel 6.2.2 besprochen. 5.2 Einführung in Prozesse, Aktivitäten, Methoden und Werkzeuge Laut IEEE ist „ein Prozess eine Sequenz von Schritten, die für einen bestimmten Zweck durchgeführt werden" In ihrem Capability Maturity Model (CMM) erweitert die SEI diese Prozessdefinition, um damit einen Software Prozess definieren zu können: „eine Menge von Aktivitäten, Methoden, Praktiken und Transformationen, welche Menschen benutzen, um Software und verwandte Produkte zu entwickeln und zu erhalten."

Wir bevorzugen die Definition des SEI aus zwei Gründen: Sie ist flexibel und erweckt nicht den Eindruck, ein Prozess sei eine starre Abfolge von Schritten. Wir sehen uns bei der Einführung von Prozessen oft mit Problemen konfrontiert, weil die Definition des Prozesses zu starr ist und keinerlei Änderungen zulässt. Der zweite Grund für die Bevorzugung der SEI-Definition ist, dass sie über Menschen spricht. Viele Prozesse scheitern. Vielleicht scheitern sie deswegen, weil die Autoren und Manager nicht in Betracht ziehen, dass die Prozesse durch Menschen ausgeführt werden. Nach der Definition von HOOD ist ein Prozess „eine Menge von Aktivitäten, ausgeführt mit Hilfe von Methoden, welche von Werkzeugen unterstützt werden können. Prozesse werden von Menschen für bestimmte Zwecke benutzt". Um zu klären, was mit Aktivitäten gemeint ist, benutzen wir als Beispiel aus dem RM&,E die Erhebung von Anforderungen und die Analyse der Anforderungen. Lassen Sie uns die Erhebung von Anforderungen betrachten. Es gibt viele Methoden wie z.B. Interviews Nutzung von Prototypen