Softwareanforderungen richtig definieren: Von der Idee zur prüfbaren Spezifikation

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

Gute Softwareanforderungen sind eindeutig, notwendig, widerspruchsfrei, realistisch, priorisiert, rückverfolgbar und verifizierbar. Sie beschreiben nicht nur, was eine Software tun soll, sondern auch, für wen, unter welchen Bedingungen, mit welchem Ergebnis und wie die Erfüllung nachgewiesen wird.

Die wichtigste praktische Regel lautet: Gehen Sie vom Problem und Ziel aus – nicht von einer vorschnell gewählten Lösung. Aus der Stakeholder-Aussage „Wir brauchen ein Dashboard“ muss zunächst eine überprüfbare Beschreibung des Informationsbedarfs werden. Erst danach lässt sich entscheiden, ob ein Dashboard tatsächlich die richtige Lösung ist.

Was sind Softwareanforderungen?

Eine Softwareanforderung beschreibt eine benötigte Fähigkeit, ein Verhalten, eine Eigenschaft oder eine Randbedingung eines Softwaresystems. Sie kann sich auf Funktionen, Schnittstellen, Leistung, Sicherheit, Datenschutz, Bedienung, Betrieb, Migration oder gesetzliche und vertragliche Vorgaben beziehen.

Die IEEE-Definition versteht eine Anforderung als eine Bedingung oder Fähigkeit, die ein Nutzer zur Problemlösung oder Zielerreichung benötigt beziehungsweise die ein System aufgrund eines Vertrags, Standards oder formell vorgegebenen Dokuments erfüllen muss.

Nicht jede Aussage eines Stakeholders ist bereits eine fertige Anforderung:

Aussage	Einordnung
„Die Anwendung muss schneller werden.“	Wunsch oder Problem, noch nicht prüfbar
„Die Suchergebnisse sollen sofort erscheinen.“	Qualitätsziel, aber zu unpräzise
„Das System muss 95 Prozent der Suchanfragen innerhalb von zwei Sekunden beantworten.“	Messbare nichtfunktionale Anforderung
„Als Sachbearbeiter möchte ich Kunden nach E-Mail-Adresse suchen, um Datensätze schnell zu finden.“	User Story beziehungsweise Nutzeranforderung
„Das System muss bei einer gültigen E-Mail-Adresse den passenden Kundendatensatz anzeigen.“	Funktionale Anforderung

Requirements Engineering und Requirements Management

Requirements Engineering umfasst die inhaltliche Arbeit an Anforderungen:

1. Bedürfnisse und Ziele ermitteln
2. Anforderungen analysieren
3. Konflikte abstimmen und verhandeln
4. Anforderungen spezifizieren
5. Sie mit Stakeholdern validieren
6. Sie anhand neuer Erkenntnisse weiterentwickeln

Requirements Management sorgt dafür, dass diese Anforderungen über den gesamten Projektlebenszyklus kontrolliert bleiben. Dazu gehören Versionierung, Status, Priorisierung, Baselines, Abhängigkeiten, Änderungsmanagement, Reviews, Freigaben und Rückverfolgbarkeit. Auch Microsoft beschreibt Requirements Management als fortlaufenden Prozess und nicht als einmalige Dokumentation.

Eine Anforderungsliste ist deshalb kein Dokument, das nach der Freigabe unverändert abgearbeitet wird. Neue Nutzererkenntnisse, technische Entscheidungen, Risiken, regulatorische Vorgaben und Feedback können Änderungen erforderlich machen.

Welche Arten von Softwareanforderungen gibt es?

Geschäftsanforderungen

Geschäftsanforderungen beschreiben das übergeordnete Ziel der Organisation. Beispiele sind eine kürzere Bearbeitungszeit für Kundenanfragen, eine geringere Fehlerquote bei manuellen Eingaben, die Erfüllung einer Nachweispflicht oder die Erschließung eines neuen Vertriebskanals. Sie beantworten vor allem die Frage: Warum wird das Produkt oder die Funktion benötigt?

Stakeholder- und Nutzeranforderungen

