Lastenheft Software: Aufbau, Vorlage und KI-Projekte

Ein Lastenheft für Software beschreibt aus Sicht des Auftraggebers, was eine Anwendung leisten muss und woran ihre Abnahme gemessen wird: Ziele, Nutzer, Abläufe, Daten, Schnittstellen und Qualitätsanforderungen. Das Pflichtenheft ist die Antwort des Auftragnehmers und beschreibt, wie er diese Anforderungen umsetzt. Bei KI-Projekten kommen Anforderungen hinzu, die klassische Vorlagen nicht kennen: ein Test-Set als Abnahmegrundlage, Qualitätskennzahlen, Kosten pro Antwort und die Rolle des Menschen im Ablauf.

Dieser Artikel richtet sich an Geschäftsführung, Fachbereiche und IT-Verantwortliche, die Individualsoftware oder eine KI-Funktion beauftragen wollen. Er erklärt den Unterschied zwischen Lastenheft und Pflichtenheft, zeigt, wie Sie Anforderungen abnahmefähig formulieren, was ein Lastenheft für ein KI-Projekt zusätzlich braucht und wann ein Backlog die bessere Form ist. Am Ende steht eine Gliederung, die Sie als Vorlage übernehmen können.

Lastenheft vs. Pflichtenheft in der Softwareentwicklung

Die Begriffe sind in der DIN 69901-5 (Projektmanagement, Teil 5: Begriffe, Ausgabe Januar 2009) definiert. Das Lastenheft ist dort die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Pflichtenheft enthält die vom Auftragnehmer erarbeiteten Realisierungsvorgaben, mit denen er das Lastenheft umsetzt. Für das Vorgehen beim Erstellen beider Dokumente gibt es die Richtlinie VDI 2519 Blatt 1 (Dezember 2001). Sie wurde für Materialfluss- und Automatisierungssysteme geschrieben, ihr Grundgedanke lässt sich aber auf Software übertragen: Betreiber, Planer und Hersteller sollen auf einer gemeinsamen, schriftlichen Grundlage zusammenarbeiten.

Das Pflichtenheft in der Softwareentwicklung ist also kein ausführlicheres Lastenheft, sondern ein anderes Dokument mit anderem Verfasser. Ein typischer Fehler ist die Vermischung: Steht im Lastenheft schon eine Lösung („Umsetzung als Web-App mit relationaler Datenbank und Excel-Export“), können Anbieter keine besseren Wege mehr vorschlagen, und Sie vergleichen am Ende Preise für Ihre eigene Lösungsidee. Beschreiben Sie im Lastenheft das Problem und die Randbedingungen, nicht die Umsetzung. Für Fertigungssysteme mit ERP-Anbindung und mehreren Werken gelten eigene Schwerpunkte, die wir im Artikel zum MES-Lastenheft beschreiben.

Was ins Pflichtenheft gehört und wie Sie es prüfen

Ein Pflichtenheft für Individualsoftware enthält typischerweise diese Teile:

• Systemarchitektur und Technologien: Aufbau der Anwendung, eingesetzte Plattformen und Frameworks, Hosting.
• Datenmodell: Datenobjekte, ihre Beziehungen und das jeweils führende System.
• Schnittstellenspezifikation: für jede Schnittstelle aus dem Lastenheft Format, Protokoll, Takt und Fehlerbehandlung.
• Test- und Abnahmekonzept: Testfälle, Testdaten und der Ablauf der Abnahme.
• Betriebs- und Übergabekonzept: Monitoring, Updates, Dokumentation und Übergabe an Ihre IT.

Prüfen Sie das Pflichtenheft, bevor Sie es unterschreiben: Jede Muss-Anforderung aus dem Lastenheft sollte sich einer nachvollziehbaren Stelle im Pflichtenheft und einem Testfall zuordnen lassen. Fehlt eine Anforderung oder wurde sie umformuliert, klären Sie das vor der Unterschrift.

Anforderungen, die sich abnehmen lassen

Ein Lastenheft ist so gut wie seine Abnahmekriterien. Jede Anforderung sollte eine Frage beantworten: Woran erkennen beide Seiten, dass sie erfüllt ist?

Funktionen als Abläufe beschreiben

