Software-Anforderungen richtig definieren: Requirements für Ihr Projekt

Die meisten Probleme in Softwareprojekten entstehen nicht beim Programmieren, sondern davor: bei der Frage, was überhaupt gebaut werden soll. Anforderungen – im Fachjargon Requirements – sind die Brücke zwischen Ihrer Geschäftsidee und der fertigen Software. Werden sie unklar, unvollständig oder widersprüchlich formuliert, pflanzt sich der Fehler durch das gesamte Projekt fort und wird mit jeder Phase teurer zu korrigieren. Dieser Leitfaden zeigt, wie Sie Anforderungen systematisch erheben, verständlich formulieren, sinnvoll priorisieren und so beschreiben, dass sie später überprüfbar sind – und wie das mit der Abnahme Ihres Projekts zusammenhängt.

Funktionale und nicht-funktionale Anforderungen

Anforderungen lassen sich grob in zwei Kategorien einteilen, und beide sind gleich wichtig. Funktionale Anforderungen beschreiben, was das System tun soll – also konkrete Funktionen und Verhaltensweisen. Beispiele: „Nutzer können sich mit E-Mail und Passwort anmelden", „Administratoren können Rechnungen als PDF exportieren" oder „Das System versendet nach jeder Bestellung eine Bestätigungs-E-Mail". Sie sind meist gut sichtbar und werden von Auftraggebern am ehesten von selbst benannt.

Nicht-funktionale Anforderungen beschreiben, wie gut das System diese Funktionen erbringen soll – also Qualitätseigenschaften. Dazu zählen Performance (Antwortzeiten, Lastfähigkeit), Sicherheit, Datenschutz, Barrierefreiheit, Verfügbarkeit, Wartbarkeit und die unterstützten Browser oder Geräte. Diese Anforderungen werden häufig vergessen, weil sie nicht so offensichtlich sind – doch gerade sie entscheiden oft über Zufriedenheit und Betriebskosten. Eine Software, die zwar alle Funktionen hat, aber bei zehn gleichzeitigen Nutzern zusammenbricht, erfüllt ihren Zweck nicht.

Typ	Beschreibt	Beispiele
Funktional	Was das System tut	Login, Suche, Export, Benachrichtigung
Nicht-funktional	Wie gut es das tut	Antwortzeit, Sicherheit, Datenschutz, Barrierefreiheit

Stakeholder frühzeitig einbeziehen

Anforderungen kommen nicht nur von einer Person. In fast jedem Projekt gibt es mehrere Stakeholder – Personen oder Gruppen, die ein berechtigtes Interesse am Ergebnis haben. Dazu gehören die spätere Nutzergruppe, die Fachabteilungen, die Geschäftsführung, die IT-Administration und manchmal externe Partner oder Behörden. Jede Gruppe bringt eigene Anforderungen mit, und diese widersprechen sich mitunter. Der Vertrieb wünscht sich vielleicht ein Maximum an Funktionen, die IT achtet auf Wartbarkeit, die Geschäftsführung auf das Budget.

Beziehen Sie diese Perspektiven bewusst und früh ein. Nichts ist teurer als eine Anforderung, die erst nach dem Go-Live auftaucht, weil eine wichtige Nutzergruppe nie befragt wurde. Bewährte Methoden zur Erhebung sind strukturierte Interviews, moderierte Workshops, die Beobachtung bestehender Arbeitsabläufe und die Analyse vorhandener Systeme. Halten Sie fest, von wem eine Anforderung stammt – so können Sie bei Rückfragen gezielt nachfragen und Prioritäten transparent begründen. Wie Sie diese Erkenntnisse für die Anbieterauswahl aufbereiten, zeigt der Ratgeber zum Briefing für die Digitalagentur.

User Stories und Akzeptanzkriterien