Stakeholder-Anforderungen geben die Erwartungen einzelner Gruppen wieder: Kunden, Endanwender, Administratoren, Support, Management, Betrieb, Compliance oder externe Partner. Nutzeranforderungen konkretisieren, was eine bestimmte Rolle erreichen können muss.

Als Sachbearbeiter möchte ich Kundendaten anhand einer E-Mail-Adresse finden, damit ich Kundenanfragen schneller zuordnen kann.

×

The Tool Desk

Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Funktionale Anforderungen

Funktionale Anforderungen beschreiben, was das System tun muss. Typische Bereiche sind Eingaben, Verarbeitung, Geschäftsregeln, Ausgaben, Workflows, Berechtigungen, Im- und Exporte, Benachrichtigungen, Schnittstellen sowie Fehlerbehandlung.

Beispiel: „Das System muss berechtigten Sachbearbeitern ermöglichen, Kundendaten anhand einer E-Mail-Adresse zu suchen und den passenden Datensatz anzuzeigen.“

Nichtfunktionale Anforderungen

Nichtfunktionale Anforderungen beschreiben, wie gut, sicher oder unter welchen Bedingungen das System funktioniert. Dazu zählen Performance, Verfügbarkeit, Skalierbarkeit, Sicherheit, Datenschutz, Barrierefreiheit, Wartbarkeit, Portierbarkeit, Bedienbarkeit, Kompatibilität, Wiederherstellbarkeit und Auditierbarkeit.

Beispiel: „Das System muss bei 500 gleichzeitigen Nutzern 95 Prozent der Suchanfragen innerhalb von maximal zwei Sekunden beantworten.“ Der Wert ist ein projektspezifisches Beispiel und kein allgemeiner Standard. Er muss aus Messungen, Nutzerforschung, Risikoanalyse, Geschäftsentscheidungen oder technischen Tests abgeleitet werden.

Randbedingungen

Randbedingungen schränken die Lösungsfreiheit ein. Dazu gehören etwa eine vorgegebene Cloud-Plattform, die Integration in ein bestehendes ERP-System, eine bestimmte Programmiersprache, ein Branchenstandard, ein definierter Betriebsstandort oder vorhandene Hardware.

Übergangs- und Migrationsanforderungen

Bei der Einführung einer neuen Lösung müssen auch Datenübernahme, Parallelbetrieb, Schulung, Rollback, Archivierung historischer Daten und die Abschaltung des Altsystems betrachtet werden. Diese Anforderungen werden häufig vergessen, entscheiden aber maßgeblich darüber, ob die Einführung im Betrieb funktioniert.

Was zeichnet eine gute Anforderung aus?

Die internationale Referenz ist derzeit ISO/IEC/IEEE 29148:2018. Die Ausgabe wurde laut ISO 2024 überprüft und bestätigt. Ein vorhandener Entwurf für eine dritte Ausgabe (ISO-Seite zum Entwurf) darf nicht mit einer bereits veröffentlichten und gültigen Norm gleichgesetzt werden. Ergänzende Informationen bietet IEEE.

Die Norm ist ein Referenzrahmen, kein unveränderliches Rezept. Dokumentationsumfang, Notation und Werkzeuge sollten an Risiko, Teamgröße, Vorgehensmodell und Regulierungsgrad angepasst werden.

Eine belastbare Anforderung ist:

• eindeutig: Sie lässt möglichst nur eine sinnvolle Interpretation zu.
• notwendig: Ihr Nutzen oder ihre Verpflichtung ist bekannt.
• atomar: Sie beschreibt möglichst eine einzelne Forderung.
• konsistent: Sie widerspricht keiner anderen Vorgabe.
• vollständig genug: Bedingungen, Ergebnis und relevante Ausnahmefälle sind enthalten.
• realistisch: Sie ist technisch, organisatorisch und wirtschaftlich umsetzbar.
• priorisiert: Bedeutung und Dringlichkeit sind festgelegt.
• verifizierbar: Die Erfüllung kann durch Test, Inspektion, Analyse oder Demonstration festgestellt werden.
• rückverfolgbar: Quelle und Folgeartefakte sind bekannt.
• verständlich: Die vorgesehenen Leser können sie ohne unnötiges Spezialwissen interpretieren.

