Software-Anforderungen richtig erheben – ein Praxisleitfaden für KMU

Wenn alle wissen, was sie wollen – aber niemand dasselbe meint

Sie haben eine Idee für eine neue Software. Die Fachabteilung hat Wünsche gesammelt, die IT hat technische Vorstellungen, und die Geschäftsführung erwartet einen klaren Zeitplan. Alle sind sich einig, dass das Projekt wichtig ist. Aber wenn Sie genauer hinschauen, stellen Sie fest: Jeder versteht unter "der Software" etwas anderes.

Diese Situation ist typisch. Sie entsteht nicht, weil jemand schlecht kommuniziert hat, sondern weil Software-Anforderungen erstellen ein Prozess ist, der aktiv gestaltet werden muss. Ein Dokument mit gesammelten Wünschen ist noch keine Grundlage für eine Entscheidung – es ist bestenfalls ein Anfang.

Warum Anforderungen so oft zum Problem werden

Die meisten Schwierigkeiten in Software-Projekten entstehen nicht bei der Programmierung, sondern vorher. Genauer: bei der Frage, was eigentlich gebaut werden soll.

Das hat strukturelle Gründe:

Anforderungen werden gesammelt statt erarbeitet. Wenn Sie alle Beteiligten fragen, was sie sich wünschen, erhalten Sie eine Liste. Diese Liste enthält Wichtiges und Unwichtiges, Konkretes und Vages, Widersprüchliches und Redundantes. Sie bildet ab, was Menschen spontan einfällt – nicht, was tatsächlich gebraucht wird.

Die Perspektive fehlt. Anforderungen ohne Kontext sind wertlos. "Das System soll schnell sein" bedeutet für die Buchhaltung etwas anderes als für den Außendienst. Ohne zu verstehen, wer eine Anforderung hat und warum, können Sie nicht beurteilen, ob sie relevant ist.

Es gibt keinen Entscheidungsmechanismus. Anforderungen stehen selten gleichberechtigt nebeneinander. Manche sind unverzichtbar, manche wären schön, manche schließen sich gegenseitig aus. Wenn niemand entscheidet, wird die Liste immer länger – und das Projekt immer teurer.

Drei verbreitete Missverständnisse

"Je mehr Anforderungen, desto besser"

Das Gegenteil ist richtig. Jede Anforderung, die in ein Projekt aufgenommen wird, verursacht Aufwand – bei der Konzeption, der Umsetzung, dem Test und der späteren Wartung. Ein Software-Konzept mit 200 Anforderungen ist nicht gründlicher als eines mit 50. Es ist meist nur unschärfer priorisiert.

Die relevante Frage ist nicht "Was könnte die Software alles können?" sondern "Was muss sie können, damit sich die Investition lohnt?"

"Anforderungen müssen technisch formuliert sein"

Anforderungen beschreiben Probleme und Bedürfnisse, keine technischen Lösungen. Wenn eine Fachabteilung schreibt "Wir brauchen eine REST-API mit OAuth2-Authentifizierung", dann formuliert sie keine Anforderung, sondern eine Lösungsvorgabe. Die eigentliche Anforderung könnte lauten: "Externe Partner sollen bestimmte Daten sicher abrufen können."

Der Unterschied ist erheblich. Im ersten Fall ist der Lösungsweg vorgegeben. Im zweiten Fall können verschiedene Umsetzungswege geprüft werden.

"Einmal dokumentiert, fertig"

Anforderungen sind nicht statisch. Je mehr Sie über ein Projekt verstehen, desto klarer wird, was wirklich gebraucht wird – und was nicht. Ein Anforderungsmanagement, das Änderungen als Störung betrachtet, arbeitet gegen die Realität.

Das bedeutet nicht, dass Anforderungen beliebig änderbar sein sollten. Es bedeutet, dass Sie einen Prozess brauchen, der Änderungen kontrolliert zulässt und ihre Auswirkungen sichtbar macht.

Wie Sie Anforderungen strukturiert erheben

Ausgangspunkt: Das Problem verstehen

Bevor Sie fragen, was die Software können soll, klären Sie, welches Problem sie lösen soll. Das klingt banal, wird aber regelmäßig übersprungen.

Relevante Fragen dafür:

• Welcher Prozess funktioniert heute nicht gut genug?
• Was kostet das Problem – in Zeit, Geld, Qualität?
• Wer ist betroffen?
• Was passiert, wenn das Problem nicht gelöst wird?

Die Antworten helfen Ihnen, Anforderungen einzuordnen. Eine Funktion, die ein teures Problem löst, ist wichtiger als eine, die einen Komfortwunsch erfüllt.

