Anforderungen dokumentieren, aus denen Entwicklung und Test dasselbe lesen
Die Prüfbarkeit entscheidet, nicht die Länge. Wer eine Anforderung so schreibt, dass daraus ein Testfall wird, hat die Abstimmung schon zur Hälfte hinter sich.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Anforderung war eindeutig, bis drei Leute sie gelesen haben
Der Satz, um den es geht, lautet meistens so ähnlich wie: Das System soll die Daten schnell und benutzerfreundlich anzeigen. Alle nicken, weil jeder etwas versteht. Die Entwicklung denkt an eine Ladezeit, der Fachbereich an eine bestimmte Reihenfolge der Spalten, der Test weiß nicht, was er prüfen soll, und die Abnahme scheitert später an einem Punkt, den niemand aufgeschrieben hat. Der Aufwand für die Korrektur fällt dabei an der teuersten Stelle an, nämlich am Ende.
Zwei Wörter verursachen davon den größten Teil: schnell und einfach. Beide beschreiben eine Empfindung und kein Verhalten, und beide sind nicht prüfbar. Dasselbe gilt für Passiv ohne Akteur, also Sätze in der Art von es wird sichergestellt, dass, denn dort fehlt genau die Information, wer etwas tut. Ein Prüfer kann daraus keinen Testfall bauen, und eine Entwicklerin kann daraus nicht ableiten, was sie schreiben soll.
Der zweite häufige Fehler ist eine Anforderung, die eigentlich eine Lösung ist. Wenn im Lastenheft steht, dass ein bestimmtes Feld als Auswahlliste umzusetzen ist, dann ist die Entscheidung über die Lösung bereits gefallen, obwohl der eigentliche Bedarf vielleicht ein ganz anderer war. Solche Sätze schließen Wege aus, die günstiger gewesen wären, und sie sind später schwer zu korrigieren, weil sie den Anschein von Verbindlichkeit haben.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ablauf, Schritt für Schritt
Sechs Stationen vom ersten Gespräch bis zur verwalteten Anforderung. Die Reihenfolge ist bewusst so gewählt, dass die Frage nach der Prüfbarkeit früh kommt und nicht erst dann, wenn schon gebaut wird.
- 1
Zweck, Rahmen und Beteiligte festhalten
Schreibt in wenigen Sätzen auf, welches Problem gelöst werden soll, was ausdrücklich nicht dazugehört und wer betroffen ist. Der Teil über das, was nicht dazugehört, ist der wertvollste, weil er später die Diskussion über schleichende Erweiterungen abkürzt. Benennt zu jeder Gruppe von Betroffenen eine Person, die für sie sprechen darf, sonst holt ihr die Rückmeldung ein, wenn es zu spät ist.
Geschafft, wenn: Eine Seite mit Ziel, Abgrenzung und einer namentlichen Liste der Beteiligten, der alle zugestimmt haben.
- 2
Erheben und nach Art sortieren
Sammelt zunächst ohne Formatierung, aus Gesprächen, aus vorhandenen Unterlagen, aus der Beobachtung der heutigen Arbeit. Sortiert das Ergebnis anschließend in drei Körbe: was das System tun soll, wie gut es das tun soll und was von außen feststeht, etwa Vorgaben aus Recht, Betrieb oder vorhandener Technik. Diese Sortierung entscheidet über den weiteren Weg, weil die drei Arten unterschiedlich formuliert und unterschiedlich geprüft werden.
Geschafft, wenn: Eine sortierte Sammlung, in der zu jeder Aussage die Quelle steht, aus der sie stammt.
- 3
Jede Anforderung in einen prüfbaren Satz bringen
Jetzt kommt die Schablone zum Einsatz: handelndes System, Modalverb, Verhalten, Bedingung. Ein Satz enthält genau eine Anforderung, und ein und in der Mitte ist fast immer ein Hinweis darauf, dass zwei daraus werden müssen. Streicht Wörter, die eine Empfindung beschreiben, und ersetzt Passiv ohne Akteur durch den, der tatsächlich handelt. Wenn ihr an dieser Stelle merkt, dass ein Sachverhalt in Prosa gar nicht klar wird, ist ein kleines Diagramm die bessere Darstellung, und der Satz verweist darauf.
Geschafft, wenn: Anforderungen, die jeweils in einem Satz stehen, mit erkennbarem Akteur und klarer Verbindlichkeit.
- 4
Qualitätsanforderungen messbar machen
Zu jeder Aussage über Antwortzeit, Verfügbarkeit, Menge, Sicherheit oder Bedienbarkeit gehören drei Angaben: die Größe, der Wert und das Verfahren, mit dem gemessen wird. Bei Bedienbarkeit ist das Verfahren keine Zahl, sondern eine Beobachtung mit einer benannten Aufgabe und einem Erfolgskriterium. Rechnet damit, dass an dieser Stelle Widerspruch kommt, und behandelt ihn als Gewinn: Ein Wert, dem jemand widerspricht, ist ein Wert, über den vorher niemand nachgedacht hat.
Geschafft, wenn: Qualitätsanforderungen, die jemand nachmessen kann, ohne den Autor zu fragen.
- 5
Akzeptanzkriterium und Testfall daneben schreiben
Formuliert zu jeder Anforderung mindestens einen Fall aus Ausgangslage, Auslöser und erwartetem Ergebnis, und ergänzt die Fälle, die schiefgehen können. Diese Übung deckt Lücken auf, die beim Formulieren unsichtbar bleiben, etwa fehlende Angaben zu Grenzwerten, zu leeren Eingaben oder zum Verhalten bei einem Fehler. Wenn Entwicklung und Test den Fall gemeinsam schreiben, ist die Abstimmung nebenbei erledigt.
Geschafft, wenn: Zu jeder Anforderung mindestens ein Testfall, der ohne Rückfrage ausführbar ist.
- 6
Prüfen, freigeben und verfolgbar halten
Lest die Anforderungen gemeinsam gegen eine kurze Prüfliste: eindeutig, prüfbar, genau eine Anforderung je Satz, keine Lösung statt Bedarf, keine unbelegte Zahl, keine Widersprüche zu anderen. Vergebt danach eine stabile Kennung, haltet den Zustand fest und verbindet jede Anforderung mit Testfall und Umsetzung. Ab hier gilt: Änderungen laufen über denselben Weg wie die Erstfassung, und die Verbindungen zeigen, was von einer Änderung betroffen ist.
Geschafft, wenn: Eine freigegebene Fassung, bei der zu jeder Anforderung sichtbar ist, wodurch sie umgesetzt und wodurch sie geprüft wird.
Fünf Prüfsteine für eine fertige Anforderung
- 01 Steht ein handelndes System im Satz, oder ist es Passiv ohne Akteur?
- 02 Ist die Verbindlichkeit über ein vereinbartes Modalverb ausgedrückt?
- 03 Enthält der Satz genau eine Anforderung, oder verstecken sich mehrere darin?
- 04 Hat jede Qualitätsanforderung Größe, Wert und Messverfahren?
- 05 Lässt sich daraus ohne Rückfrage ein Testfall schreiben?
Was ihr nach dieser Seite anders macht
Sechs Handgriffe, und keiner davon verlangt ein neues Werkzeug. Die ersten drei betreffen die Formulierung, die letzten drei die Verwaltung, und beides zusammen entscheidet darüber, ob die Anforderung eine Abnahme trägt.
Eine Schablone für den Satzbau festlegen
Ein handelndes System, ein Modalverb für die Verbindlichkeit, ein Verhalten und die Bedingung, unter der es gilt. Wenn jede Anforderung nach demselben Muster gebaut ist, fallen Lücken beim Schreiben auf und nicht erst im Review, und die Sätze lassen sich schnell überfliegen.
Die Verbindlichkeit über das Modalverb ausdrücken
Legt einmal fest, was muss, sollte und wird bei euch bedeuten, und haltet euch daran. Ohne diese Vereinbarung liest der eine eine Pflicht, wo der andere einen Wunsch gemeint hat, und die Diskussion darüber kommt garantiert am Tag der Abnahme.
Funktion, Qualität und Randbedingung trennen
Was das System tut, wie gut es das tut und was von außen vorgegeben ist, sind drei verschiedene Dinge und gehören nicht in denselben Satz. Vermischt geschrieben lässt sich keiner der drei Teile für sich prüfen oder ändern.
Qualitätsanforderungen mit Zahl und Messverfahren versehen
Nicht schnell, sondern: Antwortzeit im Regelbetrieb, gemessen an dieser Stelle, bei dieser Last, in diesem Perzentil. Erst mit Größe, Wert und Messverfahren ist die Anforderung prüfbar, und erst dann kann jemand widersprechen, wenn der Wert unrealistisch ist.
Den Testfall neben die Anforderung schreiben
Formuliert zu jeder Anforderung mindestens einen Fall aus Ausgangslage, Auslöser und erwartetem Ergebnis. Diese Übung ist der schärfste Prüfstein: Wenn sich der Fall nicht schreiben lässt, ist die Anforderung noch nicht fertig, und das merkt ihr in Minuten statt Monaten.
Jede Anforderung eindeutig kennzeichnen und verbinden
Eine stabile Kennung, eine Verbindung zum Testfall und zur Umsetzung, ein Zustand und ein Verantwortlicher. Mehr Verwaltung braucht es am Anfang nicht, und weniger reicht nicht, sobald die erste Änderung kommt.
Vor dem Bau gemeinsam lesen
Ein kurzes Review mit Fachbereich, Entwicklung und Test findet Mehrdeutigkeiten in der Zeit, in der sie noch nichts kosten. Wichtig ist die Besetzung: Ohne den Test fehlt genau die Perspektive, die nach der Prüfbarkeit fragt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die Form über die Prüfbarkeit entscheidet
Eine Schablone ist kein Selbstzweck. Sie erzwingt, dass in jedem Satz die vier Bestandteile vorkommen, ohne die eine Anforderung unvollständig bleibt: wer handelt, wie verbindlich es ist, was geschieht und unter welcher Bedingung. Fehlt der Akteur, weiß niemand, ob das System, der Anwender oder ein Nachbarsystem gemeint ist. Fehlt die Bedingung, gilt der Satz scheinbar immer, und genau daran scheitert später die Abnahme.
Es gibt verschiedene ausformulierte Ansätze dafür. Im deutschsprachigen Raum sind Satzschablonen verbreitet, die genau diese Bestandteile in eine feste Reihenfolge bringen, und im englischsprachigen Umfeld ist ein Ansatz üblich, der die Anforderung nach dem Auslöser unterscheidet, also danach, ob sie immer gilt, ob sie durch ein Ereignis ausgelöst wird, ob sie an einen Zustand gebunden ist oder ob sie einen unerwünschten Fall abdeckt. Welchen ihr nehmt, ist zweitrangig; entscheidend ist, dass ihr euch für einen entscheidet.
Der Nutzen zeigt sich beim Lesen. Wenn alle Anforderungen nach demselben Muster gebaut sind, überfliegt man dreißig Sätze in wenigen Minuten und erkennt die auffälligen sofort, nämlich die, in denen ein Bestandteil fehlt. Ohne Muster liest man dreißig unterschiedlich gebaute Absätze und übersieht zuverlässig die Hälfte der Lücken, weil die Aufmerksamkeit beim Entziffern des Satzbaus verbraucht wird.
Funktion, Qualität und Randbedingung auseinanderhalten
Eine funktionale Anforderung beschreibt, was das System tut: Es berechnet, es speichert, es meldet, es weist zurück. Sie ist meist unstrittig und lässt sich gut in einen Testfall überführen. Der übliche Fehler ist hier nicht die Formulierung, sondern die Menge: Ein Satz mit mehreren Verben enthält mehrere Anforderungen, und jede davon braucht eine eigene Kennung, weil sie einzeln umgesetzt, geprüft und geändert wird.
Eine Qualitätsanforderung beschreibt, wie gut das System etwas tut. Sie ist der Ort, an dem am meisten Geld verbrannt wird, weil sie oft unspezifisch bleibt und trotzdem als vereinbart gilt. Antwortzeiten, Verfügbarkeit, gleichzeitige Nutzung, Wiederherstellungszeit, Anforderungen an Vertraulichkeit und Nachvollziehbarkeit gehören hierher, und jede von ihnen braucht Größe, Wert und Messverfahren. Diese Anforderungen bestimmen häufig die Architektur, deshalb müssen sie früh vorliegen und nicht erst kurz vor der Abnahme.
Eine Randbedingung ist etwas, das ihr nicht verhandeln könnt: eine gesetzliche Vorgabe, ein vorhandenes System, an das angebunden werden muss, eine Betriebsvorgabe des Rechenzentrums, ein Termin. Sie gehört ausdrücklich aufgeschrieben, weil sie Entwurfsentscheidungen ausschließt. Der häufigste Fehler ist, sie mit einer Anforderung zu vermengen, denn dann sieht es so aus, als sei sie verhandelbar, und die Diskussion darüber kommt jedes Mal aufs Neue.
Anforderung, User Story und Akzeptanzkriterium
Eine User Story ist keine Anforderung, sie ist eine Erinnerung an ein Gespräch. Der bekannte Satz aus Rolle, Wunsch und Nutzen sagt, für wen etwas gebaut wird und warum, aber er sagt nicht, was genau geschehen soll. Das Prüfbare steckt in den Akzeptanzkriterien, die daneben stehen, und genau dort passiert die eigentliche Arbeit des Aufschreibens.
Für die Akzeptanzkriterien hat sich eine Form aus Ausgangslage, Auslöser und erwartetem Ergebnis durchgesetzt, die sich in vielen Teams auch als ausführbarer Test schreiben lässt. Der Nutzen ist derselbe wie bei der Satzschablone für Anforderungen: Die Form erzwingt die Bestandteile. Wer den Auslöser nicht benennen kann, hat noch nicht verstanden, wann die Funktion überhaupt greift.
Für den Alltag heißt das: In agilen Vorhaben ersetzt die Story die Anforderung nicht, sie ordnet sie nur anders an. Die inhaltliche Sorgfalt bleibt gleich, und für Qualitätsanforderungen und Randbedingungen braucht ihr ohnehin einen Ort außerhalb der Stories, weil sie nicht zu einer einzelnen Aufgabe gehören, sondern für alle gelten. Häufig wird daraus eine kurze Liste, die für jede Aufgabe gilt und in der Definition dessen steht, was als fertig zählt.
Verfolgbarkeit ohne Bürokratie
Verfolgbarkeit heißt: Zu jeder Anforderung lässt sich sagen, woher sie kommt, wodurch sie umgesetzt und wodurch sie geprüft wird. Das klingt nach Verwaltung und ist im Kern nur eine Kennung mit ein paar Verbindungen. Der Nutzen zeigt sich bei der ersten Änderung, wenn die Frage kommt, was betroffen ist, und bei der Abnahme, wenn jemand belegt haben will, dass nichts vergessen wurde.
Wichtig ist der Zuschnitt. Eine Verbindung von jeder Anforderung zu jedem einzelnen Codeabschnitt ist Aufwand ohne Ertrag und veraltet sofort. Was sich trägt, sind drei Verbindungen: zur Quelle, also zur Person oder zum Dokument, aus dem die Anforderung stammt, zum Testfall, und zur Aufgabe, in der die Umsetzung stattfand. Damit sind die Fragen beantwortet, die tatsächlich gestellt werden.
In regulierten Bereichen ist die Sache strenger, und dort ist die Verfolgbarkeit Teil des Nachweises gegenüber einer Prüfstelle. Wenn ihr in diesem Umfeld arbeitet, klärt früh, welches Werkzeug die führende Quelle für Anforderungen ist und wie die Verbindungen entstehen. Zwei Orte, an denen dieselben Anforderungen gepflegt werden, sind der verlässlichste Weg zu zwei Wahrheiten, und die Prüfung findet immer die veraltete.
Was in einem Review auffällt
Ein Review von Anforderungen dauert kurz und findet viel, wenn die Besetzung stimmt. Nötig sind drei Blickwinkel: der Fachbereich, der sagen kann, ob der Bedarf richtig getroffen ist, die Entwicklung, die sagt, ob sich daraus etwas bauen lässt, und der Test, der als Einziger konsequent nach der Prüfbarkeit fragt. Fehlt der letzte, bleibt der häufigste Mangel unentdeckt.
Die Prüfliste ist kurz. Enthält der Satz genau eine Anforderung? Steht ein Akteur darin? Ist die Verbindlichkeit über ein vereinbartes Modalverb ausgedrückt? Kommen Wörter vor, die eine Empfindung beschreiben statt eines Verhaltens? Ist eine Lösung vorgegeben, wo ein Bedarf gemeint war? Gibt es eine Zahl ohne Herkunft? Widerspricht die Anforderung einer anderen? Sechs bis sieben Fragen reichen, mehr wird nicht angewendet.
Ein Hinweis zum Umgang mit Befunden: Nicht jeder Mangel muss sofort behoben werden. Was zählt, ist, dass er festgehalten wird und dass entschieden ist, wer ihn behebt und bis wann. Eine Anforderung mit einer offenen Frage, die als offen markiert ist, richtet weniger Schaden an als eine, die eindeutig aussieht und es nicht ist, weil die erste noch jemanden zum Nachfragen bringt und die zweite direkt in den Bau geht.
Dazu passende Kurse
Weil Anforderung und Testfall zusammengehören, findest du beides bei cmt in die Kurse zu Requirements Engineering und Softwaretest .
Wenn die Reibung weniger an der Formulierung als an der Zusammenarbeit hängt, helfen Kurse zur Abstimmung zwischen Fachbereich und Entwicklung an der richtigen Stelle.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Brauchen wir ein Lastenheft, wenn wir agil arbeiten?
Reicht eine User Story als Anforderung?
Wie messbar muss eine Qualitätsanforderung sein?
Wer schreibt die Anforderungen, Fachbereich oder Entwicklung?
Lohnt sich eine Zertifizierung im Requirements Engineering?
Welches Werkzeug brauchen wir dafür?
Passt thematisch dazu
Sobald diese Arbeit regelmäßig anfällt und nicht mehr nebenherläuft, stellt sich die Frage, wo die Anforderungsarbeit zur eigenen Rolle wird und wie sie sich vom Product Owner abgrenzt.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
An eigenen Anforderungen üben statt an Beispielsätzen
Bei cmt bringst du Anforderungen aus einem laufenden Vorhaben mit und formulierst sie so um, dass daraus Testfälle werden. Genau an dieser Übung zeigt sich, welche Sätze bisher nur eindeutig aussahen.