SMART kann dabei als Merkhilfe dienen, ersetzt aber nicht Kriterien wie Atomarität, Konsistenz, Traceability und Verifizierbarkeit.

Unklare Wörter ersetzen

Begriffe wie schnell, einfach, intuitiv, flexibel, robust, modern, sicher, möglichst, zeitnah oder ausreichend sind nur dann brauchbar, wenn das Projekt sie messbar definiert.

Schlecht: „Das System muss benutzerfreundlich und schnell sein.“

Besser: „Ein Erstnutzer muss einen neuen Kunden ohne Schulung in höchstens fünf Eingabeschritten anlegen können.“

Besser: „Das System muss den Speichervorgang bei 95 Prozent der Anfragen innerhalb von 1,5 Sekunden bestätigen.“

Ein geeignetes Satzmuster

Ein nützliches Muster lautet:

Das System muss [Funktion oder Verhalten] unter [Bedingung] für [Akteur oder Objekt] mit [messbarem Kriterium] ermöglichen.

Beispiele:

• „Das System muss berechtigten Sachbearbeitern ermöglichen, Kundendaten anhand einer E-Mail-Adresse zu suchen und innerhalb von zwei Sekunden höchstens 20 Treffer anzuzeigen.“
• „Das System muss nach drei fehlgeschlagenen Anmeldeversuchen das Benutzerkonto für 15 Minuten sperren.“
• „Das System muss alle Änderungen an Rechnungsdaten mit Benutzerkennung, Zeitstempel sowie altem und neuem Wert protokollieren.“

Verbindliche Modalverben sollten als Projektkonvention definiert werden: muss für zwingende Vorgaben, soll für verbindlich angestrebte Anforderungen, kann für optionale oder nachrangige Funktionen und darf nicht für ausdrückliche Verbote.

Softwareanforderungen systematisch erheben

1. Mit Problem und Ziel beginnen

Bevor Funktionen gesammelt werden, sollten Sie klären:

• Welches Problem besteht heute?
• Wer ist betroffen?
• Wie wird es aktuell gelöst?
• Was kostet oder verhindert die bestehende Situation?
• Woran lässt sich eine Verbesserung erkennen?
• Was geschieht, wenn nichts geändert wird?

Aus „Wir brauchen ein Dashboard“ können so konkrete Fragen entstehen: Welche Entscheidung soll damit getroffen werden? Wer nutzt es? Wie aktuell müssen die Daten sein? Welche Kennzahlen, Filter und Exportfunktionen werden gebraucht? Erst die Antworten zeigen, welche Anforderungen tatsächlich notwendig sind.

2. Stakeholder vollständig erfassen

Eine Stakeholder-Matrix kann so aussehen:

Stakeholder	Interesse	Einbindung
Endnutzer	Hoher Nutzwert und schnelle Abläufe	Interviews, Beobachtung, Usability-Tests
Fachbereich	Fachlich korrekte Prozesse	Workshops und Reviews
IT-Betrieb	Stabilität und betreibbare Architektur	Betriebs- und Architekturreview
Datenschutz und Security	Rechtmäßige und sichere Verarbeitung	Frühe Prüfungen und Risikoanalyse
Management	Wirtschaftlichkeit und Zielerreichung	Entscheidungen an Meilensteinen

Beziehen Sie nicht nur Auftraggeber und Nutzer ein. Support, Betrieb, Datenschutz, Sicherheit, Rechtsabteilung, Einkauf und externe Schnittstellen liefern oft Vorgaben, die sonst erst kurz vor der Einführung sichtbar werden.

3. Geeignete Erhebungsmethoden kombinieren

• Interviews: liefern Kontext, können aber durch Einzelmeinungen verzerrt sein.
• Workshops: machen Konflikte sichtbar, werden jedoch leicht von dominanten Teilnehmern geprägt.
• Beobachtung: zeigt reale Abläufe statt nur erinnerte Abläufe.
• Dokumentenanalyse: findet bestehende Prozesse, Verträge und Vorgaben.
• Prototypen: reduzieren Missverständnisse, dürfen aber nicht mit einer Funktionszusage verwechselt werden.
• Use Cases und Prozessmodelle: helfen bei komplexen Abläufen und Ausnahmefällen.
• Logs, Daten und Umfragen: ergänzen subjektive Aussagen um messbare Hinweise.

