Dokumentieren von Anforderungen

Dokumentieren von Anforderungen

https://oer-informatik.de/anforderungsanalyse-dokumentieren

Anforderungen dokumentieren, Requirements Engineering, Lastenheft, Pflichtenheft, Anwendungsfall, Use-Case-Diagramm, User Story, Satzschablone, INVEST, Akzeptanzkriterium, FURPS

https://bildung.social/@oerinformatik/109422853120283884

tl/dr; (ca. 13 min Lesezeit): Es stehen die Wünsche der Stakeholder im Raum – und auch die Normen und Gesetze wollen als Anforderung dokumentiert werden. Welche unterschiedlichen Artefakte gibt es, in denen Anforderungen erfasst werden können, und wo eignen sie sich besonders [AI-Assisted]? (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Bestandteil einer mehrteiligen Reihe zu Requirements Engineering:

Dieser Artikel baut auf der Kann-Liste der Artikel Anforderungsanalyse und Anforderungsermittlung auf.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.

Als Grundlagen der Anforderungsdokumentation kann ich nach Durchlesen des Artikels…

  • … Artefakte nennen, in denen Anforderungen dokumentiert werden (Anforderungsdokumente, Anwendungsfälle, Product Backlog Items, User Stories und Satzschablonen).

  • … Lastenheft und Pflichtenheft nach Verfasser, Inhalt und Sprache unterscheiden.

  • … erläutern, wofür Use-Case-Diagramme genutzt werden und warum sie nur eine Übersicht der Anwendungsfälle sind.

  • … den Aufbau einer User Story nennen und Anforderungen mit einer Satzschablone formulieren.

  • … die I.N.V.E.S.T.-Kriterien nennen und erklären.

  • … die Angaben nennen, die zu einer Anforderung erfasst werden sollten (Name, Beschreibung, Akzeptanzkriterium, Testfälle, Risiko, Aufwand).

Darüber hinaus kann ich als Expertenwissen zur Anforderungsdokumentation…

  • … für Qualitätsanforderungen messbare Akzeptanzkriterien (Metriken) formulieren, z. B. für Usability, Reliability, Performance und Supportability.

Haupttätigkeit 2: Dokumentieren der Anforderungen (requirements documentation)

Je nach Vorgehensmodell und Granularität (Detailgrad) der erfassten Anforderungen können sich die Dokumentationsmittel unterscheiden. Die Mindmap zeigt die Formen, um die es in diesem Artikel geht:

Mindmap der Dokumentationsformen für Anforderungen: Anforderungsdokumente, Anwendungsfälle, Product Backlog Items, User Stories, Satzschablone und Angaben je Anforderung (mit KI erstellt)

Übersicht von Anforderungen

Anforderungen können auf verschiedenste Art dokumentiert werden. Wichtig ist hierbei, dass die wesentlichen Kriterien (siehe unten) genannt sind. In der folgenden Phase wird die Qualität der so erfassten Anforderungen überprüft.

Um das big picture von Anforderungen zu erhalten, bieten sich beispielsweise folgende Artefakte an:

Dokumentationsformen für Anforderungen im Überblick
Form eignet sich, wenn … typische Darstellung
Anforderungsdokumente (Lastenheft, Pflichtenheft) die Anforderungen von Beginn an weitgehend feststehen; das Pflichtenheft wird oft Vertragsbestandteil Stichpunktliste bis formelles Dokument, auch tabellarisch
Anwendungsfälle funktionale Anforderungen mit Stakeholdern im Dialog erarbeitet und im Überblick gezeigt werden sollen UML-Anwendungsfalldiagramm, tabellarische Beschreibung mit Szenarien
Product Backlog Items agil gearbeitet wird und Anforderungen als einzelne, möglichst unabhängige Einträge gesammelt werden Einträge im Backlog, geprüft mit den I.N.V.E.S.T.-Kriterien
User Stories / Satzschablonen Anforderungen einheitlich, einfach und präzise formuliert werden sollen „Als ROLLE möchte ich ZIEL, um zu NUTZEN“ bzw. „Das System muss …“
Anforderungsdokumente (Lastenheft / Pflichtenheft)

Stehen die Anforderungen von Beginn an weitgehend fest, können sie oft vorab textuell aufgelistet werden:

  • In diesen Anforderungsdokumenten können funktionale und nicht-funktionale Anforderungen festgeschrieben werden. Der Grad an Formalität kann von Stichpunktlisten bis hin zu streng formellen Dokumenten reichen.

  • Das Lastenheft wird durch den Auftraggeber erstellt (DIN 69901-5: vom Auftraggeber festgelegte Gesamtheit der Forderungen): Was soll umgesetzt werden und warum? Es enthält oft noch keine technische Sicht und ist in der Sprache der Problemdomäne formuliert. (Hier ein Beispiel für ein Microcontrollerprojekt)

  • Im Pflichtenheft erarbeitet der Auftragnehmer, wie und womit die Anforderungen des Lastenhefts umgesetzt werden sollen. Es beschreibt Werkzeuge und (grobe) Entwürfe und nutzt die Sprache der Lösungsdomäne. Das Pflichtenheft wird in der Regel Vertragsbestandteil und sollte mit entsprechender Sorgfalt erstellt werden. (Hier ein Beispiel für ein Microcontrollerprojekt)

Pflichtenhefte können auch in Stichpunkten oder tabellarisch ausgeführt sein. Beispielhaft könnten folgende Aspekte erfasst werden:

Beispiel für die tabellarische Erfassung einer Anforderung
Nr. Name der Anforderung Beschreibung des Nutzens und der Realisierung
(z.B. als Satzschablone)		 Akzeptanzkriterium
(wann gilt Anforderung als erfüllt)		 Grundlegende Testfälle
(Dokumentation von Eingabe, Randbedingung, erwartetem Ergebnis an anderer Stelle)		 Priorisierung / Risiko
bei Nichterfüllung		 Geschätzter Aufwand
1. Einschalten Das System muss einfach per Taster einschaltbar sein, um mit der Benutzung starten zu können. Betätigen eines Knopfs führt innerhalb von 10s in das Startmenü mit aktivierter Anzeige. 1. Einschalten wenn aus: an
2. Einschalten wenn an: Meldung
3. Einschalten während Hochfahren: Meldung
4. Einschalten während Runterfahren: Meldung		 must-have

Ausschlusskriterium		 2h
Anwendungsfälle (Use-Cases)

Anwendungsfälle können tabellarisch oder als Übersicht per UML-Anwendungsfalldiagramm erfasst werden.

  • “A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.” (Ivar Jacobson) 1
  • Anwendungsfälle können in UML Use-Case-Diagrammen (Anwendungsfalldiagramm) grafisch und übersichtlich dargestellt werden.
Beispiel eines UML-Anwendungsfalldiagramms (Nutzerstatistik-Dashboard) mit Akteuren und «include»- und «extend»-Beziehungen

  • Mithilfe dieser einfachen grafischen Darstellungsform können Anwendungsfälle dialogisch mit Stakeholdern erarbeitet werden.

  • In Anwendungsfällen werden funktionale Anforderungen zusammengefasst, die gemeinsam von einem Akteur initiiert werden und den Anwendenden einen Nutzen bringen.

  • Use-Case-Diagramme sind jedoch nur eine Übersicht, Anwendungsfälle haben weit mehr Details! Die einzelnen Anwendungsfälle können im nächsten Schritt tabellarisch präzisiert werden. Hierbei werden ein Name, eine kurze Beschreibung, ein auslösender Akteur, Randbedingungen sowie Haupt- und Nebenszenarien erfasst.

  • Einzelne Wege durch den Anwendungsfall werden als Szenarien definiert und als Stichpunktliste oder ggf. als UML Aktivitäts-, Zustands- oder Sequenzdiagramm entworfen.

Product Backlog Items

Vor allem im agilen Umfeld werden die Anforderungen häufig als einzelne isolierte Tasks gesammelt. Diese Tasks sollten – unabhängig von der genutzten Technik – so formuliert werden, dass sie den I.N.V.E.S.T.-Kriterien genügen:

Die I.N.V.E.S.T.-Kriterien für Product Backlog Items
Name Beschreibung
I: Independent Jeder Task muss unabhängig von anderen Tasks umgesetzt werden können. Er sollte frei von Abhängigkeiten sein.
N: Negotiable Nichts ist in Stein gemeißelt. Der Inhalt eines Tasks ist im Team verhandelbar: sie können geteilt, geändert, zusammengelegt… werden.
V: Valuable Jeder Task produziert aus sich heraus einen Nutzen und hat einen Wert für den Anwender.
E: Estimable Das Team muss in der Lage sein, abschätzen zu können, wie lange es für jeden Task etwa benötigt. Erscheint die Schätzung nicht möglich, ist der Task vermutlich zu groß.
S: Small Tasks müssen die richtige Größe haben: zu große Tasks sollten unterteilt werden. Ziel muss es sein, dass jeder Eintrag innerhalb einer Iteration (oft sogar an einem Tag) umgesetzt werden kann.
T: Testable Alle Daten, die zum Testen des Tasks nötig sind, müssen genannt sein. Im einfachsten Fall sind dies Akzeptanzkriterien.
Userstories / Satzschablonen

Es kann hilfreich sein, zur Formulierung der Anforderungen auf Satzschablonen zuzugreifen, um die Formulierungen einfach und präzise zu halten. Die bekannteste Satzschablone stellen die User Stories dar, die festlegen, dass Rolle des Nutzers, Ziel der Anforderung und der Nutzen für die Anwender genannt werden müssen:

Als ROLLE möchte ich ZIEL, um zu NUTZEN

Ausführlich beschreibt das der Artikel User Stories.

Eine weitere Satzschablone, mit deren Hilfe Anforderungen beschrieben werden können, ist die folgende. Je nach Art der Anforderung beschreibt sie eine selbstständige Systemaktivität, eine Benutzerinteraktion („<wem?> die Möglichkeit bieten“) oder eine Schnittstelle („fähig sein“):

Syntaxdiagramm der Satzschablone: Das System muss, sollte, wird zukünftig oder kann zukünftig – als Systemaktivität, Benutzerinteraktion oder Schnittstelle – Objekt und Ergänzung sowie Prozesswort (mit KI erstellt)

Welche Informationen sollten zu Anforderungen erfasst werden?

Im Idealfall wird für jede Anforderung bereits im Vorfeld erfasst:

  • Name der Anforderung / des Tasks

  • Beschreibung (ggf. in Form von Satzschablonen)

  • Akzeptanzkriterium: Messbare und mit Stakeholdern abgestimmte Bedingung, wann eine Anforderung als erfüllt gilt (besonders bei nicht funktionalen Anforderungen wichtig!)

  • Grundlegende Testfälle (Eingabeparameter, Randbedingungen, erwartetes Ergebnis)

  • Risiko bei Nichterfüllung / fehlerhafter Erfüllung

  • Geschätzter Aufwand

Festlegung von Akzeptanzkriterien bei Qualitätsanforderungen

Die Beschreibung von Akzeptanzkriterien ist v. a. bei den Qualitätsanforderungen (also nichtfunktionalen Anforderungen, in der FURPS-Systematik die Bereiche U, R, P und S) schwierig. Es sollten nach Möglichkeit Metriken entwickelt und festgeschrieben werden, die die Erfüllung der Anforderung objektivieren. Ein paar Beispiele als Anhaltspunkt:

  • U wie Usability: Eine Person mit gegebenem Vorwissen muss eine definierte Aufgabe ohne Hilfe in einer definierten Zeitspanne abarbeiten können. Die Zeit wird gestoppt und ihr Verhalten beobachtet.

  • R wie Reliability: Das System wird mit einem Last- bzw. Stresstest bewusst an die Belastungsgrenze gebracht (definierte Anzahl an Zugriffen pro Zeiteinheit). Die akzeptablen Antwortzeiten oder verlorenen Pakete / Neustarts werden festgeschrieben. Informationen zu Abstürzen werden den Logfiles entnommen.

  • P wie Performance: Analog zur Reliability werden für die maximal erwarteten Nutzungsdaten Antwortzeiten des Systems erfasst und als Metrik festgeschrieben.

  • S wie Supportability: Hier kann z.B. festgeschrieben werden, wie lange ein Durchgang durch die CI/CD-Pipeline (also von der IDE bis zum getesteten Code in der Produktivumgebung) dauern darf. Die Update-Zyklendauer, die verpflichtende Benutzung von Clean-Code Metriken (zyklomatische Komplexität, Testabdeckung) geben darüber hinaus ein Maß der Wartbarkeit, das vereinbart werden kann.

Wie geht es weiter?

Noch haben wir uns keine Gedanken gemacht, welche Anforderungen wirklich wichtig sind – und woran ich gute Anforderungen erkenne. Darum geht es im nächsten Blogpost zu …

… Validierung und Verwaltung von Anforderungen (requirement validation)

Leitfragen

  1. In welchen Dokumenten / Artefakten können Anforderungen gesammelt und gemanagt werden?

Anforderungen werden in Anforderungsdokumenten (Lastenheft, Pflichtenheft), in Anwendungsfällen (UML-Anwendungsfalldiagramm und tabellarische Beschreibung), als Product Backlog Items und als User Stories bzw. mit Satzschablonen dokumentiert. Welche Form passt, hängt vom Vorgehensmodell und vom Detailgrad ab – siehe Abschnitt „Übersicht von Anforderungen“.

  1. Wie unterscheiden sich Lastenheft und Pflichtenheft?

Das Lastenheft erstellt der Auftraggeber: Es beschreibt in der Sprache der Problemdomäne, was umgesetzt werden soll und warum. Im Pflichtenheft legt der Auftragnehmer in der Sprache der Lösungsdomäne fest, wie und womit die Anforderungen umgesetzt werden; es wird in der Regel Vertragsbestandteil – siehe Abschnitt „Anforderungsdokumente (Lastenheft / Pflichtenheft)“.

  1. Wie ist der generelle Aufbau von Userstories?

Eine User Story nennt die Rolle der Nutzenden, ihr Ziel und den Nutzen: „Als ROLLE möchte ich ZIEL, um zu NUTZEN“. Als weitere Satzschablone kannst Du „Das System muss/sollte/wird … <wem?> die Möglichkeit bieten / fähig sein, <Objekt> zu <Prozesswort>“ nutzen – siehe Abschnitt „Userstories / Satzschablonen“.

  1. Welche Anforderungen können in einem Use-Case-Diagramm dargestellt werden, welche nicht?

Ein Use-Case-Diagramm zeigt funktionale Anforderungen als Anwendungsfälle mit den auslösenden Akteuren und ihren Beziehungen im Überblick. Details wie Randbedingungen, Haupt- und Nebenszenarien sowie nichtfunktionale Anforderungen stehen nicht im Diagramm, sondern in der tabellarischen Beschreibung der Anwendungsfälle bzw. in eigenen Anforderungen – siehe Abschnitt „Anwendungsfälle (Use-Cases)“.

  1. Was versteht man unter I.N.V.E.S.T.-Kriterien?

Die I.N.V.E.S.T.-Kriterien beschreiben gut formulierte Product Backlog Items: Independent (unabhängig), Negotiable (verhandelbar), Valuable (mit Nutzen), Estimable (schätzbar), Small (klein genug) und Testable (testbar) – siehe Abschnitt „Product Backlog Items“.

  1. Welche Angaben sollten zu einer Anforderung erfasst werden, und wie legst Du Akzeptanzkriterien für Qualitätsanforderungen fest?

Zu jeder Anforderung gehören Name, Beschreibung, Akzeptanzkriterium, grundlegende Testfälle, Risiko bei Nichterfüllung und geschätzter Aufwand. Für Qualitätsanforderungen legst Du messbare Metriken fest, z. B. die Bearbeitungszeit einer definierten Aufgabe (Usability) oder Antwortzeiten unter Last (Performance) – siehe Abschnitt „Welche Informationen sollten zu Anforderungen erfasst werden?“ und Abschnitt „Festlegung von Akzeptanzkriterien bei Qualitätsanforderungen“.

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Dokumentieren von Anforderungen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/anforderungsanalyse-dokumentieren veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/anforderungsanalyse. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

  1. Ivar Jacobson, der Initiator der UseCase-Diagramme, in “Use-Case 2.0”: https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf↩︎

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...