eine kleine praktische philosophie über das requirements engineering

Vortrag im Rahmen der SOPHIST Days 2011 Seite 1 von 12

Folie 1 – Philosophie ist Liebe zur Weisheit

Eine kleine praktische Philosophie über das Requirements Engineering

oder

„Was ist das überhaupt, eine Anforderungsspezifikation?“

Kim Lauenroth

adesso AG, Stockholmer Allee 24, 44269 Dortmund

[email protected]

Philosophie und Requirements Engineering ... geht das zusammen?

Mit dem Begriff Philosophie wird eine Viel-zahl verschiedener Dinge assoziiert, daher ist eine allgemeine Definition von Philosophie sehr schwierig. Generell kann man jedoch festhalten, dass die Philosophie das Ziel ver-folgt, die Dinge in der Welt, die Natur der Dinge und ihre Zusammenhänge besser zu verstehen. Dazu gehört insbesondere das Stellen von kritischen und teilweise auch un-angenehmen Fragen. Dieses Streben nach Erkenntnis versteckt sich hinter der ur-sprünglichen Bedeutung des Wortes „Philo-sophie“, welches aus dem Altgriechischen stammt und wörtlich übersetzt so viel wie „Liebe zur Weisheit“ bedeutet.

Aber wieso sollte man jetzt Philosophie in der Informatik oder spezieller im Software bzw. Requirements Engineering betreiben? Der Computer und die ihn antreibenden Programme sind doch mit Abstand die präzisesten und am genauesten arbeitenden Maschinen, die es gibt. Der gesamte Computer baut auf den zwei Werten „Wahr“ und „Falsch“ auf. Diese werden durch exakt definierte Operationen (z.B. das „logische Und“, das „logische Oder“ und die „logische Ne-gation“) miteinander verknüpft. Vom Prinzip her ist diese Beobachtung richtig. Dieses zentrale Element von Programmen ist recht präzise definiert. Aber, wenn man genauer hinschaut, ist die Bedeutung eines Programms nicht unbedingt präzise definiert.

Dies zeigt sich zum Beispiel an der Frage, ob zwei gegeben Programme identisch sind. Muss dazu der Programmcode gleich sein, oder ist es ausreichend, wenn die Programme das Gleiche tun? Diese Fragen beziehen sich unmittelbar auf die Natur von Programmen und gehören damit schon zur Philosophie (im Bereich Informatik). Aus diesen und weiteren Fragen hat sich ein ganzer wissenschaftlicher Zweig entwickelt, die Informatik-Philosophie.

Den Schritt in Richtung einer philosophischen Betrachtung von Software bzw. Requirements Engineering kann man durch viele Fragen vollziehen: Was ist der Unterschied zwischen einem Programm und einer Anforderungsspezifikation? Was ist die Natur von Anforderungsspezifika-tionen oder wie entstehen Anforderungen überhaupt? Auch wenn diese Fragen auf den ersten Blick etwas akademisch anmuten, sind sie für die tägliche Arbeit mit Anforderungen sehr wich-tig, da sie unser grundlegendes Verständnis dieser Dinge beleuchten und uns dazu bringen, die-ses in Frage zu stellen.

Philosophie

Liebe zur Weisheit

Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth



Dieser Vortag möchte Sie mitnehmen, auf eine Reise zu einigen dieser philosophischen Fra-gen (und zu möglichen Antworten darauf) und Ihnen Appetit auf das Philosophieren über Re-quirements Engineering machen. Ausgangspunkt unserer Betrachtungen ist die Frage „Was ist eine Anforderungsspezifikation?“

Was ist eine Anforderungsspezifikation?

Die Literatur sagt uns, dass eine Anforderungsspezifikation eine Menge von Anforderungen beschreibt, die basierend auf vordefinierten und projektabhängigen Spezifikationsregeln (ein-

deutig, atomar, etc.) dokumentiert wurde. So weit, so gut. Damit besteht eine Anforde-rungsspezifikation aus einer Menge von An-forderungen. Aber dies führt uns dann schon zur nächsten Frage: „Was ist eine Anforde-rung?“

Zunächst ist eine Anforderung eine Forde-rung, die an ein System gestellt wird. Ebenso kann eine Anforderung auch als Eigenschaft verstanden werden, die dieses System erfül-len soll. Und was ist der Zweck dieses Sys-tems? Allgemein kann man hier sagen, dass der Zweck dieses Systems darin besteht, ein Problem zu lösen. Probleme und Anforderun-gen hängen an sich nicht im luftleeren Raum,

sondern werden von Jemandem gestellt. Im Requirements Engineering wird dieser „Jemand“ typischerweise als Stakeholder bezeichnet. Dieser Stakeholder möchte eine Lösung für sein Problem haben (in unserem Fall ein Software-System). Dieses System ist genau dann eine Lö-sung für sein Problem, wenn es seine Anforderungen an die Lösung erfüllt. Soweit eigentlich nichts Ungewöhnliches. Der bisher beschrieben Sachverhalten ist in Folie 2 dargestellt.

Ein Beispiel ...