In agilen Projekten werden Anforderungen häufig als User Stories formuliert. Eine User Story beschreibt eine Anforderung aus Sicht des Nutzers in einem einfachen Muster: „Als [Rolle] möchte ich [Ziel], um [Nutzen]". Ein Beispiel: „Als Kunde möchte ich meine Bestellhistorie einsehen, um frühere Käufe schnell wiederzufinden." Dieses Format hält die Anforderung kurz, rückt den Nutzen in den Mittelpunkt und lässt bewusst offen, wie die Lösung technisch aussieht – das ist Aufgabe des Entwicklungsteams.

Damit eine User Story überprüfbar wird, gehören Akzeptanzkriterien dazu. Sie beschreiben die konkreten Bedingungen, unter denen die Anforderung als erfüllt gilt – zum Beispiel: „Die Bestellhistorie zeigt Datum, Betrag und Status jeder Bestellung" und „Bestellungen sind nach Datum absteigend sortiert". Akzeptanzkriterien sind die Brücke zwischen Wunsch und Prüfbarkeit: Erst mit ihnen lässt sich objektiv feststellen, ob eine Funktion fertig ist.

User Stories und ihre Verfeinerung sind eng mit dem agilen Rahmenwerk Scrum verbunden. Der Scrum Guide beschreibt, wie Arbeit in Sprints organisiert wird – festen Zeiträumen von einem Monat oder weniger – und wie das Product Backlog kontinuierlich verfeinert und neu priorisiert wird. Scrum ruht dabei auf den Säulen Transparenz, Inspektion und Adaption: Anforderungen werden regelmäßig überprüft und angepasst, statt einmalig festgeschrieben zu werden. Ob dieses Vorgehen zu Ihrem Projekt passt, erläutert der Vergleich von agilem und klassischem Vorgehen.

Priorisierung mit MoSCoW

Kaum ein Projekt kann alle Anforderungen gleichzeitig und sofort umsetzen. Deshalb ist eine klare Priorisierung entscheidend – sie macht handlungsfähig, wenn Zeit oder Budget knapp werden. Eine verbreitete und leicht anwendbare Methode ist MoSCoW. Der Name steht für vier Kategorien:

• Must have: unverzichtbar. Ohne diese Anforderungen ist das Projekt nicht sinnvoll nutzbar.
• Should have: wichtig, aber nicht überlebenswichtig. Sollte umgesetzt werden, kann aber notfalls warten.
• Could have: wünschenswert. Wird umgesetzt, wenn Zeit und Budget es zulassen.
• Won't have (this time): bewusst zurückgestellt. Für diese Version nicht vorgesehen, aber dokumentiert.

Der Vorteil dieser Methode liegt in der Klarheit: Wenn ein Termin oder Budget nicht ausreicht, wissen alle Beteiligten sofort, worauf verzichtet werden kann, ohne den Kern des Produkts zu gefährden. Priorisierung ist besonders wertvoll, wenn Sie mit einem MVP starten und Funktionen schrittweise ausbauen wollen.

Anforderungen messbar formulieren

Die häufigste Schwäche von Anforderungen ist mangelnde Überprüfbarkeit. Ein Satz wie „Die Anwendung soll schnell und benutzerfreundlich sein" klingt gut, lässt sich aber nicht objektiv testen – und wird bei der Abnahme fast zwangsläufig zum Streitpunkt. Formulieren Sie stattdessen messbar. Statt „schnell" schreiben Sie: „Die Startseite lädt bei Standard-Internetverbindung in unter zwei Sekunden." Statt „viele Nutzer" schreiben Sie: „Das System bedient 500 gleichzeitige Nutzer ohne spürbare Verzögerung."

