Die übliche Sicht der Anforderungsbestimmung betrachtet es als das Hauptproblem, die Anforderungen überhaupt zu finden und dann so genau zu beschreiben, daß sie korrekt implementiert werden können. Demgegenüber werden wir in diesem Abschnitt eine alternative Sicht benutzen, die die Anforderungsbestimmung hauptsächlich als einen Konfliktlösungs- und Risikomanagementprozeß betrachtet.
In dieser Sicht gibt es drei Klassen von Schwierigkeiten bei der Anforderungsbestimmung: Unsicherheiten (niemand weiß, wie es ist oder sein sollte), Risiken (man weiß, wie es sein soll, aber nicht, ob man das hinkriegt) und Konflikte (die Anforderungen verschiedener Parteien sind nicht unmittelbar miteinander zu vereinbaren).
Der Anforderungsbestimmungsprozeß besteht darin, diese Schwierigkeiten aufzulösen, was für alle drei Klassen mit Hilfe von Verhandlungen erfolgen kann, in denen zwischen den Beteiligten vereinbart wird, wie mit der Schwierigkeit umgegangen werden soll. Diese vereinheitlichende Sichtweise führt erstens dazu, daß wichtige Aspekte weniger leicht vergessen werden (Risiken und Unsicherheiten), die Anforderungen also vollständiger werden, zweitens dazu, daß Kommunikationsprobleme explizit (nämlich als Unsicherheiten) behandelt werden und drittens dazu, daß die in der konventionellen Sicht gar nicht ausdrücklich vorhandene Problemklasse der Konflikte besser bewältigt werden kann.
Diese beiden Sichten sind natürlich nicht äquivalent, überlappen sich aber stärker, als man zunächst meinen könnte: Die Hauptschwierigkeiten in der konventionellen Sicht sind Kommunikationsprobleme und Verständnisprobleme. Diese rühren jedoch vor allem aus der unterschiedlichen Sichtweise der Beteiligten her, die zum Teil von ihrer Herkunft erklärt wird und zum Teil von ihren verschiedenen Interessen. Sie lassen sich also als Risiko (Verständnisunsicherheit) und als Konflikt (Interessenlagen) deuten, so daß die Konfliktlösungssicht weite Teile der konventionellen Sicht mitabdeckt.
Das Interessante an der Konfliktlösungssicht ist, daß sie den Rahmen der reinen Anforderungsanalyse sprengt. Sie dient vielmehr als einheitliche Grundlage für das gesamte strategische Projektmanagement. Damit eröffnet sie insbesondere einen guten Weg, um mit sich ändernden Anforderungen während eines Projekts umzugehen, denn solche Änderungen verlangen ja gerade, die Anforderungsanalyse nicht nur als eine in sich abgeschlossene Phase vor Implementationsbeginn zu betrachten, sondern als eine ständig während der Projektdurchführung weiterzuführende Aktivität.
Der Hauptvertreter der Konfliktlösungssicht ist Barry Boehm, der die Verfahrensgrundlage dieser Sicht in Form einer einfachen allgemeinen Managementtheorie formuliert hat, genannt Theorie W. Diese ist als Fortentwicklung dreier bisheriger Managementtheorien zu verstehen, die die Bezeichnungen Theorie X, Theorie Y und Theorie Z tragen und deshalb hier zuvor kurz vorgestellt werden sollen.
Theorie X baut auf den Ideen des ,,wissenschaftlichen Managements`` auf, die Frederick Taylor Anfang des 20. Jahrhunderts eingeführt hat. Sie besagt, daß die effizienteste Art, eine Arbeit zu erledigen, darin besteht, sie aufgrund von Zeit- und Bewegungsstudien so in glatt aneinanderpassende Teile zu zerlegen, daß die arbeitenden Menschen so effizient und vorhersagbar wie Maschinen arbeiten können. Management besteht in dieser Theorie darin, das System ohne Störungen am Laufen zu halten. Diese Theorie führte zur Einführung der Fließbandarbeit. Der große Nachteil dieser Theorie besteht darin, daß sie die Flexibilität, Kreativität und Selbstachtung der Menschen unterdrückt. Das führt unter anderem dazu, daß eine Organisation, die nach Theorie X arbeitet, sehr schlecht mit Wandel umgehen kann.
Theorie Y besagt deshalb, das Management solle vor allem die Kreativität und Initiative der Menschen fördern. Dies erzeugt jedoch viele Konflikte und hält keine Mittel bereit, mit ihnen umzugehen.
Theorie Z geht dieses Problem an, indem sie Vorabinvestitionen in die Ausbildung gemeinsamer Werte empfiehlt und wichtige Entscheidungen im Konsens zu fällen vorschlägt. Allerdings macht sie dabei die Annahme, daß alle diese Prozesse nur innerhalb einer Organisation stattfinden und hält wenig Rat bereit für den Fall mehrerer Organisationen und mehrerer Parteien, wie es bei Softwareentwicklung stets der Fall ist (Anwender, Kunde, Entwickler etc.).
Theorie W ist auf diesen Fall unterschiedlicher Parteien mit unterschiedlichen Interessen ausgerichtet. Bei der Softwareentwicklung haben die beteiligten Gruppen recht unterschiedliche Interessen, z.B.: Die Benutzer wünschen sich ein zuverlässiges, benutzerfreundliches System, das möglichst viele Funktionen hat, die sie in ihrer Arbeit unterstützen. Der Kunde möchte ein Produkt, das pünktlich und zum vereinbarten Preis geliefert wird und dann wie gewünscht funktioniert. Die Programmwarter möchten ein wohldokumentiertes, leicht änderbares System ohne Fehler. Die Entwickler wünschen sich technische Herausforderungen mit viel Entwurfs- und wenig Dokumentationsarbeit. Die Reihe ließe sich fortsetzen mit Testern, Projektmanagern und anderen.
Diese verschiedenen Interessen sind die Wurzel zahlreicher Konflikte. Wenn diese Konflikte nicht ausdrücklich erkannt und aufgelöst werden, sind sie die Ursache eine großen Menge von oft dramatischen Schwierigkeiten. Einen Konflikt aufzulösen bedeutet nicht nur, irgendeine Entscheidung herbeizuführen, sondern eine solche Entscheidung zu treffen, die für alle Parteien akzeptabel ist oder idealerweise sogar eine, mit der alle Parteien zufrieden sind. Das Grundprinzip von Theorie W lautet deshalb ,,Mache jeden zum Gewinner (make everyone a winner)``.
Dieses Prinzip besagt, daß bei Konflikten stets Lösungen angestrebt werden, die für alle Beteiligten vorteilhaft sind. Grundlage dieses übertrieben wirkenden Anspruchs ist die Beobachtung, daß oft Lösungen gefunden werden können, die sogenannte Gewinn-Gewinn (win-win) Situationen herstellen, wenn man nur den geeigneten Betrachtungsrahmen für die Beteiligten herstellt. Die normale Wahrnehmungsweise von Konflikten ist meist die von Nullsummenspielen: der Vorteil des einen ist der Nachteil des anderen, also eine Gewinn-Verlust (win-lose) Situation.
Beispielsweise ist eine nachlässige und deshalb billigere Softwareentwicklung ein Gewinn für den Entwickler und ein Verlust für den Kunden (win-lose). Die Situation läßt sich jedoch in eine Gewinn-Gewinn-Situation überführen, indem der Entwickler an dem Gewinn, den der Kunde aus der Software zieht, beteiligt wird. Nun wird die Softwareentwicklung sorgfältig sein und sowohl Kunde als auch Entwickler profitieren davon.
Im schlimmsten Fall treten Verlust-Verlust (lose-lose) Situationen auf: überhöhte Erwartungen, unrealistische Pläne, unverträgliche Leute in einem Projekt, oder der Versuch, Planrückstände durch Personalaufstockung aufzuholen, führen meist zu allseitigem Verlust. Leider sind diese Fehler gerade im Softwarebereich häufig zu beobachten, weil kein Risikomanagement und keine Konfliktauflösung betrieben wird.
Im Mittelpunkt von Theorie W steht also die Frage, wie man win-win Situationen erzeugt und erhält. Hierzu gibt es eine Reihe von Prinzipien:
Das Herstellen und vor allem Aufrechterhalten allseitiger win-win Bedingungen in einem Projekt erfordert die Einhaltung von zwei Hilfsprinzipien von Theorie W:
Planen und Planeinhaltung ist wichtig, weil ein Plan die gegenseitige Zusicherung der Beteiligten ist, bestimmte win-win Bedingungen einzuhalten, und außerdem einen Rahmen für die Entdeckung von Abweichungen von diesen Bedingungen bildet. Ein Plan in Theorie W beantwortet zu diesem Zweck einheitlich immer eine Reihe von Fragen, nämlich Warum? (Ziele), Was? (Produkte), Wann? (Meilensteine), Wer und Wo? (Verantwortlichkeiten), Wie? (Vorgehen), Wieviel? (Ressourcen). Alle diese Planelemente sprechen ausdrücklich die betroffenen Gewinnbedingungen der Beteiligten an und regeln, wie diese zu win-win Situationen vereint werden. Dadurch erlaubt der Plan die Identifikation von Abweichungen von win-win Bedingungen. Das Korrigieren des Projektverlaufs im Falle solcher Abweichungen ist eine der empfindlichsten Maßnahmen für die Einhaltung der win-win Situationen. In den meisten Fällen müssen dabei nämlich neue lokale win-win Situationen erzeugt werden, während eine unterlassene oder unüberlegt vorgenommene Korrekturaktion zu win-lose oder gar lose-lose Situationen führt. Dies ist ein Hauptproblem vieler Projekte, die anfangs gut geplant waren.
Planen und der Versuch der Planeinhaltung machen nur dann alle zu Gewinnern, wenn die Pläne realistisch sind. Dies ist der Zweck des Risikomanagements. Risikomanagement besteht aus zwei Schritten
Die Forschungsgruppe von Boehm hat ein CSCW-Werkzeug (computer supported cooperative work) entwickelt, das die Anforderungsbestimmung und das Projektmanagement gemäß Theorie W unterstützt. Dieses Werkzeug wird WinWin genannt [BBHL95].
Die Zusammenarbeit der Beteiligten mit Hilfe von WinWin geschieht auf Basis folgender drei Hauptkonzepte:
Das Vorgehensmodell von WinWin besteht darin, daß ein Gleichgewichtszustand (Equilibrium) zwischen den WCs der Beteiligten hergestellt wird, der darin besteht, daß es erstens keine Konflikte zwischen WCs und POAs gibt, zweitens alle POAs miteinander konsistent sind und es drittens keine unaufgelösten CRUs oder offene POAs gibt. Dieser Zustand ist ganz zu Beginn erfüllt, wenn es überhaupt noch keine WCs gibt und kann jeweils durch die Einführung einer neuen WC gestört werden, wenn diese einen Konflikt mit einer anderen WC hat oder ein Risiko oder eine Unsicherheit aufwirft. Dieses Vorgehensmodell unterstützt ständige Änderungen der Anforderungen, weil es überhaupt keinen Unterschied zwischen einer anfänglichen Anforderungsbestimmung und späteren Anforderungsänderungen macht.
![\includegraphics[scale=1]{Bild/anfordwinwinstates.ps}](img78.gif)
In Abbildung 8.2 sehen wir die verschiedenen Zustände von WinWin und die Übergänge zwischen diesen. Alle Zustände mit Ausnahme des Gleichgewichtszustands sind mit einer Aktivität verbunden, deren Ergebnis die Übergangsbedingung zum Folgezustand spezifiziert. Die Aktivitäten werden, wo nicht anders vermerkt, vom Analytiker ausgeführt. Der Gleichgewichtszustand wird verlassen, sobald von irgendwoher eine neue WC auftaucht und wird wieder erreicht, wenn diese in eine Übereinkunft (POA) umgesetzt wurde, die nicht mit den übrigen Übereinkünften kollidiert.
Das Verfahren bei der Benutzung von WinWin besteht also darin, daß die Beteiligten mit dem System arbeiten, um ihre WCs zu definieren und die WCs der anderen Beteiligten kennenzulernen; alle WCs werden in einem zentralen Speicher gehalten. Bei Konflikten oder Risiken werden von den Analytikern die entsprechenden CRUs erarbeitet. WinWin hilft bei der Identifikation dieser Fälle und beim Zusammentragen der nötigen Information für die CRU. Die CRU dient anschließend dazu, die Verhandlungen zwischen den Beteiligten auf das jeweilige Problem zu konzentrieren. WinWin stellt außerdem Unterstützung für die Verhandlungen zur Verfügung, zum Beispiel Schätzmodelle.
Zwei entscheidende Hilfsmittel in diesem Prozeß sind die Wahlmöglichkeitsübersichten und die Bereichstaxonomie.
Eine Wahlmöglichkeitsübersicht (option summary) wird vom Analytiker als Teil einer CRU aufgestellt. Sie führt alle erkennbaren Maßnahmen auf, wie der von der CRU beschriebenen Schwierigkeit begegnet werden könnte. Zu jeder Möglichkeit sind die absehbaren Vorteile und Nachteile mit aufgeführt. Diese Vor- und Nachteile werden von den Beteiligten bei der Verhandlung dazu benutzt abzuschätzen, welche Optionen für sie in Anbetracht ihrer wichtigsten WCs akzeptabel sind oder unter welchen Umständen sie es werden könnten. Dies ermöglicht die schnelle Entfernung von irrelevanten oder inakzeptablen Optionen aus der Diskussion und konzentriert die Verhandlungen schnell auf erfolgversprechende Auswahlmöglichkeiten.
Die Bereichstaxonomie liefert eine einheitliche Terminologie für die Formulierung von WCs, CRUs und POAs. Das hat zwei Vorteile. Zum einen ermöglichst die Taxonomie, vermutete Konflikte zwischen WCs schneller als vorhanden oder nicht vorhanden zu klassifizieren, weil sie Verständnisunsicherheit verringert. Zum anderen erlaubt sie eine schnellere Bestimmung der Kandidaten für Konflikte oder Risiken, weil sie eine Auswahl von WCs nach betroffenen Aspekten ermöglicht, indem alle WCs die von ihnen betroffenen Taxonomieelemente aufführen. Die Bereichstaxonomie in WinWin hat drei Teile: Erstens eine konzeptionelle Komponentenzerlegung des gewünschten Systems in Teile und Unterteile, zweitens eine Funktionalitätszerlegung in Funktionen und Unterfunktionen und drittens eine Hierarchie von allgemeinen Attributen des Systems (Produktattribute) oder des Entwicklungsprojekts (Prozeßattribute). Die Bereichstaxonomie von WinWin ist projektspezifisch.
Das WinWin-System verringert eine Reihe von Problemen bei der Anforderungsbestimmung, kann aber natürlich keine Wunderlösung für den Kern der Sache sein. In der Terminologie von WinWin bleiben drei schwierige Arbeitsaufgaben bestehen:
QARCC beschränkt sich auf die Konflikte, die zwischen Qualitätsanforderungen (im Gegensatz zu Funktionalitätsanforderungen) auftreten. Es beruht darauf, die Menge der möglichen Konflikte samt Vorschlägen zu ihrer Lösung in einer Wissensbasis abzuspeichern und mit deren Hilfe die Menge der WCs auf Qualitätsanforderungskonflikte zu untersuchen.
Diese Wissensbasis besteht aus drei Teilen, die wir der Reihe nach besprechen: Erstens eine Liste der typischen Qualitätsanforderungen, aufgeschlüsselt nach Art der Beteiligten, zweitens eine Verfeinerung dieser globalen Qualitätsanforderungen in eine größere Zahl detaillierter Anforderungen und drittens eine Zuordnung von sogenannten Qualitätsattributstrategien zu diesen Anforderungen (groben oder verfeinerten).
Die Liste der typischen Qualitätsanforderungen wurde aus der Erfahrung bei der Anwendung von Theorie W hergeleitet. Sie enthält folgende Punkte: Sicherheit/Betriebsgarantien (assurance), Interoperabilität, Benutzbarkeit/Benutzungsfreundlichkeit, Geschwindigkeit, Weiterentwickelbarkeit/Portabilität, Kosten und Zeitplan, Wiederverwendbarkeit.
Die Verfeinerung dieser Anforderungen schlüsselt jede von ihnen in eine Reihe konkreterer Anforderungen auf. Beispielsweise besteht Sicherheit/Betriebsgarantien aus den Einzelpunkten Zuverlässigkeit, Genauigkeit, Korrektheit, Verfügbarkeit, Robustheit, Gefährdungsfreiheit, Datensicherheit, Datenschutz. Diese Auflistung könnte man beliebig verfeinern, sie dient aber nur dazu, Qualitätsanforderungen, die in win-conditions auftreten, erkennen und einer Anforderungsklasse zuordnen zu können.
Der dritte Teil der Wissensbasis ist der entscheidende. Er gibt zu jedem Qualitätsattribut eine Liste von Strategien an, mit denen dieses Attribut erzielt werden kann. Die Liste unterscheidet zwischen Produktstrategien (auch Architekturstrategien genannt), also anzustrebenden Eigenschaften der Software, und Prozeßstrategien, also anzustrebenden Eigenschaften der Vorgehensweise bei ihrer Konstruktion. Produktstrategien für gute Benutzbarkeit und Benutzungsfreundlichkeit sind zum Beispiel: Verteilbarkeit (groupware), fehlervermeidende, konsistente, flexible, benutzeranpaßbare Benutzerschnittstellen, On-line-Hilfe, äußere Modularität, Navigationshilfen, Benutzerprogrammierschnittstellen, Undo-Funktion. Zugehörige Prozeßstrategien sind: Bau von Prototypen, Benutzungsprotokollierung und -modellierung, Benutzerbeteiligung beim Entwurf, Benutzung von Benutzerschnittstellenwerkzeugen.
Die Produktstrategien werden nicht nur einfach aufgelistet, sondern weisen eine eigene Struktur in der Wissensbasis auf; jede besteht aus folgenden Teilen:
Die Funktionsweise von QARCC zusammen mit WinWin ist nun folgendermaßen:
In einer Fallstudie wurden mit Hilfe von QARCC sieben Konflikte zwischen Qualitätsanforderungen aufgedeckt; nur zwei von diesen waren zuvor von den menschlichen Beteiligten der Anforderungsanalyse bemerkt worden. Zusätzlich signalisierte QARCC weitere drei Konflikte, die von den Benutzern als nicht signifikant eingestuft und deshalb ignoriert wurden. Die hybrid automatisch/manuelle Vorgehensweise von QARCC ist ein sinnvoller Ansatz zur Unterstützung der Entdeckung und Behandlung von Anforderungskonflikten. Es ist noch offen, inwieweit die relativ simple Struktur der Wissensbasis auch größeren Projekten gerecht werden kann, oder ob QARCC dann dazu führt, daß die Benutzer mit Meldungen über potentielle Konflikte überschüttet werden.