Schlagwort-Archive: Requirements Engineering

Was ist falsch an den modernen Ansätzen?

Die Planung eines Projekts oder die Führung einer Unternehmung ist der Versuch, die zeitliche Entwicklung eines komplexen Systems durch Intervention nach unseren Vorstellungen zu beeinflussen. Die zeitliche Entwicklung eines komplexen Systems läuft aber immer auf eine räumliche und organisatorische Strukturierung hinaus, die dem System erlaubt, die einwirkenden Kräfte am besten zu verteilen. Das ist ziemlich hemdsärmlig ausgedrückt und tönt sehr statisch. Tatsache ist aber, dass die Kräfte in der Hauptsache von Material-, Energie- und Informationsflüssen herrühren, die das System durchströmen und dissipiert, d.h. verbraucht und entwertet werden. Das System lebt von diesen Flüssen und erhält seine Struktur damit.

Das beste Beispiel ist ein menschliches Individuum. Das ist gewiss ein komplexes System. Es hält seine Identität und sich selbst am Leben, indem es ständig Nahrung und Wärme aufnimmt und mit Mitmenschen kommuniziert. Seine stofflichen Ausscheidungen, die Wärme, die das Individuum abstrahlt und die Information, die seine Existenz markiert, sind grösstenteils nicht mehr brauchbar.

Ein anderes Beispiel ist eine Stadt. Stellen Sie sich vor, eine Stadt mit 100’000 Einwohnern wäre unter einer grossen Käseglocke verdeckt. Auf gegenüberliegenden Seiten hätte die Käseglocke je eine Öffnung. Sie hätten den Job gefasst, durch die eine alles, was die Stadt für ihren „Betrieb“ benötigt, rein zu schieben, und alles, was die Stadt nicht mehr braucht, durch die andere Öffnung zu entsorgen. Überlegen Sie sich, was und wieviel Sie durch die In-Öffnung hinein geben müssen, und was und wieviel durch die Out-Öffnung heraus käme (auch Abwärme und „verbrauchte“ Information). Heben Sie dann in Gedanken die Käseglocke und schauen Sie sich die Strukturen und Organisationen an, die durch den Fluss an Materie, Energie und Information aufrecht erhalten werden.

Sehr eindrücklich, weil sehr viel einfacher, ist das Beispiel eines Wasserstrahls, der aus einem Hahn ohne Mündungssieb fliesst. Wenn Sie den Hahn nur ganz wenig öffnen, wird daraus ein klarer, völlig durchsichtiger Faden fliessen. Erhöhen Sie das Wasservolumen ein wenig, dann vermag das System das Gewicht des Fadens nicht mehr ohne weiteres tragen. Es teilt daher den Faden in mehrere Teilfäden auf, die sich umeinander schlingen, wie ein Butterzopf. Jedesmal, wenn Sie den Hahn ein wenig mehr aufdrehen, strukturiert sich der Wasserstrahl auf eine andere Weise. So ist es auch bei der Stadt: Quantitativ und qualitativ verschiedene Inputs entsprechen verschiedenen Städtestrukturen.

Unsere Führungs- und Planungsinterventionen sollen als zusätzliche Kraft die Entwicklung des Systems in eine Bahn lenken, die unseren Vorstellungen entspricht. Leider gibt es nebst unseren Bemühungen noch andere Kräfte, die auf das System einwirken und unvorhergesehene Effekte auslösen können. Wir sind geneigt, unsere Interventionen isoliert zu betrachten, anstatt auch die anderen Kräfte in Betracht zu ziehen. Wir glauben immer noch, dass wir in der Lage seien, ein komplexes System allein durch unseren Willen und durch unsere Anstrengungen zu steuern. Das System (Projekt oder Unternehmen) richtet sich allerdings nach der Gesamtheit des Kräftefeldes aus, das sich durch die gegenseitige Beeinflussung der einzelnen Kräfte ergibt. Wir müssen weniger studieren, wie sich unsere Interventionen auf das System auswirken, als vielmehr, welche Vernetzungen sie mit anderen Kräften und Flüssen haben. Dazu benötigen wir passende Modelle, die die gegenseitigen Beeinflussungen sichtbar machen.

Das kann etwas stringenter in sechs Punkten zusammengefasst werden.

  1. Durch laufende Aufnahme hochwertiger Materie, Energie und Information (Input) entsteht in komplexen Systemen ein Ungleichgewicht von Kräften und Interessen
  2. Kooperative Prozesse der Systemteile suchen solange eine neue Systemstruktur bis das Ungleichgewicht abgebaut und einem dynamischen Gleichgewicht gewichen ist. Dieses Gleichgewicht sorgt umgekehrt dafür, dass sich die Systemteile der von ihnen geschaffenen Struktur unterordnen („Versklavung“)
  3. Der Aufbau einer neuen Struktur ist mit Ungewissheit und Unsicherheit verbunden. Es ist a priori nicht klar, welche Verzweigungen die Entwicklung des Systems nimmt. Kleine Änderungen der Gegebenheiten können daher auf die Entwicklung enorme Konsequenzen haben (Sensitivität der Anfangsbedingungen)
  4. Der hochwertige Input wird zur Aufrechterhaltung der Struktur (Aufbau- und Ablauforganisation) verwendet. Der dabei anfallende Abfall wird als niederwertige Formen von Materie, Energie und Information ausgeschieden und muss abtransportiert werden
  5. Ist die Struktur erreicht, die dem dynamischen Gleichgewicht entspricht, kann das System ziemlich stabil sein. Nach zufälligen und nicht allzu grossen Störungen kehrt das System wieder zu seiner ihm eigenen Struktur zurück (z.B. nach der Genesung von einer Krankheit)
  6. Ändert sich der Input, kann sich das System neu ausrichten, indem es eine neue Struktur bildet

