Der Paradigmenwechsel im Requirements Engineering

Über Requirements-Engineering und Requirements-Management gibt es Bücher, Vorträge, Ausbildungen und Konferenzen. Die Fachwelt ist sich einig, dass ein sorgfältiges Beachten bestimmter Regeln zum (fast) garantierten Erfolg führt. Manchmal wird noch über Details gestritten, aber die Sache an sich ist klar. In meiner Tätigkeit als Berater stoße ich hingegen immer wieder auf folgende Ergebnisse:

• 80% der Qualitätsdefizite in Requirements sind auch bei Auslieferung des Produkts immer noch vorhanden
• Produkte werden ausgeliefert – trotz bekannter kritischer “Lücken” in der Umsetzung

Woher kommt diese Diskrepanz zwischen Theorie und Praxis? Wieso schlagen die meisten Ingenieure beim Thema „Requirements“ immer wieder die Hände über dem Kopf zusammen? Und woher kommt dieser Stress am Ende eines Projektes?

Eine meiner Lieblingsbeschäftigungen (das habe ich praktischerweise zu meinem Beruf gemacht) liegt im Aufspüren von Fehlern in Systemen. Für viele mag es eine nervige Arbeit sein, doch wenn man die Quellen aufgespürt hat und diese bereinigt, wird der Prozess immens erleichtert. Prozessorientiertes Denken ist die Devise, um nicht wieder in alte Verhaltensmuster zurückzufallen. Aber warum ist das Finden der Systemfehler so schwer? Und warum können in der heutigen Zeit bei der Entwicklung von Systemen überhaupt gravierende Fehler bis in die ausgelieferten Produkte gelangen?

Die Praxis im Umgang mit Anforderungen

In den Unternehmen ist es normalerweise so, dass es Fachingenieure gibt, die seit Jahren nichts anderes machen, als Systeme zu entwickeln. Diese Ingenieure wissen genau, was sie tun müssen und haben normalerweise auch ein gutes Gespür darin, was ein neu zu entwickelndes System bieten soll und wie viel Aufwand diese Entwicklung benötigen wird. Das ist ihre Qualifikation, ihr Know-how, ihre Berufserfahrung. Und das ist auch gut so. Vorher aufzuschreiben, was am Ende herauskommen soll, macht so gesehen wenig Sinn. Im besten Fall beschreibt ein Ingenieur ein paar Alibi-Anforderungen, damit der Ablauf oberflächlich eingehalten wird. Alle Beteiligten wissen das und so schaut sich dann normalerweise niemand diese Anforderungen wirklich in der Tiefe an. Das ganze Projekt ähnelt an dieser Stelle eher einer Vollgas-Fahrt im Nebel, weil jeder den Weg sowieso schon kennt! Oder zumindest zu kennen glaubt. Getreu dem Motto: “Wir haben das schon immer so gemacht, wir machen das auch weiterhin so.” Man könnte aber auch statt des üblichen Weges durch den Nebel eine schönere Route entlang der wunderbaren (System-)Landschaft wählen. Verkehrsschilder (Prozessanweisungen) und Warnhinweise (Reviews) säumen die Etappen (agiles Entwickeln) entlang der Strecke und die eine oder andere Tankstelle (Meilensteine, Zwischenstände) lässt sich während der Reise ansteuern. Hier ist nicht der Weg das Ziel, sondern das Verhindern von Fehlentwicklungen.

Die Fahrt durch den Nebel

Nun schreibt aber der Entwicklungsprozess vor, dass ein Review auf die Requirements zu machen ist. Also setzt der Projektleiter ein Meeting an, lädt den Autor der Requirements, den Systemarchitekten und einen Tester ein. Nach einer Stunde stellen sie fest, dass sie nur die ersten zehn Requirements angeschaut haben und dabei auch nur zu vier Requirements tatsächlich eine Einigung erzielen konnten. Allen ist klar, dass es so nicht funktionieren kann und der Abgabetermin nie und nimmer zu halten sein wird. Also wird dem Autor nahegelegt, die Qualität der Requirements zu steigern, sprich nachzubessern – und nebenher seinen Teil des Systems weiter zu entwickeln.

Und so schließt sich der Kreis. Wieder sitzt derselbe Mensch an einer Aufgabe, die ihrem Wesen nach nicht seiner Qualifikation entspricht. Das Ergebnis ist mit großer Gewissheit schlecht.

Die Leidenschaft eines Systemingenieurs

Die Ursachen für Fehler werden viel zu selten in den Anforderungen gesucht. Viele, viele Projekte haben mir gezeigt, dass die Fehler im Grunde durch Fehlinterpretationen der Requirements entstanden sind. Das kann nur dann passieren, wenn Annahmen im Spiel sind, die durch den Autor der Requirements nicht beabsichtigt bzw. als Interpretationsmöglichkeit berücksichtigt wurden, aber auch in einem Review niemandem aufgefallen sind. Doch wo liegt nun der Schlüssel für eine mögliche Lösung?