Betrachten wir hierzu ein einfaches Beispiel. Nehmen wir an, dass unser Problem darin besteht, den Fahrer eines PKW vor zu gerin-gem Luftdruck in den Reifen seines PKW zu warnen. Die Lösung dieses Problem ist nahe-liegend. Wir messen regelmäßig den Reifen-druck und sobald der Druck eine definierte Schwelle unterschreitet, wird der Fahrer gewarnt. Daraus ergeben sich eine Reihe von Anforderungen, von den drei beispielhaft im oberen Teil der Folie 3 dargestellt sind.

Schaut man sich die dargestellten Anfor-derungen genau an, so erkennt man, dass der

Aspekt der Druckmessung bereits in den An-forderungen enthalten ist. Dies würde bedeu-ten, dass zur Formulierung der Anforderungen Wissen über die Gestalt der Lösung notwendig ist oder anders formuliert: Die Anforderungen hängen von der Gestalt der Lösung (hier Druck-sensoren) ab. Diese Aussage können wir als erste philosophische Erkenntnis über Anforderun-gen festhalten. Um diese Erkenntnis zu überprüfen, wechseln wir versuchsweise das Lösungs-

System

Stakeholder

An was?

Wer?

Zweck?

Problem

Lösung

Warum?

Anforderung Wann?

für

Folie 2 – Problem, Anforderung, Lösung

Folie 3 – Ein Beispiel für Anforderungen

Problem Lösung Anforderung

Fahrer vor zu

geringem

Reifenlu druck

warnen

Reifen-

druck-

messung

Auswertung

von ESP-

Daten

Der Sensor soll den Druck im Bereich

zwischen 0 und 5 Bar mit einer Genauigkeit

von +/-x% messen.

Der Reifendruck soll alle y Sekunden

gemessen werden.

Das ESP-System soll kon nuierlich die

Reifendrehzahl aller vier Räder

überwachen.

Zu geringer Reifendruck liegt vor, wenn

über einen Zeitraum von y Sekunden eine

Abweichen in der Drehzahl eines Reifens

von z% vorliegt.

Die Reifendrehzahl soll mit einer

Genauigkeit von +/-x% gemessen werden.

Zu geringer Reifendruck liegt vor, wenn

der gemessene Druck unter den

Grenzwert z sinkt.




konzept. Anstatt eines Drucksensors kann man sich die Tatsache zu Nutze machen, dass ein Reifen der Luft verliert auch gleichzeitig seinen Durchmesser verringert. Dies hat zur Folge, dass dadurch ein Reifen mit geringerem Luftdruck im Vergleich zu den anderen am PKW mon-tierten Reifen mehr Umdrehungen vollzieht. Dieses Lösungskonzept und die daraus resultie-renden Anforderungen sind im unteren Teil der Folie dargestellt und unterscheiden sich sub-stanziell von den Anforderungen für das Lösungskonzept „Drucksensor“.

Drei Denkkategorien: Problem, Anforderung, Lösung (PAL)

Aus der zuvor beschriebenen Untersuchung des Wortes „Anforderung“ (Folie 2) können wir drei Denkkategorien ableiten:

- Das Problem beschreibt, was in der Welt verändert oder erreicht werden soll. Häufig wird für das Wort „Problem“ auch das Wort „Ziel“ oder „Zweck“ verwendet.

- Die Anforderung(en) beschreiben notwendige Eigenschaften eines Systems zur Lösung eines Problems.

- Die Lösung beschreibt das System, mit dem das Problem gelöst, bzw. das Ziel erreicht oder der Zweck realisiert wird.

Zur Vereinfachung bezeichnen wir diese drei Denkkategorien im Folgenden mit PAL (für Prob-lem, Anforderung, Lösung).

Eigenschaften von PAL und Anwendung von PAL

Betrachtet man PAL genauer, so erkennt man besondere Eigenschaften:

1) Probleme sind unabhängig und hängen damit nicht von Anforderungen oder Lösungen ab. Dies zeigt sich im betrachteten Beispiel daran, dass das Problem durch verschiedenste Lö-sungskonzepte gelöst werden kann.

2) Die Wahl des Lösungskonzeptes bestimmt die Anforderungen, d.h. ändert man das Lösungs-konzept, so ändern sich auch die Anforderungen. Oben haben wir das am Beispiel der Lö-sungskonzepte „Drucksensor“ und „ESP-Daten“ gezeigt.

3) Anforderungen sind Beziehungen zwischen Problem und Lösung. Anforderungen beschrei-ben die notwendigen Eigenschaften, die ein System aufweisen muss, um die Lösung für ein Problem zu sein. Damit stellen Anforde-rungen eine Beziehung zwischen Prob-lem und Lösung her.

Unsere bisherigen Erkenntnisse in Bezug auf PAL scheinen auf den ersten Blick eher aka-demischer Natur zu sein und nicht unbedingt von praktischem Wert zu sein. Dennoch können wir einige interessante Implikatio-nen für den praktischen Umgang mit Anfor-derungen ableiten. Die drei Denkkategorien PAL können zum Beispiel unmittelbar ange-wendet werden, indem eine Aussage (bspw. während eines Anforderungsworkshops) dahingehend interpretiert und geprüft wird, ob und welcher Problem-, Anforderungs- und/oder Lösungsanteil in der Aussage enthalten ist. Betrachten wir hierzu beispielhaft eine Aussage basierend auf dem „Reifendruckbeispiel“ (siehe Folie 4), wie sie in einer typischen Dis-kussion über ein solches System vorkommen kann.