4. Aussagen klassifizieren

Ordnen Sie jede Aussage mindestens einer Kategorie zu: Ziel, Problem, Annahme, funktionale Anforderung, nichtfunktionale Anforderung, Randbedingung, offene Frage, Risiko, Entscheidung oder Abnahmekriterium. So werden Wünsche und Vermutungen nicht versehentlich als verbindliche Spezifikation behandelt.

5. Konflikte dokumentiert entscheiden

Typische Zielkonflikte entstehen zwischen maximaler Flexibilität und standardisiertem Betrieb, einfacher Bedienung und zusätzlichen Compliance-Nachweisen oder schneller Lieferung und umfangreichen Security-Prüfungen.

Die Lösung sollte nicht stillschweigend durch Interpretation erfolgen. Dokumentieren Sie betroffene Anforderungen, Entscheidung, Begründung, Entscheider, Datum, Auswirkungen und neue Risiken.

User Stories, Use Cases und SRS sinnvoll einsetzen

User Stories

Das verbreitete Format lautet:

Als [Rolle] möchte ich [Fähigkeit], damit [Nutzen].

User Stories eignen sich besonders für agile Produktentwicklung und nutzerzentrierte Kommunikation. Sie sind aber kein vollständiger Ersatz für jede andere Anforderung. Bei komplexen, sicherheitskritischen oder regulierten Produkten benötigen sie zusätzliche Geschäftsregeln, Datenmodelle, Rollen, Fehlerfälle, Schnittstellen, Qualitätsziele und Verifikationskriterien.

Use Cases

Ein Use Case beschreibt einen Ablauf zwischen Akteur und System:

1. Akteur startet den Vorgang.
2. Das System fordert Eingaben an.
3. Der Akteur liefert Daten.
4. Das System validiert die Eingabe.
5. Es wendet Geschäftsregeln an.
6. Es zeigt das Ergebnis.
7. Alternativ- und Fehlerpfade werden beschrieben.

Use Cases sind besonders hilfreich, wenn mehrere Rollen, Integrationen, Ausnahmen oder lange Geschäftsprozesse beteiligt sind.

SRS oder lebende Spezifikation

Eine Software Requirements Specification (SRS) ist sinnvoll, wenn mehrere Organisationen beteiligt sind, Verträge oder Ausschreibungen vorliegen, Nachweispflichten bestehen oder Anforderungen über lange Zeit formal archiviert werden müssen.

„Agil“ und „SRS“ sind jedoch keine Gegensätze. Ein agiles Team kann eine lebende, versionierte Spezifikation pflegen, die Epics, Features, User Stories, Architekturentscheidungen, Tests und Freigaben verbindet. Entscheidend ist, dass die Dokumentation aktuell bleibt und einen konkreten Zweck erfüllt.

Funktionale Anforderungen vollständig beschreiben

Eine funktionale Anforderung sollte möglichst beantworten:

• Wer löst die Funktion aus?
• Was ist der Auslöser?
• Welche Eingaben sind erlaubt?
• Welche Vorbedingungen gelten?
• Welche Verarbeitung und Geschäftsregeln gelten?
• Was ist das erwartete Ergebnis?
• Was passiert bei ungültigen Eingaben?
• Welche Berechtigungen gelten?
• Was muss protokolliert werden?

Eine praktische Vorlage:

ID:
Titel:
Quelle:
Ziel oder Nutzen:
Akteur:
Auslöser:
Vorbedingungen:
Eingaben:
Systemverhalten:
Ausgaben:
Fehler- und Ausnahmefälle:
Berechtigungen:
Akzeptanzkriterien:
Priorität:
Abhängigkeiten:
Verifikationsmethode:
Status:
Version:

Nicht jedes Projekt benötigt jedes Feld. In kleinen Vorhaben genügt eine Kurzform, solange Herkunft, Inhalt, Prüfung, Priorität und Status nicht verloren gehen.

Nichtfunktionale Anforderungen messbar machen

