68% aller IT-Projekte scheitern an Anforderungen - so machen Sie es besser

Das Problem kennt jeder

Ein neues Software-Projekt startet. Der Dienstleister fragt: „Was soll das System können?"

Die Antwort kommt meistens so:

„Das System soll Rechnungen verarbeiten können." „Es muss irgendwie mit dem ERP kommunizieren." „Die Nutzer sollen alles Wichtige auf einen Blick sehen."

Klingt erstmal vernünftig. Aber was heißt „verarbeiten"? Automatisch erfassen, prüfen, freigeben, archivieren? Wer genau sind „die Nutzer"? Was ist „alles Wichtige"?

Solche Anforderungen landen im Pflichtenheft. Und 6 Monate später im Streitgespräch.

Warum schlechte Anforderungen so teuer sind

Die Zahlen sind eindeutig.

Laut dem Standish Group Chaos Report scheitern 68% aller IT-Projekte - und der häufigste Grund sind nicht technische Probleme, sondern unklare, unvollständige oder widersprüchliche Anforderungen.

Was dabei passiert:

• Entwickler interpretieren Anforderungen unterschiedlich - es entstehen Fehl-Implementierungen
• Änderungswünsche kommen spät, wenn die Architektur schon steht - Kosten explodieren
• Abnahmen scheitern, weil nicht klar war, was „fertig" bedeutet

Eine Studie von IBM Systems Sciences Institute zeigt: Ein Fehler, der in der Anforderungsphase 1 € kostet, kostet in der Entwicklung 6 € und in der Wartung bis zu 100 €.

Die SOPHIST-Satzschablone: Ein bewährtes Framework

Prof. Chris Rupp hat mit ihrem Team bei SOPHIST ein Framework entwickelt, das genau dieses Problem löst. Die Methode stammt aus dem Standardwerk „Requirements-Engineering und Management" und wird in Unternehmen weltweit eingesetzt.

Die Grundidee: Jede Anforderung folgt einer definierten Satzstruktur. Keine Prosa, keine Interpretationsspielräume, keine „irgendwie"-Formulierungen.

Drei Typen von Anforderungen

Typ 1 - Selbstständige Systemaktivität: Das System handelt eigenständig, ohne Benutzerinteraktion.

„Das System MUSS dem Vorgesetzten eine Benachrichtigung per E-Mail senden."

Typ 2 - Benutzerinteraktion: Das System stellt einem Benutzer eine Funktion zur Verfügung.

„Das System MUSS dem Sachbearbeiter die Möglichkeit bieten, eine Eingangsrechnung im PDF-Format hochzuladen."

Typ 3 - Schnittstellenanforderung: Das System kommuniziert mit einem externen System.

„Das System MUSS fähig sein, Stammdaten vom ERP-System zu empfangen."

Die drei Verbindlichkeitsstufen

Jede Anforderung hat eine klare rechtliche Verbindlichkeit:

• MUSS - Rechtlich verbindlich. Ohne diese Funktion wird das System nicht abgenommen.
• SOLL - Dringend empfohlen. Wird implementiert, wenn es wirtschaftlich vertretbar ist.
• WIRD - Für die Zukunft geplant. Nicht im aktuellen Scope, aber bereits dokumentiert.

Bedingungen machen Anforderungen präzise

Optional kann jede Anforderung an eine Bedingung geknüpft werden:

• Falls (logisch): „Falls ein Dokument älter als 12 Monate ist, SOLL das System dieses Dokument automatisch archivieren."
• Wenn (temporal): „Wenn der Nutzer eine Freigabe erteilt, MUSS das System dem Vorgesetzten eine Benachrichtigung senden."
• Nachdem / Während - für sequenzielle oder parallele Abhängigkeiten.

Warum ein strukturierter Ansatz den Unterschied macht

Korrekt definierte und dokumentierte Anforderungen ermöglichen dem Team, klare Projektziele und einen klaren Scope zu etablieren - und verhindern, dass Missverständnisse erst in der Entwicklung oder beim Testing auffallen.

Die Vorteile eines strukturierten Ansatzes:

• Projektplanung: Stakeholder sind von Tag 1 aligned. Kein „Das habe ich aber anders gemeint."
• Entwicklungseffizienz: Entwickler wissen exakt, was das System leisten soll.
• Testbarkeit: Jede Anforderung kann direkt in einen Testfall überführt werden.
• Änderungsmanagement: Wenn sich Anforderungen ändern, ist klar dokumentiert, was sich geändert hat und warum.

Ein gutes Beispiel für komplexes Anforderungsmanagement zeigt unser ISMS App Use Case, bei dem strukturierte Anforderungen den Unterschied zwischen Erfolg und Scheitern ausmachten.

Die 5 häufigsten Fehler bei Software-Anforderungen

Aus über 60 Beratungsprojekten sehen wir immer wieder die gleichen Muster:

1. Zu vage formuliert „Das System soll benutzerfreundlich sein." - Was heißt das konkret? Für wen? In welchem Kontext?

2. Mehrere Anforderungen in einem Satz „Das System muss Rechnungen erfassen, prüfen und freigeben." - Das sind 3 Anforderungen mit potenziell 3 verschiedenen Verbindlichkeiten.

3. Keine Verbindlichkeit definiert Ohne MUSS/SOLL/WIRD ist bei der Abnahme nicht klar, was vertraglich geschuldet ist.

4. Technische Lösung statt Anforderung „Das System muss eine REST-API mit OAuth 2.0 implementieren." - Besser: „Das System MUSS fähig sein, Daten sicher an externe Systeme zu übertragen."

5. Kein Bezug zum Benutzer Wer nutzt die Funktion? Was ist die Rolle? Typ 2 der Satzschablone erzwingt genau diese Klarheit.

Der Requirements Builder: Das Tool dazu

Wir haben auf Basis der SOPHIST-Satzschablone einen interaktiven Requirements Builder gebaut. Er führt in 5 Schritten durch die Erstellung professioneller Anforderungen - Prozesswort bestimmen, Typ wählen, Verbindlichkeit festlegen, Objekte ergänzen, Bedingung hinzufügen.

Alle Anforderungen können als CSV, Excel oder PDF exportiert werden. Ohne Login, ohne Einschränkungen.

Wer komplexe Anforderungen an zusammenhängende Systeme formulieren muss, findet weitere Inspiration in unserem Use Case zum Produkt-Konfigurator im Handwerk. Und wer versteht, wie End-to-End-Prozesse funktionieren, schreibt auch bessere Anforderungen - unser Artikel zu End-to-End-Prozessen erklärt warum.