Folie 4 – Analyse mit PAL




PAL erlaubt uns, diese Aussage wie folgt zu interpretieren. Das betrachtete Problem besteht darin, dass der Fahrer sofort einen zu geringen Druck in den Reifen erkennen soll. Das vorge-schlagene Lösungskonzept besteht in einer Anzeige des Reifendrucks, welche kontinuierlich erfolgen soll (Anforderungsanteil). Auch wenn der Anforderungsanteil in diesem Beispiel auf den ersten Blick sehr gering ist (nur das Wort „kontinuierlich“), hat dieser Anforderungsanteil eine große Bedeutung für die Lösung, da der Fahrer nur durch eine kontinuierliche Anzeige sofort einen zu geringen Reifendruck erkennen kann.

PAL ist eine selbstreferenzielle Struktur

Das zuvor betrachtete Beispiel „Warnung vor zu geringem Reifendruck“ (siehe Folie 3) macht bei genauem Hinsehen zwei interessante Annahmen:

1) Es wurde stillschweigend davon ausgegangen, dass Drucksensoren oder ESP-Sensoren in der gewünschten Form existieren und als Lösung verfügbar sind. Sollte dies nicht der Fall sein, so könnte man bspw. auch das Mes-sen des Reifendrucks an sich als Problem ansehen, oder auch die Übertragung der gemessenen Daten vom Reifen zum Sys-tem. Damit würde die im Beispiel ver-wendete Lösung selbst wieder zu einem Problem werden. Oder, um noch genauer zu sein, würde die Lösung in viele weitere (und nicht unbedingt minder schwierige) Probleme zerfallen.

2) Es wurde ebenfalls stillschweigend davon ausgegangen, dass das Problem „Warnung vor zu geringem Reifendruck“ ein festge-

legtes Problem ist. Verwirft man diese Annahme, so ist es leicht vorstellbar, dass die Warnung vor zu geringem Reifendruck die Lösung für ein anderes, übergeordnetes Problem ist. Denkbar ist hier zum Beispiel, dass das Fahrzeug stets eine optimale Straßenla-ge haben soll und hierzu ist ein optimaler Reifendruck zwingend notwendig. Ebenso denk-bar ist aber auch, dass der optimale Reifendruck eingehalten werden soll, um den Ver-schleiß der Reifen zu minimieren.

Es ist leicht vorstellbar, dass man diese ange-deutete Kette von Problemen und Lösungen nach Oben und Unten ins Unendliche fortset-zen könnte. Genauso als ob man in einem un-endlich großen Treppenhaus hinauf- und hin-absteigen kann (Folie 5). Zusammengefasst bedeutet dies für unsere Denkstruktur PAL, dass sie eine selbstreferenzielle Struktur dar-stellt. Der Begriff „selbstreferenziell“ bedeutet in diesem Zusammenhang, dass die Struktur PAL zum einen aus vielen weiteren Substruk-turen der Art PAL besteht und zum anderen auch Teil einer größeren, übergeordneten Struktur der Art PAL ist. Folie 6 soll dies gra-fisch verdeutlichen, zum einen ist ein PAL Teil einer Menge weiterer PAL (oben rechts in der Folie durch ein PAL in Fettschrift). Zum ande-

PAL PAL PAL PAL PAL

PAL PAL PAL PAL PAL

PAL PAL PAL PAL PAL

PAL PAL PAL PAL PAL

PAL PAL PAL PAL PAL

PAL PAL PAL PAL PAL

PAL ... selbstreferenziell

Folie 5 – PAL unendlich?

Folie 6 – PAL ... selbstreferenziell




ren besteht jedes PAL wiederum aus vielen weiteren PAL und diese bestehen wiederum aus vielen weiteren (unteren links in der Folie dargestellt).

Das mit der Unendlichkeit ist ja schon in der Mathematik so eine Sache, aber das wir hier bei der Untersuchung des Wortes „Anforderung“ auf einmal in die Unendlichkeit fallen ist schon etwas verwunderlich? Es drängt sich sofort die Frage auf, ob dies nicht ein Irrweg ist? Das Sprichwort „von Hundertste ins Tausendste“ und seine (zumindest in meiner Arbeit mit Anfor-derungen) häufige Verwendung ist ein Indiz, dass wir es zumindest mit recht komplexen Struk-turen zu tun haben.

Auf der Suche nach dem Anfang von PAL...

Wir haben im vorherigen Abschnitt recht leichtfertig das Wort „Unendlichkeit“ gebraucht und PAL als eine unendliche Struktur bezeichnet. Irgendwie widerspricht diese Unendlichkeit doch den eigenen Erfahrungen in der Arbeit mit Anforderungen und mit Software im Allgemeinen. Zugegeben, dann und wann kommt man wirklich vom Hundertste in Tausendste, aber dennoch werden Systeme gebaut und man verliert sich nicht immer gleich in einer unendlichen Struktur.