Performance

Statt „Das System muss schnell reagieren“ sollten Lastprofil, Messpunkt, Datensatzgröße, Netzwerksituation, Perzentil und akzeptierte Fehlerquote festgelegt werden. Beispiel: „Bei 500 gleichzeitigen Sitzungen beantwortet das System 95 Prozent der Suchanfragen innerhalb von zwei Sekunden.“

Verfügbarkeit

„Die Anwendung muss jederzeit verfügbar sein“ ist nicht ausreichend. Eine präzisere Formulierung könnte lauten: „Der produktive Dienst muss monatlich eine Verfügbarkeit von 99,9 Prozent erreichen, ausgenommen zuvor angekündigte Wartungsfenster.“ Zusätzlich muss geklärt werden, wie externe Dienste, geplante Wartung und Ausfälle von Abhängigkeiten behandelt werden.

Sicherheit

„Das System muss sicher sein“ beschreibt ein Ziel, aber keine überprüfbare Anforderung. Mögliche Konkretisierungen betreffen Authentifizierung, Rollen, Verschlüsselung, Sitzungsablauf, Berechtigungsprüfungen, Protokollierung, Schwachstellenbehandlung, Angriffserkennung und Wiederherstellung.

Beispiel: „Nach fünf aufeinanderfolgenden fehlgeschlagenen Anmeldeversuchen sperrt das System das Konto für 15 Minuten.“

Datenschutz

„DSGVO-konform“ ist allein keine vollständige technische Spezifikation. Je nach Land, Branche, Datenart und Einsatzszenario müssen unter anderem verarbeitete Daten, Zweck, Rechtsgrundlage, Speicherfristen, Löschung, Berichtigung, Zugriff, Auskunft, Protokollierung und Datenübermittlung geklärt werden. Die konkrete rechtliche Bewertung gehört in die zuständige Datenschutz- oder Rechtsberatung.

Barrierefreiheit

Auch „Die Anwendung muss barrierefrei sein“ sollte operationalisiert werden. Beispiel: „Alle primären Bedienabläufe müssen vollständig per Tastatur ausführbar sein und eine sichtbare Fokusdarstellung besitzen.“ Ergänzend gehören Zielstandard, Konformitätsniveau, Zielplattformen und Testmethode in die Spezifikation.

Akzeptanzkriterien und Verifikation früh definieren

Zu jeder wichtigen Anforderung sollte ein überprüfbares Ergebnis gehören. Das Given–When–Then-Format hilft dabei:

Given ein angemeldeter Sachbearbeiter
When er eine syntaktisch gültige E-Mail-Adresse eingibt
Then zeigt das System den passenden Kundendatensatz oder eine eindeutige Meldung an

Given eine nicht vorhandene E-Mail-Adresse
When die Suche ausgeführt wird
Then zeigt das System keine fremden Kundendaten und eine verständliche Meldung an

Given ein Benutzer ohne Suchberechtigung
When er die Suchfunktion aufruft
Then verweigert das System den Zugriff und protokolliert den Vorgang gemäß Sicherheitsvorgabe

Mögliche Verifikationsmethoden sind:

• Test: Ausführung mit definierten Eingaben
• Inspektion: Prüfung von Dokumenten, Code oder Konfiguration
• Analyse: rechnerischer oder analytischer Nachweis
• Demonstration: Vorführung eines Systemverhaltens
• Review: fachliche oder formale Bewertung

Wenn sich kein sinnvoller Testfall formulieren lässt, ist die Anforderung häufig noch zu unpräzise. Akzeptanzkriterien sollten spätestens während Refinement oder Spezifikation entstehen, nicht erst nach der Implementierung. Sie sind außerdem nicht dasselbe wie eine allgemeine Definition of Done: Akzeptanzkriterien beziehen sich auf das konkrete fachliche oder qualitative Ergebnis, die Definition of Done auf den Abschlussstandard eines Arbeitselements.

Anforderungen priorisieren

Wenn alles „dringend“ ist, wurde nicht priorisiert. Berücksichtigen Sie Geschäftswert, Nutzerwert, Risiko, gesetzliche oder vertragliche Verpflichtungen, technische Abhängigkeiten, Aufwand, Zeitkritikalität, Reversibilität sowie Auswirkungen auf Sicherheit und Betrieb.

