Arten von Anforderungen
Das IREB unterscheidet drei Arten. Die Trennung hilft, nichts zu vergessen, denn in Gesprächen dominieren fast immer die Funktionen.
Für Qualitätsanforderungen bietet die Norm ISO/IEC 25010 einen Katalog von Merkmalen, etwa Zuverlässigkeit, Sicherheit, Performanz und Wartbarkeit. Diese Anforderungen prägen später die Softwarearchitektur stärker als jede einzelne Funktion.
Woran du eine gute Anforderung erkennst
ISO/IEC/IEEE 29148 nennt Merkmale guter Einzelanforderungen. Die wichtigsten für die Praxis:
- Notwendig: Fällt sie weg, fehlt dem System etwas Wesentliches.
- Eindeutig: Es gibt nur eine Lesart. Wörter wie „schnell“, „einfach“ oder „benutzerfreundlich“ sind ohne Messgröße nicht eindeutig.
- Vollständig und einzeln: Eine Anforderung beschreibt genau eine Sache, und zwar ganz.
- Machbar: Sie lässt sich mit den vorhandenen Mitteln umsetzen.
- Verifizierbar: Man kann prüfen, ob sie erfüllt ist. Daraus werden später Akzeptanzkriterien und Testfälle.
Methoden der Anforderungsanalyse
Keine Technik passt für alle Vorhaben. In der Praxis kombinierst du mehrere, je nachdem, ob das Wissen in Köpfen, in Dokumenten oder in einem Altsystem steckt.
Ein Klickdummy ist besonders hilfreich, wenn die Beteiligten erst beim Anschauen merken, was ihnen fehlt. Für fachlich komplexe Abläufe eignet sich Event Storming: Fachleute und Entwickler legen die Ereignisse eines Prozesses gemeinsam auf eine Zeitachse.
Dokumentieren und priorisieren
Je nach Vorgehen landen die Ergebnisse in einem Lastenheft (Sicht des Auftraggebers), einem Pflichtenheft (Antwort des Auftragnehmers), in Use Cases oder als User Stories in einem Product Backlog. Zur Priorisierung dienen etwa MoSCoW (Must, Should, Could, Won't) oder das Kano-Modell, das Basis-, Leistungs- und Begeisterungsmerkmale unterscheidet. Basismerkmale fallen Nutzern erst auf, wenn sie fehlen, und werden in Interviews deshalb oft gar nicht genannt.
Beispiel: Anforderungsanalyse für ein Kundenportal
Ein Großhändler möchte, dass Geschäftskunden Nachbestellungen selbst online auslösen, statt per E-Mail und Telefon. Die erste Aussage lautet: „Die Kunden sollen online bestellen können.“ Die Analyse macht daraus prüfbare Anforderungen:
- Ermitteln: Interviews mit Vertrieb und Innendienst zeigen, dass jeder Kunde eigene Preise und ein eigenes Sortiment hat und dass Bestellungen heute im ERP von Hand erfasst werden.
- Analysieren: Daraus folgen eine funktionale Anforderung (kundenspezifische Preise anzeigen), eine Randbedingung (Preise und Bestände kommen ausschließlich aus dem ERP) und eine Qualitätsanforderung (Bestand und Preis sind beim Bestellabschluss aktuell).
- Formulieren: Als User Story: „Als Einkäufer eines Geschäftskunden möchte ich eine frühere Bestellung mit einem Klick wiederholen, damit ich Standardware schneller nachbestelle.“ Akzeptanzkriterium: Nicht mehr lieferbare Artikel werden vor dem Absenden markiert, und der Warenkorb übernimmt nur lieferbare Positionen.
- Prüfen: Im Review mit Vertrieb und Buchhaltung fällt auf, dass Kunden mit offenen Posten nicht bestellen dürfen. Diese Regel stand in keinem Dokument und wird als neue Anforderung aufgenommen.
Der letzte Schritt zeigt den Nutzen: Die Regel zu offenen Posten wäre ohne Analyse erst nach dem Livegang als Fehler aufgefallen.
Anforderungsanalyse vs. Anforderungsmanagement
Die beiden Begriffe werden oft gleichgesetzt, beschreiben aber verschiedene Aufgaben. Die Anforderungsanalyse klärt, welche Anforderungen gelten. Das Anforderungsmanagement sorgt dafür, dass diese Anforderungen über die gesamte Laufzeit eines Projekts und darüber hinaus nachvollziehbar, aktuell und konsistent bleiben.
Kern des Anforderungsmanagements ist die Verfolgbarkeit (Traceability): Zu jeder Anforderung ist erkennbar, woher sie stammt, wo sie umgesetzt ist und mit welchem Test sie geprüft wird. Kommt eine Änderung, zeigt diese Verknüpfung, welche Teile des Systems betroffen sind. In agilen Teams übernimmt das gepflegte Product Backlog viele dieser Aufgaben. In regulierten Umgebungen oder bei Festpreisprojekten ist ein formaler Änderungsprozess mit Bewertung und Freigabe üblich.
Anforderungsanalyse im agilen und im klassischen Projekt
Im klassischen Vorgehen, etwa nach dem V-Modell, steht die Anforderungsanalyse als eigene Phase am Anfang, und ihre Ergebnisse werden vertraglich festgeschrieben. In der agilen Softwareentwicklung verschwindet sie nicht, sondern verteilt sich: Ein grobes Zielbild und die wichtigsten Randbedingungen werden früh geklärt, die Details jeder User Story kurz vor ihrer Umsetzung. Eine Discovery-Phase verbindet beides, weil sie Problem, Nutzer und technische Risiken untersucht, bevor das erste Inkrement gebaut wird.
Die häufigsten Fehler sind in beiden Welten gleich: nur mit Entscheidern statt mit späteren Nutzern sprechen, Lösungen statt Probleme aufschreiben („Wir brauchen ein Dropdown“) und Qualitätsanforderungen auf später verschieben. Wenn du die Analyse nicht allein stemmen willst, unterstützen wir dich mit Anforderungsanalyse und Projektmanagement von der Stakeholder-Runde bis zum priorisierten Backlog.
FAQ zur Anforderungsanalyse
Was ist eine Anforderungsanalyse einfach erklärt?
Die Anforderungsanalyse klärt vor der Entwicklung, was eine Software können muss, für wen und unter welchen Bedingungen. Dazu werden die Beteiligten befragt, Abläufe und Dokumente untersucht und die Ergebnisse als eindeutige, überprüfbare Anforderungen festgehalten.
Wer führt die Anforderungsanalyse durch?
Meist ein Requirements Engineer, Business Analyst oder Product Owner, gemeinsam mit den Fachabteilungen. Wichtig ist, dass jemand die Gespräche neutral moderiert und sowohl die fachliche als auch die technische Sprache versteht.
Was ist der Unterschied zwischen Anforderungsanalyse und Lastenheft?
Die Anforderungsanalyse ist die Tätigkeit, das Lastenheft ist ein mögliches Ergebnis davon. Im Lastenheft hält der Auftraggeber die ermittelten Anforderungen lösungsneutral fest, oft als Grundlage für eine Ausschreibung.
Welche Methoden der Anforderungsanalyse gibt es?
Gängig sind Interviews, Workshops, Beobachtung am Arbeitsplatz, Dokumenten- und Systemanalyse, Fragebögen sowie Prototypen und Klickdummys. Für die Dokumentation werden Use Cases, User Stories, Prozessmodelle und Lastenhefte genutzt, für die Priorisierung etwa MoSCoW oder das Kano-Modell.
Was ist Anforderungsmanagement?
Anforderungsmanagement ist das Verwalten von Anforderungen über die gesamte Laufzeit eines Systems: versionieren, priorisieren, Änderungen bewerten und freigeben sowie nachverfolgen, wo jede Anforderung umgesetzt und getestet ist. Die Anforderungsanalyse liefert die Inhalte, das Anforderungsmanagement hält sie aktuell.
Du willst aus den Ergebnissen ein abnahmefähiges Dokument machen? Wir helfen dir, das Lastenheft und die Spezifikation so zu schreiben, dass du Angebote vergleichen kannst. Wie ein Lastenheft konkret aufgebaut ist, zeigt unser Leitfaden zu Lastenheft und Pflichtenheft.
