Anforderungen ohne Expertenwissen
Beim Umgang mit Anforderungen gibt es eine Diskrepanz zwischen Theorie und Praxis. In der Theorie gibt es Techniken, Tools und Best Practices, die fast sicher zu funktionierenden, akzeptierten Lösungen führen. In der Praxis gibt es häufig Qualitätsdefizite bei ausgelieferten Systemen und Produkten, die im Zuge des Anforderungsmanagements hätten entdeckt werden müssen. Warum ist das Aufspüren von Systemfehlern so schwer? Und warum können heutzutage trotz aller Normen und Regeln gravierende Fehler in ausgelieferten Produkten überhaupt auftauchen?
Der gelebte Umgang mit Anforderungen
In vielen Organisationen gibt es Entwickler und Architekten, die seit vielen Jahren Systeme, Produkte oder Services entwickeln. Diese Mitarbeiter sind Experten auf ihren Gebieten. Sie wissen genau, was sie wie tun müssen. Sie können gut abschätzen, was eine neue Lösung bieten soll und wie umfangreich die Entwicklung dieser Lösung werden kann. Dieses Wissen haben sie sich über lange Jahre angeeignet, es ist ihre Qualifikation, ihre Berufserfahrung. Bitten Sie solche Mitarbeiter, ein neues System zu beschreiben, werden Sie möglicherweise ein leichtes Kopfschütteln, einige allgemeine Epics oder Features und in ganz wenigen Fällen mal die Beschreibung des Systemkontextes oder ein Anforderungsdiagramm erhalten. Aufzuschreiben, was am Ende herauskommen soll, macht für diese Mitarbeiter wenig Sinn. Alle Beteiligten wissen das und so wird der Alibi-Beschreibung auch kaum Aufmerksamkeit geschenkt. Hier vertrauen der Auftraggeber und der Projektleiter den Skills der Mitarbeiter. Das Vorgehen erinnert zwar eher an eine Autofahrt im Nebel mit geschlossenen Augen, aber die Hoffnung besteht, dass der Fahrer den Weg gut kennt.
Was passiert, wenn der Entwicklungsprozess ein Review der Anforderungen erfordert? Oft wird ein Meeting mit dem Projektleiter, dem Architekten, einem Tester und möglicherweise einem Entwickler angesetzt. Ohne Moderator, ohne Timebox, ohne Agenda oder Regeln. Nach einer Stunde sind erst wenige Anforderungen diskutiert und ein gemeinsames Verständnis der Herausforderungen und der Vorgehensweise ist noch lange nicht in Sicht. Allen Beteiligten ist klar, dass es auf diese Art nicht klappen kann, so dass der Autor der Anforderungen die Aufgabe erbt, die Qualität der beschriebenen Anforderungen zu steigern. Damit sitzt wieder derselbe Mensch an einer Aufgabe, die er nicht erfüllen möchte und die nicht seiner Qualifikation entspricht. Wie wird da wohl die Qualität der Anforderungen – im Sinne von Verständlichkeit, Vollständigkeit, Widerspruchsfreiheit, Nachvollziehbarkeit, etc. – aussehen?
Der andere Weg zu Anforderungen
Nach meiner Erfahrung werden Ursachen für Produktfehler nur sehr selten in den Anforderungen gesucht, obwohl viele Fehler durch Fehlinterpretationen der Anforderungen entstehen. Dies passiert, weil der Autor Interpretationsspielräume eröffnet und Annahmen als allgemeingültig erachtet. Beides wird beim Review selten entdeckt. Hinzu kommt noch ein weiterer Gegensatz: Systementwickler brennen dafür, technische Lösungen für technische Probleme zu schaffen. Das ist ihr Antrieb, darin liegt ihre Expertise. Wie soll nun ein solcher Spezialist im Vorfeld eine Idee spezifizieren, die in der Realität erst im Laufe der Entwicklung entstehen kann?
Der Lösung dieses Gegensatzes liegt im Austausch von „Wie“ mit „Was“. Oder in anderen Worten: Anforderungen müssen frei von Lösungen sein – und genau das ist nicht die Stärke der Systementwickler und Systemarchitekten. Sie sind schlicht die falschen Ansprechpartner beim Formulieren von Anforderungen, denn sie denken stets in Lösungen. Wenn sie aber nicht die richtigen Ansprechpartner sind, wer eignet sich dann am besten für die Formulierung von Anforderungen? Die Antwort ist erstaunlich einfach: Wenn Anforderungen frei von Lösungen sein sollen, muss der Autor kein Fachmann der Systementwicklung sein. Er muss lediglich beim Erfassen der Anforderungen den Auftraggeber so lange und so strukturiert hinterfragen, bis die Anforderung formal richtig niedergeschrieben ist. Dazu benötigt er eine gewisse sprachliche Begabung, eine Nähe zu Formalismen und eine Portion Beharrlichkeit, um den Auftraggeber zu genauen Festlegungen zu bewegen.
Die Kehrtwende im Anforderungsmanagement
Anforderungen zu beschreiben, ist in vielen Organisationen eine Aufgabe für hochqualifizierte Spezialisten. Dies wird sich meiner Meinung nach in Zukunft ändern. Es wird eine Aufgabe für hochstrukturierte Menschen mit speziellen Begabungen, die dabei fast keinen technischen Hintergrund besitzen müssen. Beispielweise verfügen Menschen mit besonderen Veranlagungen, wie bspw. dem Asperger-Syndrom, über Fähigkeiten, in denen sie allen anderen Menschen deutlich überlegen sind. Diese Fähigkeiten lassen sich dazu nutzen, Anforderungen frei von Lösungen zu erfassen.
Natürlich steigt auf dem Weg zu reinen, formal korrekten Anforderungen die Anzahl der dokumentieren Anforderungen deutlich an. In der Praxis ist dies aber irrelevant, den Tests belegen, dass diese Art der Behandlung von Anforderungen wesentlich effizienter ist. Selbst wenn in einer vergleichbaren Situation die Anzahl der Anforderungen um den Faktor 6 steigt, so geht die Erstellung um den Faktor 3 schneller. Das Review wird in der Folge in Rekordzeit erledigt, da Anforderungen auf ganz andere Art gelesen werden, und schneller eindeutige Ja/Nein-Entscheidungen getroffen werden können – 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 Systemarchitekten und Systementwickler wieder mit voller Leidenschaft dem „Wie“ widmen – also der Leidenschaft, mit der sie technische Lösungen für technische Probleme finden.
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Alles Wichtige über Requirements Engineering jetzt auf 37 Seiten als Download zum Mitnehmen.
Eckhard Jokisch
Eckhard Jokisch ist seit mehr als 18 Jahren im Anforderungsmanagement unterwegs. Er ist CTO und Principal Consultant bei Orange-Moon Ltd., Dublin, Mitglied von INCOSE und dort in der Requirements-Work-Group aktiv. Sein Schwerpunkt liegt in der Entwicklung besserer Methodik und höherer Effizienz. Dazu geht er auch unkonventionelle Wege. Die Erkenntnisse daraus stellt er seinen Zuhörern weltweit in Vorträgen und Workshops gerne zur Verfügung ebenso wie seinen Kunden im Bereich Regulatory Affairs in der Medizintechnik.