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

1. Eine kleine praktische Philosophie
über das Requirements Engineering
oder
„Was ist das überhaupt, eine Anforderungsspezifikation?“
Kim Lauenroth
adesso AG, Stockholmer Allee 24, 44269 Dortmund
kim.lauenroth@adesso.de
Philosophie und Requirements Engineering ... geht das zusammen?
Mit dem Begriff Philosophie wird eine Viel-
zahl verschiedener Dinge assoziiert, daher ist Philosophie
eine allgemeine Definition von Philosophie Liebe zur Weisheit
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. Folie 1 – Philosophie ist Liebe zur Weisheit
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.
Vortrag im Rahmen der SOPHIST Days 2011 Seite 1 von 12

2. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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
Warum?
weit, so gut. Damit besteht eine Anforde-
Problem Stakeholder rungsspezifikation aus einer Menge von An-
forderungen. Aber dies führt uns dann schon
Wer?
zur nächsten Frage: „Was ist eine Anforde-
Wann?
rung?“
für
Anforderung Zunächst ist eine Anforderung eine Forde-
rung, die an ein System gestellt wird. Ebenso
An was? kann eine Anforderung auch als Eigenschaft
Zweck? verstanden werden, die dieses System erfül-
len soll. Und was ist der Zweck dieses Sys-
Lösung System
tems? Allgemein kann man hier sagen, dass
der Zweck dieses Systems darin besteht, ein
Folie 2 – Problem, Anforderung, Lösung 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.
Anforderung
Nehmen wir an, dass unser Problem darin Problem Lösung
Der Sensor soll den Druck im Bereich
besteht, den Fahrer eines PKW vor zu gerin- zwischen 0 und 5 Bar mit einer Genauigkeit Reifen-
von +/-x% messen. druck-
gem Luftdruck in den Reifen seines PKW zu Der Reifendruck soll alle y Sekunden messung
warnen. Die Lösung dieses Problem ist nahe- gemessen werden.
liegend. Wir messen regelmäßig den Reifen- Zu geringer Reifendruck liegt vor, wenn
der gemessene Druck unter den
Fahrer vor zu
druck und sobald der Druck eine definierte geringem
Grenzwert z sinkt.
Schwelle unterschreitet, wird der Fahrer Reifenlu druck Das ESP-System soll kon nuierlich die
gewarnt. Daraus ergeben sich eine Reihe von warnen Reifendrehzahl aller vier Räder
überwachen.
Anforderungen, von den drei beispielhaft im Die Reifendrehzahl soll mit einer
Genauigkeit von +/-x% gemessen werden.
oberen Teil der Folie 3 dargestellt sind.
Zu geringer Reifendruck liegt vor, wenn Auswertung
über einen Zeitraum von y Sekunden eine
Schaut man sich die dargestellten Anfor- Abweichen in der Drehzahl eines Reifens von ESP-
Daten
derungen genau an, so erkennt man, dass der von z% vorliegt.
Aspekt der Druckmessung bereits in den An- Folie 3 – Ein Beispiel für Anforderungen
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-
Vortrag im Rahmen der SOPHIST Days 2011 Seite 2 von 12

3. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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, Folie 4 – Analyse mit PAL
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.
Vortrag im Rahmen der SOPHIST Days 2011 Seite 3 von 12

4. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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 Folie 5 – PAL unendlich?
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-
PAL PAL PAL PAL PAL
PAL PAL PAL PAL PAL deutete Kette von Problemen und Lösungen
PAL PAL PAL PAL PAL nach Oben und Unten ins Unendliche fortset-
PAL PAL PAL PAL PAL zen könnte. Genauso als ob man in einem un-
PAL PAL PAL PAL PAL endlich großen Treppenhaus hinauf- und hin-
PAL PAL PAL PAL PAL
absteigen kann (Folie 5). Zusammengefasst
PAL ... selbstreferenziell 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
Folie 6 – PAL ... selbstreferenziell einer Menge weiterer PAL (oben rechts in der
Folie durch ein PAL in Fettschrift). Zum ande-
Vortrag im Rahmen der SOPHIST Days 2011 Seite 4 von 12

5. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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
Folie 7 – Auf der Suche nach dem Anfang .... 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-
Vortrag im Rahmen der SOPHIST Days 2011 Seite 5 von 12

6. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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 int mult(int a, int b) {
return a*b;
rechte Seite der Definition interpretiert wer- }
int mult(int a, int b) {
den. Für die Multiplikation von zwei Zahlen int result=b;
0 1 2 3 4 5 for (int i=1; i<a; i++)
bietet jede höhere Programmiersprache ei- result = result + b
0 0 0 0 0 0 0
nen eigenen Operator. Mit Hilfe dieses Opera- 1 0 1 2 3 4 5 }
return result;
tors könnte man die Multiplikation von zwei 2 0 2 4 6 8 10
Zahlen sehr einfach implementieren (siehe 3 0 3 6 9 12 15
4 0 4 8 12 16 20
Folie 8). Angenommen, dieser interne Multi-
plikationsoperator würde nicht existieren, so
5 0 5 10 15 20 25
Problem oder Lösung?
könnte man die Multiplikation basierend auf
der Summendefinition implementieren (un- Folie 8 – Multiplikation – Problem oder Lösung?
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
APIs, Bibliotheken
Hochsprachen
sind eine technische Repräsentation für die
Compiler logischen Grundeinheiten des Rechners
Maschinensprachen („Wahr“ und „Falsch“). Die Ströme fließen
Betriebssystem durch Schaltkreise, die wiederrum logische
CPUs, RAM Operationen (bspw. das „logische Und“) dar-
Register
true, false
stellen und irgendwann zu Registern zusam-
+5 Volt, -5 Volt mengefasst werden. Diese Register werden
dann auf einer höheren Ebene zum Prozessor,
zum Speicher und zu vielen anderen Bautei-
Folie 9 – Von Volt bis zur API 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
Vortrag im Rahmen der SOPHIST Days 2011 Seite 6 von 12

7. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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.
Vortrag im Rahmen der SOPHIST Days 2011 Seite 7 von 12

8. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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 Folie 10 – Abstraktionsstrukturen sind Eisberge
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
Entscheidung einer Stelle abzuschneiden (Folie 11).
Diese Möglichkeit zur Entscheidung und
Folie 11 – Abstraktion ist immer Entscheidung 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
Vortrag im Rahmen der SOPHIST Days 2011 Seite 8 von 12

9. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
bspw. Prozessorarchitektur, Rechnerarchitekturen, IT-Architekturen und auch Software-
Architekturen definiert, entwickelt und dokumentiert.
Die einzelnen Einheiten oder Komponenten, Architekturen als
die in einer Architektur beschrieben sind,
übernehmen typischerweise bestimmte Aufga-
Strukturierung für PAL
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- Folie 12 – Strukturen für PAL
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.
Folie 13 – Noch mehr PAL-Strukturen
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-
Vortrag im Rahmen der SOPHIST Days 2011 Seite 9 von 12

10. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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
Kontrolle!? 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
Folie 14 – Jonglieren und Kontrollieren von PAL
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-
Vortrag im Rahmen der SOPHIST Days 2011 Seite 10 von 12

11. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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.
Gießkanne?
Gießkanne? Gießkanne!
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!
Vortrag im Rahmen der SOPHIST Days 2011 Seite 11 von 12

12. Eine kleine praktische Philosophieüber das Requirements Engineering oder Kim Lauenroth
„Was ist das überhaupt, eine Anforderungsspezifikation?“
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
Vortrag im Rahmen der SOPHIST Days 2011 Seite 12 von 12