Dazu kommt, dass sich unsere Entscheidung, wie wir auf das System einwirken wollen, danach richtet, wie wir das System und die eigene Rolle darin wahrnehmen. Die Kognition des Kraftfeldes ist nicht identisch mit dem effektiven Kraftfeld, das für die Entwicklung des Systems verantwortlich ist. Unsere Interventionen sind mit den Axthieben eines schielenden Holzfällers vergleichbar. Er schlägt mit voller Kraft zu und ist enttäuscht über die Wirkungslosigkeit seines Schlages.

Von alledem ist in modernen Ansätzen wenig zu spüren.

Im Requirements Engineering wird z.B. nach wie vor so getan, als wäre es tatsächlich möglich, zu Beginn eines komplexen Projekts die Anforderungen vollständig zu erarbeiten. Kognitive Aspekte werden kaum berücksichtigt. Das Wesen von Unsicherheit wird nicht verstanden. Z.B. schreibt Ebert: Jedes Projekt…hat Unsicherheiten, also Bereiche wo der Kunde…nicht [weiss], was sich noch ergeben könnte. Allerdings sollten diese Unsicherheiten nicht quer durch das Projekt verstreut sein, sondern deklariert sein (sic!). Anforderungen, die sich ändern können, werden markiert1. Könnte man Unsicherheiten deklarieren, wären es keine Unsicherheiten.

Im Projektmanagement herrscht grösstenteils immer noch ein Machbarkeitswahn. Das PMBOK geht in keinem der neun Wissensgebiete auf die Sensitivität der Anfangsbedigungen ein. Mit dem Begriff der Work Breakdown Structure (WBS) wird angenommen, dass ein Projekt in vorgegebene Arbeitspakete zerlegt werden kann. Im PMBOK ist zu lesen: Im Projektstrukturplan (WBS) werden die vom Projektteam auszuführenden Arbeiten ausgehend von den Liefergegenständen hierarchisch zerlegt, um die Projektziele zu erreichen und die erforderlichen Liefergegenstände zu erstellen. Zwar wird gesagt, dass die Zerlegung … möglicherweise nicht für einen Liefergegenstand oder ein Teilprojekt möglich [ist], der bzw. das in ferner Zukunft erstellt bzw. durchgeführt wird2. Ob jedoch die auszuführenden Arbeiten und die Liefergegenstände grundsätzlich bekannt sein können, wird nicht hinterfragt.

Systems Engineering (SE) wird meist als Patentrezept zur Bewältigung von Komplexität verstanden. Es gibt verschiedene Definition von SE. Wird es im Sinne des über 30 Jahre alten Buch von Daenzer verstanden, so hat es gar nichts mit systemischem Denken zu tun. Wikipedia subsummiert unter SE u.a. Requirements Engineering und Projektmanagement, wie wir es hier kritisieren. Zu der Geschichte des SE steht, dass die… Franzosen bei der Entwicklung der Ariane-Rakete Systems Engineering intensiv eingesetzt [haben], was schliesslich zu einem grossen Erfolg der Rakete führte. Tatsächlich aber stürzte die Ariane V 1996 ab, gerade eben weil die Migration des Lenksystems von der Ariane IV nicht systemgerecht erfolgte, wie z.B. Stefan Hügel weiss.

Moderne (Projekt-)Managementansätze basieren immer noch auf einer Weltsicht, wie sie die Menschen bis in die Sechziger Jahre des letzten Jahrhunderts hatten: Systeme werden in Teile zerlegt und diese isoliert betrachtet. Es wird kaum Rechenschaft darüber abgelegt, welche Auswirkungen unsere Eingriffe haben. Kognitive Verzerrungen werden nicht wirklich hinterfragt. Parallel dazu erhöhen wir laufend die Komplexität unserer Welt, sind aber offensichtlich nicht bereit, unser Denken daran anzupassen und wundern uns, wenn die Erfolgsquote von Migrations- und Integrationsprojekten stagniert oder sogar zurück geht.

1Christoph Ebert. Systematisches Requirements Engineering und Management- Anforderungen ermitteln, spezifizieren, analysieren und verwalten. dpunkt.verlag. Heidelberg, 2008:
2Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Newtown Square 2004

Bye, bye Requirements Engineering

Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.

Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie „fahren“ oder „transportieren“? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie „transportieren“, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.

Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.

Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!

1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334

2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive „Software Engineering 2006“