Lastenheft für Software erstellen: Aufbau, Muss/Soll/Kann und Gliederung zum Kopieren

Lastenheft und Pflichtenheft: der Unterschied

In der deutschen Projektpraxis sind beide Begriffe durch DIN 69901-5 geprägt. Danach ist das Lastenheft die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers. Der Auftraggeber schreibt es. Das Pflichtenheft ist das Gegenstück: Der Auftragnehmer beschreibt darin, wie er die Vorgaben umsetzen will. Die Norm selbst ist kostenpflichtig; die Definition hier folgt veröffentlichten Erläuterungen. Ergänzend wird häufig die VDI-Richtlinie 2519 zum Vorgehen bei Lasten- und Pflichtenheften genannt, ihre Details sind hier nicht ausgewertet.

In der Praxis verschwimmen die Grenzen. Kleine Projekte haben oft nur ein Dokument, und manche Dienstleister nennen ihr Konzept „Fachkonzept“ oder „Spezifikation“. Entscheidend ist, dass beides existiert: Ihre Sicht der Anforderungen und die überprüfbare Antwort des Dienstleisters darauf. Wie Sie einen Dienstleister dafür finden, beschreibt der Leitfaden Softwaredienstleister auswählen.

Gliederung zum Kopieren

Die folgende Struktur ist ein praxisüblicher Vorschlag, keine Norm. Für kleine Vorhaben genügen Stichpunkte je Abschnitt.

1. Ausgangslage und Ziel: Welches Problem besteht heute? Woran erkennen Sie, dass es gelöst ist (Messgröße, soweit möglich)?
2. Umfang und Abgrenzung: Was gehört dazu, was ausdrücklich nicht? Welche Prozesse sind betroffen?
3. Beteiligte und Nutzergruppen: Rollen, ungefähre Anzahl, Rechte (wer darf sehen, ändern, freigeben, löschen).
4. Ist-Prozesse und Soll-Prozesse: Heutiger Ablauf mit Medienbrüchen, gewünschter Ablauf. Eine einfache Skizze genügt.
5. Funktionale Anforderungen: Nummeriert, mit Priorität (Muss/Soll/Kann) und Abnahmekriterium.
6. Daten: Welche Daten, woher, wie lange aufbewahrt, welche sind personenbezogen, was muss aus Altsystemen übernommen werden.
7. Schnittstellen und Umsysteme: Welche Systeme sind anzubinden, welches System führt welche Daten? Siehe dazu Schnittstellen und ERP-Integration.
8. Nichtfunktionale Anforderungen: Leistung, Sicherheit, Barrierefreiheit, Verfügbarkeit, Betrieb (Abschnitt unten).
9. Rahmenbedingungen: Termine, Budgetrahmen, gesetzliche und interne Vorgaben, vorhandene IT-Landschaft, Standort des Betriebs.
10. Lieferumfang und Übergabe: Quellcode, Dokumentation, Zugänge, Schulung, Tests (siehe Individualsoftware).
11. Abnahme: Wer prüft wie, anhand welcher Kriterien und Testdaten?
12. Betrieb und Wartung nach dem Start: Erwartete Reaktionszeiten, Updates, Support, Verantwortliche.
13. Offene Punkte und Annahmen: Ehrlich benennen, was noch unklar ist.
14. Anhang: Beispielbelege, Screenshots heutiger Oberflächen, Glossar.

Anforderungen so schreiben, dass man sie prüfen kann

Muss, Soll, Kann

Weisen Sie jeder Anforderung eine Priorität zu:

• Muss: Ohne diese Funktion ist die Software für den Zweck unbrauchbar.
• Soll: Wichtig, aber es gibt einen Behelf, wenn es zum Start fehlt.
• Kann: Wünschenswert, wird nur umgesetzt, wenn Zeit und Budget bleiben.

Eine Liste, in der alles „Muss“ ist, hilft niemandem. Prüfen Sie jede Muss-Anforderung mit der Frage: Was passiert im Betrieb, wenn es fehlt?

Prüfbare Formulierung

Schwach: „Das System soll schnell sein.“ Besser: „Die Auftragsliste lädt bei bis zu 10.000 Datensätzen in der Regel in wenigen Sekunden.“ Die Zahlen setzen Sie selbst aus Ihrem Bedarf; sie sind hier nur Platzhalter. Eine Anforderung ist gut, wenn zwei Personen unabhängig voneinander zum gleichen Prüfergebnis kommen.

User Story mit Akzeptanzkriterien

Beispiel (erfundenes Beispiel zur Veranschaulichung):

Als Disponentin möchte ich einen Auftrag einem Fahrer zuweisen und diesen dabei automatisch per Benachrichtigung informieren, damit ich nicht telefonieren muss.

Akzeptanzkriterien:

• Die Zuweisung ist nur für Nutzer mit der Rolle „Disposition“ möglich.
• Nach der Zuweisung erhält der Fahrer eine Benachrichtigung; schlägt sie fehl, sieht die Disponentin eine Fehlermeldung.
• Eine Zuweisung kann mit Protokolleintrag zurückgenommen werden.
• Priorität: Muss.

Nichtfunktionale Anforderungen nicht vergessen

Sie entscheiden oft stärker über Aufwand und Betrieb als einzelne Funktionen.

