Eine interdisziplinäre Retrospektive von RE

Bericht von meinem Vortrag an der TUM

Am 13. April 2010 habe ich einen Vortrag bei “Hot Spots der Software-Entwicklung 2010” gehalten zum Thema:

Requirements Engineering (RE) in Kleinen und Mittleren Unternehmen

Die Veranstaltung wurde von der TU München in Zusammenarbeit mit BICC-NET und VSEK organisiert.

Bei der Ausarbeitung des Vortrages hat mich unser Experte für Requirement Engineering, Michael Greulich und Johannes Naumann bei der Graphik unterstützt. Herzlichen Dank an Michael für seine wertvollen Beiträge und an Johannes für die schönen [download#77].

Motto des Vortrages war:

Reden über Probleme macht die Probleme größer.
Reden über Lösungen macht die Lösungen größer.

Dieser “große Seufzer” hat mich über Twitter erreicht. Autor des Tweets war ein geplagter Mensch aus unserer Branche.

Der Satz hat mich nachdenklich gemacht. Wünschen wir uns nicht, dass wenn wir über Probleme reden, diese dann auch kleiner werden? Und ist es nicht gerade im Mittelstand so, dass wir uns effiziente, einfache, kleine, smarte und vielleicht sogar schöne Lösungen wünschen. Und keine Riesensysteme, die uns letzten Endes dazu zwingen, unsere Prozesse ihren systemischen Vorgaben und Einschränkungen zu unterwerfen?

Ich habe den Vortrag in drei Teile gegliedert:

1. Persönliche Erfahrungen
   Hier berichte ich drei Beispiele aus unterschiedlichen Epochen meines IT-Lebens.
2. Terminologie
   und Einordnung der Begriffe zu agilen Technologien wie SCRUM oder KANBAN.
   Auch auf Tagungen und auch in Vorträgen immer wieder eine klare Definition der Begriffe Requirement Engineering (RE), Fachliche Architektur (FA) und Requirement Management (RM).
3. Eine Aufzählung von notwendigen oder nützlichen interdisziplinären Qualitäten für RE.

Zum Lesen empfehle ich vor allem das dritte Kapitel.

1. Persönliche Erfahrungen

Das Thema RE hat mich lebenslang in meinen Projekten begleitet. Hier drei exemplarische Beispiele:

• Entwicklung von Betriebssystemen:
  In der zweiten Hälfte der 70iger Jahre habe ich bei Siemens in der Systemtechnologie (UB D DF 131) gearbeitet. Beschäftigt war ich im Labor für Transdata. und SNA (System Network Architecture). Mein erstes Projekt war die Einführung von “Logischen Verbindungen” in Transdata. Das Projekt wurde “Connection Handling” genannt.
  Als Antwort auf meine Frage, für welchen Zweck wir diese logische Verbindungen entwickeln sollen, war: Weil IBM in SNA (System Network Architecture) das auch macht. Im Sinne von RE ist dies eine zwar einleuchtende aber nicht ganz befriedigende Antwort. In der Tat haben wir dann im folgenden eine eigene Lösung für Transdata entwickelt, mit einem dynamischen und prädefinierten Connection Handling, das uns viele Vorteile bei Projekten beschert hat.
• Anwendungsprojekt
  Um 1980 haben wir bei Softlab (heute Cirquent) eine Ausschreibung der Deutschen Bundesbank gewonnen. Es ging um die “2. Automatisierungsstufe”. Natürlich hatten wir von den Wünschen unseres Kunden keine Ahnung. Wir mussten allerdings schnell feststellen, dass auch der Kunde selbst nicht in der Lage war, seine Anforderungen präzise zu definieren.
  Mit S/E/TEC (Software Entwicklung-Technologie von Softlab) hatten wir ein Werkzeug, dass uns auf PetMaestro ermöglichte, graphische Programmabläufe zu dokumentieren. Aus der Not machten wir eine Tugend. Zahlreiche Beamte wurden bei Softlab für S/E/TEC ausgebildet und haben dann ihre kommerziellen Ziele zu Papier gebracht. In dieser Phase des Projektes haben wir durch Kurse und Unterstützung beim RE exzellent verdient. 1981 bekamen wir dann die Quittung: Die Übergabe der Systembeschreibung erfolgte durch einen LKW voll Papier. Viel Geld verdient mit Trainings, Ergebnis war ein LKW voller Papier, in meiner Erinnerung mindestens ein 7,5-Tonner.
  Aus dem Projekt wurde im ersten Anlauf natürlich nichts, allerdings wurden so sehr wertvolle Erfahrungen gesammelt.
• Moderne Anwendungsprojekte:
  Ein aktuelles Beispiel: Ein Fachverfahren mit vergleichbarer Funktionalität wurde völlig unabhängig voneinander von zwei verschiedenen Lösungsanbietern parallel für zwei deutschsprachige Länder entwickelt. Dies ohne jede fachliche Abstimmung zwischen den Projekten, aber mit einem identischen Einsatzzweck. Beide Lösungen wurden (zufällig) auch auf derselben Technologie entwickelt.
  Die erste Lösung “A” wurde mit einem begrenzten Budget und einem sehr strengem Kontrolling bei RE entwickelt. Die zweite Lösung “B” wurde nach Erstellung eines Grundkonzept über Change Requests(CR)  mit laufend dynamisch erweiterten Budgets vorangetrieben. Mittlerweile sind beide Anwendungen im produktiven Einsatz.
  Das Ergebnis: Verhältnis der Anzahl von “lines of code 1:4, die kleine Lösung hatte eine im Schnitt bessere Akzeptanz bei den Anwendern. Natürlich waren die Entstehungsaufwände und Kosten für Pflege und Wartung niedriger. Die Ursache war ein falsches (umsatzorientiertes) RE.

Das letzte Beispiel zeigt auch die Problematik mit auf Umsatz zentriert denkenden Lieferanten auf. Die Realisierung von CRs wird in der Regel unkritisch durchgeführt, denn jeder CR ist Umsatz und meistens “die kaufmännische Sahne”. Für den Kunden ist es besser, wenn  zumindest der Lieferant der Lösung “mittelständisch” denkt und nicht das beste vom Kunden (sein Geld) sondern das beste für den Kunden (eine angemessene Lösung) will.

Mittelständler denken in der Regel so, leben sie doch vom Vertrauen ihrer Kunden und Vertrauen entsteht natürlich nicht durch Ausbeuten. Am besten ist es in RE-Projekten, wenn auf beiden Seiten (Lieferant und Kunde) mittelständisches Denken vorhanden ist.

2. Terminologie

Wenn man heute zu einer Veranstaltung geht, um etwas Neues zu lernen oder wenn man gar noch selbser einen Vortrag hält, dann sollte man vorher mal die zentralen Begriffe des Themas nachlesen.

So ist das auch mit RE. Und gerade im RE ist eine präzise Terminologie von größter Wichtigkeit.

Hier ist der Link zum Begriff des RE in Wikipedia. RE ist eine Teildisziplin von Requirement Management, es geht um die Ermittlung des Was und nicht des Wie! Idealerweise sollen hier lösungsneutrale Dinge ermittelt werden.

Das Wesen von Requirement Engineering ist:

• Zuhören und verstehen (Analyse)
• Vollständigkeit – auch im Sinne von „Top-Down“
• Kommunikation in der jeweiligen Sprache und auf der jeweiligen Ebene des jeweiligen Stake-Holders.

Es geht vor  allem um

• „Mitnehmen von Stake-Holder“.
• Reviews.
• Infrage Stellen von Anforderungen
• Viele Anforderungen sind nicht so wie auf den ersten Blick scheinen.
• Implizite Anforderungen.
• Ist die Granularität der Anforderung die Richtige?
• Funktionale und nicht-funktionale Anforderungen.

Vor allem muss Requirement Engineering ganz klar und streng getrennt werden vom Begriff der Fachlichen Architektur!

Fachliche Architektur ist an sich ein Bestandteil der Systemanalyse. Auch in der Informatik an der TUM gibt es hierzu eine sehr lesenswerte Beschreibung. In Wikipedia finden wir auch unter Informationsarchitektur eine nicht so ganz falsche aber auch nicht komplette Beschreibung. Der Terminus der „fachlichen Architektur“ ist leider in Wikipedia noch nicht vorhanden. Vielleicht erbarmt sich ja einer der Leser und erarbeitet ihn für Wikipedia!?

Bei der fachlichen Architektur geht es auch um das  Herbeiführen von Konsens zwischen den relevanten Stake-Holdern, denn oft haben verschiedene Stakeholder sich absolut widersprechende Anforderungen, wie weit z.B. die Anforderung von Anforderungen an vergleichbare Systeme abweicht?

Auf jeden Fall empfehle ich – nicht nur im Mittelstand – die konsequenteste  Anwendung des Prinzips KISS. Dabei meine ich nicht nur die ursprüngliche Definition KIS,S (siehe dazu meinen auch meinen Artikel), sondern schätze vor allem Begriffe mit dem “S” wie simpel oder smart, und als Mathematiker auch für schön – man denke nur an die schönen und dann so einfachen Beweise in der Mathematik.

Wichtig ist die saubere Trennung von Requirement Engineering versus Design/Architektur! Auf der letzten Tagung zu diesem Thema hat ein erfahrener “Requirement Engineer” in einem Vortrag über RE vom ersten Satz an nur über das Entwickeln der fachlichen Architektur gesprochen. Und dabei total seine eigentliche Aufgabe vergessen, die Anforderungen an ein Produkt kritisch zu hinterfragen und sauber zu definieren.

Ein weiterer Begriff, von dem man RE sauber abgrenzen sollte, ist Requirement Management (RM). In Wikipedia finden wir auch dazu einen ausgezeichneten Artikel.

Hier geht es um Verwalten (Traceability), Steuern, Priorisieren, Dokumentieren des “Was”, der Varianten und Gründe für die Anforderungen. Im Unterschied zum Requirement Engineering adressiert das Requirement Management agile Methoden wie SCRUM.

Ich empfehle folgende Formel:

Die Produktidee, das Design des Produkts ist das Ergebnis der Summe von Requirement Engineering und der fachlichen Architektur. Diese Produktidee wird aber bei SCRUM als gegeben angenommen und vom Product Owner (Rolle in SCRUM) in den Entwicklungsprozess eingebracht.

3. Interdisziplinäre Qualitäten

Hier eine Aufzählung von Dingen, die oft vergessen werden aber von größter Bedeutung sind:

Divide et impera!

Schon im alten Rom haben die Herrscher diesen Spruch beherzigt: Teile und (be)herrsche die Dinge. Das ist sicherlich ein vernünftiges Vorgehen, um Zugang zu komplexen Situationen zu finden. Es setzt aber voraus, dass man weiß, was man will und dies sauber von oben nach unten zerlegen kann. Die Herausforderung beim Requirement Engineering ist aber gerade, dass man eben meistens nicht so genau weiß, was man oder der Kunde will, sondern dies erst gemeinsam finden und beschreiben muss.

Ein Beispiel jenseits der Entwicklung von Software. Jetzt kann man Gesetze durchaus mit Software vergleichen, die dann von den Systemen der Exekutive und Judikative abgearbeitet werden. Wie Software für unsere Applikationen sind die Gesetze und ihre Umsetzung für unsere soziale Ordnung und unsere sozialen Systeme von höchster Wichtigkeit.

In Europa entstehen jedes Jahr zehntausende von neuen Gesetzen, die quasi ohne großes Ziel so “herunterprogrammiert” werden. Unser ehemaliger Ministerpräsident “Landesvater” Stoiber versucht die EU zu “entbürokratisieren” und schafft es – wie ein kleiner Programmierer in einem großen System – ab und zu mal, ein einzelnes Gesetz zu vereinfachen oder abzuschaffen. Die Menschen in Europa verstehen aber nicht mehr, was das ganze soll.

Auch hier hätte ein vernünftiges Requirement Engineering vor Beginn der Gesetzesflut geholfen, mal fest zu stellen, was Europa und seine Menschen eigentlich wirklich brauchen und so viel Europa- und EU-Frust bei den Bürgern vermieden. Aber nein, es wird fröhlich weiter programmiert, ohne zu wissen, was man eigentlich erreichen will.

Das Beispiel soll auch zeigen, dass es nicht genügt, einfach vor sich hin zu implementieren ohne gründlich vorher nach zu denken.

Dialektik, Logik und Ethik

Die saubere Definition von Begriffen, die Suche nach Bedingungen, der konstruktive dialektische Streit, das Bilden eines Syllogismus, das Erstellen von “Fahnen” (Begriff aus der Philosophie, übrigens in Wikipedia leider auch noch nicht niedergeschrieben), das alles sind wichtige Themen in der menschlichen Kommunikation.

Schon vor weit über 2.000 Jahren hat dies alles eine zentrale Rolle gespielt. Gerade Requirement Engineering erfordert die Anwendung dieser Disziplinen mit hoher Präzision und Akkuranz (und Lust). Man sollte also nicht das  “Rad neu erfinden” wollen, sondern althergebrachte und ausgereifte Techniken nutzen.

Heute im Vortrag haben wir gelernt, dass mittelständische Unternehmen Linguisten für Requirement Engineering nutzen. Ich würde einen Schritt weiter gehen: ohne Philosophen geht es nicht.

Wir brauchen bei RE zwei Arten von Philosophen:

• den “klassischen Basisphilosophen”
  Er muss ein Meister des Wortes und der Dialektik sein. Vielleicht wäre Immanuel Kant hier ein gutes Beispiel.
• den “Ketzerphilosophen”
• Hier denke ich an die Großen der Aufklärung. Sie haben vermeintlich Selbstverständliches hinterfragt. Und an den Grundfesten (erfolgreich) gerüttelt. Erfüllt mit Zivilcourage und konstruktivem Ungehorsam. Vielleicht kann man hier Friedrich Nietzsche “prototypisch” erwähnen.

Also: Kant und Nietzsche in RE-Projekte! Vielleicht liegt auch hier ein Vorteil des Mittelstands, denn im Mittelstand finden wir eher die Zivilcourage, den Kundennutzen über den eigenen Profit z.B. durch Implementierung eines jeden CR’s zu stellen. Ist sicher auch eine ethisches Thema.

Vielleicht noch ein paar Beispiele, die RE so schwierig machen und Philosophie und Aufklärung nötig machen:

• Das Diktat von Microsoft und SAP und manchen mehr.
• paradoxe Anforderungen:
  Eine gutes Beispiel ist das Firewall-Problem. Sie soll total sicher sein, aber jeder “Befugte” muss immer rein können. Das führt dann zu Firewalls mit 10.000 Regeln (definierten Ausnahmen). Das alles geht natürlich nicht, führt zu abstrusen Sicherheitsforderungen und Folgen bis zur virtuellen Kasernierung (gated communities), die aber bei mehr als 100.000 Teilnehmern  gar nicht möglich ist und dann völlig unsinnig wird.

Und solchen Herausforderungen können wir mit traditionellen Mitteln nicht mehr begegnen.

“Cheap Design”

Welchen Beitrag kann oder muss Requirement Engineering leisten, um die Anforderungen an ein Produkt so zu definieren, dass das Produkt so einfach, preiswert und effizient wie möglich gehalten werden kann?

Den Begriff Cheap Design hat Rolf Pfeifer, hier im Interview, geprägt. Rolf Pfeifer ist Gründer und Leiter des Artificial Intelligence Laboratory, Department of Informatics, University of Zurich. Er hat den Begriff “cheap design” kreiert und bekannt gemacht. Berühmt sind seine Billigroboter, die durch völlig neuartige (Billig-)Ansätze ganz neue Wege bei Robotik und Künstlicher Intelligenz aufgezeigt haben.

Ich empfehle die inspririerende Lektüre seines Buches “How the Body Shapes the Way We Think: A New View of Intelligence” (Bradford Books).

Kreative Produkte

Natürlich kann uns hier konservatives Requirement Engineering keine vernünftigen Ansätze liefern. Wie kann man kreativ Systemanforderungen für ein Produkt beschreiben, von dem man noch gar keine Vorstellung hat? “Top down”-Ansätze werden hier sicherlich nicht funktionieren, fehlt doch das “Top”. Iterative Methoden sehe ich hier auch noch nicht. Agil im Sinne von Plan loslaufen?

Aber auch hier gibt es durchaus sinnvolle methodische Ansätze. Ich verweise hier auf das durchaus schon sehr lebendige Phänomen von “crowd sourcing”. Für InterFace hat unsere Praktikantin Monika Bi eine Forschungsarbeit zu diesem Thema gemacht. Gerne gebe ich die Ergebnisse weiter.

Werkzeuge

Immer wieder begegnen mir Situationen, in denen versucht wird, Probleme einfach durch Einsatz von neuen Werkzeugen zu lösen. Solche Werkzeug-Gläubigkeit entsetzt mich. In der Tat führt dieses Vorgehen auch meistens zu einem Werkzeug- (und Stellen-)Overkill, der nur schadet.

Komplexität kann man nicht wesentlich mit dem Einsatz von Werkzeugen bewältigen.Und mit den gängigen Werkzeugen wie gira, svn, ea, uml und vielen mehr sind wir eigentlich schon bestens versorgt. Also nicht noch mehr sondern alternative Werkzeuge.

Dazu zähle ich z.B. durchaus die sogenannten “Kreativwerkzeuge” (wie ich sie vor kurzem in einem Projekt mit unternehmerTUM von der TUM sehr positiv erfahren durfte), aber vor allem auch Internet-Technologien wie Foren, Blogs, Twitter und ähnliches. Und vor allem Video und logischerweise auch bald Virtual Reality.

Schon heute lernt man Apple oder Google am schnellsten über Videos zu nutzen.

Aber zum Schluss das wichtigste. Ich nenne es mal die

Psychologie

Das ganze fängt mit der Art an, wie man Fragen stellt. Auch in der Diskussion der vorangegangenen Vorträge konnte ich feststellen, dass die meisten Fragen halt direkt sind. Das ist ganz natürlich, haben wir doch schon meistens eine definierte Meinung, die wir nicht offen in Frage stellen lassen, sondern zuerst mal bestätigt haben wollen. Vielleicht sind wir bei partnerschaftlicher Zusammenarbeit bestenfalls bereit, eine konstruktiv und sehr gut begründete Widerlegung zu akzeptieren.

Wenn ich aber ein Problem eines anderen Menschen erfassen will und nur Fragen stelle, die darauf abzielen, mit “Ja” oder “Nein” beantwortet zu werden, dann bekomme ich halt (bei geeigneter Negation) der Frage z.B. zehnmal ein “Nein”. Wie aber kann ich mir einbilden, das Problem eines fremden Menschen verstanden zu haben, wenn er mir zehnmal mit Nein geantwortet hat?

Offene Fragen stellen erscheint so einfach – probieren Sie es aus, es ist wahnsinnig schwierig. Wir sind irgendwie auf eine geschlossene Fragestellung konditioniert worden, vielleicht, weil wir alle kleine Rechthaber sind.

Team versus Gruppe

Terminologisch ist die Unterscheidung zwischen Team und Gruppe (Arbeit, Militär) nicht einfach. Auch in Wikipedia finde ich hier zu oft Widersprüchliches.

Mein Verständnis ist, dass eine Gruppe etwas organisiertes und angeleitetes ist. Ist gibt Vorgaben, die erfüllt werden müssen. Es wird gemessen und entsprechend entlohnt.

Ich bevorzuge den Begriff des Teams. Hier findet ein großes Maß an Selbstorganisation statt. Das Problem ist der gemeinsame Gegner, nicht der Kollege im Team. Die Menschen im Team sind in der Lage und auch bereit zuzuhören.

Und das oberste Ziel aller Teammitglieder ist, die selbst übernommene Aufgabe durch gemeinsamen Erkenntnisgewinn so gut wie nur möglich optimal für alle Stakeholder zu schaffen. Das ist leider keine Selbstverständlichkeit und findet nach meiner Beobachtung gerade bei den Prozessen des Requirement Engineering nur selten statt, und wenn dann meistens nur im Mittelstand.

RMD