Softwareanforderungen schreiben (ohne Techniker zu sein)
"Bau mir ein System, um das Geschäft zu verwalten" ist der teuerste Satz der Softwareentwicklung: Jedes unscharfe Wort wird zur Annahme des Programmierers, zu unvergleichbaren Angeboten und Überraschungen bei der Lieferung. Gute Anforderungen verlangen kein Programmierwissen — sie verlangen, deinen Betrieb mit einer einfachen Struktur zu erzählen. Dieser Guide gibt sie dir, mit Beispielen.
21. Oktober 20256 Min. LesezeitIn diesem Artikel
"Bau mir ein System, um das Geschäft zu verwalten" ist der teuerste Satz der Softwareentwicklung. Nicht weil das System teuer wäre — sondern weil jedes unscharfe Wort zur Annahme des Programmierers wird, und Annahmen entdeckt man spät: bei der Lieferung, wenn "verwalten" für dich das eine bedeutete und für ihn das andere, und die Korrektur zehnmal mehr kostet, als es klar aufzuschreiben gekostet hätte.
Die gute Nachricht: Gute Anforderungen zu schreiben verlangt kein Programmierwissen — es verlangt, deinen Betrieb mit einer einfachen Struktur zu erzählen, die jeder Geschäftsinhaber an einem Nachmittag beherrscht. Der Preis ist dreifach: vergleichbare Angebote zwischen Anbietern, eine Entwicklung ohne Überraschungen und ein Dokument, das dich schützt, falls etwas strittig wird. Dieser Guide gibt dir die Struktur, die Beispiele von vage zu nützlich und den richtigen Gebrauch des Dokuments.
Warum unscharfe Anforderungen so viel kosten
Drei Mechanismen verwandeln Vagheit in verlorenes Geld. Die Annahmen: Wo dein Dokument schweigt, entscheidet der Entwickler — mit bester Absicht und ohne deinen Betrieb zu kennen; das Ergebnis kann technisch korrekt und kommerziell nutzlos sein. Die Kosten der späten Änderung: Eine Wand im Bauplan zu verschieben ist gratis; sie im gebauten Haus zu verschieben nicht — jede Anforderung, die mitten in der Entwicklung auftaucht, zahlt diesen Tarif. Die unvergleichbaren Angebote: Auf eine vage Anfrage kalkuliert ein Anbieter das Minimum, das sie andeutet, und ein anderer das Maximum, das sie hergibt — die Budgets, die du bekommst, beschreiben nicht dasselbe Projekt, und die Wahl zwischen ihnen ist Lotterie.
Die einfache Struktur, die funktioniert
- Das Problem und das messbare Ziel: was heute wehtut und wie Erfolg aussieht — "Bestellungen gehen zwischen WhatsApp und Papier verloren; Erfolg = null verlorene Bestellungen und abrufbarer Status jeder einzelnen".
- Die Nutzer und ihre Rollen: wer das System nutzen wird und was jeder darf — die Rezeption, der Lagerist, die Verwaltung; wer sieht was, wer gibt was frei.
- Die Hauptabläufe, als Geschichten erzählt: die 3-6 Wege, die das System abdecken muss, von Anfang bis Ende erzählt, wie sie wirklich passieren — samt Ausnahmen ("und wenn der Kunde mittendrin storniert?").
- Die Daten, um die es geht: welche Informationen hereinkommen, gespeichert werden und hinausgehen — die Kundenakte mit ihren Feldern, die Bestellung mit ihren; echte (erfundene, aber realistische) Beispiele sind Gold.
- Was DRAUSSEN bleibt: die explizite Liste dessen, was Version 1 NICHT tun wird — so wichtig wie alles davor, und Thema eines eigenen Abschnitts.
Schreib Geschichten, keine Funktionslisten
Von vage zu nützlich: die Übersetzungstabelle
| Vager Satz | Nützliche Anforderung |
|---|---|
| "Es soll einfach zu bedienen sein" | "Eine neue Kraft erfasst einen Verkauf ohne Schulung in unter einer Minute" |
| "Es soll Berichte haben" | "Verkäufe nach Tag, Woche und Monat sehen, gefiltert nach Filiale und Produkt, exportierbar" |
| "Es soll sicher sein" | "Die Kassiererin sieht nur ihre Tagesverkäufe; die Verwaltung sieht alles; jede Aktion wird mit Wer und Wann protokolliert" |
| "Es soll schnell sein" | "Die Kundensuche antwortet in unter 2 Sekunden bei 10.000 Datensätzen" |
Was draußen bleibt, ist so viel wert wie das, was hineinkommt
Der am schwersten zu schreibende Abschnitt — und der, der am meisten Geld spart — ist die Ausschlussliste: "Version 1 enthält NICHT": die Mobile App, die Buchhaltungsintegration, die erweiterten Berichte, die zweite Sprache. Ohne sie öffnet jedes Projektgespräch den Umfang neu ("wo wir schon dabei sind, könnte es auch…?"), und das Budget stirbt an tausend Schnitten. Die Disziplin für diese Linie kommt vom Denken in Versionen: Version 1 löst den zentralen Schmerz und geht live; alles andere bewirbt sich mit echten Nutzungsdaten um Version 2 — genau die Logik des MVP.
Wie du das Dokument nutzt (und am Leben hältst)
Zwei bis vier Seiten genügen — das perfekte Dokument, das nie fertig wird, verliert gegen das gute, das existiert. Sein erster Einsatz: Schick es identisch an jeden Anbieter-Kandidaten — zum ersten Mal beschreiben die Angebote dasselbe Projekt, und du kannst sie wirklich vergleichen, zusammen mit den Antworten auf die Technologiefragen. Sein zweiter Einsatz: das Projekt begleiten — Änderungen werden aufgeschrieben, beziffert und schriftlich entschieden, nicht in Anrufe geschmuggelt. Und der dritte: Schiedsrichter der Abnahme sein — "fertig" heißt, die Geschichten des Dokuments funktionieren, nichts anderes. Der komplette Projektrahmen um dieses Dokument steht im Guide zur eigenen App.
Häufige Fragen
Wie lang sollte das Anforderungsdokument sein?
Für ein typisches KMU-System: 2 bis 4 Seiten nach der Struktur dieses Guides. Unter einer Seite heißt meist, dass Entscheidungen nicht getroffen wurden (der Entwickler wird sie treffen); über zehn, dass du Implementierungsdetails spezifizierst, die nicht deine Aufgabe sind — oder das Projekt per Endlos-Dokumentation aufschiebst. Das echte Maß sind nicht die Seiten, sondern der Test: Würden zwei Anbieter, die es lesen, dasselbe Projekt anbieten?
Und wenn ich nicht genau weiß, was ich brauche?
Das weiß am Anfang niemand ganz — deshalb beginnt das Dokument beim Problem, nicht bei der Lösung: Präzise zu beschreiben, was heute wehtut (mit echten Beispielen von letzter Woche), ist schon die halbe Spezifikation, und ein guter Anbieter schlägt darauf Lösungen vor. Die zwei klärendsten Werkzeuge: einen Tag den echten Betrieb beobachten und jeden Schritt des zu digitalisierenden Prozesses notieren — und gnadenlos auf Version 1 kürzen; über das Ungewisse entscheidet die echte Nutzung, nicht die Vorstellung.
Sollte nicht der Anbieter die Anforderungen schreiben — er ist doch der Experte?
Es ist Arbeit zu vier Händen mit klaren Rollen: Du lieferst, was er nicht wissen kann — deinen Betrieb, deine Regeln, deine Prioritäten —, und er liefert Struktur, Fragen und technische Optionen. Der erste Entwurf sollte deiner sein (auch unvollkommen): Wer das erste Dokument schreibt, setzt den Rahmen, und ein Anbieter, der Anforderungen von null entwirft, ohne dich zu kennen, spezifiziert tendenziell das, was ihm zu bauen passt. Das Zeichen eines guten Anbieters: Er bekommt dein Dokument und gibt es voller Fragen zurück — genau das willst du.
Was passiert, wenn ich mitten in der Entwicklung meine Meinung ändere?
Das wirst du — und es ist in Ordnung, wenn es gemanagt wird: Die Änderung wird aufgeschrieben, der Anbieter beziffert sie in Zeit und Geld, und du entscheidest mit Zahlen, ob sie jetzt hineinkommt, in Version 2 wandert oder entfällt. Was Projekte ruiniert, ist nicht der Sinneswandel, sondern die informelle Änderung: das "wo wir schon dabei sind" am Telefon, das niemand beziffert hat und jeder anders erinnert. Praxisregel: Entsteht die Änderung aus Gelerntem (echte Nutzer, Daten), verdient sie meist den Einzug; entsteht sie aus einer Laune, verdient sie meist die Version-2-Liste.