Auf der Suche dem Anfang von PAL be-trachten wir nochmal unser Beispiel mit dem Reifendruck. Ausgangspunkt dieses Beispiels war das Problem, dass der Fahrer vor zu ge-ringem Reifendruck gewarnt werden soll. Die-ses Problem könnte man als Lösung für das Problem „Kraftstoffverbrauch reduzieren“ ansehen, welches wiederum als Lösung für das Problem „Kundenattraktivität verbessern“ angesehen werden kann. Diese Kette lässt sich immer weiter fortsetzen, durch höhere Kun-denattraktivität können mehr Autos verkauft werden, wodurch der Profit gesteigert werden kann, usw. Man kann hier immer weiter nach dem Warum oder Wofür fragen. Zum Beispiel „Wofür muss der Profit gesteigert werden?

Um konkurrenzfähig zu bleiben!“ Warum konkurrenzfähig bleiben, um ... usw.

Man sieht leicht ein, dass ein Anfang von PAL nicht in Sicht ist. Vielleicht haben wir aber auf der Suche nach einem Ende von PAL mehr Glück.

... und nach dem Ende von PAL

Steigen wir also noch weiter in die Tiefen von PAL ein und schauen uns ein sehr einfaches und grundlegendes Beispiel an, in der Hoffnung, ein Ende von PAL zu finden: die Multiplikation von zwei Zahlen.

Die Multiplikation von zwei (natürlichen) Zahlen ist eines der einfachsten mathematischen Operationen die wir kennen. Die Multiplikation kann für viele Probleme als Lösung benutzt werden, bspw. um die Fläche eines Rechtecks oder einen Quadrats zu berechnen. Die Definition der Multiplikation ist mathematisch gesehen auch recht einfach und auf Folie 8 oben dargestellt.

Aber halt! Schauen wir uns die Definition noch einmal etwas genauer an. Auf der linken Seite steht die Multiplikation, die wir definieren wollen und auf der rechten Seite steht, wie die Multi-plikation definiert ist (als die a-fache Addition der Zahl b, wenn wir a * b berechnen wollen). Diese Struktur sieht doch sehr verdächtig nach der PAL-Struktur aus. Die zu definierende Multi-

Folie 7 – Auf der Suche nach dem Anfang ....




plikation auf der linken Seite ist das Problem und die Definition durch die Summierung auf der rechten Seite ist die Lösung.

Vergleichbare Strukturen finden sich auch im Programmcode. Der Funktions- oder Me-thodenname kann als linke Seite der Definiti-on und der Programmcode innerhalb kann als rechte Seite der Definition interpretiert wer-den. Für die Multiplikation von zwei Zahlen bietet jede höhere Programmiersprache ei-nen eigenen Operator. Mit Hilfe dieses Opera-tors könnte man die Multiplikation von zwei Zahlen sehr einfach implementieren (siehe Folie 8). Angenommen, dieser interne Multi-plikationsoperator würde nicht existieren, so könnte man die Multiplikation basierend auf der Summendefinition implementieren (un-teres Codebeispiel in Folie 8). Aber selbst hier ist noch nicht das Ende erreicht. Nehmen wir bspw. an, dass wir nur Zahlen im Bereich von 0 bis 5 miteinander multiplizieren wollen, dann könnte man die Funktion mit Hilfe eines zweidimen-sionalen Arrays implementieren und das Ergebnis durch einfaches Auslesen des Arrays be-stimmen (Matrix in Folie 8).

Selbst dieses einfache Beispiel zeigt, dass die Multiplikation von zwei Zahlen als Problem be-trachtet werden kann und, dass viele verschiedene Lösungen existieren. Damit scheint auch hier kein Ende von PAL in Sicht.

Kann man PAL beherrschen?

Ausgehend von den bisher betrachteten Beispielen müssen wir uns wohl damit abfinden, dass PAL unendlich zu sein scheint und weder Anfang noch Ende hat. Aber ist diese Unendlichkeit überhaupt ein Problem? Schließlich werden tagtäglich Systeme gebaut, Anforderungen erhoben und Software programmiert.

Schauen wir uns als Beispiel den Computer mit seiner Software als Struktur an sich an. Auf einer sehr tiefen Ebene finden wir die Schaltkreise und den Strom der in ihnen fließt. Die Stromflüsse in den Schaltkreisen sind eine technische Repräsentation für die logischen Grundeinheiten des Rechners („Wahr“ und „Falsch“). Die Ströme fließen durch Schaltkreise, die wiederrum logische Operationen (bspw. das „logische Und“) dar-stellen und irgendwann zu Registern zusam-mengefasst werden. Diese Register werden dann auf einer höheren Ebene zum Prozessor, zum Speicher und zu vielen anderen Bautei-len des Rechners.

Soweit nichts unbekanntes, sondern viel mehr in Auszügen die typische Struktur eines Com-puters, wie man sie in einer Standardvorlesung im Informatikstudium hört und wie sie in un-zähligen Computer auf der ganzen Welt vorhanden ist. Schon auf dieser tiefen technischen Ebe-ne könnte man die PAL-Struktur anwenden. Zum Beispiel könnte man die Darstellung von Wahr

APIs, Bibliotheken

Hochsprachen

CPUs, RAM

Register true, false

+5 Volt, -5 Volt

Compiler

Betriebssystem

Maschinensprachen

Folie 8 – Multiplikation – Problem oder Lösung?

Folie 9 – Von Volt bis zur API

Problem oder Lösung?

int mult(int a, int b) {

return a*b;

}

0 1 2 3 4 5

0 0 0 0 0 0 0

1 0 1 2 3 4 5

2 0 2 4 6 8 10

3 0 3 6 9 12 15

