Anforderungsanalyse (Informatik)

Ziel und Ergebnis der Anforderungsanalyse

Die Anforderungsanalyse (englisch requirements analysis) ist ein Teil des Systementwicklungsprozesses und der Business-Analyse. Sie dient dazu, die Anforderungen des Auftraggebers an ein zu entwickelndes System zu ermitteln, zu strukturieren und zu prüfen. Damit schafft sie eine gemeinsame Grundlage für Auftraggeber und Entwickler: Es soll klar sein, was das System leisten soll und nach welchen Kriterien später beurteilt wird, ob es die Erwartungen erfüllt.

Das Ergebnis wird meistens in einem Lastenheft dokumentiert. Bei agiler Softwareentwicklung entsteht daraus ein Product Backlog. In den verschiedenen Vorgehensmodellen gehören außerdem das Dokumentieren beziehungsweise Spezifizieren, das Prüfen und Abstimmen sowie das fortlaufende Verwalten der Anforderungen dazu.

Bestandteile nach wichtigen Modellen

Das IEEE gliedert das Requirements Engineering in Anforderungserhebung, Anforderungsanalyse, Anforderungsspezifikation und Anforderungsbewertung. Diese Tätigkeiten überlappen sich und werden häufig iterativ, also mehrfach in wiederholten Durchläufen, ausgeführt.

Das Capability Maturity Model Integration (CMMI) des Software Engineering Institute der Carnegie Mellon Universität unterscheidet die Entwicklung von Anforderungen und das Management von Anforderungen.

Das Vorgehensmodell Volere von den Robertsons umfasst Anforderungsspezifikation, Stakeholder-Analyse, Bedarfsanalyse, Analyse der Priorisierung und die Aufzeichnung elementarer Anforderungen.

Der Business Analysis Body of Knowledge (BABOK) des International Institute of Business Analysis nennt die Anforderungserhebung, das Anforderungs-Management und die Kommunikation sowie die Anforderungsanalyse. Dazu gehören unter anderem das Ermitteln der Anforderungen von Stakeholdern, das Verwalten und Kommunizieren von Anforderungen, das Identifizieren wiederverwendbarer Anforderungen, die Vorbereitung zur Genehmigung, das Management von Änderungen sowie das Priorisieren, Strukturieren, Dokumentieren und Prüfen auf inhaltliche Qualität und Zielübereinstimmung.

Nach dem International Requirements Engineering Board (IREB) bestehen die zentralen Tätigkeiten aus Ermitteln, Dokumentieren, Prüfen und Abstimmen sowie Verwalten. Beim Ermitteln werden Techniken eingesetzt, um Anforderungen von Stakeholdern und anderen Quellen zu gewinnen, zu detaillieren und zu verfeinern. Die Verwaltung begleitet alle anderen Tätigkeiten; sie strukturiert Anforderungen, bereitet sie für verschiedene Rollen auf und ermöglicht konsistente Änderungen und Umsetzungen.

Ermitteln und eindeutig beschreiben

In allen Modellen werden Anforderungen zunächst gesammelt (elicitation), anschließend analysiert, textlich oder mit Modellen spezifiziert und schließlich validiert, also auf Stimmigkeit geprüft. Verwaltung und Management begleiten diesen Ablauf.

Besonders wichtig ist beim Sammeln der Übersetzungsprozess zwischen Fachseite und Entwicklung. Anforderungen müssen vollständig sein: Alle Kundenanforderungen sollen ausdrücklich beschrieben werden, ohne implizite Annahmen. Sie müssen eindeutig definiert oder abgegrenzt sein, damit Auftraggeber und Entwickler Missverständnisse vermeiden, und verständlich formuliert werden, sodass beide Seiten sie mit vertretbarem Aufwand lesen und verstehen können.

Eine Anforderung soll atomar sein: Ein Abschnitt oder Satz beschreibt nur eine Anforderung. Maßstab für ein solches „Atom“ ist, ob über die Anforderung entschieden werden kann. Außerdem muss jede Anforderung identifizierbar sein, etwa durch Kennung oder Nummer, und einheitlich dokumentiert werden; Anforderungen und ihre Quellen sollen nicht über verschieden strukturierte Dokumente verteilt sein.

Anforderungen müssen nachprüfbar sein. Dazu werden sie mit Abnahmekriterien verknüpft, aus denen sich Testfälle ableiten lassen. Ebenso müssen sie rück- und vorwärtsverfolgbar sein: Vorwärts muss erkennbar sein, ob eine Anforderung vollständig erfüllt wurde; rückwärts muss für jede implementierte Funktion nachvollziehbar sein, auf welcher Anforderung sie beruht. So wird Überflüssiges vermieden. Schließlich müssen die Anforderungen konsistent, also untereinander widerspruchsfrei, sein. Die Anforderungsaufnahme führt zunächst zu einer Anforderungsliste, die zum Beispiel in ein Lastenheft überführt werden kann.

Strukturieren und abstimmen

Nach der Erfassung werden Anforderungen strukturiert und klassifiziert. Das macht sie übersichtlicher und erleichtert das Verständnis ihrer Beziehungen. Dabei wird geprüft, ob Anforderungen abhängig sind, also ob eine Voraussetzung für eine andere ist, ob sie sich gegenseitig bedingen oder unabhängig voneinander umgesetzt werden können.

Fachlich-logisch zusammengehörige Anforderungen sollen nicht einzeln realisiert werden. Zudem werden Anforderungen rollenbezogen betrachtet, weil jede Benutzergruppe eine eigene Sicht auf die Anforderungen hat, die unterstützt werden soll.

Weitere Einteilungen unterscheiden funktionale und nichtfunktionale Anforderungen sowie fachlich motivierte Anforderungen – fachliche und technische – von technisch motivierten, also nur technischen Anforderungen. Die strukturierten Anforderungen werden zwischen Kunde und Entwickler abgestimmt. Diese Abstimmung kann iterativ erfolgen und dadurch die Anforderungen weiter verfeinern.

Prüfen, bewerten und priorisieren

Nach der Strukturierung oder teilweise parallel dazu wird die Qualität der Anforderungen gesichert. Sie müssen korrekt, also untereinander widerspruchsfrei, machbar und notwendig sein. Notwendig bedeutet: Was der Auftraggeber nicht fordert, ist keine Anforderung.

Anforderungen müssen außerdem priorisiert werden. Es soll erkennbar sein, welche Anforderungen am wichtigsten sind. Durch Priorisierung werden häufig benötigte oder für den Kunden besonders wichtige Funktionen vor weniger häufig benötigten bereitgestellt. Dies wird über eine Quantifizierung der Funktionszweige erreicht.

Auch Nutzbarkeit und Nützlichkeit sind wichtig: Selbst bei einer nur teilweisen Realisierung soll bereits ein produktives System entstehen. Das Ergebnis der Prüfung ist die Basis für das Pflichtenheft. Die Bewertungen können jedoch miteinander konkurrieren. Nur hoch priorisierte Aufgaben umzusetzen, ergibt nicht automatisch ein produktives System; bei der Bewertung muss neben einer einzelnen Funktion auch ihre Wirkung im Gesamtsystem betrachtet werden.