MoSCoW ist eine verständliche Einteilung:

• Must: Ohne die Anforderung ist das Produktziel nicht erreichbar.
• Should: Wichtig, aber mit vertretbarem Workaround verschiebbar.
• Could: Wünschenswert, aber nicht entscheidend.
• Won’t now: Bewusst nicht im aktuellen Umfang enthalten.

Die Priorität braucht immer einen Bezug zu Version, Release oder Scope. „Won’t now“ bedeutet nicht zwingend „niemals“. Außerdem darf Priorität nicht nur als Umsatzranking verstanden werden: Eine wirtschaftlich wenig attraktive Funktion kann wegen eines Sicherheits- oder Compliance-Risikos höchste Priorität haben.

Traceability und Änderungsmanagement

Traceability beziehungsweise Rückverfolgbarkeit verbindet Anforderungen mit ihrer Herkunft und ihren Folgeartefakten. Eine typische Kette lautet:

Geschäftsziel
→ Stakeholder-Bedarf
→ Systemanforderung
→ Softwareanforderung
→ Architekturentscheidung
→ User Story oder Arbeitspaket
→ Testfall
→ Testergebnis
→ Freigabe oder Nachweis

Bidirektionale Rückverfolgbarkeit erleichtert die Analyse, welche Architekturentscheidungen, Komponenten und Tests von einer Änderung betroffen sind. Jede wichtige Anforderung sollte mindestens eine eindeutige ID, Quelle, Begründung, Version, Status, Priorität, betroffene Komponenten, Abhängigkeiten, zugehörige Tests, Freigabe und Änderungshistorie besitzen.

Change-Request-Prozess

1. Änderung und Anlass erfassen
2. Quelle und betroffene Stakeholder dokumentieren
3. Abhängige Anforderungen identifizieren
4. Auswirkungen auf Aufwand, Termine, Architektur, Sicherheit und Tests analysieren
5. Entscheidung treffen und begründen
6. Betroffene Artefakte aktualisieren
7. Freigabe und Kommunikation durchführen
8. Traceability und gegebenenfalls die Baseline aktualisieren

In frühen Discovery-Phasen wäre vollständige Traceability oft unverhältnismäßig. Ihr Umfang sollte mit Risiko und Stabilität wachsen. In sicherheitskritischen oder stark regulierten Projekten kann dagegen eine lückenlose Kette zwingend erforderlich sein.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Reviews und Qualitätsprüfung

Anforderungen sollten nicht nur vom Autor geprüft werden. Je nach Projekt gehören Fachbereich, Nutzervertretung, Entwicklung, Architektur, Test, Betrieb, Security, Datenschutz und Qualitätsmanagement in den Review-Prozess.

• Ist die Quelle bekannt?
• Sind Problem und Ziel nachvollziehbar?
• Beschreibt die Anforderung ein Ergebnis statt eine voreilige Lösung?
• Ist sie atomar und eindeutig?
• Fehlen Bedingungen oder Ausnahmefälle?
• Ist sie messbar und testbar?
• Widerspricht sie anderen Vorgaben?
• Ist sie realistisch und priorisiert?
• Sind Abhängigkeiten und Verifikationsmethode bekannt?
• Wurde sie von den richtigen Personen bestätigt?

Ein praktikabler Ablauf besteht aus Entwurf, fachlicher Klärung, technischer Prüfung, Testdesign, Stakeholder-Review, Freigabe, Baseline und laufender Änderungskontrolle.

Häufige Fehler und ihre Folgen

Lösungsdetails werden zu früh festgelegt

„Wir brauchen eine mobile App mit drei Tabs“ beschreibt eine Lösungsidee, aber noch nicht das zugrunde liegende Bedürfnis. Zuerst sollte geklärt werden, welcher Nutzer welches Problem unter welchen Bedingungen lösen muss.

Einzelmeinungen werden als Bedarf behandelt