4 0 4 8 12 16 20

5 0 5 10 15 20 25

int mult(int a, int b) { int result=b;

for (int i=1; i<a; i++) result = result + b

return result; }




und Falsch durch elektrischen Signale als Problem verstehen und die Verwendung bspw. von +5 Volt und -5 Volt als Lösung ansehen.

Klettert man in dieser Struktur weiter nach oben, so gelangt man zu einem etwas anderen Wesen, dem Betriebssystem des Rechners. Das Betriebssystem verwaltet die Betriebsmittel des Rechners (CPU, Speicher, etc.) und steuert die Ausführung der Software auf dem Rechner. Damit könnte man das Betriebssystem als eine Art Vermittler zwischen der Software des Rechners und den technischen Bestandteilen verstehen und damit zugleich als Lösung für das Problem der Rechnerverwaltung. Und schon wieder eine PAL-Struktur. Dass die Entwicklung von Be-triebssystemen an sich auch ein Problem ist, zeigt sich unter anderem schon an der Vielfalt exis-tierender Betriebssysteme (also Lösungen für dieses Problem) und an dem Streit, welches denn nun das bessere sei. Diesen Streit über das „bessere Betriebssystem“ kann man basierend auf PAL als Streit um die Anforderungen interpretieren, die ein Betriebssystem erfüllen soll.

Unmittelbar über dem Betriebssystem finden sich die eigentlichen Programme die auf dem Rechner ausgeführt werden. Diese sind typischer Weise in einer für das jeweilige Betriebssys-tem und den jeweiligen Rechner passenden Maschinensprache encodiert. Erzeugt werden diese Programme in Maschinensprache von einem Compiler, der diese Programme aus einer höheren Programmiersprache in Maschinensprache übersetzt. Auch hier kann man wieder eine PAL-Struktur identifizieren. Die Kombination aus Hochsprache und Compiler kann als Lösung für das Problem der Entwicklung von Programmen in Maschinensprache gesehen werden. Und selbst bei den Hochsprachen ist noch nicht Schluss. Auf Grundlage der höheren Programmier-sprachen werden APIs und Bibliotheken entwickelt, um Funktionalitäten, die häufiger benötigt werden (bspw. Sortierung von Daten, komplexe Datenstrukturen oder grafische Benutzerober-flächen) komfortabel verwenden zu können. Auch hier kann man eine PAL-Struktur erkennen: Das Problem besteht bspw. in der Speicherung einer Folge von Daten und die Lösung besteht in einer verketteten Liste, einem Array oder einer Hashtable.

Sind denn Probleme auch immer echte Probleme?

Wir haben uns jetzt einen Rechner von den Tiefen der Spannung für Wahr und Falsch über das Betriebssystem bis hin zu Hochsprachen und APIs angeschaut. Dabei haben wir eine Reihe von PAL-Strukturen identifiziert oder zumindest existierende Sachverhalte als PAL-Struktur inter-pretiert.

Ein berechtigter Zweifel an den bisherigen Ausführungen wäre doch, dass alle angeführten Beispiele für PAL-Strukturen keine Probleme mehr sind, sondern vielfach gelöst und gut ver-standen sind. Dieser Einwand ist vollkommen korrekt und berechtigt. Die Probleme sind gelöst und in den meisten Fällen denkt man auch gar nicht mehr darüber nach, dass dies mal Probleme waren, da Lösungen für diese Probleme im Wesentlichen verfügbar sind und eine angemessene Qualität haben. Oder kennen Sie jemanden, der für die Entwicklung eines neuen Internetshops die bestehenden Programmiersprachen verwirft und zunächst erst mal eine neue Program-miersprache entwickelt? Ebenso werden sich die wenigsten Nutzer beim Kauf eines neuen PCs Gedanken darüber machen, mit welcher Spannung die CPU betrieben wird.

Einfach gesagt, blenden wir diese Probleme aus bzw. entscheiden uns dafür, dass diese Prob-leme für uns nicht relevant sind und die verfügbaren Lösungen akzeptabel sind. Dies ändert allerdings nichts an der Tatsache, dass die zuvor beschriebenen Strukturen existieren und von jemandem, der mit der Materie vertraut ist, auch benannt und beherrscht werden können. Wir sind so vertraut mit uns verfügbaren Lösungen, dass wir die ihnen zugrundeliegenden Proble-me nicht mehr wahrnehmen. Während ich diesen Text in mein Notebook eingebe, passieren innerhalb dieses Notebooks unendlich komplexe Prozesse, die dazu führen, dass aus meinen Tastenanschlägen die Buchstaben auf dem Bildschirm werden und sie schlussendlich auf dem Papier landen, das Sie gerade lesen. Dabei mache ich mir allerdings keine Gedanken darüber, was wann oder wie genau passiert, ich verwende diese Technik einfach.




Die Informatik kennt für dieses Phänomen den Begriff der Abstraktion. Abstraktion be-deutet so viel wie das bewusste Auslassen von Details oder das Verbergen einer größe-ren Menge Information hinter einer allgemei-neren Information. Damit kann man die zuvor beschriebene Struktur von der Prozessor-spannung bis zur API als eine komplexe Struktur von Abstraktionen beschreiben.