Beschreiben Sie Funktionen als Abläufe mit Auslöser, Beteiligten und Ergebnis, nicht als Liste von Menüpunkten. „Die Disposition sieht offene Aufträge“ ist eine Absicht. „Beim Anlegen eines Auftrags im ERP-System erscheint er innerhalb von fünf Minuten in der Auftragsliste der Disposition, sortiert nach Liefertermin“ ist eine Anforderung, die sich testen lässt. Nennen Sie außerdem die Sonderfälle: Storno, Teillieferung, fehlende Stammdaten. In ihnen steckt meist mehr Aufwand als im Normalfall.

Nicht-funktionale Anforderungen mit Zahlen

Nicht-funktionale Anforderungen beschreiben, wie gut, schnell und sicher die Software arbeitet: Antwortzeiten, Verfügbarkeit, Anzahl gleichzeitiger Nutzer, Datenmengen, Aufbewahrungsfristen, Rollen und Rechte, Protokollierung. Ohne Zahlen bleiben sie Wünsche. Das Mengengerüst, also die Zahlen, auf die das System ausgelegt sein muss, ist eine zentrale Eingabe für jede Aufwandsschätzung.

Priorisieren statt alles zu fordern

Teilen Sie Anforderungen in Muss, Soll und Kann ein. Ein Lastenheft, in dem alles Muss ist, macht Angebote unvergleichbar und das Projekt teuer. Eine klare Priorisierung erlaubt dagegen ein erstes, produktiv nutzbares Release und spätere Ausbaustufen.

Schnittstellen als eigene Anforderungen

Aus der Praxis unseres Gründers als Product Owner einer MES-Plattform bei einem Hausgerätehersteller, vor Gründung von Amperbytes AI: Zur Plattform gehörten die ERP-Anbindung und Schnittstellen über REST, SOAP, XML und FTP; sie wurden konzipiert, in Integrationstests geprüft und im Go-Live begleitet. Daraus unsere Empfehlung für jedes Softwareprojekt: Beschreiben Sie jede Schnittstelle als eigene Anforderung mit Richtung, Inhalt, führendem System und Fehlerverhalten. Ein Beispiel: „Aufträge vom ERP-System in die neue Anwendung, alle fünf Minuten, führend ist das ERP-System, bei Fehler automatische Wiederholung und Meldung an die IT.“ Eine Schnittstelle, die im Lastenheft nur mit einem Satz vorkommt, führt im Projekt häufig zu Nachträgen.

Was ein Lastenheft für ein KI-Projekt zusätzlich braucht

Klassische Software verhält sich deterministisch: Gleiche Eingabe, gleiches Ergebnis. Ein Sprachmodell (LLM, Large Language Model) antwortet dagegen mit Wahrscheinlichkeiten und kann auf dieselbe Frage unterschiedlich formulieren oder sich irren. Eine Anforderung wie „Der Assistent beantwortet Fragen korrekt“ lässt sich deshalb nicht abnehmen. Ein Lastenheft für ein KI-Projekt ersetzt sie durch messbare Qualität auf einem vereinbarten Test-Set.

Aus der Praxis unseres Gründers als Product Owner bei einem Premium-Automobilhersteller, außerhalb von Amperbytes AI: KI-Anwendungsfälle wurden dort gemeinsam mit dem Fachbereich identifiziert und in Produktion gebracht, darunter ein Assistent mit Retrieval über Diagnoseinhalte. Bei der Entscheidung zwischen Eigenbau und Zukauf wurden KI-Services nach Antwortqualität, Kosten, Latenz und Datenschutz bewertet, und die Qualität in Produktion wurde mit definierten Kennzahlen in Grafana und Kibana gemessen. Genau diese vier Kriterien gehören als Anforderungen ins Lastenheft, bevor ein Anbieter oder ein Modell ausgewählt wird. Wie Sie die Entscheidung zwischen Eigenbau und Zukauf strukturieren, beschreibt unser Artikel KI Build vs. Buy im Mittelstand.

Die Werte in der Tabelle sind Beispiele. Welche Zielwerte angemessen sind, hängt davon ab, was eine falsche Antwort in Ihrem Prozess kostet.

Test-Set und Qualitätskennzahlen

Das Test-Set ist die Abnahmegrundlage einer KI-Funktion: eine Liste echter Fragen oder Eingaben mit der erwarteten Antwort, die Fachleute aus Ihrem Haus erstellt oder geprüft haben. Diese Referenzdaten sind die eigentliche Kennzeichnungsarbeit (Labeling) im Projekt, und sie kostet Zeit im Fachbereich. Planen Sie sie im Lastenheft als Beistellung des Auftraggebers ein. Welche Kennzahlen sich für Assistenten mit Retrieval eignen und wie Sie sie erheben, beschreibt unser Artikel Antwortqualität von RAG-Assistenten messen.

