Software-Anforderungen formulieren: KMU-Guide

Schlechte Anforderungen sind der teuerste Fehler in einem Softwareprojekt - und er passiert, bevor die erste Zeile Code geschrieben wird. Bitkom hat 2021 in der Studie „Heiter Scheitern" gemessen, dass 75 % aller Projektfehler in der Definitionsphase entstehen. Die gute Nachricht: Sie brauchen keine IT-Ausbildung, um das zu verhindern. Sie brauchen ein Format und die Disziplin, Ihr eigenes Geschäftsproblem präzise zu beschreiben.

Dieser Guide zeigt Ihnen, wie das geht - mit konkreten Beispielen aus typischen Mittelstandsprozessen und einer Vorlage, die Sie direkt ausfüllen können.

Auf einen Blick

• 75 % aller Projektfehler entstehen bereits in der Definitionsphase (Bitkom, 2021).
• Unklare Anforderungen verursachen in über 47 % der Fälle Projektverzögerungen (think-ics.com).
• Gut formulierte User Stories reduzieren den Klärungsaufwand um 40–60 % (businessanalysisexperts.de).
• Projekte mit vollständigen Anforderungen schließen mit 2,5x höherer Wahrscheinlichkeit erfolgreich ab (Standish Group).
• Das richtige Format für KMU-Auftraggeber ohne IT-Hintergrund: die User Story.

[INTERNAL-LINK: Zurück zum Pillar → /blog/softwareentwickler-beauftragen-guide]

---

Warum die Anforderungsformulierung das Herzstück jedes Softwareprojekts ist

Unklare Anforderungen sind in über 47 % der Fälle die Hauptursache für Projektverzögerungen in der Softwareentwicklung (think-ics.com). Wer mit vagen Beschreibungen in ein Projekt startet, produziert Change Requests - und Change Requests kosten Zeit, Geld und Vertrauen. Die Anforderungsphase ist nicht Vorarbeit; sie ist das Projekt.

Das Problem im Mittelstand ist selten böser Wille. Es ist ein Missverständnis darüber, wer die Anforderungen formulieren soll. Viele Auftraggeber denken: „Das ist Aufgabe des Entwicklers. Er fragt schon nach, was er braucht." Stimmt nicht. Ein Entwickler kann fragen, was er fragen kann. Er weiß nicht, was er nicht weiß. Und er kennt Ihr Geschäft nicht.

[UNIQUE INSIGHT] In der Praxis beobachten wir regelmäßig dasselbe Muster: Der Auftraggeber beschreibt eine Funktion, der Entwickler baut sie, beide sind zufrieden - bis die Software im echten Betrieb läuft und sich herausstellt, dass der eigentliche Bedarf ein anderer war. Nicht weil jemand gelogen hat. Sondern weil das zugrundeliegende Geschäftsproblem nie klar auf dem Tisch lag.

Das teuerste Gespräch in jedem Softwareprojekt ist das, das nicht stattgefunden hat - und zwar vor dem ersten Angebot.

[INTERNAL-LINK: Kosten und Vertragsmodelle → /blog/softwareentwicklung-festpreis-zeitaufwand]

---

Funktionale vs. nicht-funktionale Anforderungen: Der Unterschied mit Beispielen

Funktionale Anforderungen beschreiben, was die Software tun soll. Nicht-funktionale Anforderungen beschreiben, wie gut sie es tun soll. Beide sind Pflicht. In der Praxis werden nicht-funktionale Anforderungen fast immer vergessen - und dann nachträglich nachgerüstet, was laut Bitkom (2021) zu einem der häufigsten Kostentreiber in der Definitionsphase zählt.

Funktionale Anforderungen - Beispiele aus dem Mittelstand:

• „Als Lagerist kann ich den aktuellen Bestand jedes Artikels in Echtzeit einsehen."
• „Als Auftragserfasser kann ich einen neuen Auftrag mit Kundendaten, Leistungspositionen und Fälligkeitsdatum anlegen."
• „Als Vorgesetzter kann ich alle offenen Aufträge meiner Mitarbeiter nach Status filtern."

Das ist konkret. Das ist prüfbar. Daraus kann ein Entwickler kalkulieren.

Nicht-funktionale Anforderungen - was Auftraggeber vergessen:

• Performance: „Die Auftragsübersicht lädt in unter 2 Sekunden, auch bei 500 gleichzeitigen Einträgen."
• Sicherheit: „Alle Nutzer müssen sich per Zwei-Faktor-Authentifizierung anmelden."
• Verfügbarkeit: „Das System ist werktags zwischen 7 und 20 Uhr zu 99,5 % verfügbar."
• Datenschutz: „Die Anwendung ist DSGVO-konform; personenbezogene Daten werden nur auf deutschen Servern gespeichert."
• Mobilfähigkeit: „Die Oberfläche ist vollständig auf Smartphones mit Android und iOS nutzbar."

Nicht-funktionale Anforderungen sind unsichtbar, solange sie erfüllt sind. Sobald sie fehlen, sind sie sehr teuer.

[IMAGE: Zwei-Spalten-Vergleich funktionale vs. nicht-funktionale Anforderungen am Whiteboard - search terms: requirements whiteboard business planning functional nonfunctional]

---

User Stories: Das einfachste Format für Nicht-Techniker

Gut formulierte User Stories reduzieren den Klärungsaufwand während der Entwicklung um 40–60 % (businessanalysisexperts.de). Das Format ist bewusst einfach gehalten - weil es für Menschen entwickelt wurde, die Software nutzen, nicht bauen.

Das Grundformat:

Als [Rolle] möchte ich [Aktion], damit [Nutzen].

Drei Teile. Kein Technikwissen nötig. Jede Rolle beschreibt einen echten Menschen in Ihrem Betrieb.

Beispiele aus typischen Mittelstandsprozessen:

Lagerverwaltung:

• „Als Lagerist möchte ich den aktuellen Bestand jedes Artikels per Scan abrufen, damit ich Nachbestellungen rechtzeitig auslöse, bevor es zu Engpässen kommt."
• „Als Einkäufer möchte ich eine automatische Benachrichtigung erhalten, wenn ein Artikel unter den Mindestbestand fällt, damit ich ohne manuelle Kontrolle reagieren kann."

Auftragserfassung:

• „Als Innendienst-Mitarbeiterin möchte ich Aufträge mit allen Kundendaten in unter 3 Minuten erfassen, damit der Außendienst sofort losfahren kann."
• „Als Geschäftsführer möchte ich alle offenen Aufträge nach Fälligkeitsdatum sortiert sehen, damit ich Kapazitätsengpässe früh erkenne."

Mitarbeiterplanung:

• „Als Teamleiter möchte ich die Einsatzpläne meiner Mitarbeiter für die nächsten zwei Wochen auf dem Smartphone sehen, damit ich auch unterwegs umplanen kann."
• „Als Mitarbeiter möchte ich meinen Schichtplan per App einsehen und Tausche direkt beantragen, ohne den Teamleiter anrufen zu müssen."

[PERSONAL EXPERIENCE] Was wir in fast jedem Projekt sehen: Die ersten User Stories eines Auftraggebers sind zu technisch - „Als Nutzer möchte ich einen Button, der..." - oder zu vage - „Als Nutzer möchte ich eine bessere Übersicht." Beides ist kein gutes Ausgangsmaterial. Die Faustregel: Wenn Sie die Nutzerrolle nicht mit einem echten Namen aus Ihrem Betrieb besetzen könnten, ist die Story zu abstrakt.

Was eine gute User Story nicht enthält:

• Technologievorgaben („Als Nutzer möchte ich, dass React verwendet wird...")
• Mehrere Aktionen in einer Story
• Die Lösung statt des Bedarfs

[INTERNAL-LINK: Lastenheft-Vorlage für formale Projekte → /blog/lastenheft-vorlage-kmu]

---

Akzeptanzkriterien: Wie Sie messbar machen, wann eine Funktion "fertig" ist

Eine User Story ohne Akzeptanzkriterien ist ein Wunsch, keine Anforderung. Projekte mit vollständigen, validierten Anforderungen schließen laut Standish Group mit 2,5x höherer Wahrscheinlichkeit erfolgreich ab. Der Unterschied liegt fast immer in der Frage: Wann gilt eine Funktion als fertig?

Akzeptanzkriterien sind die Bedingungen, die erfüllt sein müssen, damit Sie eine Funktion abnehmen. Sie schützen Sie - und sie schützen den Entwickler.

Format: „Gegeben [Ausgangssituation], wenn [Aktion], dann [Ergebnis]."

Beispiel - Auftragserfassung:

User Story: „Als Innendienst-Mitarbeiterin möchte ich einen neuen Auftrag anlegen, damit der Außendienst sofort starten kann."

Akzeptanzkriterien:

• Gegeben: ich bin eingeloggt und befinde mich auf der Auftragsübersicht, wenn ich auf „Neuer Auftrag" klicke, dann öffnet sich ein Formular mit den Feldern Kunde, Leistung, Datum und Priorität.
• Gegeben: ich habe alle Pflichtfelder ausgefüllt, wenn ich auf „Speichern" klicke, dann erscheint der Auftrag sofort in der Auftragsübersicht - ohne Neuladen der Seite.
• Gegeben: ich habe ein Pflichtfeld nicht ausgefüllt, wenn ich auf „Speichern" klicke, dann erscheint eine Fehlermeldung direkt beim betroffenen Feld.
• Gegeben: der Auftrag wurde gespeichert, dann erhält der zuständige Außendienstmitarbeiter innerhalb von 30 Sekunden eine Push-Benachrichtigung.

Das klingt aufwendig. Es ist Arbeit - einmalig. Was Sie damit vermeiden: ein stundenlanges Gespräch drei Monate später darüber, was „fertig" hätte bedeuten sollen.

[CHART: Beispiel-User-Story mit drei Akzeptanzkriterien als annotiertes Diagramm - Quelle: eigene Darstellung]

---

Priorisierung: Must-have, Should-have, Could-have (MoSCoW-Methode)

Die MoSCoW-Methode ist keine Unternehmensberatungs-Erfindung. Sie ist ein Werkzeug, das Budget-Kontrolle in Softwareprojekten ermöglicht. Wer alle Anforderungen als gleich wichtig behandelt, landet unweigerlich bei einem MVP, das kein MVP mehr ist - und einem Projekt, das teurer wird als kalkuliert.

MoSCoW steht für vier Kategorien:

M - Must-have: Ohne diese Funktion funktioniert der Kernprozess nicht. Das ist der MVP. Kein Must-have bleibt außen vor, kein Could-have kommt in den ersten Sprint.

S - Should-have: Wichtig und wertvoll, aber das System läuft auch ohne. Wird nach dem MVP umgesetzt.

C - Could-have: Nett, aber verzichtbar. Kommt in Version 2 - wenn überhaupt.

W - Won't-have (jetzt): Explizit ausgeschlossen für diese Version. Nicht vergessen, sondern bewusst vertagt.

Beispiel - Lagerverwaltungs-App:

Anforderung	Kategorie
Lagerbestand in Echtzeit anzeigen	Must-have
Artikel per Barcode-Scan buchen	Must-have
Automatische Nachbestellungsbenachrichtigung	Should-have
Historische Bestandsverläufe als Diagramm	Could-have
Lieferantenportal für externe Bestellungen	Won't-have (v1)

Der Trick liegt im „W": Wenn Sie die Won't-haves benennen, verhindert das Scope Creep. Sie können im Projektverlauf nicht mehr behaupten, es sei immer geplant gewesen.

[PERSONAL EXPERIENCE] Wir sehen in fast jedem Erstgespräch dieselbe Situation: Alles ist Must-have. Das ist verständlich - Sie wollen die beste Software. Aber ein Projekt, bei dem alles gleich wichtig ist, hat keine Prioritäten. Und ohne Prioritäten gibt es kein Budget-Management. Unsere Faustregel: Ein gesunder MVP hat 60–70 % Must-haves, 20–25 % Should-haves und maximal 15 % Could-haves. Wenn Ihre Liste anders aussieht, ist sie noch nicht fertig.

---

Häufige Formulierungsfehler und wie man sie erkennt

Unklare Anforderungen sind in über 47 % der Fälle die Hauptursache für Projektverzögerungen (think-ics.com). Die meisten davon sind vermeidbar. Die häufigsten Muster sehen immer gleich aus.

Fehler 1: Lösungen statt Probleme beschreiben.

Falsch: „Wir brauchen einen Button oben rechts, der eine PDF-Rechnung erzeugt." Richtig: „Als Buchhalter möchte ich eine Rechnung als PDF exportieren, damit ich sie direkt per E-Mail an den Kunden schicken kann."

Der Entwickler weiß, wo er den Button hinbaut. Was er nicht weiß: Welche Daten soll die Rechnung enthalten? Welches Format? Welche Felder sind Pflicht? Das steht im richtigen Format automatisch im Akzeptanzkriterium.

Fehler 2: Zu vage formulieren.

Falsch: „Das System soll schnell sein." Richtig: „Die Auftragsübersicht lädt in unter 1,5 Sekunden, auch wenn 1.000 Aufträge im System sind."

Vage ist nicht falscher Wunsch - vage ist keine testbare Anforderung. Was nicht testbar ist, kann nicht abgenommen werden.

Fehler 3: Mehrere Anforderungen in einer Story mischen.

Falsch: „Als Mitarbeiter möchte ich meine Aufträge sehen, bearbeiten, und eine Benachrichtigung bekommen, wenn neue reinkommen." Richtig: Drei separate Stories - eine für Anzeige, eine für Bearbeitung, eine für Benachrichtigungen.

Jede Story sollte eine einzige Aktion abbilden. Gemischte Stories lassen sich nicht vernünftig priorisieren und nicht einzeln testen.

Fehler 4: Nutzerrollen weglassen oder zu allgemein wählen.

Falsch: „Als Nutzer möchte ich..." Richtig: „Als Lagerist / Als Teamleiter / Als Buchhalter möchte ich..."

Verschiedene Rollen haben verschiedene Berechtigungen, verschiedene Ansichten und verschiedene Anforderungen. „Nutzer" ist keine Rolle.

Fehler 5: Nicht-funktionale Anforderungen komplett auslassen.

Das haben wir oben schon beschrieben - aber es ist der häufigste Fehler. Legen Sie sich eine feste Checkliste an: Performance, Sicherheit, Verfügbarkeit, Datenschutz, Mobilfähigkeit. Gehen Sie diese für jede Hauptfunktion durch.

[IMAGE: Checkliste auf Klemmbrett mit angehakten Punkten, Hintergrund Büro - search terms: checklist clipboard office requirements review]

---

Vorlage: Anforderungsdokument für KMU-Web-Apps

Diese Vorlage ist ohne Vorkenntnisse ausfüllbar. Sie deckt alles ab, was ein Entwickler für ein erstes verbindliches Angebot braucht. Bitkom (2021) hat gemessen, dass 75 % aller Projektfehler in der Definitionsphase entstehen - diese Vorlage ist Ihre Versicherung dagegen.

[ORIGINAL DATA] Die Struktur dieser Vorlage basiert auf typischen Anforderungsgesprächen mit KMU-Kunden aus den Bereichen Lagerverwaltung, Auftragserfassung und Mitarbeiterplanung. Sie wurde gezielt für Auftraggeber ohne IT-Hintergrund entwickelt.

---

TEIL 1: Das Problem

Was ist der aktuelle Prozess, der gelöst werden soll? (Beschreiben Sie, was heute passiert - Schritt für Schritt. Wer macht was? Wo entsteht manuelle Arbeit? Was kostet das an Zeit?)

---

Was kostet dieser Prozess heute - grob geschätzt? (z. B. 3 Mitarbeiter × 2 Stunden täglich × 220 Arbeitstage = 1.320 Stunden / Jahr)

---

---

TEIL 2: Die Nutzerrollen

Wer nutzt die Software? (Benennen Sie alle Nutzergruppen. Beispiel: Lagerist, Teamleiter, Buchhalter, Geschäftsführer.)

Rolle	Anzahl Personen	Hauptaufgabe in der Software

---

TEIL 3: User Stories (Kernfunktionen)

Formulieren Sie für jede Hauptfunktion eine User Story: Format: „Als [Rolle] möchte ich [Aktion], damit [Nutzen]."

#	User Story	Priorität (M/S/C/W)
1	Als ... möchte ich ..., damit ...
2	Als ... möchte ich ..., damit ...
3	Als ... möchte ich ..., damit ...

---

TEIL 4: Nicht-funktionale Anforderungen

Kategorie	Anforderung	Pflicht?
Performance	Seiten laden in unter ___ Sekunden
Sicherheit	Login-Methode: Passwort / 2FA / SSO
Verfügbarkeit	System verfügbar zu ___% werktags
Datenschutz	Daten auf deutschen Servern: Ja / Nein
Geräte	Nutzung auf: Desktop / Tablet / Smartphone

---

TEIL 5: Bestehende Systeme

Welche Systeme müssen angebunden werden?

System	Zweck	Anbindung Pflicht?
(z. B. DATEV)	(z. B. Rechnungsexport)	Ja / Nein

---

TEIL 6: Projektrahmen

• Budget-Rahmen: _______
• Gewünschtes Go-Live-Datum: _______
• Harte Deadline (mit Begründung): _______
• Interner Ansprechpartner für das Projekt: _______

---

[INTERNAL-LINK: Web-App-Kosten einschätzen → /blog/web-app-kosten-mittelstand]

---

So nutzen Sie Ihre Anforderungen im Gespräch mit Entwicklern

Vollständige, validierte Anforderungen erhöhen die Projekterfolgschance laut Standish Group um den Faktor 2,5. Aber ein Dokument allein reicht nicht - Sie müssen es im Gespräch aktiv einsetzen. Das Erstgespräch mit einem Entwickler ist kein Brainstorming. Es ist ein Qualitätscheck.

Konkret: Was sagt die Art, wie ein Entwickler auf Ihre Anforderungen reagiert, über ihn aus?

Ein guter Entwickler:

• Stellt Rückfragen zu unklaren Akzeptanzkriterien.
• Benennt, welche Anforderungen er für zu vage hält und warum.
• Weist auf Widersprüche hin - z. B. wenn eine Must-have-Funktion technisch eine andere voraussetzt, die Sie als Could-have eingestuft haben.
• Liefert ein Angebot mit einer Scope-Zusammenfassung in eigenen Worten.

Ein Warnsignal:

• Kein Rückfragen nach Ihrem Dokument. Wer ohne Rückfragen ein vollständiges Angebot liefert, hat Ihr Briefing nicht durchgearbeitet.
• Eine Angebotssumme ohne Phasenstruktur. Ein gutes Angebot zeigt, welche User Stories in welchem Sprint-Block umgesetzt werden - nicht nur eine Gesamtzahl.

Was Sie vor jedem Entwicklergespräch tun sollten:

1. Vorlage vollständig ausfüllen - auch die Teile, die sich schwierig anfühlen.
2. Drei Must-have-User-Stories herausgreifen, für die Sie Akzeptanzkriterien formuliert haben.
3. Im Gespräch konkret fragen: „Wie würden Sie diese drei Stories technisch umsetzen, und was wäre dabei das größte Risiko?"

Die Antwort auf Frage 3 zeigt Ihnen in fünf Minuten, ob dieser Partner Ihr Projekt versteht.

Wenn Sie wissen wollen, wie ein Softwareprojekt von der Anforderungsphase bis zum Go-Live abläuft, lesen Sie unseren vollständigen Guide: Softwareentwickler beauftragen: Der KMU-Guide.

Und wenn Sie ein formales Lastenheft brauchen - für Ausschreibungen oder öffentliche Vergaben: Lastenheft-Vorlage für KMU.

[INTERNAL-LINK: Pillar zurück → /blog/softwareentwickler-beauftragen-guide] [INTERNAL-LINK: Lastenheft → /blog/lastenheft-vorlage-kmu]

---

Fazit

75 % aller Projektfehler entstehen in der Definitionsphase (Bitkom, 2021). Das ist keine abstrakte Statistik - das ist die Erfahrung aus jedem Projekt, das teurer wurde als geplant, länger dauerte als vereinbart oder am Ende nicht das lieferte, was gebraucht wurde.

Die Lösung ist kein komplexes Prozess-Framework. Sie ist: das eigene Geschäftsproblem präzise beschreiben, konkrete Nutzungsszenarien aufschreiben, messbar definieren wann eine Funktion fertig ist - und alles priorisieren.

Wenn Sie die Vorlage aus diesem Artikel vollständig ausgefüllt haben, bevor Sie den ersten Entwickler anschreiben, haben Sie die gefährlichsten Risiken bereits adressiert. Der Rest - Vertragsmodell, Technologiewahl, Teamgröße - ist sekundär.

Wenn Sie Ihr Projekt konkret besprechen wollen: Unsere Custom Web-App Entwicklung begleitet KMU von der Anforderungsaufnahme bis zum Go-Live. Das erste Gespräch kostet nichts und endet mit einer ehrlichen Einschätzung - ob das Projekt umsetzbar ist, was es kosten würde und was es nicht leisten kann.

[INTERNAL-LINK: Leistungsseite → /leistungen/custom-webapps]

---

Quellen: Bitkom „Heiter Scheitern im Projekt" (2021); think-ics.com, Studie zu Projektverzögerungen durch unklare Anforderungen; businessanalysisexperts.de, User-Story-Studie; Standish Group CHAOS Report 2022.