Ein sehr naheliegendes Bild für diesen Zu-sammenhang ist der Eisberg (Folie 10). Jeder PC-Nutzer sitzt bei der Verwendung seines PCs auf einem riesigen Eisberg von Abstrakti-on und der größte Teil dieser Abstraktion ist für die meisten nicht sichtbar und wie beim Eisberg unter Wasser verborgen, wie zum Beispiel die Abläufe im Betriebssystem, die Struktu-ren im Speicher und die Vorgänge in der CPU. Dieses Sitzen auf einem Eisberg ist aber nicht nur auf Nutzer beschränkt. Auch Entwickler von Software machen sich komplexeste Strukturen bei der Erstellung von Software zu nutzen, die nur die wenigsten Entwickler im Detail verstehen, zum Beispiel den Compiler, die APIs und Bibliotheken.

Abstraktionen sind auch immer Entscheidungen

Wichtig in diesem Zusammenhang ist aber eine Erkenntnis, die sich aus der PAL-Struktur ableitet: Die Lösung für ein Problem wird stets durch eine bewusste Entscheidung herbeige-führt. Diese Entscheidung besteht im Wesent-lichen darin, auf einer Ebene der Struktur zu stoppen, nicht tiefer in die Struktur einzutau-chen und die Lösung für ein Problem an ein System zu delegieren bzw. das System für die Lösung zu verwenden. Anders ausgedrückt, wir entscheiden uns bewusst die Struktur an einer Stelle abzuschneiden (Folie 11).

Diese Möglichkeit zur Entscheidung und zur Verwendung bestehender Lösungen für verstandene Probleme ist eine der zentralen

Eigenschaften und Stärken von Software, die wesentlich zum Erfolg von Computern und Soft-waresystemen beigetragen hat. Gleichzeitig sind die Abstraktionsstrukturen aber auch eines der größten Risiken für bestehende Systeme, und zwar dann, wenn das Wissen um die Abstrakti-ons- bzw. PAL-Strukturen dieser Altsysteme verloren gehen und damit Anpassungen und Wei-terentwicklung nahezu unmöglich werden.

Architekturen als Strukturierung für PAL

Gerade haben wir das Wissen um PAL-Strukturen diskutiert und stoßen unmittelbar auf die nächste Frage: Wie wird das Wissen um PAL-Strukturen dokumentiert und wie wird mit diesen Strukturen gearbeitet? Die generelle Antwort aus der Informatik auf die Frage nach Strukturen und Strukturierung wird mit dem Begriff „Architektur“ beantwortet. In der Informatik werden

Entscheidung

Folie 10 – Abstraktionsstrukturen sind Eisberge

Folie 11 – Abstraktion ist immer Entscheidung




bspw. Prozessorarchitektur, Rechnerarchitekturen, IT-Architekturen und auch Software-Architekturen definiert, entwickelt und dokumentiert.

Die einzelnen Einheiten oder Komponenten, die in einer Architektur beschrieben sind, übernehmen typischerweise bestimmte Aufga-ben innerhalb des Systems. Zum Beispiel die Speicherung von Daten, die Kommunikation mit entfernten anderen Systemteilen, die Be-reitstellung einer Schnittstelle zum Nutzer, usw. Im Sinne der PAL-Struktur können damit die Komponenten einer Architektur als Lösun-gen für Probleme interpretiert werden. Im ein-fachsten Fall wäre das zugrundeliegende Prob-lem für eine Architektur das Ausgangsproblem für die Systementwicklung (z.B. das oben genannte Beispiel zur Warnung vor geringem Reifen-druck).

Aber auch die Architekturentwicklung als Disziplin hat Konzepte zur Strukturierung von Ar-chitekturen entwickelt. Besonders bekannte Konzepte sind bspw. die Trennung von fachlichen, funktionalen und technischen Architekturen. Mit Hilfe dieser Konzepte ist es möglich, ein Sys-

tem mit zunehmendem Grad an technologi-schen Bestandteilen zu beschreiben. Wenn wir noch einmal zurück zu unserem Struktur-bild von Rechner und Software gehen (Folie 9), dann könnte man die drei zuvor genannten Architekturkonzepte oberhalb der APIs und Bibliotheken ansiedeln (siehe Folie 13) und ebenfalls als PAL-Struktur interpretieren. Zum Beispiel könnte man die fachliche Architektur als Problemstellung und darauf aufbauend die funktionale Architektur als Lösung interpre-tieren und weiter dann die funktionale Archi-tektur als Problem und die technische Archi-

tektur als Lösung, usw.

PAL und die Automatisierung...

Betrachtet man das vollständige Bild der Rechner bzw. Softwarestrukturen in Kombination mit Architekturen (Folie 13), so lässt sich noch eine interessante Beobachtung machen. Die Struktu-ren hinauf bis zu den APIs und Bibliotheken sind im Wesentlichen vollautomatisiert, bspw. übernimmt ein Compiler nahezu eigenständig die Übersetzung von Hochsprachen in Maschi-nensprachen. Die Struktur oberhalb ist wesentlich geringer automatisiert, da der Mensch im Wesentlichen die (zum großen Teil kreative) Arbeit übernimmt. Zum Beispiel die Entwicklung einer technischen Architektur aus einer funktionalen Architektur.