Ein einzelner Stakeholder ist nicht automatisch repräsentativ. Aussagen sollten mit Prozessbeobachtung, Daten, realen Szenarien und den Perspektiven weiterer Rollen abgeglichen werden.

Nichtfunktionale Anforderungen fehlen

Eine fachlich korrekte Anwendung kann trotzdem scheitern, wenn sie zu langsam, nicht sicher genug, nicht betreibbar, nicht wiederherstellbar oder inkompatibel mit vorhandenen Systemen ist.

Mehrere Forderungen werden verbunden

„Das System muss Daten importieren, prüfen, speichern und automatisch versenden“ enthält mindestens vier Verhaltensbereiche. Teilen Sie solche Anforderungen auf, damit Priorisierung, Umsetzung und Test möglich bleiben.

Anforderung und Implementierung werden vermischt

„Das System muss Redis verwenden“ ist nur dann eine Anforderung, wenn diese Technologie ausdrücklich vorgeschrieben ist. Andernfalls sollte das Ziel formuliert werden: „Das System muss wiederkehrende Suchanfragen mit einer maximalen Antwortzeit von 200 Millisekunden bedienen.“ Die konkrete Architekturentscheidung gehört in ein separates Designartefakt.

Fehlerfälle werden vergessen

Für wichtige Funktionen sollten neben dem Happy Path mindestens ungültige Eingaben, fehlende Berechtigungen, Timeouts, Dubletten, konkurrierende Änderungen, Schnittstellenausfälle, unvollständige Daten, Wiederholungen, Abbrüche und Rollbacks geprüft werden.

Offen und unklar werden verwechselt

Eine offene Anforderung ist nicht automatisch schlecht. Sie muss aber gekennzeichnet sein und eine verantwortliche Person sowie einen Klärungstermin besitzen. Wird sie ohne diese Information bereits implementiert, entsteht vermeidbares Risiko.

Welche Tools eignen sich?

Das Werkzeug sollte dem Prozess folgen, nicht umgekehrt. Entscheidend sind Teamgröße, bestehender Technologie-Stack, Regulierungsgrad, gewünschte Traceability, Zahl der Beteiligten und Budget.

Werkzeug	Geeignet für	Grenzen
Word oder Google Docs	Kleine Projekte und kurze, relativ stabile Spezifikationen	Schwache Traceability, manuelle Versionierung und Auswirkungsanalyse
Excel oder Tabellen	Erste Listen, einfache Priorisierung und kleine Teams	Wenig Kontext, fehleranfällige Statuspflege und schwierige Abhängigkeiten
Jira	Agile Backlogs, Stories, Bugs und Arbeitspakete	Formale Spezifikationen und Traceability benötigen Struktur oder Zusatz-Apps
Jira Product Discovery	Ideen, Feedback, Priorisierung und Roadmaps	Kein alleiniger Ersatz für tief technische oder regulierte Requirements
Azure DevOps	Microsoft-zentrierte Teams mit Backlogs, Code und Tests	Formale Governance kann Zusatzkonfiguration erfordern
Spezialisierte ALM-Tools	Komplexe, regulierte und sicherheitskritische Vorhaben	Höhere Einführungskosten und größerer Prozessaufwand

Jira

Jira eignet sich für agile Backlogs, User Stories, Aufgaben und Bugs sowie für eine einfache Verbindung zwischen Anforderungen und Umsetzung. Atlassian nennt auf der offiziellen Preisseite einen kostenlosen Cloud-Plan für bis zu zehn Nutzer. Zum Recherchezeitpunkt wurden für Standard 7,91 US-Dollar und Premium 14,54 US-Dollar pro Nutzer und Monat angezeigt. Preise können nach Region, Nutzerzahl, Abrechnungszyklus und Konfiguration variieren.

Jira ist nicht automatisch ein vollwertiges formales Requirements-Engineering-System. Quellen, Entscheidungen, Baselines, Tests und Freigaben müssen bewusst modelliert und verknüpft werden.

Jira Product Discovery

Jira Product Discovery ist für Produktideen, Kundenfeedback, Priorisierung und Roadmaps gedacht. Atlassian nennt auf der offiziellen Seite einen kostenlosen Plan für bis zu drei Creator, Standard mit zehn US-Dollar und Premium mit 25 US-Dollar pro Creator und Monat. Das Produkt ist Cloud-only. Für sicherheitskritische technische Requirements reicht es allein meist nicht aus.