Eine gute Anforderung ist eindeutig, überprüfbar, konsistent zu anderen Anforderungen und frei von vorweggenommenen Lösungen. Vermeiden Sie Sammelbegriffe wie „intuitiv", „modern" oder „State of the Art" ohne konkrete Kriterien. Wo Qualitätsziele schwer in Zahlen zu fassen sind, definieren Sie zumindest ein prüfbares Verfahren – etwa einen Usability-Test mit einer festgelegten Erfolgsquote. Diese Messbarkeit zahlt sich doppelt aus: Sie macht Angebote vergleichbar und die spätere Abnahme eindeutig. Wie Sie mehrere Angebote strukturiert gegenüberstellen, zeigt der Ratgeber zum Angebotsvergleich.

Verbindung zur Abnahme

Anforderungen und Abnahme gehören untrennbar zusammen. Bei der Abnahme prüfen Sie als Auftraggeber, ob das gelieferte Werk der vereinbarten Beschaffenheit entspricht. Nach § 640 BGB ist der Besteller verpflichtet, ein vertragsmäßig hergestelltes Werk abzunehmen. Was „vertragsmäßig" bedeutet, ergibt sich unmittelbar aus Ihren Anforderungen: Nur was zuvor als geschuldete Beschaffenheit definiert wurde, kann bei der Abnahme eingefordert werden.

Daraus folgt ein praktischer Grundsatz: Jede Anforderung, deren Erfüllung Ihnen wichtig ist, muss vor Projektbeginn überprüfbar dokumentiert sein. Akzeptanzkriterien werden so direkt zur Grundlage der Abnahmeprüfung. Fehlen sie, entsteht Streit darüber, ob ein Zustand ein Mangel oder eine nie vereinbarte Zusatzanforderung ist. Der geschuldete Erfolg wird beim Werkvertrag nach § 631 BGB definiert, die Abnahme nach § 640 BGB festgestellt. Wie Abnahme und Qualitätssicherung praktisch ablaufen, vertieft der Ratgeber zu Software-Abnahme und Qualitätssicherung. Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.

Tools und Vorgehen

Für die Verwaltung von Anforderungen reicht bei kleinen Projekten ein strukturiertes Dokument oder eine Tabelle mit eindeutiger Nummerierung. Größere Vorhaben profitieren von spezialisierten Werkzeugen: Backlog- und Ticket-Systeme wie Jira, Azure DevOps oder GitLab bilden User Stories, Prioritäten und Akzeptanzkriterien ab und machen den Fortschritt sichtbar. Entscheidend ist weniger das Werkzeug als die Disziplin, jede Anforderung eindeutig zu kennzeichnen, ihren Status nachzuverfolgen und Änderungen zu dokumentieren.

Behandeln Sie Anforderungen als lebendes Dokument. Gerade in agilen Projekten werden sie im Verlauf verfeinert, ergänzt und neu priorisiert. Vereinbaren Sie einen klaren Prozess, wie neue Anforderungen aufgenommen und wie Auswirkungen auf Zeit und Budget bewertet werden. Ein gute Zusammenarbeit mit dem Dienstleister lebt davon, dass beide Seiten Änderungen transparent nachvollziehen können. Unterstützung bei der methodischen Erhebung bietet auch eine externe IT-Beratung.

Anforderungen als Grundlage für Vertrag und Preis

Anforderungen sind nicht nur eine technische Fleißarbeit, sondern die Grundlage jeder Vertrags- und Preisgestaltung. Der Umfang und die Klarheit Ihrer Requirements entscheiden darüber, welche Vertragsform sinnvoll ist. Ein präzise abgegrenzter, stabiler Anforderungsumfang eignet sich für einen Werkvertrag mit Festpreis, weil sich der geschuldete Erfolg klar bestimmen lässt. Ein Vorhaben, dessen Anforderungen sich absehbar im Verlauf entwickeln, passt eher zu einer Abrechnung nach Aufwand, bei der die Zusammenarbeit im Vordergrund steht. Welches Modell für Ihr Projekt geeignet ist, vergleicht der Ratgeber zu Festpreis und Abrechnung nach Aufwand.