Datenzugang und Datenschutz

Fehlender Datenzugang ist einer der Gründe, an denen KI-Piloten stecken bleiben (siehe warum KI-Piloten nicht in Produktion kommen). Halten Sie fest, welche Datenquellen genutzt werden, über welche Schnittstelle, wie aktuell die Daten sein müssen und wer den Zugriff freigibt. Dazu gehören die Datenschutzanforderungen: Welche personenbezogenen Daten sind betroffen, in welcher Region dürfen sie verarbeitet werden, welche Berechtigungen gelten für wen? Für Assistenten mit Retrieval gibt die Orientierungshilfe der Datenschutzkonferenz „Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode“ (Oktober 2025) einen Rahmen, an dem Sie die Anforderungen ausrichten können. Die technischen Optionen dazu vergleicht unser Artikel zur DSGVO-konformen LLM-Integration.

Kosten pro Antwort und Antwortzeit

Bei klassischer Software fallen Betriebskosten vor allem für Infrastruktur an. Bei KI-Funktionen kommt ein Anteil hinzu, der mit jeder Anfrage wächst: Modellanbieter rechnen bei Nutzung über eine API in der Regel nach Tokens ab, also nach den Textbausteinen in Frage, Kontext und Antwort. Legen Sie deshalb das erwartete Anfragevolumen fest und fordern Sie, dass Kosten pro Antwort und Antwortzeit gemessen und berichtet werden. Nur so erkennen Sie, ob ein größeres Modell oder ein längerer Kontext die bessere Qualität wert ist.

Mensch im Ablauf und Kennzeichnung

Legen Sie fest, wo ein Mensch eingreift: Freigabe vor dem Versand, Stichproben, Übergabe an einen Sachbearbeiter bei Unsicherheit. Dieses Prinzip heißt Human-in-the-Loop. Dazu gehört die Kennzeichnung gegenüber Nutzern: Nach der Übersicht der EU-Kommission zu Art. 50 KI-Verordnung gelten seit dem 2. August 2026 Transparenzpflichten, etwa der Hinweis, dass Menschen mit einem KI-System interagieren. Für die maschinenlesbare Kennzeichnung KI-erzeugter Inhalte nach Art. 50 Abs. 2 gilt für Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, eine Übergangsfrist bis 2. Dezember 2026. Rechtsstand dieser Angaben: 29. September 2026; sie sind allgemeine Information und keine Rechtsberatung. Was das für Ihr Unternehmen bedeutet, ordnet unser Artikel zur KI-Verordnung im Mittelstand ein.

Lastenheft oder Backlog: die agile Alternative

Ein vollständiges Lastenheft setzt voraus, dass Sie die Anforderungen vorab kennen. Bei neuen Produkten und besonders bei KI-Funktionen ist das selten der Fall: Erst der Prototyp zeigt, welche Fragen Nutzer wirklich stellen und wo das Modell Fehler macht. Agile Vorgehensmodelle arbeiten deshalb mit einem Product Backlog. Der Scrum Guide (Fassung 2020) beschreibt es als geordnete, sich entwickelnde Liste dessen, was das Produkt verbessern soll. Die Einträge werden laufend verfeinert, und die Definition of Done beschreibt, welche Qualitätsanforderungen ein Inkrement, also ein nutzbarer Zwischenstand des Produkts, erfüllen muss, bevor es als fertig gilt. Üblich ist zusätzlich, jeden Eintrag mit Akzeptanzkriterien zu versehen, die beschreiben, wann genau er erledigt ist.

Wir empfehlen eine Kombination: ein kurzes Rahmen-Lastenheft mit Zielen, Rahmenbedingungen, nicht-funktionalen Anforderungen, KI-Qualitätskennzahlen und Abnahmeregeln, dazu ein Backlog für die Funktionen. Das Rahmen-Lastenheft ändert sich selten, das Backlog jede Woche. Unser Gründer ist Certified ScrumMaster und war in früheren Projekten, vor bzw. außerhalb von Amperbytes AI, als Product Owner für die Anforderungen verantwortlich. Die Aufteilung folgt einer einfachen Logik: Stabile Leitplanken schützen vor ständigem Neuverhandeln, das Backlog lässt Raum für das, was man erst im Projekt lernt.

