Wie man ein Software-Anforderungsdokument schreibt (mit einer einfachen Vorlage)

Die meisten Softwareprojekte scheitern nicht an schlechtem Code. Sie scheitern, weil die Beteiligten unterschiedliche Vorstellungen hatten. Der Auftraggeber hatte eine Idee, der Entwickler setzte eine andere um, und niemand bemerkte es bis zur Demo. Ein Anforderungsdokument ist das einfachste und kostengünstigste Mittel, um dies zu verhindern.

Der Begriff „Anforderungsdokument“ klingt vielleicht kompliziert, nach etwas, das ein Gremium über Monate hinweg erarbeitet hat. Das muss aber nicht sein. Für die meisten Projekte genügt ein klares Dokument von fünf bis fünfzehn Seiten in einfacher Sprache, um alle Beteiligten auf einen gemeinsamen Nenner zu bringen, präzise Schätzungen zu erstellen und das Projekt vor Abweichungen zu schützen. Dieser Leitfaden zeigt Ihnen, was hineingehört, wie Sie die einzelnen Abschnitte verfassen und enthält eine Vorlage zum Kopieren. Wenn Sie sich noch nicht sicher sind, ob Sie überhaupt selbst entwickeln lassen möchten, lesen Sie zuerst Individuelle Software vs. Standardsoftware.

Warum ein Anforderungsdokument wichtig ist

Ein gutes Dokument erfüllt mehrere Funktionen gleichzeitig.

• Es schafft ein gemeinsames Verständnis. Alle lesen dieselbe Beschreibung dessen, was entwickelt werden soll.
• Es ermöglicht präzise Kostenschätzungen. Anbieter können dasselbe Produkt bepreisen, sodass Angebote vergleichbar werden. Unser Leitfaden zu den Kosten individueller Softwareentwicklung erklärt, wie der Umfang den Preis bestimmt.
• Er kontrolliert den Umfang. Alles, was nicht im Dokument enthalten ist, ist entweder eine Änderung oder eine spätere Version, und das ist allen bekannt.
• Er reduziert Nacharbeiten. Missverständnisse werden auf dem Papier gefunden, wo sie kostengünstig sind, anstatt im Code.
• Er dient als Referenz. Neue Teammitglieder, Tester und zukünftige Wartungsmitarbeiter können sehen, was das System leisten soll.
• Er hilft Ihnen bei der Partnerwahl. Wenn Sie mehreren Anbietern dasselbe Briefing geben, zeigt sich, wer die richtigen Fragen stellt; siehe Wie man ein Softwareentwicklungsunternehmen auswählt.

Was es nicht ist

Ein Anforderungsdokument ist kein technischer Entwurf, und Sie müssen nicht wissen, wie die Software entwickelt wird. Es beschreibt was die Software leisten muss und warum, nicht wie sie es leistet. Entscheidungen über Frameworks, Datenbanken und Architektur obliegen dem Entwicklungsteam und orientieren sich an Ihren Anforderungen.

Diese sind auch nicht in Stein gemeißelt. Anforderungen ändern sich im Laufe der Zeit, und ein gutes Dokument bietet eine einfache Möglichkeit, damit umzugehen. Ziel ist Klarheit jetzt, mit der Option, später kontrolliert Anpassungen vorzunehmen.

Die von uns empfohlene Struktur

Hier ist eine Struktur, die für die meisten Projekte funktioniert. Passen Sie sie an die Größe Ihres Projekts an.

1. Überblick und Ziele
2. Benutzer und ihre Bedürfnisse
3. Umfang: Was ist enthalten und was nicht
4. Funktionen und User Stories
5. Regeln und Einschränkungen
6. Daten und Integrationen
7. Nicht-funktionale Anforderungen
8. Prioritäten und Releaseplan
9. Erfolgskriterien
10. Offene Fragen und Annahmen

Wir gehen im Folgenden auf jeden Punkt ein.

1. Überblick und Ziele

Beginnen Sie mit einer kurzen Zusammenfassung, die jeder in einer Minute verstehen kann. Berücksichtigen Sie drei Punkte.