Auch die Höhe des Angebots hängt unmittelbar von der Qualität Ihrer Anforderungen ab. Bleiben Requirements vage, kalkulieren seriöse Anbieter Risikopuffer ein oder benennen viele Annahmen – beides erschwert den Vergleich. Je klarer der Umfang, desto belastbarer die Schätzung. Als grobe Orientierung liegt der Stundensatz für Softwareentwicklung in der DACH-Region laut Freelancer-Kompass bei rund 90 € pro Stunde, mit erheblicher Streuung nach Technologie und Erfahrung. Die geschätzten Aufwände hinter einem solchen Satz lassen sich nur mit präzisen Anforderungen realistisch beurteilen. Diese Zusammenhänge gelten unabhängig davon, ob Sie mit einer Agentur oder einem Freelancer arbeiten; Vor- und Nachteile beider Wege beschreibt der Vergleich von Agentur und Freelancer. Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.

Häufige Fehler

• Lösung statt Bedarf beschreiben: Wer die technische Umsetzung vorschreibt, verschenkt das Know-how des Anbieters und übersieht möglicherweise bessere Wege.
• Nicht-funktionale Anforderungen ignorieren: Performance, Sicherheit und Datenschutz werden gern vergessen und später teuer nachgerüstet.
• Keine Priorisierung: Wenn alles gleich wichtig ist, kann bei Engpässen nichts sinnvoll gestrichen werden.
• Stakeholder auslassen: Eine übergangene Nutzergruppe bringt ihre Anforderungen erst nach dem Go-Live ein – zum ungünstigsten Zeitpunkt.
• Unmessbare Formulierungen: Ohne überprüfbare Kriterien wird die Abnahme zur Auslegungssache.

Häufige Fragen

Was ist der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen?

Funktionale Anforderungen beschreiben, was das System tun soll – also konkrete Funktionen wie Login oder Export. Nicht-funktionale Anforderungen beschreiben, wie gut es das tut, also Qualitätseigenschaften wie Geschwindigkeit, Sicherheit, Datenschutz oder Barrierefreiheit. Für den Projekterfolg sind beide gleich wichtig.

Wie schreibt man eine gute User Story?

Nutzen Sie das Muster „Als [Rolle] möchte ich [Ziel], um [Nutzen]" und ergänzen Sie Akzeptanzkriterien, die überprüfbar festhalten, wann die Anforderung erfüllt ist. Halten Sie die Story kurz und lassen Sie die technische Lösung bewusst offen – das ist Aufgabe des Entwicklungsteams.

Wozu dient die MoSCoW-Priorisierung?

MoSCoW ordnet Anforderungen in Must, Should, Could und Won't ein. So ist bei Zeit- oder Budgetdruck sofort klar, worauf verzichtet werden kann, ohne den Kern des Produkts zu gefährden. Die Methode ist besonders nützlich, wenn Sie mit einem schlanken ersten Funktionsumfang starten.

Muss ich alle Anforderungen vor Projektbeginn festlegen?

Bei klassischem Vorgehen möglichst vollständig, bei agilem Vorgehen entwickeln sich Anforderungen im Verlauf weiter. In beiden Fällen sollten die grundlegenden Ziele und Must-have-Anforderungen früh feststehen. Agile Projekte verfeinern das Product Backlog laufend, statt alles einmalig festzuschreiben.

Warum sind messbare Anforderungen für die Abnahme wichtig?

Nur was zuvor als geschuldete Beschaffenheit überprüfbar definiert wurde, lässt sich bei der Abnahme nach § 640 BGB eindeutig einfordern. Unmessbare Formulierungen führen zu Streit darüber, ob ein Zustand ein Mangel oder eine nie vereinbarte Zusatzforderung ist.

Passende Agentur finden: Sie haben Ihre Anforderungen erarbeitet und suchen ein Team für die Umsetzung? Vergleichen Sie neutral Anbieter für Softwareentwicklung und Webentwicklung auf Deine-Agenturen.com.