Use Cases statt Feature-Listen

Ein Use Case beschreibt, wie ein Nutzer mit der Software interagiert, um ein Ziel zu erreichen. Er zwingt Sie, in Abläufen zu denken statt in Funktionen.

Ein Beispiel: Statt "Das System soll eine Suchfunktion haben" formulieren Sie: "Ein Vertriebsmitarbeiter sucht einen Kunden anhand der Kundennummer, um dessen letzte Bestellungen einzusehen."

Der Unterschied: Im ersten Fall wissen Sie, dass es eine Suchfunktion geben soll. Im zweiten Fall wissen Sie, wer sucht, wonach gesucht wird und warum. Das ermöglicht Entscheidungen: Wie schnell muss die Suche sein? Welche Suchkriterien werden gebraucht? Welche Ergebnisse sind relevant?

Use Cases sind kein Allheilmittel, aber sie verhindern, dass Sie Funktionen spezifizieren, ohne ihren Zweck verstanden zu haben.

Priorisierung als Entscheidungsinstrument

Nicht alle Anforderungen sind gleich wichtig. Eine sinnvolle Unterscheidung:

Muss: Ohne diese Funktion ist die Software nicht nutzbar oder das Kernproblem nicht gelöst.

Soll: Diese Funktion ist wichtig für die Akzeptanz oder Wirtschaftlichkeit, aber nicht unverzichtbar für den Start.

Kann: Diese Funktion wäre schön, aber ihr Fehlen ist kein ernsthaftes Problem.

Diese Einteilung ist nur nützlich, wenn sie ernst genommen wird. Wenn 80 Prozent aller Anforderungen als "Muss" eingestuft werden, findet keine Priorisierung statt.

Die Priorisierung ist eine Managementaufgabe, keine technische. Sie erfordert Entscheidungen darüber, was wichtiger ist – und die Bereitschaft, manche Wünsche zurückzustellen.

Was gute Anforderungen kennzeichnet

Eine brauchbare Anforderung ist:

Verständlich: Alle Beteiligten verstehen dasselbe darunter – Fachbereich, IT und Management.

Überprüfbar: Sie können feststellen, ob die Anforderung erfüllt ist oder nicht. "Das System soll benutzerfreundlich sein" ist nicht überprüfbar. "Ein neuer Nutzer kann ohne Schulung innerhalb von fünf Minuten eine Bestellung erfassen" ist überprüfbar.

Unabhängig: Anforderungen sollten möglichst wenig voneinander abhängen. Das erleichtert Priorisierung und spätere Änderungen.

Begründet: Zu jeder Anforderung gehört ein Warum. Die Begründung hilft bei der Priorisierung und ermöglicht es, bei Änderungen zu prüfen, ob die Anforderung noch relevant ist.

Der Unterschied zwischen Wunschliste und Entscheidungsgrundlage

Am Ende des Anforderungsprozesses sollte kein Dokument stehen, das alle Wünsche enthält. Es sollte ein Dokument stehen, das Entscheidungen ermöglicht:

• Was wird gebaut und was nicht?
• In welcher Reihenfolge?
• Mit welchen Abhängigkeiten und Risiken?
• Zu welchen ungefähren Kosten?

Dieses Dokument ist ein Software-Konzept, das unabhängig davon funktioniert, wer die Umsetzung später übernimmt. Es gehört Ihnen, nicht einem Dienstleister. Und es schützt Sie davor, Entscheidungen erst dann zu treffen, wenn die Entwicklung bereits läuft – zu einem Zeitpunkt, an dem Änderungen teuer werden.

Ein strukturierter Ausgangspunkt

Anforderungen erheben ist Arbeit. Es erfordert Zeit, die richtigen Fragen und die Bereitschaft, Entscheidungen zu treffen. Wenn Sie diese Arbeit nicht leisten, erledigt sie jemand anderes für Sie – oft der Dienstleister, der die Software entwickelt. Das ist nicht grundsätzlich schlecht, aber es verschiebt Entscheidungen, die eigentlich Ihnen gehören.

Fazit

Software-Anforderungen erstellen ist kein Dokumentationsprojekt. Es ist ein Entscheidungsprozess, der strukturiert werden muss. Die typischen Probleme – zu viele Wünsche, zu wenig Priorisierung, fehlende Klarheit – entstehen nicht durch mangelnde Sorgfalt, sondern durch fehlende Methodik.

Wer Anforderungen als das behandelt, was sie sind – Grundlage für Investitionsentscheidungen –, hat bessere Chancen auf ein Projekt, das im Budget bleibt und das liefert, was tatsächlich gebraucht wird.