• Das Problem. Was läuft aktuell schief? Beschreiben Sie es anhand konkreter Beispiele: „Mitarbeiter verbringen täglich zwei Stunden damit, Bestellungen zwischen Tabellenkalkulationen zu übertragen, und Fehler führen zu Lieferverzögerungen.“ – Das Ziel. Was soll sich ändern, sobald die Software verfügbar ist? „Bestellungen fließen automatisch von der Website ins Lager, ohne dass eine erneute Dateneingabe erforderlich ist.“ – Der Kontext. Beschreiben Sie Ihr Unternehmen kurz, damit die Leser den Kontext verstehen. Halten Sie diesen Abschnitt kurz. Er dient dazu, den Zweck des Projekts zu erläutern, und alle späteren Entscheidungen können daran gemessen werden. ## 2. Benutzer und ihre Bedürfnisse. Listen Sie alle Personengruppen auf, die das System nutzen werden, und beschreiben Sie deren Aufgaben. Diese werden oft als Benutzerrollen oder Personas bezeichnet.

Schreiben Sie für jede Rolle:

• Wer sie sind. Kunde, Empfangsmitarbeiter, Manager, Administrator usw.
• Was sie erreichen wollen. Ihre Hauptziele.
• Womit sie aktuell zu kämpfen haben. Probleme, die die Software lösen soll.
• Wie sie die Software nutzen werden. Gerät, Nutzungshäufigkeit und technisches Know-how.

Schon wenige Zeilen pro Rolle sind wertvoll. Wenn Sie Ihre Benutzer nicht benennen können, sind Sie noch nicht bereit für die Entwicklung. Dieser Ansatz beugt außerdem dem häufigen Fehler vor, die Software für den Auftraggeber statt für die Anwender zu entwickeln.

3. Umfang: Was ist enthalten und was nicht.

Dieser Abschnitt beugt mehr Diskussionen vor als jeder andere. Erstellen Sie zwei Listen.

Im Umfang dieser Version: Die Funktionen, die Sie unbedingt benötigen.

Derzeit nicht im Umfang: Funktionen, die Sie in Betracht gezogen, aber bewusst für später aufgehoben haben.

Die zweite Liste ist genauso wichtig wie die erste. Es hält gute Ideen fest, ohne die erste Version unnötig aufzublähen, und liefert Ihnen eine fertige Antwort, wenn jemand fragt: „Was ist mit …?“. Wenn Sie eine erste Version planen, lesen Sie Was ist ein MVP? und MVP vs. Vollprodukt, um zu erfahren, wie Sie die Grenze ziehen.

4. Funktionen und User Stories

Dies ist der Kern des Dokuments. Beschreiben Sie, was das System leisten muss, geordnet nach Bereichen. Ein einfaches und effektives Format ist die User Story:

Als [Benutzertyp] möchte ich [etwas tun], um [einen Nutzen zu erhalten].

Beispiele:

• Als Kunde möchte ich einen Termin auswählen, damit ich nicht in der Klinik anrufen muss.
• Als Manager möchte ich die heutigen Buchungen auf einem Bildschirm sehen, um die Personalplanung zu erleichtern.
• Als Administrator möchte ich einen Benutzer deaktivieren, damit sich ehemalige Mitarbeiter nicht mehr anmelden können.

Fügen Sie unter jeder Story Akzeptanzkriterien hinzu: eine kurze Liste von Bedingungen, die erfüllt sein müssen, damit die Story als abgeschlossen gilt.

• Der Kunde sieht nur verfügbare Termine.
• Innerhalb einer Minute nach der Buchung wird eine Bestätigungs-E-Mail versendet.
• Ein gebuchter Termin kann bis zu 24 Stunden im Voraus geändert werden.

Akzeptanzkriterien machen aus Meinungen konkrete Prüfkriterien. Sie geben Testern außerdem etwas Präzises zum Überprüfen.

Tipps für die Entwicklung guter Funktionen

