Your SlideShare is downloading. ×
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Eine kleine praktische Philosophie über das Requirements Engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Eine kleine praktische Philosophie über das Requirements Engineering

2,215

Published on

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

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,215
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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.dePhilosophie und Requirements Engineering ... geht das zusammen?Mit dem Begriff Philosophie wird eine Viel-zahl verschiedener Dinge assoziiert, daher ist Philosophieeine allgemeine Definition von Philosophie Liebe zur Weisheitsehr schwierig. Generell kann man jedochfesthalten, dass die Philosophie das Ziel ver-folgt, die Dinge in der Welt, die Natur derDinge und ihre Zusammenhänge besser zuverstehen. Dazu gehört insbesondere dasStellen von kritischen und teilweise auch un-angenehmen Fragen. Dieses Streben nachErkenntnis versteckt sich hinter der ur-sprünglichen Bedeutung des Wortes „Philo-sophie“, welches aus dem Altgriechischenstammt 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 sinddoch mit Abstand die präzisesten und am genauesten arbeitenden Maschinen, die es gibt. Dergesamte Computer baut auf den zwei Werten „Wahr“ und „Falsch“ auf. Diese werden durchexakt 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 zentraleElement von Programmen ist recht präzise definiert. Aber, wenn man genauer hinschaut, ist dieBedeutung eines Programms nicht unbedingt präzise definiert. Dies zeigt sich zum Beispiel an der Frage, ob zwei gegeben Programme identisch sind. Mussdazu der Programmcode gleich sein, oder ist es ausreichend, wenn die Programme das Gleichetun? Diese Fragen beziehen sich unmittelbar auf die Natur von Programmen und gehören damitschon zur Philosophie (im Bereich Informatik). Aus diesen und weiteren Fragen hat sich einganzer wissenschaftlicher Zweig entwickelt, die Informatik-Philosophie. Den Schritt in Richtung einer philosophischen Betrachtung von Software bzw. RequirementsEngineering kann man durch viele Fragen vollziehen: Was ist der Unterschied zwischen einemProgramm und einer Anforderungsspezifikation? Was ist die Natur von Anforderungsspezifika-tionen oder wie entstehen Anforderungen überhaupt? Auch wenn diese Fragen auf den erstenBlick 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 isteine Anforderungsspezifikation?“Was ist eine Anforderungsspezifikation?Die Literatur sagt uns, dass eine Anforderungsspezifikation eine Menge von Anforderungenbeschreibt, 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 seinProblem 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 eigentlichnichts Ungewöhnliches. Der bisher beschrieben Sachverhalten ist in Folie 2 dargestellt.Ein Beispiel ...Betrachten wir hierzu ein einfaches Beispiel. AnforderungNehmen wir an, dass unser Problem darin Problem Lösung Der Sensor soll den Druck im Bereichbesteht, 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 messungwarnen. 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 zudruck und sobald der Druck eine definierte geringem Grenzwert z sinkt.Schwelle unterschreitet, wird der Fahrer Reifenlu druck Das ESP-System soll kon nuierlich diegewarnt. 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- Datenderungen genau an, so erkennt man, dass der von z% vorliegt.Aspekt der Druckmessung bereits in den An- Folie 3 – Ein Beispiel für Anforderungenforderungen enthalten ist. Dies würde bedeu-ten, dass zur Formulierung der Anforderungen Wissen über die Gestalt der Lösung notwendigist 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 einReifen 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 wirdrei 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 PALBetrachtet 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 aufPAL scheinen auf den ersten Blick eher aka-demischer Natur zu sein und nicht unbedingtvon praktischem Wert zu sein. Dennochkönnen wir einige interessante Implikatio-nen für den praktischen Umgang mit Anfor-derungen ableiten. Die drei DenkkategorienPAL 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 PALob und welcher Problem-, Anforderungs-und/oder Lösungsanteil in der Aussage enthalten ist. Betrachten wir hierzu beispielhaft eineAussage 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 bestehtdarin, 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 kontinuierlicherfolgen soll (Anforderungsanteil). Auch wenn der Anforderungsanteil in diesem Beispiel aufden ersten Blick sehr gering ist (nur das Wort „kontinuierlich“), hat dieser Anforderungsanteileine große Bedeutung für die Lösung, da der Fahrer nur durch eine kontinuierliche Anzeigesofort einen zu geringen Reifendruck erkennen kann.PAL ist eine selbstreferenzielle StrukturDas zuvor betrachtete Beispiel „Warnung vor zu geringem Reifendruck“ (siehe Folie 3) machtbei 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 ausvielen weiteren (unteren links in der Folie dargestellt). Das mit der Unendlichkeit ist ja schon in der Mathematik so eine Sache, aber das wir hier beider Untersuchung des Wortes „Anforderung“ auf einmal in die Unendlichkeit fallen ist schonetwas verwunderlich? Es drängt sich sofort die Frage auf, ob dies nicht ein Irrweg ist? DasSprichwort „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 undPAL als eine unendliche Struktur bezeichnet. Irgendwie widerspricht diese Unendlichkeit dochden eigenen Erfahrungen in der Arbeit mit Anforderungen und mit Software im Allgemeinen.Zugegeben, dann und wann kommt man wirklich vom Hundertste in Tausendste, aber dennochwerden 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 aufder Suche nach einem Ende von PAL mehr Glück.... und nach dem Ende von PALSteigen wir also noch weiter in die Tiefen von PAL ein und schauen uns ein sehr einfaches undgrundlegendes Beispiel an, in der Hoffnung, ein Ende von PAL zu finden: die Multiplikation vonzwei Zahlen. Die Multiplikation von zwei (natürlichen) Zahlen ist eines der einfachsten mathematischenOperationen die wir kennen. Die Multiplikation kann für viele Probleme als Lösung benutztwerden, bspw. um die Fläche eines Rechtecks oder einen Quadrats zu berechnen. Die Definitionder 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 Seitesteht 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 derrechten Seite ist die Lösung. Vergleichbare Strukturen finden sich auchim 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 0nen 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 10Zahlen sehr einfach implementieren (siehe 3 0 3 6 9 12 15 4 0 4 8 12 16 20Folie 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 aufder Summendefinition implementieren (un- Folie 8 – Multiplikation – Problem oder Lösung?teres Codebeispiel in Folie 8). Aber selbst hierist noch nicht das Ende erreicht. Nehmen wir bspw. an, dass wir nur Zahlen im Bereich von 0 bis5 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 hierkein Ende von PAL in Sicht.Kann man PAL beherrschen?Ausgehend von den bisher betrachteten Beispielen müssen wir uns wohl damit abfinden, dassPAL 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 erhobenund 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 WahrVortrag 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 +5Volt und -5 Volt als Lösung ansehen. Klettert man in dieser Struktur weiter nach oben, so gelangt man zu einem etwas anderenWesen, dem Betriebssystem des Rechners. Das Betriebssystem verwaltet die Betriebsmittel desRechners (CPU, Speicher, etc.) und steuert die Ausführung der Software auf dem Rechner. Damitkönnte man das Betriebssystem als eine Art Vermittler zwischen der Software des Rechnersund den technischen Bestandteilen verstehen und damit zugleich als Lösung für das Problemder 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 dennnun das bessere sei. Diesen Streit über das „bessere Betriebssystem“ kann man basierend aufPAL als Streit um die Anforderungen interpretieren, die ein Betriebssystem erfüllen soll. Unmittelbar über dem Betriebssystem finden sich die eigentlichen Programme die auf demRechner ausgeführt werden. Diese sind typischer Weise in einer für das jeweilige Betriebssys-tem und den jeweiligen Rechner passenden Maschinensprache encodiert. Erzeugt werden dieseProgramme in Maschinensprache von einem Compiler, der diese Programme aus einer höherenProgrammiersprache in Maschinensprache übersetzt. Auch hier kann man wieder eine PAL-Struktur identifizieren. Die Kombination aus Hochsprache und Compiler kann als Lösung fürdas Problem der Entwicklung von Programmen in Maschinensprache gesehen werden. Undselbst 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ötigtwerden (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 ineiner 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 dasBetriebssystem bis hin zu Hochsprachen und APIs angeschaut. Dabei haben wir eine Reihe vonPAL-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ührtenBeispiele 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östund in den meisten Fällen denkt man auch gar nicht mehr darüber nach, dass dies mal Problemewaren, da Lösungen für diese Probleme im Wesentlichen verfügbar sind und eine angemesseneQualität haben. Oder kennen Sie jemanden, der für die Entwicklung eines neuen Internetshopsdie bestehenden Programmiersprachen verwirft und zunächst erst mal eine neue Program-miersprache entwickelt? Ebenso werden sich die wenigsten Nutzer beim Kauf eines neuen PCsGedanken 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 ändertallerdings nichts an der Tatsache, dass die zuvor beschriebenen Strukturen existieren und vonjemandem, der mit der Materie vertraut ist, auch benannt und beherrscht werden können. Wirsind 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, passiereninnerhalb dieses Notebooks unendlich komplexe Prozesse, die dazu führen, dass aus meinenTastenanschlägen die Buchstaben auf dem Bildschirm werden und sie schlussendlich auf demPapier 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änomenden Begriff der Abstraktion. Abstraktion be-deutet so viel wie das bewusste Auslassenvon Details oder das Verbergen einer größe-ren Menge Information hinter einer allgemei-neren Information. Damit kann man die zuvorbeschriebene Struktur von der Prozessor-spannung bis zur API als eine komplexeStruktur von Abstraktionen beschreiben. Ein sehr naheliegendes Bild für diesen Zu-sammenhang ist der Eisberg (Folie 10). JederPC-Nutzer sitzt bei der Verwendung seinesPCs auf einem riesigen Eisberg von Abstrakti-on und der größte Teil dieser Abstraktion ist Folie 10 – Abstraktionsstrukturen sind Eisbergefür die meisten nicht sichtbar und wie beimEisberg 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 nurauf Nutzer beschränkt. Auch Entwickler von Software machen sich komplexeste Strukturen beider 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 zentralenEigenschaften und Stärken von Software, die wesentlich zum Erfolg von Computern und Soft-waresystemen beigetragen hat. Gleichzeitig sind die Abstraktionsstrukturen aber auch eines dergröß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 PALGerade haben wir das Wissen um PAL-Strukturen diskutiert und stoßen unmittelbar auf dienächste Frage: Wie wird das Wissen um PAL-Strukturen dokumentiert und wie wird mit diesenStrukturen gearbeitet? Die generelle Antwort aus der Informatik auf die Frage nach Strukturenund Strukturierung wird mit dem Begriff „Architektur“ beantwortet. In der Informatik werdenVortrag 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 alsdie in einer Architektur beschrieben sind,übernehmen typischerweise bestimmte Aufga- Strukturierung für PALben innerhalb des Systems. Zum Beispiel dieSpeicherung von Daten, die Kommunikationmit entfernten anderen Systemteilen, die Be-reitstellung einer Schnittstelle zum Nutzer,usw. Im Sinne der PAL-Struktur können damitdie 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 PALlem für eine Architektur das Ausgangsproblemfü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-StrukturenPAL und die Automatisierung...Betrachtet man das vollständige Bild der Rechner bzw. Softwarestrukturen in Kombination mitArchitekturen (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 imWesentlichen die (zum großen Teil kreative) Arbeit übernimmt. Zum Beispiel die Entwicklungeiner technischen Architektur aus einer funktionalen Architektur. Nichtsdestotrotz gibt es auch auf diesen Ebenen Bemühungen, den Grad an Automatisierungzu erhöhen. Bekannte Konzepte in diesem Zusammenhang sind Model-Driven Architecture,Codegenerierung, etc. Diese Konzepte sind in Teilbereichen der Softwareentwicklung äußersterfolgreich, haben aber bei weitem noch nicht den Verbreitungsgrad erreicht, den klassischeCompiler 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 Anforderungenhinreichend 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“ vongroßer Bedeutung, die Anforderungen an die Lösung (bspw. Effizienz, etc.) sind gut verstandenund abgestimmt und die Lösungen haben einen hohen Reifegrad erreicht. Wohingegen dasProblem einer funktionalen Architektur für Webshop-Anwendungen zwar eine hohe Relevanzhat, aber alleine schon die Anforderungen an ein solches System hochgradig verschieden undgar 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 isoliertbetrachten 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 Problemenbeschä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 entwickeltwerden? Dem ist zum Glück nicht so. Es ist zwar richtig, dass Anforderungen abhängig von derLö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 wiraktuell betrachten und darüber wirbeln verschiedenste Hierarchien von PAL-Strukturen, diemögliche Lösungen für das Ausgangsproblem beschreiben. Dieser Wirbel von Gedanken undIdeen 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 sichein 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 formulierendarauf aufbauend die Lösung und mögliche Anforderungen. Eventuell denken Sie daran, dasFlugzeug zu nehmen, verwerfen diese Idee aber, da der Weg vom Flughafen zu Ihrem Termin zuweit ist. Oder Sie denken über die Bahn nach und verwerfen diese Idee, da die Zugfahrt zu langedauert. Alternativ könnten Sie Ihren Geschäftspartner auch anrufen, aber das wäre eventuell zuunpersö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 Sienoch 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 habendann aber ziemlich schnell eine einzelne Anforderung untersucht und sind einer Struktur mitdem Namen PAL begegnet, die besagt, dass Anforderungen eine Beziehung zwischen Problemund 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 denzweiten Blick sind diese Eigenschaften aber gar nicht so sehr unangenehm, denn wir haben dieMö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 unddort verschiedenste Beispiele für PAL-Strukturen entdeckt. Schließlich haben wir uns damit beschäftigt, was während des Requirements Engineeringpassiert: 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ähergenannten schwedischen Möbelhauses mit der faszinierenden Eigenschaft, von mehreren Seitenbenutzt werden zu können, d.h. es bleibt dem Nutzer der Kanne überlassen, mit welchem Teilder 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 undphilosophieren 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 LesetippsHaben 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 SprecherDr. 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 undRequirements Engineering in verschiedensten Domänen. Zum Thema RE hält er regelmäßigVorträ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.deBildnachweisFolie 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 JonischkatVortrag im Rahmen der SOPHIST Days 2011 Seite 12 von 12

×