Was ist Requirements Engineering? Gelegentlich wird man das auch von Nichtinformatikern gefragt. Dann spreche ich nicht mehr von Dokumentation, Verträgen oder Testen, sondern von Kommunikation. Das agile Manifest[1] hat Recht: Es geht um Menschen, Kommunikation und funktionierende Software, nicht um Verträge, Arbeitsprozesse und Dokumentation! Das gilt auch für das Requirements Engineering im Speziellen. In meinen Vorlesungen stelle ich Requirements Engineering darum als Übersetzerarbeit dar. Der Requirements Engineer ist der zweisprachige Übersetzer, der die expliziten Wünsche und impliziten Bedürfnisse der Benutzer übersetzt in eine Sprache, die der Entwickler verstehen kann, um genau die richtige Software zu entwickeln. Und in die umgekehrte Richtung übersetzt der Requirements Engineer Aussagen und Fragen der Entwickler in eine Form, dass der Benutzer sie verstehen und beantworten kann. Das ist die Essenz des Requirements Engineering! Alles andere, was gemeinhin zum Requirements Engineering gezählt wird, sind nur Hilfsmittel.
Die Definition einer Anforderung
Die Definition einer Anforderung nach CPRE-Glossar [2] bzw. IEEE Standard 610 [3] erfasst genau diese Zweisprachigkeit:
„Eine Anforderung ist:
- Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
- Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
- Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß 1. oder 2.“
Die dokumentierte Darstellung der Anforderung wird extra genannt, weil Anforderungen auch implizit, unbewusst, unterbewusst und mündlich existieren und gelten. Das Dokumentieren ist Mittel zum Zweck: Das Aufschreiben zwingt zum exakten Formulieren, zum Entscheiden und unterstützt dann auch das Diskutieren, Entdecken von Widersprüchen und Lücken, Validieren und Verifizieren der Anforderungen. Missverständnisse kann man so zwar nicht verhindern, aber doch deren Häufigkeit verringern.
Während die agile Entwicklung die Dokumentation von Anforderungen in der minimalistischsten Form auf User Stories reduziert, erfolgt das Validieren und Verifizieren der Anforderungen im Gespräch und anhand des IT-Systems aus der vorigen Iteration. Einerseits ist das gut, weil man es so vermeidet, nutzlos Papier mit möglicherweise schlechten, missverständlichen Anforderungen vollzuschreiben, die morgen sowieso nicht mehr gelten. Allerdings fällt so auch etwas weg, das bei komplexen Projekten nach wie vor nötig ist: Eine Feedbackschleife zum Benutzer, ob man ihn richtig verstanden hat, und eine Feedbackschleife zum Entwickler, ob die Anforderungen nicht nur einzeln machbar sind, sondern auch im Verbund mit den anderen Anforderungen zu einer sinnvollen technischen Lösung passen. Irgendwann ist doch mal ein umfassendes, durchdachtes Konzept nötig.
Fachliche und technische Übersetzung
Ich finde, dass der Informationsgehalt von User Stories zu gering ist. Aber was soll man zusätzlich noch dokumentieren? Das hängt natürlich von den Gesprächspartnern ab! Auch die schriftliche Anforderungsspezifikation dient nur der Kommunikation. Darum sieht das optimale Dokument für jedes Projekt anders aus. Maßgeblich ist, wer hier miteinander diskutiert. Sprechen Benutzer- und Entwickler-Seite nicht dieselbe Sprache (Fachsprache und/ oder grafische Notation), dann werden mindestens zwei Darstellungen derselben Anforderungen nötig, beispielsweise Fachkonzept und technisches Konzept, Lastenheft und Pflichtenheft. Fachliche Anforderungen müssen dann in technische übersetzt werden und bei Änderungen auch wieder zurück. Natürlich ist diese Redundanz nicht effizient, weil dieselben Inhalte in verschiedenen Sprachen vorliegen und ständig konsistent gehalten werden müssen. Jede Änderung in einem Dokument muss also auch im anderen nachgezogen werden. Leider gibt es oft keine eins-zu-eins-Entsprechung zwischen den Kapiteln, weil die Benutzer ihre Anforderungen nach fachlichen Kriterien strukturieren (z.B. Benutzergruppen oder Geschäftsprozessen oder verwalteten Objekten), während die Entwicklerseite nach technischen Kriterien strukturiert (z.B. IT-Komponenten). Und schon benötigt unser Übersetzer Nachverfolgbarkeit zwischen den Kapiteln oder Einheiten der beiden Spezifikationen.
Mit dieser Komplexität sollten Sie jedoch nicht hadern, ist sie doch direkt ein Abbild der Tatsache, dass hier Fachseite und Entwicklungsseite ihre Kompetenzen integrieren, um ein komplexes IT-System zu erstellen. Das kann bei interkulturellen Projekten vorkommen, außer man arbeitet lange genug zusammen, so dass entweder die Benutzerseite die Techniksprache erlernt oder umgekehrt die Entwickler die Fachsprache. Oder man einigt sich auf „simple English“ als kleinsten gemeinsamen Nenner und schreibt eine Spezifikation in schlichter Notation, mit minimalem Vokabular und schlichtester Syntax, die beide Seiten verstehen. Wobei wir wieder bei den User Stories wären. Diese erfüllen genau diesen Zweck.
Auf dem Weg zu den Inhalten einer Spezifikation
Aber gehen wir davon aus, die User Stories genügen uns nicht. Wenn der Inhalt und die Form der Spezifikation jeweils von den beteiligten Gesprächspartnern abhängen, kann es keine Standardvorlage geben, die überall optimal passt. Dann stellt sich immer wieder erneut die Frage: „Welche Inhalte sollen in welcher Spezifikation schriftlich festgehalten werden?“ Das Maßschneidern einer eigenen Vorlage verlangt ein iteratives Vorgehen mit Versuch und Irrtum, weil noch keine allgemeingültigen Erkenntnisse darüber existieren, wer welche Inhalte benötigt. Die Forschung hat bisher nur schlaglichtartige Einzelerkenntnisse [4] darüber zusammengetragen, beispielsweise über die Informationsbedürfnisse von Software-Architekten [5].
Die folgende Abbildung zeigt Ihnen die drei möglichen Richtungen für Ihr Vorgehen auf:
- Sie können von einem umfangreichen Standard wie dem ISO/IEC/IEEE 29148 [6] ausgehen und gezielt Kapitel weglassen, die keiner der Beteiligten benötigt. Der Standard ist dermaßen umfassend, dass vermutlich alles vorgesehen ist, was irgendjemand benötigen könnte.
- Oder Sie starten umgekehrt beim Minimum, beispielsweise mit den User Stories der agilen Entwicklung und fügen nach und nach zusätzliche Inhalte dazu. Wenn Sie iterativ arbeiten, können Sie am Ende jeder Iteration in der Retrospektive entscheiden, was gefehlt hätte. Die Fachliteratur bietet reichhaltige Ideen, mit welchen Notationen man welchen Inhalt darstellen kann. Daraus können Sie bei diesem Ansatz schöpfen.
- Der dritte Ansatz startet in der Mitte mit einer Vorlage, die sich bereits bewährt hat: eine leichtgewichtige Vorlage für eine Anforderungsspezifikation aus Benutzersicht, die ich aufgrund meiner Erfahrungen entwickelt habe. Sie kann Ihnen als Ausgangslage für Ihre Eigenentwicklung einer Vorlage dienen, um weitere Kapitel hinzuzufügen oder auch welche wegzulassen.
Quellen:
[1] Das agile Manifest
[2] CPRE Glossar bei IREB bzw. Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering. dpunkt.Verlag, 4. Auflage, 2015, S. 3
[3] IEEE STANDARD 610-1990
[4] Anne Gross, Joerg Doerr: What you need is what you get!: The vision of view-based requirements specifications, 20th IEEE International Requirements Engineering Conference (RE), 2012,
[5] Anne Gross, Joerg Doerr: What do software architects expect from requirements specifications? results of initial explorative studies, 2012 IEEE First International Workshop on the Twin Peaks of Requirements and Architecture (Twin Peaks)
[6] ISO/IEC/IEEE 29148:2011 – Systems and software engineering – Life cycle processes – Requirements engineering