• Verwenden Sie einfache Sprache. Vermeiden Sie Fachjargon. Wenn ein nicht-technischer Kollege den Text nicht versteht, schreiben Sie ihn um.
• Beschreiben Sie das Verhalten, nicht die Bildschirme. „Der Kunde kann Bestellungen nach Datum filtern“ ist verständlicher als „Fügen Sie oben rechts ein Dropdown-Menü hinzu“.
• Seien Sie bei Zahlen präzise. „Schnell“ und „viele Benutzer“ sagen nichts aus. Sagen Sie stattdessen „lädt in unter drei Sekunden“ oder „unterstützt 500 Benutzer gleichzeitig“.
• Eine Idee pro Anforderung. Kombinierte Anforderungen verschleiern Details und sind schwer zu testen.
• Verwenden Sie Beispiele. Ein konkretes Szenario ist einen Absatz Beschreibung wert.
• Fügen Sie Skizzen hinzu. Eine grobe Zeichnung, selbst auf Papier, beseitigt viele Unklarheiten.

5. Geschäftsregeln und -beschränkungen

Jedes Unternehmen hat Regeln, die die Software einhalten muss. Diese geraten leicht in Vergessenheit, weil sie den Mitarbeitern im Gedächtnis bleiben. Notieren Sie diese.

Beispiele:

• Rabatte über 10 Prozent bedürfen der Genehmigung des Managers.
• Bestellungen, die nach 15:00 Uhr eingehen, werden am nächsten Werktag versandt.
• Ein Kunde kann nicht zwei Buchungen gleichzeitig haben.
• Rückerstattungen sind innerhalb von 30 Tagen nach dem Kauf möglich.
• Die Preise enthalten die Mehrwertsteuer für Privatkunden und nicht für Geschäftskunden.

Listen Sie außerdem Einschränkungen auf: Budgetbeschränkungen, Fristen, technologische Vorgaben, regulatorische Vorgaben oder bestehende Systeme. Beispiele: „Muss auf unserem bestehenden Hosting laufen“, „Muss vor Beginn der Sommersaison fertig sein“ oder „Kundendaten müssen im Inland bleiben.

Wenn Ihre Branche spezifische Regeln hat, z. B. im Gesundheitswesen oder im Bildungsbereich, erwähnen Sie diese und bestätigen Sie die Details mit Ihren Beratern.

6. Daten und Integrationen

Erläutern Sie, welche Informationen das System verarbeitet und womit es verbunden werden muss.

Daten: Welche Datensätze existieren (Kunden, Bestellungen, Produkte, Rechnungen)? Wem gehören sie? Wie lange werden die Daten aufbewahrt? Haben Sie bereits Daten, die aus Tabellenkalkulationen oder anderen Systemen importiert werden sollen?

Integrationen: Listen Sie alle Systeme auf, mit denen die Software kommunizieren muss: Zahlungsanbieter, Buchhaltungssoftware, E-Mail-Dienste, Versandpartner, CRM-Systeme, mobile Apps. Beschreiben Sie für jedes System die Richtung des Datenflusses und dessen Häufigkeit.

Integrationen sind oft eine Quelle versteckter Kosten. Beschreiben Sie die Systeme daher so vollständig wie möglich. Wenn Sie sich nicht sicher sind, ob ein System eine API bietet, geben Sie dies an; Ihr Entwicklungspartner kann dies überprüfen. Projekte, die mehrere Tools zusammenführen, wie z. B. ein benutzerdefiniertes CRM-System, das mit Buchhaltung und E-Mail verbunden ist, sind stark von diesem Abschnitt abhängig.

7. Nicht-funktionale Anforderungen

Diese beschreiben, wie gut das System funktionieren muss, nicht was es tut. Sie werden leicht übersehen und sind nachträglich teuer hinzuzufügen.

