Anforderungsanalyse: Anforderungen richtig formulieren

Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung, die ein Produkt, ein System oder ein Prozess erfüllen soll. Die Anforderungsanalyse ist ein Teil der Systementwicklung. Ihr Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln, zu strukturieren und zu prüfen.

Das International Requirements Engineering Board (IREB) nennt dafür vier Tätigkeiten: Ermitteln, Dokumentieren, Prüfen und abstimmen sowie Verwalten. Üblicherweise werden Anforderungen erst gesammelt, dann dokumentiert und danach geprüft. Das Verwalten läuft dagegen neben allen anderen Tätigkeiten her.

Das Ergebnis wird meistens in einem Lastenheft dokumentiert. Das ist ein Dokument, in dem die Anforderungen des Auftraggebers festgehalten sind. Bei agiler Softwareentwicklung, zum Beispiel in Scrum, entsteht stattdessen ein Product Backlog als Ergebnis der Analyse. Die Anforderungen müssen außerdem zwischen Kunde und Entwickler abgestimmt werden. Das kann ein iterativer Prozess werden, also einer mit mehreren Runden, der die Anforderungen immer weiter verfeinert.

Am verbreitetsten ist die Unterteilung in funktionale und nichtfunktionale Anforderungen. Daneben werden häufig auch Randbedingungen als Anforderungen beschrieben.

Eine funktionale Anforderung legt fest, was das Produkt tun soll. Ein Beispiel: „Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.“ (Saldo heißt Kontostand.)

Eine nichtfunktionale Anforderung geht über die funktionale Anforderung hinaus. Sie beschreibt, wie gut das System die Leistung erbringen soll. Ein Beispiel: „Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten.“ Zu den Qualitätseigenschaften zählen etwa Zuverlässigkeit, Benutzbarkeit und Leistung mit Antwortzeiten. Achtung: Nichtfunktionale Anforderungen sind in der Literatur nicht einheitlich definiert. Sie werden vielfach als Randbedingungen und Qualitätseigenschaften verstanden. Die Grenze kann also je nach Quelle anders gezogen werden.

Häufig werden neben diesen beiden Typen auch Randbedingungen (englisch Constraints) als Anforderungen beschrieben. Häufige Randbedingungen sind eine Obergrenze für Kosten und ein einzuhaltender Termin für den Abschluss des Projekts.

Merkhilfe: „Was?“ führt zu funktional, „Wie gut?“ zu nichtfunktional, „Welcher Rahmen?“ zu einer Randbedingung.

Anforderungen werden oft in natürlicher Sprache geschrieben. Die muss gedeutet werden, und manche Voraussetzungen gelten als selbstverständlich und werden nicht erwähnt. Deshalb braucht es möglichst präzise Kommunikation.

Drei Kriterien helfen dir:

Eindeutig: Präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden. Jeder soll dasselbe unter dem Satz verstehen.

Atomar: Es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein „Atom“ sollte die Entscheidbarkeit einer Anforderung sein. Du fragst also: Kann man klar entscheiden, ob genau diese Anforderung erfüllt ist?

Nachprüfbar: Die Anforderung wird mit einem Abnahmekriterium verknüpft. Daraus werden später Testfälle abgeleitet. Ein Wort wie „schnell“ lässt sich nicht prüfen, ein Wert wie „innerhalb von einer Sekunde“ schon.

Außerdem sollte jede Anforderung eindeutig identifizierbar sein, zum Beispiel über eine Kennung oder Nummer.

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz und umfasst in der Regel nicht mehr als zwei Sätze. Als Vorlage dient: „Als (Rolle) möchte ich (Ziel/Wunsch), um (Nutzen)“. Der Autor der Story sollte der Kunde des Software-Projektes sein. Ein Beispiel: „Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.“

User Stories werden in der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. Mit den Akzeptanzkriterien beschreibt der Anforderer, wie er die korrekte Umsetzung der User Story testen würde. Traditionell stehen sie auf der Rückseite der Story-Card, also der Karte, auf der die Story steht.

Im Extreme Programming (XP), einer agilen Methode, gilt: Eine User Story kann einen oder mehrere Akzeptanztests brauchen. Sie gilt nicht als abgeschlossen, wenn sie den Akzeptanztest nicht besteht.

Beim Behavior Driven Development schreibt man die Kriterien als Szenarien mit festem Aufbau. Dazu dient oft die Gherkin-Syntax mit den Wörtern Gegeben, Wenn, Dann und Und. Die Wörter sind aber nicht unumgänglich. Das Ziel ist, dass sich die Kriterien automatisch testen lassen.

So gehst du vor: Lies Rolle, Ziel und Nutzen. Überlege, wie der Anforderer die Umsetzung testen würde. Schreibe Ausgangslage, Handlung und erwartetes Ergebnis mit konkreten Werten auf. Frage dann, ob das Ergebnis immer gilt. So können weitere Szenarien entstehen. Akzeptanzkriterien müssen klar, präzise und zumindest prinzipiell automatisch testbar sein. Das Abnahmekriterium aus dem vorigen Abschnitt beschreibt eine messbare Bedingung. Darum sind konkrete Werte besser als vage Wörter.