Nichtsdestotrotz gibt es auch auf diesen Ebenen Bemühungen, den Grad an Automatisierung zu erhöhen. Bekannte Konzepte in diesem Zusammenhang sind Model-Driven Architecture, Codegenerierung, etc. Diese Konzepte sind in Teilbereichen der Softwareentwicklung äußerst erfolgreich, haben aber bei weitem noch nicht den Verbreitungsgrad erreicht, den klassische Compiler für höhere Programmiersprachen erreicht haben.

Die PAL-Struktur kann für diese Beobachtung eine mögliche Erklärung anbieten. Automati-sierung funktioniert dann, wenn das Problem eine große Bedeutung hat, die Anforderungen hinreichend gut verstanden und abgestimmt sind und die entwickelte Lösung einen angemes-

Architekturen als

Strukturierung für PAL

Folie 12 – Strukturen für PAL

Folie 13 – Noch mehr PAL-Strukturen




senen Reifegrad erreicht hat. Zum Beispiel ist das Problem „Erzeugung von Maschinencode“ von großer Bedeutung, die Anforderungen an die Lösung (bspw. Effizienz, etc.) sind gut verstanden und abgestimmt und die Lösungen haben einen hohen Reifegrad erreicht. Wohingegen das Problem einer funktionalen Architektur für Webshop-Anwendungen zwar eine hohe Relevanz hat, aber alleine schon die Anforderungen an ein solches System hochgradig verschieden und gar widersprüchlich sein können.

Was passiert beim Requirements Engineering?

Mit diesem Wissen wollen wir unserer letzten Frage nachgehen, was passiert beim Require-ments Engineering?

Requirements Engineering beinhaltet, dass man sich intensiv mit Anforderungen, ihrer Ana-lyse, ihrer Spezifikation, ihrer Abstimmung etc. befasst. Aufbauend auf unserem neuen Wissen über die PAL-Strukturen können wir allerdings ableiten, dass man Anforderungen nicht isoliert betrachten kann, da Anforderungen stets eine Beziehung zwischen Problem und Lösung dar-stellen. Damit muss man sich im Requirements Engineering in jedem Fall auch mit Problemen beschäftigen. Aber auf der anderen Seite muss man sich auch in jedem Fall mit Lösungen befas-sen, da wir gezeigt haben, dass Anforderungen durch die Lösung bestimmt werden.

Würde damit aber nicht der komplette Entwicklungsprozess in das Requirements Enginee-ring fallen, da Probleme, Anforderungen und Lösung im Requirements Engineering entwickelt werden? Dem ist zum Glück nicht so. Es ist zwar richtig, dass Anforderungen abhängig von der Lösung sind, aber die Lösung muss zur Formulierung der Anforderungen nur festgelegt bzw. entschieden werden, aber nicht im Detail ausgearbeitet oder gar realisiert werden.

Darüber hinaus haben wir die selbstrefe-renzielle Struktur von PAL noch nicht berück-sichtigt, die besagt, dass jede PAL-Struktur selbst wieder aus unzähligen PAL-Strukturen besteht, die selbst wieder aus PAL-Strukturen bestehen, usw.

Das Explorieren oder Erforschen von PAL-Strukturen und damit das Betrachten und Auswählen von Lösungskonzepten kann bis zu einem gewissen Grad dem Requirements Engineering zugerechnet werden. Der bei dieser Exploration in unserem Gehirn ablau-fende Prozess ist vermutlich hochgradig krea-tiv und dynamisch. Ein (für mich) passendes Bild für diesen Prozess ist ein Wirbel von Ideen und Gedanken über Probleme, Lösun-

gen und Anforderungen (Folie 14). An der Basis des Wirbels liegt das Ausgangsproblem, das wir aktuell betrachten und darüber wirbeln verschiedenste Hierarchien von PAL-Strukturen, die mögliche Lösungen für das Ausgangsproblem beschreiben. Dieser Wirbel von Gedanken und Ideen entzieht sich in jedem Fall unserer vollständigen Kontrolle und wird maßgeblich beein-flusst von unserem Erfahrungswissen und spontanen Assoziationen.

Ein kleines Gedankenexperiment ...

Gönnen Sie sich an dieser Stelle doch mal ein kleines Gedankenexperiment. Überlegen Sie sich ein ganz einfaches Problem (kann, muss aber nichts mit Software zu tun haben). Zum Beispiel: „Morgen Mittag um 12 Uhr einen Geschäftspartner in Paris sprechen“. Beobachten Sie sich be-

Folie 14 – Jonglieren und Kontrollieren von PAL

Kontrolle!?




wusst dabei, wie sich verschiedene PAL-Strukturen in Ihrem Kopf entwickeln und formulieren darauf aufbauend die Lösung und mögliche Anforderungen. Eventuell denken Sie daran, das Flugzeug zu nehmen, verwerfen diese Idee aber, da der Weg vom Flughafen zu Ihrem Termin zu weit ist. Oder Sie denken über die Bahn nach und verwerfen diese Idee, da die Zugfahrt zu lange dauert. Alternativ könnten Sie Ihren Geschäftspartner auch anrufen, aber das wäre eventuell zu unpersönlich. Vielleicht käme aber doch eine Videokonferenz in Frage? So oder so ähnlich könn-ten die Gedankenverläufe zum genannten Problem aussehen, aber vielleicht entwickeln Sie noch vollkommen andere Lösungen.

