Abstraktion als Denkwerkzeug für das Requirements Engineering

29. Oktober 2013Dr. Kim Lauenroth

Um das Wort Abstraktion kommt man in der Softwarebranche kaum herum. Abstrakte Klassen und abstrakte Datentypen sind nur zwei Stichworte in diesem Universum. An dieser Stelle möchte ich aber von einer anderen Seite auf Abstraktion schauen und zeigen, dass dieser Begriff nicht nur für die Programmierung, sondern auch im Requirements Engineering ein wichtiges Denkwerkzeug ist.

Aber zunächst einmal zum Wort „Abstraktion“ an sich, welches ja selbst schon reichlich abstrakt ist. Ganz allgemein definiert ist Abstraktion das Prinzip der Reduktion oder Verallgemeinerung. Aber auch diese Definition ist nicht wirklich förderlich. Ein Blick in die Literatur hilft an dieser Stelle, etwas Licht ins Dunkel zu bringen. Timothy Colburn und Gary Shute unterscheiden in ihrem Artikel „Abstraction in Computer Science“1 zwei Arten der Abstraktion:

  • Vergessende Abstraktion (Information Neglect): Die verborgene Information geht verloren.
  • Verbergende Abstraktion (Information Hiding): Die verborgene Information kann wiederhergestellt werden.

Die vergessende Abstraktion ist nach Colburn und Shute die Abstraktion der Mathematik. Als Beispiel führen sie die Gruppentheorie der Mathematik an, bei der es darum geht, das Rechnen mit Zahlen zu verallgemeinern.

Die verbergende Abstraktion ist die Abstraktion der Informatik und für uns die viel interessantere Art, denn hier geht Information nicht verloren, sondern wird wiederherstellbar verborgen. Die besondere Macht dieses Konzeptes entsteht durch das unscheinbare Wort „wiederherstellbar“, denn ich habe zu jedem Zeitpunkt die Möglichkeit, die verborgene Information wieder hervorzuholen und sie mir anzuschauen. So erzeugt die verbergende Abstraktion eine eindeutige Grenze zwischen dem abstrahierten Inhalt und dem darauf bezogenen abstrakten Gegenstand. Programmiersprachen nutzen diese Form der Abstraktion beispielsweise bei der Definition von Methoden (oder Funktionen), um den Umfang komplizierter Implementierungen zu reduzieren.

Wie hilft mir der Abstraktionsgedanke beim Requirements Engineering? Das Ziel des Requirements Engineerings besteht ja darin, soviel Wissen über ein geplantes System zu erarbeiten, dass das mit diesem Wissen konstruierte System den Wünschen der Stakeholder (Kunden) entspricht. Stellen wir uns vor, unsere Aufgabe besteht darin, ein Sicherheitssystem für Pkws zu bauen. Unser Auftraggeber hat das System in wenigen Sätzen wie folgt umrissen:

Ein Pkw fährt auf einer Straße im Feierabendverkehr. Das erste Fahrzeug einer Kolonne von Pkws bremst scharf ab, da ein Kind auf die Straße springt. Die nachfolgenden Fahrzeuge werden unmittelbar durch ein Funksignal über die Notbremsung informiert und leiten ebenfalls automatisch ein Notbremsmanöver ein. Das Kind bleibt unverletzt und es passiert kein Auffahrunfall.

Die ersten beiden Sätze und der letzte Satz besagen, dass das geplante System Auffahrunfälle bei spontanen Bremsmanövern im Straßenverkehr verhindern soll. Erst einmal eine gute Idee. Realisiert werden soll diese Idee über eine Funkverbindung zwischen den Fahrzeugen einer Kolonne, die ein automatisches Notbremsmanöver auslösen kann. Klingt eigentlich auch recht plausibel.

Beim Lesen des Textes stolpert man aber irgendwie über zwei Stellen. Zum einen über „ein Funksignal“ und zum anderen über „automatisch ein Notbremsmanöver“. Das Funksignal ist doch etwas eher technisches und das Wort „automatisch“ impliziert eine mysteriöse Maschine, die im Hintergrund etwas tut. Konzeptuell hat unser Beispieltext eine Reihe von Abstraktionsbrüchen, das heißt, er bewegt sich auf verschiedenen inhaltlichen Ebenen.

Formulieren wir den Text ein wenig um, beispielsweise so:

Ein Pkw fährt auf einer Straße im Berufsverkehr. Das erste Fahrzeug einer Kolonne von Pkws bremst scharf ab, da ein Kind auf die Straße springt. Die nachfolgenden Fahrzeuge werden unmittelbar über die Notbremsung informiert und können dadurch rechtzeitig abbremsen. Das Kind bleibt unverletzt und es passiert kein Auffahrunfall. Die Information über die Notbremsung wird über ein Funksignal übertragen. Das rechtzeitige Bremsen kann durch ein dediziertes automatisches Notbremssystem realisiert werden.