Ein Systemingenieur brennt dafür, technische Lösungen für technische Probleme zu schaffen. Darin liegt seine Kreativität. Nun soll dieser Systemingenieur im Vorhinein eine Idee definieren, also vorab eine genaue, validierbare Beschreibung abliefern, die aber in der Realität erst im Prozess entsteht bzw. entstehen kann. Eigentlich könnte er das System dann gleich selbst entwickeln und wäre damit vermutlich schneller fertig.

Das Entwickeln ohne Anforderungen fällt in den heutigen komplexen Systemen als Möglichkeit weg. Es führt also kein Weg an Anforderungen vorbei. In der gelebten Praxis entstehen so meist nicht-eindeutige, ja blumige Texte. Formal saubere Anforderungen zu schreiben ist zermürbend und häufig langweilig. Ich jedenfalls habe noch keinen Systemingenieur getroffen, dem das Schreiben von tausenden formal sauberen Anforderungen wirklich Spaß macht.

Der bessere Weg zu Anforderungen

Der Schlüssel liegt in der Verwechslung des “Wie” mit dem “Was”. In Kurzform bedeutet das: Requirements müssen frei von Lösungen sein – und genau das ist nicht die Baustelle des Systemingenieurs sondern dazu diametral entgegengesetzt. Systemingenieure sind die falschen Leute für das Schreiben von Anforderungen!

Aber wer sind dann die richtigen Leute? Die Antwort ist eigentlich erstaunlich einfach. Da die Anforderungen frei von Lösungen sein sollen, muss der Autor gar kein Fachmann auf dem Gebiet sein. Die einzige Aufgabe des Requirement-Autors ist es, die Anforderungen der Auftraggeber so lange strukturiert zu hinterfragen, bis genau diese formal richtig niedergeschrieben sind. Es gehört also sowohl eine gewisse sprachliche Begabung dazu, als auch eine Liebe zu Formalismen sowie eine Portion Sturheit (wenn der Auftraggeber sich in “Wolken” verstrickt). Hilfreich ist auch noch ein “kriminalistischer Spürsinn” für die Stellen, an denen Auftraggeber gerne “blumig” werden und versuchen, einer genauen ersten Festlegung zu entgehen.

Im Grunde muss den Beteiligten klar sein, dass es in einem geordneten Prozess um eine erste Festlegung geht, die keinesfalls endgültig ist. Genau dann, wenn sich die erste Festlegung als “falsch” erweist, gibt es die Chance in einem geordneten Prozess diese Festlegung durch eine neue zu ersetzen. Formale, strukturierte Requirements sind daher der einzige funktionierende Weg, eine prozesssichere Entwicklung durchzuführen. Und auch hier wird die angesprochene “gewisse Sturheit” benötigt, weil es für Ingenieure einfach zu verlockend wäre, eine Abkürzung zu suchen.

Der Paradigmenwechsel

Requirements zu beschreiben gilt derzeit als Aufgabe für hochqualifizierte Ingenieure. Meiner Meinung nach wird dies in Zukunft eine Aufgabe für hochstrukturierte Menschen mit besonderen Begabungen, die aber fast keinen technischen Background haben müssen. Beispielweise verfügen Menschen mit speziellen Veranlagungen, wie bspw. dem Asperger-Syndrom, über Fähigkeiten, in denen sie allen anderen Menschen haushoch überlegen sind. Diese Fähigkeiten lassen sich dazu nutzen, “reine” Anforderungen ohne Lösungsanteile zu erstellen.

Auf dem Weg zu “reinen” Anforderungen steigt die Anzahl der Requirements deutlich an, doch das spielt keine Rolle. Vielfache Tests haben in meiner Praxis gezeigt, dass diese Art Requirements zu behandeln wesentlich effizienter ist. Selbst wenn für einen gleichen Sachverhalt die sechsfache Anzahl an Requirements entsteht, geht das Erstellen um den Faktor drei schneller. Das Review wird dann in Rekordzeit erledigt, weil diese Art Requirements auf eine ganz andere Art gelesen werden. So wird weitaus schneller zu einer eindeutigen Ja/Nein-Entscheidung gefunden – und das ist schließlich der eigentliche Sinn von Reviews. Und dadurch, dass durch diesen Prozess das “Was” klar definiert ist, können sich die Ingenieure nun mit voller Leidenschaft wieder dem “Wie” widmen – der Leidenschaft, technische Lösungen für technische Probleme zu finden.

Hinweis

In Kontakt können Sie mit Herrn Jokisch über Linkedin (www.linkedin.com/in/eckhard-jokisch) oder contact@orangemoon.ie treten.