Zusammenfassung ... wohin geht die Reise...

Dies war eine kleine Reise zu philosophischen Fragen rund um das Requirements Engineering. Eigentlich sind wir ja mit der Frage gestartet, was eine Anforderungsspezifikation ist. Wir haben dann aber ziemlich schnell eine einzelne Anforderung untersucht und sind einer Struktur mit dem Namen PAL begegnet, die besagt, dass Anforderungen eine Beziehung zwischen Problem und Lösung beschreiben.

PAL beschreibt eine Form der Abstraktion und hat auf den ersten Blick leider sehr unange-nehme Eigenschaften: Sie ist selbstreferenziell und leider auch irgendwie unendlich. Auf den zweiten Blick sind diese Eigenschaften aber gar nicht so sehr unangenehm, denn wir haben die Möglichkeit, an einem (nahezu) beliebigen Punkt zu stoppen. Des Weiteren haben wir uns ver-schiedene Beispiele (den Rechner an sich und die darauf ausgeführte Software) angeschaut und dort verschiedenste Beispiele für PAL-Strukturen entdeckt.

Schließlich haben wir uns damit beschäftigt, was während des Requirements Engineering passiert: Wir jonglieren mit komplexen Wirbeln von PAL-Strukturen, während wir über Prob-leme, Anforderungen und Lösungen nachdenken. Die in diesem Vortrag vorgestellte PAL-Struktur kann auf viele weitere Aspekte des Requirements Engineering und der Softwareent-wicklung im Allgemeinen angewendet werden. Probieren Sie es einfach aus.

Zum Abschluss noch ein kleines Beispiel dafür, dass Lösungen wirklich stets eine Entschei-dung sind. Die folgende Reihe von Bildern zeigt eine sehr flexible Gießkanne eines nicht näher genannten schwedischen Möbelhauses mit der faszinierenden Eigenschaft, von mehreren Seiten benutzt werden zu können, d.h. es bleibt dem Nutzer der Kanne überlassen, mit welchem Teil der Kanne er oder sie das Problem „Kanne greifen“ und mit welchem er oder sie das Problem „Blumen bewässern“ löst.

Folie 15 – eine sehr flexible Gießkanne

Die PAL-Struktur und ihre vielen Aspekten sollten aber nicht die primäre Erkenntnis aus die-sem Vortrag sein. Dieser Vortrag sollte Ihnen viel mehr aufzeigen, wie schnell man durch eigent-lich sehr einfache Fragen über das Requirements Engineering eine philosophische Ebene er-reicht, die wertvolle Erkenntnisse für die tägliche Arbeit liefert. Halten Sie Ausschau und philosophieren Sie selbst!

Gießkanne?

Gießkanne?

Gießkanne!




Post Skriptum ... ein paar Lesetipps

Haben Sie Appetit auf mehr Philosophie? Nachfolgend noch ein paar Lesetipps:

- Eine schöne und umfassende Einführung in das Gebiet der Philosophie gibt der Wikipedia-Artikel „Philosophie“: http://de.wikipedia.org/wiki/Philosophie

- Eine detaillierte Einführung in das Thema Informatik-Philosophie gibt die Stanford Encyc-lopedia of Philosophy im Artikel „Philosophy of Computer Science“: http://plato.stanford.edu/entries/computer-science

- Wenn Sie mehr über selbstreferenzielle oder unendliche Strukturen erfahren wollen, dann dürfte das Buch „Gödel, Escher, Bach – ein endlos geflochtenes Band“ von Douglas R. Hof-stadter genau das Richtige für Sie sein.

- Wenn Sie lieber über Dinge nachdenken wollen, die Ingenieure tun, dann sollten Sie sich mal das Buch „What Engineers Know and How They Know It: Analytical Studies from Aeronauti-cal History“ von Walter G. Vincenti anschauen.

- Und, für eine äußerst kurzweilige Einführung in Philosophie und Ideengeschichte kann ich Ihnen das Buch „Zen und die Kunst ein Motorrad zu warten“ von Robert M. Pirsig empfeh-len.

Über den Sprecher Dr. Kim Lauenroth ist Software-Architekt bei der adesso AG an der Schnittstelle zwischen An-forderungen und Facharchitektur. Er verfügt über mehr als 10 Jahre Erfahrung im Software und Requirements Engineering in verschiedensten Domänen. Zum Thema RE hält er regelmäßig Vorträge auf internationalen Tagungen und ist Mitglied des International Requirements Engine-ering Board e.V.

Weitere Informationen zur adesso AG sind zu finden unter: http://www.adesso.de

Bildnachweis Folie 1: ©iStockphoto.com/Brigida_Soriano (14696510), Folie 3: ©iStockphoto.com/1MoreCreative (15251741), Folie 5: ©iStockphoto.com/Sashkinw (15994667), Folie 9: ©office.microsoft.com (MP900443152), Folie 10: ©office.microsoft.com (MP900400492), Folie 11: ©office.microsoft.com (MP900433044), Folie 12: ©iStockphoto.com/Sage78 (5437267), Folie 13: ©office.microsoft.com (MP900443152), Folie 14: ©iStockphoto.com/ JamesBrey (11451754), Folie 15: Fotos mit freundlicher Genehmigung von Tim Jonischkat

eine kleine praktische philosophie über das requirements engineering

Technology