Eine der häufigsten Ursachen, warum Softwareprojekte scheitern, liegt nicht beim Entwicklungsteam. Sie liegt in dem Moment, in dem ein Unternehmer sich hinsetzt und erklären möchte, was er braucht – und feststellt, dass er sich nicht sicher ist, wie er es formulieren soll.
Das ist kein Mangel an Wissen. Unternehmer kennen ihre eigenen Betriebsabläufe besser als irgendjemand sonst. Die Lücke ist eine Frage der Übersetzung: Was Sie über Ihr Unternehmen wissen, in eine Beschreibung zu verwandeln, die klar genug ist, damit ein externes Team sie umsetzen kann.
Dieser Leitfaden hilft Ihnen, diese Lücke zu schließen.
Warum Anforderungen wichtiger sind, als Sie vielleicht denken
Viele Unternehmer gehen davon aus, dass das Entwicklungsteam die Details schon herausfinden wird. Sie beschreiben eine grobe Idee und erwarten, dass Fachleute den Rest ergänzen.
Dieser Ansatz führt fast immer zu Problemen. Entwicklungsteams sind Spezialisten für die Erstellung von Software, nicht für die Führung Ihres Unternehmens. Sie können nicht wissen, welche Ausnahmefälle wichtig sind, welche Arbeitsabläufe kritisch sind oder welche Situationen Ihre Mitarbeiter derzeit manuell bewältigen. Ohne diese Informationen treffen sie Annahmen – und Annahmen, auch gut gemeinte, verfehlen das Ziel häufig.
Die Zeit, die Sie in die Dokumentation der Anforderungen vor Entwicklungsbeginn investieren, zahlt sich vielfach aus. Klare Anforderungen reduzieren Missverständnisse, Streitigkeiten über den Umfang, die Kosten später Änderungen und erhöhen die Wahrscheinlichkeit erheblich, dass das Gelieferte tatsächlich dem entspricht, was Sie benötigt haben.
Beginnen Sie mit dem Problem, nicht mit der Lösung
Der häufigste Fehler beim Schreiben von Anforderungen ist, direkt mit der Beschreibung zu beginnen, was die Software tun soll – ohne zu erklären, warum.
Bevor Sie eine Funktion beschreiben, schreiben Sie das Problem auf, das sie löst. Nicht „die Software soll automatische Erinnerungen senden" – sondern „unsere Mitarbeiter verbringen drei Stunden pro Woche damit, Kunden mit nahenden Terminen manuell zu kontaktieren, und verpassen dabei ungefähr fünfzehn Prozent dieser Anrufe, was zu kurzfristigen Absagen führt."
Diese Problembeschreibung gibt dem Entwicklungsteam Kontext. Sie hilft ihnen, einen besseren Ansatz vorzuschlagen, falls es einen gibt. Außerdem gibt sie Ihnen eine Möglichkeit, später zu beurteilen, ob das Gebaute das Problem tatsächlich löst – weil das Problem klar formuliert ist.
Fragen Sie sich bei jeder Funktion, die Sie aufnehmen möchten: Welches konkrete Problem löst diese Funktion? Wenn Sie diese Frage nicht beantworten können, muss die Funktion möglicherweise gar nicht im Projektumfang enthalten sein.
Beschreiben Sie, wer die Software nutzen wird
Nützliche Anforderungen benennen die Personen, die mit dem System interagieren werden, und beschreiben, was diese Personen zu erreichen versuchen.
Beginnen Sie damit, alle Benutzertypen aufzulisten, die mit der Software interagieren werden. Dazu können Ihre Mitarbeiter (und verschiedene Kategorien von Mitarbeitern mit unterschiedlichen Verantwortlichkeiten), Ihre Kunden, Ihr Management oder sogar automatisierte Systeme gehören, die mit der neuen Software verbunden werden müssen.
Beschreiben Sie für jeden Benutzertyp:
- Was sie zu erreichen versuchen, wenn sie diesen Teil des Systems nutzen
- Welche Informationen sie für ihre Arbeit benötigen
- Welche Einschränkungen oder Regeln dafür gelten, was sie sehen oder tun können
- Wie oft sie das System nutzen werden und in welchem Kontext
Diese Benutzerbeschreibungen werden in der Entwicklungssprache oft als „User Stories" bezeichnet und sind weitaus nützlicher als abstrakte Funktionslisten, weil sie echtes Verhalten statt imaginierter Funktionalität beschreiben.
Beschreiben Sie Prozesse, nicht nur Funktionen
Der wertvollste Beitrag, den Sie zu einem Anforderungsdokument leisten können, ist eine Beschreibung dessen, wie Ihr Unternehmen heute tatsächlich funktioniert – und wie Sie möchten, dass es mit der neuen Software funktioniert.
Gehen Sie jeden Kernprozess von Anfang bis Ende durch. Was löst den Prozess aus? Wer ist bei jedem Schritt beteiligt? Welche Entscheidungen werden getroffen und auf welcher Grundlage? Welche Informationen werden zwischen den Schritten weitergegeben? Was passiert, wenn etwas schiefläuft oder eine Ausnahme auftritt?
Diese Prozessbeschreibungen müssen nicht technisch sein. Sie können als unkomplizierte Berichte verfasst oder mit einfachen handgezeichneten Flussdiagrammen illustriert werden. Was zählt, ist, dass sie vollständig und genau sind.
Achten Sie besonders auf Ausnahmen und Randfälle. Der normale Ablauf ist gewöhnlich leicht zu beschreiben. Was Entwickler oft übersehen, sind die ungewöhnlichen Situationen, die Ihre Mitarbeiter jeden Tag unbewusst handhaben – die Bestellung mit drei verschiedenen Lieferadressen, der Kunde mit zwei Konten, die verspätet eingegangene Zahlung. Wenn diese Ausnahmen nicht beschrieben werden, kann die Software damit nicht umgehen.
Seien Sie konkret bei Daten
Vage Anforderungen führen zu vager Software. Je konkreter Sie die Daten beschreiben, mit denen Ihr Unternehmen arbeitet, desto präziser kann die Software erstellt werden.
Beschreiben Sie für jeden Informationstyp, den das System verwalten wird:
- Welche Felder oder Attribute er hat (beispielsweise für einen Kundendatensatz: Name, Adresse, Kontaktdaten, Kontonummer, Kreditlimit, Zahlungsbedingungen)
- Welche Felder erforderlich und welche optional sind
- In welchem Format die Daten vorliegen (Telefonnummern, Daten, Geldbeträge)
- Welche Regeln gelten (ein Kreditlimit kann nicht negativ sein; eine Buchung kann nicht in der Vergangenheit liegen)
- Wie lange Daten aufbewahrt werden sollen und wer sie löschen darf
Sie müssen nichts über Datenbanken oder technische Implementierung wissen. Beschreiben Sie einfach die Informationen, mit denen Ihr Unternehmen arbeitet, so präzise wie möglich – das Entwicklungsteam erhält alles, was es braucht.
Beschreiben Sie, was Sie nicht möchten
Anforderungsdokumente konzentrieren sich dazu auf das, was das System tun soll. Es ist ebenso nützlich zu notieren, was es nicht tun soll – oder was es verhindern muss.
Dazu können gehören:
- Wer keinen Zugriff auf bestimmte Informationen haben sollte (Mitarbeiter, die keine Gehaltsdaten sehen sollten; Kunden, die keine Datensätze anderer Kunden sehen sollten)
- Aktionen, die unter bestimmten Bedingungen nicht möglich sein sollten (eine Rechnung kann nach Zahlungseingang nicht gelöscht werden)
- Integrationen, die Sie vermeiden möchten, oder Systeme, mit denen die Software nicht verbunden werden soll
- Daten, die niemals Ihre Server verlassen oder an Dritte weitergegeben werden sollen
Diese Einschränkungen und Beschränkungen sind Teil der Anforderungen und werden leicht übersehen, wenn der Fokus auf den Funktionen liegt.
Beschreiben Sie, wie Erfolg aussieht
Bevor ein Entwicklungsteam etwas liefern kann, mit dem Sie zufrieden sind, müssen beide Seiten übereinstimmen, was „fertig" bedeutet.
Schreiben Sie für jeden Hauptbereich des Systems auf, wie Sie bewerten werden, ob es korrekt funktioniert. Das müssen keine technischen Testkriterien sein – es kann in Geschäftsbegriffen formuliert werden:
„Ein Mitarbeiter kann sich einloggen, einen Kundendatensatz in unter zehn Sekunden finden und seine Kontaktdaten aktualisieren, ohne den IT-Support anrufen zu müssen."
„Das System sendet eine Erinnerung an jeden Kunden, dessen Termin innerhalb von achtundvierzig Stunden liegt, ohne manuelle Aktion seitens der Mitarbeiter."
„Ein Manager kann einen monatlichen Umsatzbericht für jeden beliebigen Datumsbereich der letzten drei Jahre erstellen und in Excel exportieren."
Diese Abnahmekriterien bilden die Grundlage für formale Tests und geben Ihnen eine klare, eindeutige Möglichkeit, die Software vor der Abnahme zu bewerten.
Priorisieren Sie konsequent
Nicht jede Anforderung hat das gleiche Gewicht. Manche Funktionen sind unverzichtbar – ohne sie kann die Software ihren Zweck nicht erfüllen. Andere sind nützlich, aber nicht kritisch. Weitere sind wünschenswert, würden aber Zeit und Kosten ohne entsprechenden Mehrwert hinzufügen.
Kategorisieren Sie jeden Punkt, bevor Sie Ihre Anforderungen an ein Entwicklungsteam übergeben:
- Muss haben: Das Projekt scheitert, wenn dies fehlt
- Sollte haben: Wichtig, aber das System kann anfangs ohne es funktionieren
- Wäre schön zu haben: Wünschenswert, kann aber auf eine spätere Phase verschoben werden
Diese Priorisierung dient zwei Zwecken. Erstens hilft sie dem Entwicklungsteam, die Energie dort zu konzentrieren, wo sie am wichtigsten ist. Zweitens gibt sie Ihnen Flexibilität: Wenn Budget oder Zeit knapp werden, wissen Sie genau, welche Funktionen verschoben werden können und welche nicht.
Eine häufige Falle ist es, alles als unverzichtbar zu behandeln. Wenn alles kritisch ist, kann nichts gestrichen werden – und dann erzwingt eine Budget- oder Zeitplaneinschränkung dennoch Kürzungen, aber ohne eine klare Grundlage für die Entscheidung, was geopfert werden soll. Ehrliche Priorisierung verhindert dies.
Was tun, wenn Sie unsicher sind
Es ist üblich, mit dem Schreiben von Anforderungen zu beginnen und festzustellen, dass man Fragen hat, die man selbst nicht beantworten kann. Welche Zahlungsmethoden soll das System akzeptieren? Wie soll das System reagieren, wenn zwei Mitarbeiter gleichzeitig versuchen, denselben Datensatz zu aktualisieren? Was passiert mit historischen Daten, wenn ein Kunde seinen Vertrag kündigt?
Das sind gute Fragen – und sie sind weit besser vor Beginn der Entwicklung zu stellen als während ihr entdeckt zu werden. Möglichkeiten umfassen:
Notieren Sie sie als offene Fragen. Ein Anforderungsdokument mit einer klaren Liste ungelöster Fragen ist nützlicher als ein Dokument, das so tut, als wäre alles entschieden. Ein Entwicklungsteam kann Ihnen helfen, diese Fragen systematisch durchzuarbeiten.
Beziehen Sie die Menschen ein, die es wissen. Ihr Betriebsteam, Ihre Finanzabteilung, Ihre kundenzugewandten Mitarbeiter – sie haben Antworten auf viele dieser Fragen, weil sie täglich mit den zugrunde liegenden Situationen umgehen. Das Schreiben von Anforderungen ist oft eine gemeinschaftliche Übung, keine Einzelleistung.
Binden Sie das Entwicklungsteam früh ein. Viele Entwicklungspartnerschaften beginnen mit einer Anforderungs- und Analysephase, gerade weil das gemeinsame Erarbeiten von Anforderungen effizienter ist als das alleinige Schreiben. Ein guter Entwicklungspartner stellt Fragen, die Ihnen helfen, Ihre Überlegungen zu klären – und wartet nicht nur auf ein fertiges Dokument.
Ein praktischer Ausgangspunkt
Wenn Sie noch nie Anforderungen geschrieben haben und nicht wissen, wo Sie anfangen sollen, beginnen Sie hier:
- Schreiben Sie jeden Prozess auf, den die neue Software unterstützen soll, in einfacher Sprache
- Beschreiben Sie für jeden Prozess, wer ihn ausführt, womit er beginnt, welche Schritte er befolgt und was dabei herauskommt
- Notieren Sie jede Ausnahme oder jeden ungewöhnlichen Fall, an den Sie denken können
- Listen Sie jeden Informationstyp auf, den das System speichern oder verwalten muss
- Schreiben Sie Ihre Einschränkungen auf: Wer kann was sehen, was das System niemals tun darf, womit es verbunden sein muss
- Beschreiben Sie, wie ein erfolgreicher Ausgang für jeden Bereich aussieht
Dieser Ausgangspunkt wird weder perfekt noch vollständig sein. Aber er gibt einem Entwicklungsteam etwas Reales, womit es arbeiten kann – und er startet ein Gespräch, das zu wesentlich besserer Software führt, als es ein vages Brief jemals könnte.
Sie wissen nicht, wie Sie Ihre Anforderungen strukturieren sollen, oder suchen Hilfe dabei, den Bedarf Ihres Unternehmens in ein klares Projektbriefing zu verwandeln? Kontaktieren Sie uns. Anforderungen gemeinsam zu erarbeiten ist eines der wertvollsten Dinge, die wir mit neuen Kunden tun – und es prägt oft das gesamte Projekt zum Besseren.