• Leistung: Nutzerzahlen, Datenmengen, Spitzenlasten, akzeptable Wartezeiten.
• Sicherheit und Datenschutz: Rollen und Rechte, Protokollierung, Umgang mit personenbezogenen Daten, Löschkonzept. Bei externen Dienstleistern mit Datenzugriff kann ein Auftragsverarbeitungsvertrag nötig sein (siehe Dienstleister auswählen).
• Barrierefreiheit: Das Barrierefreiheitsstärkungsgesetz (BFSG) erfasst bestimmte Produkte und Dienstleistungen, darunter E-Commerce-Dienste und Bankdienstleistungen für Verbraucher; die Regeln gelten für Dienstleistungen, die nach dem 28. Juni 2025 erbracht werden. Ob und wie Ihr Vorhaben betroffen ist, klären Sie rechtlich; bei interner Software ist es eher eine Qualitätsfrage. Halten Sie im Lastenheft fest, ob Barrierefreiheit gefordert ist. Dies ist keine Rechtsberatung.
• Betrieb: Wo läuft die Software (eigene Server, Cloud, Hosting beim Dienstleister)? Welche Verfügbarkeit brauchen Sie, wie läuft die Datensicherung, wer überwacht?
• Wartbarkeit: Dokumentation, Tests, Übergabe des Quellcodes.

Was nicht ins Lastenheft gehört

• Technische Lösungsvorgaben ohne Grund: „Die Anwendung muss in Framework X mit Datenbank Y laufen“ schränkt den Dienstleister ein. Ausnahmen: Betriebsvorgaben, vorhandene Plattformen, Sicherheitsrichtlinien. Nennen Sie dann den Grund.
• Oberflächen bis ins Pixel: Skizzen als Beispiel sind hilfreich, verbindliche Gestaltung gehört in die Konzeptphase.
• Vermischung von Muss-Funktionen und Wunschliste: Trennen Sie klar.
• Preise und Termine als Anforderung getarnt: Budgetrahmen und Wunschtermin gehören in die Rahmenbedingungen, nicht zwischen die Funktionen.

Lastenheft im agilen Projekt

Agil heißt nicht „ohne Vorbereitung“. Der Scrum Guide beschreibt das Product Backlog als geordnete Liste dessen, was zur Verbesserung des Produkts nötig ist; es entwickelt sich laufend weiter und enthält ein langfristiges Product Goal. Für die Auswahl eines Dienstleisters brauchen Sie dennoch eine belastbare Grundlage. Eine schlanke Fassung enthält:

• Ziel und Erfolgskriterien (Product Goal)
• Umfang und Abgrenzung auf einer Seite
• Nutzergruppen und die wichtigsten Abläufe
• Rahmenbedingungen: Budgetrahmen, Termine, Datenschutz, Betrieb, Schnittstellen
• Ein erstes, priorisiertes Backlog der Muss-Stories mit Akzeptanzkriterien
• Spielregeln: Wer priorisiert, wer entscheidet über Änderungen, wie wird abgerechnet

Eine mögliche Vorstufe ist eine bezahlte Discovery-Phase gemeinsam mit dem Dienstleister, in der das Backlog geschärft wird. Mit dem Werkzeug Projekt vorbereiten können Sie die wichtigsten Angaben strukturiert in einem kopierbaren Projektbrief zusammenstellen.

Typische Fehler

• Zu früh zu detailliert, an der falschen Stelle: Hundert Zeilen zu Randfunktionen, aber keine Zeile zu Rollen, Daten oder Schnittstellen.
• Keine Abnahmekriterien: Nach § 640 BGB muss der Besteller ein vertragsgemäß hergestelltes Werk abnehmen; wegen unwesentlicher Mängel darf er die Abnahme nicht verweigern. Ohne klare Kriterien streiten sich beide Seiten darüber, was „vertragsgemäß“ heißt. Das ist eine allgemeine Information und keine Rechtsberatung.
• Der Ist-Prozess fehlt: Software bildet sonst den Idealprozess ab, den es im Betrieb nicht gibt.
• Datenmigration vergessen: Altdaten, Dubletten und Datenqualität sind regelmäßig der größte Posten, der im Angebot fehlt.
• Nur eine Person hat geschrieben: Fachabteilung, IT und Datenschutz sollten gegenlesen.
• Das Lastenheft ist Stückwerk: Jede Änderung erzeugt eine neue Version; legen Sie Versionsstand und Verantwortliche fest.

Checkliste vor dem Versand an Anbieter

• Ziel und Erfolgskriterium stehen auf der ersten Seite.
• Umfang und Nicht-Umfang sind benannt.
• Jede Anforderung hat Nummer, Priorität und Prüfkriterium.
• Rollen, Rechte und Datenarten sind beschrieben.
• Schnittstellen und führende Systeme sind aufgelistet.
• Nichtfunktionale Anforderungen, Betrieb und Datenschutz sind erfasst.
• Annahmen und offene Punkte sind ausdrücklich genannt.
• Budgetrahmen und Wunschtermin stehen unter Rahmenbedingungen.
• Fachabteilung, IT und Datenschutz haben gegengelesen.

Wie sich die Anforderungen auf Kosten auswirken, lesen Sie im Leitfaden Was kostet Individualsoftware?. Ob Sie überhaupt Individualsoftware brauchen, klärt der Vergleich Standardsoftware oder Individualsoftware.