• Performance: Wie schnell sollten Seiten laden? Wie viele Benutzer können gleichzeitig arbeiten?
• Sicherheit: Wer kann welche Daten einsehen? Gibt es Anforderungen an Passwörter, Logins oder Datenschutz?
• Verfügbarkeit. Wie viel Ausfallzeit ist akzeptabel? Ist ein Backup erforderlich?
• Kompatibilität. Welche Browser, Geräte und Betriebssysteme müssen unterstützt werden?
• Barrierefreiheit. Muss das System Barrierefreiheitsstandards erfüllen?
• Skalierbarkeit. Welches Wachstum sollte es in den nächsten Jahren bewältigen?
• Wartbarkeit. Welche Dokumentation, Codeverantwortung und Übergabe erwarten Sie?
• Sprache und Region. Sprachen, Währungen, Datumsformate und Zeitzonen.

Seien Sie realistisch. Die Forderung nach „perfekter Verfügbarkeit“ und „sofortiger Geschwindigkeit“ für jede Aktion treibt die Kosten in die Höhe. Entscheiden Sie, was für das Unternehmen wirklich wichtig ist.

8. Prioritäten und Releaseplan

Nicht alles kann zuerst entwickelt werden. Priorisieren Sie die Funktionen, damit das Team weiß, was am wichtigsten ist. Eine gängige und effektive Methode ist MoSCoW:

• Unbedingt erforderlich. Ohne diese Funktion funktioniert das System nicht.
• Sollte erforderlich. Wichtig, aber die Veröffentlichung kann auch ohne diese Funktion erfolgen.
• Wünschenswert. Wünschenswert, wenn Zeit und Budget es zulassen.
• Wird (diesmal) nicht enthalten. Zur Kenntnis genommen, aber bewusst verschoben.

Gruppieren Sie anschließend Funktionen in Releases. Ein erstes Release sollte bereits einen echten Mehrwert bieten, der durch spätere Releases erweitert wird. Dies unterstützt die stufenweise Entwicklung, die wir für nahezu jedes Projekt empfehlen und in unserem Ansatz erläutern.

9. Erfolgsmessung

Woran erkennen Sie, dass die Software erfolgreich war? Entscheiden Sie, bevor Sie mit der Entwicklung beginnen.

Beispiele:

• Die Auftragserfassungszeit sinkt von 10 auf 2 Minuten.
• Versäumte Termine gehen um ein Drittel zurück.
• 80 Prozent der Kunden buchen innerhalb von sechs Monaten online.
• Die monatliche Berichterstattung dauert nur eine Stunde statt zwei Tage.

Kennzahlen stellen sicher, dass das Projekt mit dem Geschäftswert verknüpft ist und helfen Ihnen zu beurteilen, ob spätere Investitionen gerechtfertigt sind.

10. Offene Fragen und Annahmen

Kein Dokument ist vollständig. Seien Sie ehrlich, was Sie nicht wissen.

• Offene Fragen: Zu klärende Punkte mit Verantwortlichem und Datum.
• Annahmen: Annahmen, die Sie für richtig halten und auf denen der Plan basiert. „Wir gehen davon aus, dass das aktuelle Buchhaltungssystem eine API bietet."

Die Auflistung dieser Annahmen zeigt, wo Risiken liegen, und ermöglicht es Ihrem Entwicklungspartner, diese frühzeitig zu beheben. Gute Partner werden Ihre Annahmen hinterfragen. Das ist ein Zeichen für ein gründliches, nicht für ein schwieriges Team.

Eine einfache Vorlage zum Kopieren

Kopieren Sie diese Gliederung in ein Dokument und füllen Sie sie aus.

1. Überblick. Problem, Ziel, Kontext.

2. Benutzer. Für jede Rolle: Wer, Ziele, Probleme, Gerät und Vertrauen.

3. Umfang. Im Umfang von Release 1. Derzeit nicht im Umfang.

4. Funktionen. Für jeden Bereich: User Stories mit Akzeptanzkriterien.

5. Regeln und Einschränkungen. Geschäftsregeln. Budget, Frist, Technologie, Vorschriften.

6. Daten und Integrationen. Verarbeitete Datensätze, zu importierende Daten, zu verbindende Systeme, Richtung und Häufigkeit.