Azure DevOps

Azure DevOps passt zu Teams im Microsoft-Ökosystem, die Anforderungen mit Code, Builds und Tests verbinden möchten. In Azure Boards werden Anforderungen je nach Prozessmodell beispielsweise als User Stories, Product Backlog Items, Issues oder Requirements geführt, wie Microsoft in der Dokumentation erläutert. Ein pauschaler Gesamtpreis ist wegen Dienst-, Nutzer- und Pipelineumfang nicht sinnvoll.

Modern Requirements4DevOps

Modern Requirements4DevOps richtet sich an Organisationen, die Azure DevOps um formale Dokumentation, Traceability, Varianten, Baselines und Governance erweitern wollen. Der Anbieter beschreibt unter anderem Smart Documents und optionale KI-Funktionen. Die Preisseite nennt keine festen Endkundenpreise, sondern verweist auf eine Anfrage.

Spezialisierte Requirements- und ALM-Systeme

Jama Connect, IBM DOORS Next, Polarion, Codebeamer und ReqSuite RM sind relevante Kategorien für größere, komplexe oder regulierte Entwicklungsprozesse. Ein G2-Marktvergleich für Frühjahr 2026 führt unter anderem diese Produkte auf. Das ist ein Markt- beziehungsweise Nutzervergleich und kein unabhängiger Beleg dafür, dass ein bestimmtes Produkt für jedes Projekt geeignet ist.

Für die Auswahl gilt:

• Kleines agiles Team: Jira oder Azure DevOps können genügen.
• Produktdiscovery: Jira Product Discovery ist passend, aber kein Ersatz für technische Spezifikation.
• Azure-DevOps-Unternehmen mit Governancebedarf: Modern Requirements4DevOps kann geprüft werden.
• Reguliertes Systems Engineering: Jama Connect, DOORS Next, Polarion, Codebeamer oder ReqSuite RM sollten anhand eines Proof of Concept und der konkreten Nachweispflichten verglichen werden.
• Kleine, stabile Spezifikation: Eine kontrollierte Dokumentvorlage und Ablage können ausreichen.

Kein Tool ersetzt Stakeholder-Analyse, fachliche Reviews, Testdesign oder Freigabe. Auch automatisch erzeugte Anforderungen müssen fachlich geprüft werden.

Praktische Checkliste

Inhalt

• Ist das zugrunde liegende Problem beschrieben?
• Sind Nutzer und Stakeholder bekannt?
• Ist der erwartete Nutzen nachvollziehbar?
• Vermeidet die Anforderung unnötige Lösungsvorgaben?
• Sind funktionale und nichtfunktionale Aspekte getrennt?
• Sind Vorbedingungen und Fehlerfälle berücksichtigt?
• Gibt es Abhängigkeiten sowie regulatorische oder vertragliche Vorgaben?

Sprache

• Verwendet die Anforderung eindeutige Subjekte und Verben?
• Fehlen unbestimmte Adjektive?
• Beschreibt sie nur eine Forderung?
• Sind Modalverben einheitlich verwendet?
• Sind Abkürzungen erklärt?
• Sind passive oder mehrdeutige Formulierungen vermieden?

Prüfung und Management

• Ist die Anforderung testbar?
• Sind Akzeptanzkriterien vorhanden?
• Ist die Verifikationsmethode bekannt?
• Sind Priorität, Quelle, Verantwortlicher und Status festgelegt?
• Sind Änderungen versioniert?
• Sind Umsetzungselemente und Tests verknüpft?

Fünf Kernregeln

1. Beginnen Sie mit Problem, Ziel und Nutzerbedarf.
2. Formulieren Sie pro Requirement möglichst eine einzelne Forderung.
3. Ersetzen Sie unklare Wörter durch messbare Kriterien.
4. Definieren Sie Akzeptanz und Verifikation vor der Implementierung.
5. Verfolgen Sie Quellen, Entscheidungen, Änderungen und Abhängigkeiten nach.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.