Für einen Festpreisvertrag mit fest definiertem Umfang bleibt das klassische Lastenheft die bessere Grundlage. Für ein Produkt, das nach dem ersten Release weiterentwickelt wird, ist das Backlog ehrlicher. Wenn auf Ihrer Seite niemand die Rolle des Product Owners übernehmen kann, lässt sie sich auch auf Zeit besetzen, siehe Solution Architect und Product Owner.

Vorlage: Gliederung eines Lastenhefts für Software und KI

Die folgende Gliederung deckt auch die Punkte ab, die in Lastenheften oft fehlen: Mengengerüst, Schnittstellen, Abnahme und Betrieb. Kapitel 7 entfällt, wenn keine KI-Funktion geplant ist.

1. Ausgangslage und Ziele: heutiger Ablauf, Problem, messbares Ziel (etwa Durchlaufzeit, Fehlerquote, Suchaufwand).
2. Nutzer und Rollen: wer die Software nutzt, wie oft, auf welchen Geräten, mit welchen Rechten.
3. Abläufe und Funktionen: je Ablauf Auslöser, Schritte, Ergebnis, Sonderfälle; priorisiert nach Muss, Soll, Kann.
4. Daten und Mengengerüst: Datenobjekte, führendes System, Mengen, Wachstum, Aufbewahrung.
5. Schnittstellen: Umsysteme, Richtung, Inhalt, Auslöser, Fehlerverhalten, Ansprechpartner.
6. Nicht-funktionale Anforderungen: Antwortzeiten, Verfügbarkeit, Sicherheit, Datenschutz, Barrierefreiheit, Betrieb und Monitoring.
7. KI-spezifische Anforderungen: Test-Set und Referenzdaten, Qualitätskennzahlen mit Zielwerten, Datenzugang, Kosten pro Antwort, Antwortzeit, Mensch im Ablauf, Kennzeichnung gegenüber Nutzern.
8. Rahmenbedingungen: vorhandene Infrastruktur, Hosting-Vorgaben, Rechte am Quellcode, Beistellungen des Auftraggebers.
9. Abnahme: Abnahmekriterien je Muss-Anforderung, Testdaten, Abnahmeverfahren.
10. Betrieb und Weiterentwicklung: Wartung, Updates, Support, Übergabe und Dokumentation.

Als Faustregel aus unserer Sicht: Für ein mittelgroßes Projekt reichen oft 15 bis 30 Seiten. Maßstab ist nicht der Umfang, sondern ob jede Muss-Anforderung ein prüfbares Abnahmekriterium hat.

Vorlage für eine einzelne Anforderung

Innerhalb der Kapitel 3 bis 7 hilft ein einheitliches Format je Anforderung. Die ID macht jede Anforderung im Pflichtenheft, in Testfällen und bei der Abnahme referenzierbar.

Typische Fehler im Lastenheft

• Lösung statt Anforderung: Bildschirmmasken und Technologien vorgeben, bevor das Problem beschrieben ist.
• Schnittstellen als Einzeiler: „Anbindung an das ERP-System“ ist keine Anforderung, sondern der Anfang von Nachträgen.
• Kein Mengengerüst: Leistung und Betriebskosten bleiben Schätzungen.
• KI ohne Messlatte: Qualität, Test-Set und Kosten pro Antwort fehlen, die Abnahme wird zur Geschmacksfrage.
• Fachbereich fehlt: Die IT schreibt allein, und die Anforderungen der späteren Nutzer tauchen erst beim Test auf.

Fazit

Ein Lastenheft für Software beschreibt das Was aus Sicht des Auftraggebers, das Pflichtenheft das Wie aus Sicht des Auftragnehmers. Seinen Wert bekommt es durch abnahmefähige Anforderungen, ein Mengengerüst und sauber beschriebene Schnittstellen, nicht durch Umfang. Bei KI-Projekten kommen ein Test-Set, Qualitätskennzahlen, Datenzugang, Kosten pro Antwort und die Rolle des Menschen im Ablauf hinzu. Wo sich Anforderungen erst im Projekt klären, ist ein kurzes Rahmen-Lastenheft mit Backlog die bessere Form.

Wenn Sie Ihre Anforderungen gemeinsam mit uns schärfen möchten, finden Sie unser Vorgehen unter Softwareentwicklung in München; für KI-Funktionen mit Test-Set und Qualitätskennzahlen unter KI-Entwicklung. Für ein erstes Gespräch nutzen Sie gern unser Kontaktformular.