7. Nicht-funktionale Anforderungen. Leistung, Sicherheit, Verfügbarkeit, Kompatibilität, Barrierefreiheit, Skalierbarkeit, Sprache.

8. Prioritäten. MoSCoW-Liste und Releaseplan.

9. Erfolgsmessung. Spezifische, messbare Ziele.

10. Offene Fragen und Annahmen. Mit Verantwortlichen und Terminen.

Häufige Fehler

1. Eine Lösung statt eines Bedarfs formulieren. „Wir brauchen ein Dropdown-Menü“ ist eine Lösung. „Mitarbeiter müssen schnell ein Produkt auswählen können“ ist ein Bedarf.
2. Vage Formulierungen. „Benutzerfreundlich“, „schnell“ und „modern“ lassen sich nicht testen.
3. Alles bis ins kleinste Detail festlegen. Zu viele Details zu Beginn veralten schnell. Beschreiben Sie die erste Version detailliert; skizzieren Sie den Rest.
4. Die Nutzer vergessen. Sprechen Sie mit den Nutzern des Systems, nicht nur mit den Käufern.
5. Ausnahmen ignorieren. Rückerstattungen, Stornierungen, Fehler und Sonderfälle sind die Schwachstellen von Systemen.
6. Die Administration vernachlässigen. Jemand muss Nutzer, Inhalte und Einstellungen verwalten.
7. Keine Änderungsmöglichkeit. Integrieren Sie eine Möglichkeit, Änderungen vorzuschlagen, zu schätzen und zu genehmigen.
8. Allein schreiben. Besprechen Sie das Dokument mit Nutzern, Managern und Ihrem Entwicklungspartner.

So verwenden Sie das Dokument mit Entwicklern

Das Dokument eignet sich am besten als Gesprächseinstieg, nicht als Vertrag, der einfach über die Wand gereicht wird.

1. Teilen Sie es mit den in die engere Wahl gekommenen Anbietern und bitten Sie sie, auf Basis des Dokuments Kostenvoranschläge zu erstellen.
2. Achten Sie auf ihre Fragen. Die besten Fragen kommen von den Teams, die Ihr Problem verstehen.
3. Besprechen Sie die Vor- und Nachteile. Ein guter Partner wird Vereinfachungen und Alternativen vorschlagen.
4. Gemeinsam verfeinern. Aktualisieren Sie das Dokument, sobald Entscheidungen getroffen werden.
5. Während der Entwicklung verwenden. Überprüfen Sie die gelieferten Ergebnisse anhand der Akzeptanzkriterien.
6. Aktualisieren. Genehmigte Änderungen sollten im Dokument festgehalten werden.

Wenn Sie nicht sicher sind, wie Sie beginnen sollen, führen viele Teams, darunter auch unseres, eine kurze Discovery-Phase durch, in der die Anforderungen gemeinsam mit Ihnen formuliert werden. Dies ist oft der hilfreichste erste Schritt. Auf unserer Seite individuelle Software können Sie sehen, wie das aussieht. Melden Sie sich dann bei uns unter [contact.php](Kontaktieren Sie uns), sobald Sie bereit sind.

Abschließende Gedanken

Ein Anforderungsdokument ist keine Bürokratie. Es ist die günstigste Versicherung, die Sie für ein Softwareprojekt abschließen können. Es sorgt für Klarheit, deckt Unstimmigkeiten frühzeitig auf, gibt Schätzungen eine realistische Grundlage und hält das Projekt auf das Ziel ausgerichtet.

Sie müssen kein perfektes Dokument erstellen. Ein klares, ehrliches und verständliches Dokument, das die Benutzer, den Umfang, die Funktionen, die Regeln und die offenen Fragen benennt, verschafft Ihnen einen Vorsprung gegenüber den meisten anderen Projekten. Wenn Sie Unterstützung bei der Erstellung eines solchen Dokuments benötigen, erzählen Sie uns von Ihrem Projekt. Wir arbeiten es dann gemeinsam mit Ihnen durch.