Im Lastenheft steht „Das System soll Aufträge schnell und einfach verarbeiten“. Jeder Anbieter nickt dazu, und jeder meint etwas anderes. Das Problem ist kein fehlender Wille, sondern der Satz: Er sagt nicht, was geschehen soll, und er lässt sich nicht prüfen.
Dieser Beitrag zeigt, was funktionale Anforderungen sind, wie sie sich von nichtfunktionalen unterscheiden und wie Sie beide so aufschreiben, dass am Ende jemand sagen kann: erfüllt oder nicht erfüllt. Er richtet sich an Geschäftsführung, Inhaber und Fachverantwortliche, die ein Lastenheft schreiben oder ein fremdes Pflichtenheft lesen müssen.
Funktionale Anforderungen: was sie festlegen
Eine Anforderung ist nach der Wikipedia-Übersicht zu Anforderungen in der Informatik eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder Prozesses (Stand Oktober 2026). Eine funktionale Anforderung legt dort fest, was das Produkt tun soll. Das Beispiel der Quelle: „Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.“
Daran sieht man drei Merkmale, die jede gute funktionale Anforderung hat:
- Sie beschreibt eine Fähigkeit des Systems, keine Technik und keine Lösung.
- Sie nennt ein Ergebnis, das man beobachten kann.
- Sie ist einzeln: Ein Satz, eine Fähigkeit. Kommt ein „und“ hinein, sind es meist zwei Anforderungen.
Sie legt dagegen nicht fest, wie schnell, wie sicher oder wie bequem das geschieht. Dafür gibt es die zweite Sorte.
Funktionale und nichtfunktionale Anforderungen: der Unterschied
Nichtfunktionale Anforderungen beschreiben nach derselben Quelle, wie gut das System die Leistung erbringen soll. Sie werden vielfach als Randbedingungen und Qualitätseigenschaften verstanden. Ihr Beispiel: „Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten.“ Die Quelle weist auch darauf hin, dass der Begriff in der Literatur nicht einheitlich definiert ist. Die Unterteilung in funktionale und nichtfunktionale Anforderungen gilt als die verbreitetste.
| Funktional | Nichtfunktional | |
|---|---|---|
| Frage | Was tut das System? | Wie gut tut es das, unter welchen Bedingungen? |
| Typische Wörter | erzeugt, sendet, berechnet, zeigt, speichert | innerhalb von, mindestens, höchstens, verfügbar, nachvollziehbar |
| Beispiel | „Ein Auftrag aus dem CRM wird im ERP angelegt.“ | „Das Anlegen dauert höchstens fünf Minuten.“ |
| Typischer Fehler | zu vage („verarbeitet Aufträge“) | fehlt ganz |
Häufig kommen dazu Randbedingungen, die die Quelle ebenfalls nennt: eine Obergrenze für Kosten und ein Termin für den Abschluss des Projekts.
Beide Sorten gehören ins Lastenheft. Die gängige Gliederung des Lastenhefts führt laut Wikipedia funktionale und nichtfunktionale Anforderungen als eigene Punkte, daneben Schnittstellen, Lieferumfang und Abnahmekriterien. Wie das Lastenheft als Ganzes aufgebaut ist, steht im Beitrag Lastenheft für IT-Projekte. Hier geht es um den einzelnen Satz.
Funktionale Anforderungen formulieren: fünf Regeln
Die Regeln sind einfach, die Wirkung ist groß. Sie ziehen die Grenze zwischen einem Satz, den jeder anders liest, und einem Satz, den man abnehmen kann.
1. Eine Fähigkeit pro Satz
„Das System legt Aufträge an und informiert den Vertrieb und bucht den Lagerbestand“ sind drei Anforderungen in einem Satz. Wird eine davon nicht erfüllt, ist der Satz weder erfüllt noch nicht erfüllt. Teilen Sie auf.
2. Auslöser, Ergebnis, Bedingung
Eine brauchbare Form: Wenn etwas passiert, dann geschieht dies, sofern eine Bedingung gilt. „Wenn ein Auftrag im CRM auf ‚gewonnen‘ gesetzt wird, legt das System im ERP einen Auftrag an, sofern die Kundennummer bekannt ist.“ Der letzte Teil ist wichtig: Die Bedingung zwingt dazu, den Sonderfall zu nennen, statt ihn zu übersehen.
3. Ein Abnahmekriterium dazu
Nach der Wikipedia-Übersicht besteht eine einzelne Anforderung typischerweise aus Identifikator, kurzer Beschreibung, Problembeschreibung (Rationale), Quelle und einem Abnahmekriterium. Das Abnahmekriterium ist dort eine messbare Bedingung, mit der später geprüft wird, ob die Anforderung erfüllt wurde. Als Quelle kann eine Rechtsvorschrift dienen. Das Kriterium ist der Teil, den die meisten Lastenhefte weglassen. Fügen Sie ihn pro Anforderung hinzu, auch wenn er nur einen Satz lang ist: „Geprüft an drei Testaufträgen, davon einer ohne Kundennummer.“
4. Gewichten: muss, soll, kann
Die Übersicht zu Softwareanforderungen nennt die Unterscheidung in Muss-, Sollte-, Könnte- und Nicht-Anforderungen und verweist dafür auf RFC 2119 (Stand Oktober 2026). Ohne Gewichtung wird alles gleich teuer. Mit Gewichtung sehen Sie im Angebot, was der Anbieter für die Muss-Punkte verlangt und was er für die Wünsche aufschlägt.
5. Schriftlich und eindeutig
Anforderungen, die nur mündlich, per E-Mail oder auf Notizzetteln festgehalten sind, gehören laut derselben Quelle nicht zum Anforderungskatalog, den ein Entwickler umsetzen muss. Sie müssen erst strukturiert erfasst werden. Die Quelle nennt auch einen Grund, warum Sätze scheitern: Natürliche Sprache muss interpretiert werden, und selbstverständliche Voraussetzungen werden nicht erwähnt. Schreiben Sie deshalb Begriffe aus, die im Betrieb jeder anders benutzt („Auftrag“, „Kunde“, „Lieferung“), und halten Sie sie überall gleich.
Beispiele für funktionale Anforderungen
Die Beispiele zeigen den Unterschied zwischen vage und prüfbar. Die Zahlen und Rollen sind Platzhalter für Werte aus Ihrem Betrieb.
| Vage | Prüfbar |
|---|---|
| „Aufträge werden schnell übertragen.“ | „Wenn ein Auftrag im CRM auf ‚gewonnen‘ gesetzt wird, legt das System im ERP einen Auftrag mit denselben Positionen an. Abnahme: drei Testaufträge, davon einer mit Rabatt.“ |
| „Rechnungen werden freigegeben.“ | „Eine Eingangsrechnung über dem festgelegten Schwellenwert geht zur Freigabe an eine zweite Person. Abnahme: Rechnung über und unter dem Schwellenwert, Freigabe wird mit Name und Zeitpunkt gespeichert.“ |
| „Das Lager ist immer aktuell.“ | „Jede Änderung des Bestands wird als Buchung mit Datum, Benutzer und Menge gespeichert. Abnahme: Der Bestand eines Artikels lässt sich aus seinen Buchungen nachrechnen.“ |
| „Es gibt Rechte.“ | „Mitarbeitende der Rolle ‚Vertrieb‘ sehen Aufträge ihres Bereichs, nicht die der anderen. Abnahme: Testbenutzer je Rolle.“ |
Mehr zu Rechnungsfreigabe und Bestandsführung steht in den Beiträgen Rechnungsfreigabe: Regeln, Grenzen und Vertretung und Excel-Lagerverwaltung: wann die Grenzen erreicht sind.
Auffällig ist die Struktur: Jede Zeile rechts enthält eine Handlung, ein Ergebnis und einen Test. Das ist kein Mehraufwand, sondern ein vorgezogener Teil der Abnahme.
Nichtfunktionale Anforderungen: was Sie zusätzlich benennen
Funktionen reichen nicht. Software, die alles kann, aber unter Last einbricht, ist nicht fertig. Als Prüfraster eignen sich die Qualitätsmerkmale der Norm ISO/IEC 25010. Die Wikipedia-Übersicht nennt sie als Möglichkeit, Anforderungen als Qualitätskriterien zu klassifizieren. Nach der Beschreibung des ISO-25000-Portals umfasst das Produktqualitätsmodell neun Merkmale (Stand Oktober 2026), darunter:
- Funktionale Eignung: wie vollständig und richtig die Funktionen die festgelegten Aufgaben abdecken. Das ist die Gegenseite zu den funktionalen Anforderungen.
- Leistungseffizienz: Zeitverhalten, Ressourcenverbrauch und Kapazitätsgrenzen.
- Kompatibilität: ob das System mit anderen Systemen Informationen austauschen und sie gemeinsam nutzen kann.
- Interaktionsfähigkeit: wie gut bestimmte Nutzer ihre Aufgaben über die Oberfläche erledigen können.
Das Portal führt unter den neun Merkmalen weitere Gruppen auf, die für das Lastenheft ebenso taugen. Die Wikipedia-Übersicht gliedert nichtfunktionale Anforderungen außerdem in Ausführungsqualität (zur Laufzeit beobachtbar, etwa Zuverlässigkeit, Leistung, Sicherheit) und Weiterentwicklungsqualität (etwa Wartbarkeit, Portierbarkeit, Skalierbarkeit).
Für ein Vorhaben im Mittelstand reichen meist fünf Fragen, jede mit einem Wert aus Ihrem Betrieb:
- Zeit: In welcher Zeit muss eine Aktion fertig sein, und bei wie vielen gleichzeitigen Nutzern?
- Verfügbarkeit: Wann darf das System ausfallen, und wie schnell muss es wieder laufen?
- Sicherheit: Wer darf was sehen, und wie wird das nachgewiesen?
- Betrieb: Wer pflegt es, wie sind Updates, Protokolle und Datensicherung geregelt?
- Anschluss: Mit welchen Systemen muss es reden, und über welche Schnittstellen?
Bei Sicherheit und Verfügbarkeit kann eine Rechtsvorschrift die Quelle der Anforderung sein. Bei personenbezogenen Daten verlangt etwa Art. 32 DSGVO geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik. Die Maßnahmen schließen laut Text unter anderem die Fähigkeit ein, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer sicherzustellen und die Verfügbarkeit der Daten nach einem Zwischenfall rasch wiederherzustellen. Prüfen Sie, welche Pflichten für Ihren Betrieb gelten; das ist keine Rechtsberatung. In die Anforderung gehört dann ein Maß: „Nach einem Ausfall steht das System innerhalb von vier Stunden wieder zur Verfügung“ ist prüfbar, „Das System ist ausfallsicher“ nicht.
Vom Satz zur Abnahme: warum das Vertragsfolgen hat
Wird ein Softwareprojekt als Werkvertrag geschlossen, ist das Werk laut § 633 BGB frei von Sachmängeln, wenn es die vereinbarte Beschaffenheit hat (Stand Oktober 2026). Was Sie als Anforderung festhalten und im Vertrag aufgreifen, ist ein naheliegender Ort für diese Vereinbarung. Auch die Wikipedia-Übersicht zum Lastenheft sagt, dass das Lastenheft im Rahmen eines Werkvertrags und der formellen Abnahme die nachprüfbaren Leistungen und Lieferungen beschreibt.
Zur Abnahme regelt § 640 BGB, dass der Besteller das vertragsmäßig hergestellte Werk abzunehmen hat und die Abnahme wegen unwesentlicher Mängel nicht verweigern kann. Ein Werk gilt auch als abgenommen, wenn der Unternehmer eine angemessene Frist zur Abnahme gesetzt hat und der Besteller sie nicht innerhalb dieser Frist unter Angabe mindestens eines Mangels verweigert. Wer in dieser Frist sachlich prüfen will, braucht Kriterien, die vorher feststanden. Anforderungen mit Abnahmekriterium sind genau das. Das ist ein Hinweis, keine Rechtsberatung; lassen Sie bei hohen Summen den Vertrag rechtlich lesen.
Typische Fehler
Häufig scheitern funktionale Anforderungen an wenigen Mustern:
- Adjektive statt Maße. „Schnell“, „einfach“, „flexibel“, „bei Bedarf“ lassen sich nicht abnehmen.
- Lösung statt Fähigkeit. „Per REST-API an System X“ ist eine Vorentscheidung. Das Lastenheft sollte laut Wikipedia die Anforderungen so allgemein wie möglich und so einschränkend wie nötig formulieren.
- Alles ist „muss“. Wenn jede Zeile gleich schwer wiegt, hilft die Liste keinem Angebot.
- Sonderfälle fehlen. Die Quelle zu Softwareanforderungen hält fest, dass sich Anforderungen in der Praxis kaum vollständig und widerspruchsfrei formulieren lassen und Lücken oft erst in der Entwicklung auffallen. Planen Sie deshalb einen Weg ein, Anforderungen zu ändern, und halten Sie fest, wer entscheidet.
- Nichtfunktionales fehlt. Dann entscheidet der Anbieter über Antwortzeit, Ausfallzeit und Rechte, ohne dass es jemand gesagt hat.
- Der Auftraggeber liefert zu spät. Nach derselben Quelle gehört zu den Pflichten des Kunden, Entscheidungen und Auskünfte zu Anforderungen in angemessener Zeit zu geben und Akzeptanzkriterien festzulegen.
Wann Aufschreiben nicht genügt
Eine Liste prüfbarer Sätze ersetzt kein Gespräch. Die Quelle zu Softwareanforderungen empfiehlt regelmäßige Reviews der Anforderungen und das Auswerten von Prototypen. Bei kleinen Vorhaben genügt oft eine Seite; bei Schnittstellen zu gewachsenen Systemen lohnt es sich, den Bestand zu prüfen, bevor die ersten Anforderungen feststehen. Dazu hilft der Beitrag Neu bauen, ablösen oder weiterbetreiben.
Haben Sie die Anforderungen beisammen, folgt im nächsten Schritt das Pflichtenheft des Anbieters. Wie Sie es gegen Ihr Lastenheft prüfen, steht im Beitrag Pflichtenheft: was es enthält und wie Sie es prüfen. Liegt schon ein Angebot vor, hilft Woran erkennt man, dass ein IT-Angebot nicht trägt?.
Wenn niemand im Haus gegenliest
Die häufigste Lücke ist nicht das Wissen, sondern die zweite Person, die fragt: „Woran sehen wir, dass das erfüllt ist?“ Genau dafür ist die Technische Begleitung gedacht: laufende Unterstützung für Unternehmen ohne IT-Leitung, bei der Anforderungen gegengelesen und Dienstleister eingeordnet werden. Ab 1.900 € netto im Monat.
Liegt statt eines Lastenhefts schon ein Angebot oder ein Pflichtenheft mit Frist auf dem Tisch, ist die Architektur-Zweitmeinung der kürzere Weg: eine Woche, 1.400 € netto, ein Dokument mit klarer Aussage.