Jetzt liest sich der Text auf einmal ganz anders. Aber warum funktioniert dieser nun aus Sicht des Requirements Engineerings besser als der erste Text? Der zweite Text strukturiert die Gedanken wesentlich stärker und stellt die für das geplante System relevanten Konzepte wesentlich deutlicher dar. Jede Aussage (beziehungsweise jeder Satz im Text) bewegt sich auf einer bestimmten Abstraktionsebene. Beispielsweise wird zuerst davon gesprochen, dass die Information über das Notbremssignal übertragen werden muss. Erst später wird diese abstrakte Aussage (Übertragung der Information) durch die Idee des Funksignals konkretisiert.

Zu Recht kann man jetzt einwenden, dass sich solche Konzepte anhand von Beispielen immer gut illustrieren lassen und auch plausibel sind. Aber wie bekommt man das jetzt in die eigene Arbeit übertragen? Für meine tägliche Arbeit als Requirements Engineer nutze ich diese Idee in Form eines einfachen Denkwerkzeugs. Ich versuche meine Gedanken und Konzepte anhand von drei prinzipiellen Abstraktionsebenen zu strukturieren:

  • Kontext: System als Blackbox; Beziehung zur Umgebung steht im Fokus
  • System: Aufbau des Systems mit logischen Einheiten
  • Technologie: Aufbau des Systems mit technischen Einheiten

Jede dieser Ebenen definiert eine Grenze, die ich beim Arbeiten (also beim Nachdenken über Softwaresysteme) möglichst einhalte und mit denen ich bestimmte Informationen über ein geplantes System bewusst verbergen kann. Beispielsweise versuche ich ein System zuerst auf der Ebene des Kontextes zu verstehen: Wie ist das System in die Umgebung eingebettet? Erst wenn ich auf der Kontextebene ein ausreichendes Verständnis erlangt habe, kann ich über den logischen Aufbau und ggf. auch über Technologien sprechen und diese spezifizieren.

Auf den ersten Blick könnte man an dieser Stelle ein Top-Down-Vorgehen oder sogar ein verstecktes Wasserfallmodell vermuten. Das trifft definitiv nicht zu, denn es geht mir primär um das Strukturieren der eigenen Gedanken über ein geplantes System. In Gesprächen mit Stakeholdern finde ich beinahe täglich Situationen wie im obigen Beispiel vor. Äußert ein Stakeholder beispielsweise die Idee mit dem Funksignal, dann kann ich dies in die Ebene „Technologie“ einsortieren und nachfragen, welche Information von wo nach wo übertragen wird. Auf diese Weise abstrahiere ich von der Technologie und bewege die Diskussion auf die Systemebene. Die Information über das Funksignal wird in dieser Diskussion natürlich nicht vergessen, sondern nur verborgen und erneut betrachtet, wenn die Kommunikation auf der höheren Abstraktionsebene verstanden ist.

Nehmen wir in unserem fiktiven Projekt einmal an, dass wir die zwischen den Fahrzeugen der Kolonne zu übertragenen Informationen verstanden haben und jetzt über die technische Umsetzung nachdenken. Nun können wir uns dem zuvor verborgenen Gedanken des Funksignals zuwenden. Es geht also darum, sich die Kommunikation zwischen „Fahrzeugen innerhalb einer Kolonne“ vorzustellen. „Innerhalb einer Kolonne“ impliziert jetzt aber, dass die Kommunikation gerichtet ist. Ein Funksignal ist nicht zwangsläufig gerichtet, sondern geht erst mal in alle Richtungen. Daher müsste man darüber nachdenken, wie verhindert wird, dass ein Funksignal auf einmal alle Fahrzeuge im Umkreis von 100 Metern zum stehen bringt. Sicherlich würde auch so der Auffahrunfall verhindert, aber irgendwie würde das System dann doch über sein Ziel hinausschießen.

Unterm Strich hilft mir dieses kleine Denkwerkzeug dabei, meine Gedanken zu strukturieren und die für den Moment unwichtigen Informationen im Hinterkopf zu verbergen. So kann ich auf einer Ebene arbeiten und auf einer anderen ein vollständiges Bild des geplanten Systems erhalten. Wichtig ist dabei aber immer, dass die Information nur verborgen ist und ich zu einem späteren Zeitpunkt die Zusammenhänge zu den verborgenen Informationen (zwischen den Ebenen) herstellen muss, damit das geplante System auch realisiert werden kann.

Finden Sie so ein Vorgehen hilfreich? Wie lösen Sie abstrakte Anforderungen in Ihrem Arbeitsalltag? Ich freue mich sehr auf Ihr Feedback und Ihre Gedanken zum Thema.

  1. Siehe: T. Colburn, G. Shute, Abstraction in Computer Science, Minds & Machines, Vol. 17, S. 169–184, 2007.
Dr. Kim Lauenroth Dr. Kim Lauenroth ist Chief Requirements Engineer bei adesso und verfügt über mehr als 10 Jahre Erfahrung im Software und Requirements Engineering in verschiedensten Domänen. Er spricht regelmäßig zum Thema RE auf internationalen Tagungen und engagiert sich an Hochschulen und im IREB e.V. für die Aus- und Weiterbildung im Requirements Engineering.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: