Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was ein Projekt leisten soll: Ziele, Ausgangslage, Anforderungen und Rahmenbedingungen. Es legt das Was und Wofür fest, nicht das Wie. Anbieter erstellen auf dieser Grundlage ihr Angebot und später das Pflichtenheft. Ein gutes Lastenheft ist vollständig, lösungsneutral und so formuliert, dass sich jede Anforderung bei der Abnahme prüfen lässt.
Das Wichtigste in Kürze
- Das Lastenheft schreibt der Auftraggeber. Es ist die Grundlage für Ausschreibung, Angebotsvergleich und Abnahme.
- Es beschreibt Anforderungen, keine technischen Lösungen. Die Lösung gehört ins Pflichtenheft des Auftragnehmers.
- Ein typischer Aufbau: Ausgangslage, Ziele, Nutzer, funktionale und nicht-funktionale Anforderungen, Rahmenbedingungen, Abnahmekriterien.
- Auch in agilen Projekten lohnt sich ein schlankes Lastenheft: Es gibt Richtung und Budgetrahmen vor, die Details wandern ins Product Backlog.
Was ist ein Lastenheft?
Ein Lastenheft ist das Dokument, in dem ein Auftraggeber alle Anforderungen an ein Projektergebnis zusammenfasst. Die DIN 69901-5 definiert es als die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags“.
Im Alltag begegnen Ihnen dafür auch andere Namen: Anforderungsspezifikation, Anforderungskatalog, Kundenspezifikation oder im Englischen Requirements Specification. Im V-Modell XT, dem Vorgehensmodell für IT-Projekte der öffentlichen Hand in Deutschland, heißt das entsprechende Dokument „Anforderungen (Lastenheft)“. Den Standard und die Variante V-Modell XT Bund veröffentlicht der WEIT e.V..
Das Lastenheft erfüllt drei Aufgaben:
- Intern Klarheit schaffen. Fachabteilung, IT und Geschäftsführung einigen sich schriftlich darauf, was das Projekt erreichen soll.
- Angebote vergleichbar machen. Alle Anbieter kalkulieren auf derselben Grundlage. So vergleichen Sie Preise für dieselbe Leistung und nicht für unterschiedliche Annahmen.
- Die Abnahme vorbereiten. Was im Lastenheft steht und im Pflichtenheft bestätigt wurde, können Sie am Ende einfordern und prüfen.
Was gehört in ein Lastenheft?
In ein Lastenheft gehört alles, was ein Anbieter wissen muss, um ein belastbares Angebot abzugeben, und nichts, was ihm die Lösung vorschreibt. Bewährt hat sich der folgende Aufbau.
| Abschnitt | Inhalt | Leitfrage |
|---|---|---|
| Ausgangslage | Unternehmen, heutiger Prozess, vorhandene Systeme, Anlass des Projekts | Warum machen wir das Projekt? |
| Ziele | Geschäftsziele und messbare Erfolgskriterien | Woran erkennen wir, dass sich das Projekt gelohnt hat? |
| Nutzer und Stakeholder | Nutzergruppen, Rollen, Ansprechpartner, Entscheider | Wer arbeitet mit dem Ergebnis, wer entscheidet? |
| Funktionale Anforderungen | Was das System können muss, gegliedert nach Abläufen oder Modulen | Was soll das System tun? |
| Nicht-funktionale Anforderungen | Leistung, Sicherheit, Datenschutz, Verfügbarkeit, Bedienbarkeit, Barrierefreiheit | Wie gut soll es das tun? |
| Schnittstellen und Daten | Systeme, mit denen Daten ausgetauscht werden; Datenübernahme aus Altsystemen | Womit muss das System zusammenarbeiten? |
| Rahmenbedingungen | Budgetrahmen, Termine, rechtliche und technische Vorgaben, Betrieb | Welche Grenzen sind gesetzt? |
| Lieferumfang | Software, Dokumentation, Schulung, Wartung und Support | Was wird am Ende übergeben? |
| Abnahmekriterien | Wie und durch wen die Ergebnisse geprüft werden | Wann gilt die Leistung als erbracht? |
Zwei Regeln machen aus einer Wunschliste ein brauchbares Lastenheft.
Anforderungen priorisieren. Kennzeichnen Sie jede Anforderung als Muss, Soll oder Kann. Anbieter erkennen so, wo sie sparen können, und Sie behalten Spielraum, wenn das Budget nicht für alles reicht.
Prüfbar formulieren. „Das System soll schnell sein“ lässt sich nicht abnehmen. „Die Suche liefert bei 10.000 Datensätzen in höchstens zwei Sekunden ein Ergebnis“ schon. Jede Anforderung bekommt außerdem eine eindeutige Nummer, auf die sich Angebot, Pflichtenheft und Abnahmeprotokoll beziehen können.
Lastenheft Vorlage: Gliederung zum Kopieren
Die folgende Vorlage können Sie in Ihr Textprogramm übernehmen und die Platzhalter in eckigen Klammern ersetzen. Sie ist für Softwareprojekte gedacht, lässt sich aber leicht auf andere Vorhaben übertragen.
1. Dokumentinformationen
- Projektname: [Projektname]
- Auftraggeber: [Unternehmen, Abteilung]
- Verantwortlich: [Name, Rolle, Kontakt]
- Version und Datum: [Version], [Datum]
- Status: [Entwurf / abgestimmt / freigegeben]
2. Ausgangslage und Anlass
- Kurzbeschreibung des Unternehmens: [Branche, Größe, Standorte]
- Heutiger Ablauf und eingesetzte Systeme: [Ist-Zustand]
- Probleme und Auslöser des Projekts: [was heute nicht funktioniert]
3. Ziele
- Geschäftsziel: [zum Beispiel weniger manuelle Arbeit im Vertrieb]
- Messbare Erfolgskriterien: [Kennzahl, Zielwert, Zeitpunkt]
- Was ausdrücklich nicht zum Projekt gehört: [Abgrenzung]
4. Nutzer und Stakeholder
- Nutzergruppen und ihre Aufgaben: [Rolle, Anzahl, wichtigste Tätigkeiten]
- Fachliche Ansprechpartner: [Name, Bereich]
- Entscheider und Freigaben: [Name, Rolle]
5. Funktionale Anforderungen
| Nr. | Anforderung | Priorität | Abnahmekriterium |
|---|---|---|---|
| F-01 | [Das System ermöglicht …] | [Muss / Soll / Kann] | [Wie wird geprüft?] |
| F-02 | [Der Nutzer kann …] | [Muss / Soll / Kann] | [Wie wird geprüft?] |
| F-03 | [Das System benachrichtigt …] | [Muss / Soll / Kann] | [Wie wird geprüft?] |
6. Nicht-funktionale Anforderungen
- Leistung: [Antwortzeiten, Anzahl gleichzeitiger Nutzer]
- Verfügbarkeit: [Betriebszeiten, zulässige Ausfallzeit]
- Sicherheit und Datenschutz: [Rollen und Rechte, DSGVO, Ort der Datenhaltung]
- Bedienbarkeit: [Sprachen, Geräte, Barrierefreiheit]
7. Schnittstellen und Daten
- Anzubindende Systeme: [System, Richtung des Datenaustauschs, Häufigkeit]
- Datenübernahme: [Quelle, Umfang, Qualität der Altdaten]
8. Rahmenbedingungen
- Budgetrahmen: [Betrag oder Spanne]
- Termine: [gewünschter Start, Meilensteine, Go-live]
- Vorgaben: [rechtliche Anforderungen, vorhandene Infrastruktur, Betrieb]
9. Lieferumfang und Abnahme
- Lieferumfang: [Software, Quellcode, Dokumentation, Schulung, Support]
- Abnahmeverfahren: [Testphase, Beteiligte, Fristen]
10. Hinweise für Anbieter
- Gewünschte Angaben im Angebot: [Vorgehen, Team, Referenzen, Preisstruktur]
- Abgabefrist und Kontakt für Rückfragen: [Datum, Ansprechpartner]
Lastenheft Beispiel: Buchungs-App für ein Fitnessstudio
Das folgende Beispiel ist frei erfunden und stark gekürzt. Es zeigt, wie konkret die Einträge sein sollten, und ist kein Bericht aus einem Kundenprojekt.
Ausgangslage. Ein Fitnessstudio mit drei Standorten nimmt Kursanmeldungen per Telefon und über Listen am Empfang entgegen. Kurse sind häufig überbucht oder bleiben trotz Warteliste halb leer, weil Absagen nicht rechtzeitig ankommen.
Ziele. Mitglieder buchen und stornieren Kurse selbst. Der Empfang wird von Telefonaten entlastet, freie Plätze werden automatisch nachbesetzt.
Nutzer. Mitglieder (Smartphone), Trainer (Teilnehmerlisten), Studioleitung (Kursplan und Auswertungen).
| Nr. | Anforderung | Priorität | Abnahmekriterium |
|---|---|---|---|
| F-01 | Mitglieder sehen den Kursplan aller Standorte mit freien Plätzen. | Muss | Der Kursplan zeigt für jeden Kurs Ort, Zeit, Trainer und freie Plätze. |
| F-02 | Mitglieder buchen und stornieren Kurse bis zwei Stunden vor Beginn. | Muss | Buchung und Storno sind in der App möglich; danach ist die Schaltfläche gesperrt. |
| F-03 | Wird ein Platz frei, rückt das erste Mitglied der Warteliste nach und erhält eine Push-Nachricht. | Muss | Nach einem Storno ist der Platz neu vergeben und die Nachricht zugestellt. |
| F-04 | Trainer rufen die Teilnehmerliste ihres Kurses ab und haken Anwesenheit ab. | Soll | Die Liste entspricht den Buchungen; die Anwesenheit wird gespeichert. |
| F-05 | Die Studioleitung sieht die Auslastung je Kurs und Standort. | Kann | Die Auswertung lässt sich nach Zeitraum und Standort filtern. |
Nicht-funktionale Anforderungen. Die App läuft auf iOS und Android. Personenbezogene Daten werden DSGVO-konform in der EU gespeichert. Der Kursplan lädt bei normaler Mobilfunkverbindung in höchstens drei Sekunden.
Schnittstellen. Mitgliederdaten kommen aus der bestehenden Mitgliederverwaltung. Die Anmeldung erfolgt mit der Mitgliedsnummer.
Rahmenbedingungen. Einführung vor Beginn der Herbstsaison, zunächst an einem Standort als Pilot.
Auffällig ist, was im Beispiel fehlt: Es nennt keine Programmiersprache, kein Framework und keine Datenbank. Wie die App gebaut wird, schlägt der Anbieter vor, etwa eine Agentur für App-Entwicklung.
Lastenheft und Pflichtenheft: der Unterschied
Das Lastenheft beschreibt die Anforderungen des Auftraggebers, das Pflichtenheft die Lösung des Auftragnehmers. Die DIN 69901-5 nennt das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.
| Merkmal | Lastenheft | Pflichtenheft |
|---|---|---|
| Verfasser | Auftraggeber | Auftragnehmer |
| Leitfrage | Was soll erreicht werden und wofür? | Wie und womit wird es umgesetzt? |
| Zeitpunkt | Vor der Ausschreibung oder Anfrage | Nach der Auswahl des Anbieters, vor der Umsetzung |
| Inhalt | Ziele, Anforderungen, Rahmenbedingungen | Lösungskonzept, Architektur, Funktionen im Detail, Aufwand |
| Detailgrad | Fachlich, lösungsneutral | Technisch, umsetzungsnah |
| Rolle im Vertrag | Grundlage für Angebote | Nach Freigabe verbindliche Grundlage für Umsetzung und Abnahme |
In der Praxis gehören beide Dokumente zusammen: Jeder Anforderung im Lastenheft stehen im Pflichtenheft eine oder mehrere Leistungen gegenüber. Wie ein Pflichtenheft aufgebaut ist und worauf Sie bei der Freigabe achten sollten, lesen Sie im Artikel Pflichtenheft: Vorlage & Unterschied zum Lastenheft.
Ist ein Lastenheft noch zeitgemäß?
Ja, allerdings nicht in Form eines Dokuments mit Hunderten Seiten, das vor dem Projektstart jede Einzelheit festschreibt. In agilen Projekten ändern sich Anforderungen unterwegs, und genau dafür ist das Product Backlog gedacht: Der Scrum Guide beschreibt es als geordnete Liste dessen, was zur Verbesserung des Produkts gebraucht wird, und als einzige Quelle der Arbeit, die das Scrum Team erledigt.
Ein Backlog ersetzt das Lastenheft trotzdem nicht ganz. Bevor Sie einen Dienstleister beauftragen, brauchen Sie Antworten, die kein einzelnes Ticket liefert: Welches Ziel verfolgt das Produkt? Wer nutzt es? Welches Budget und welcher Termin sind gesetzt? Welche Vorgaben zu Datenschutz, Betrieb und Schnittstellen gelten unabhängig vom Sprint?
Bewährt hat sich deshalb eine Arbeitsteilung:
- Schlankes Lastenheft für das, was stabil bleibt: Ausgangslage, Ziele, Nutzergruppen, Rahmenbedingungen, nicht-funktionale Anforderungen und die wichtigsten Abläufe.
- Product Backlog mit User Storys für die Details. Eine User Story folgt dem Muster „Als [Rolle] möchte ich [Funktion], damit [Nutzen]“ und erhält Akzeptanzkriterien. Sie wird erst kurz vor der Umsetzung ausgearbeitet.
Welche Form passt, hängt auch vom Vertragsmodell ab. Für einen Festpreis muss der Umfang vorab genau beschrieben sein. Arbeiten Sie nach Aufwand oder mit einem Dedicated Team, genügt ein kürzeres Lastenheft, weil der Umfang im Projektverlauf gemeinsam gesteuert wird.
Typische Fehler im Lastenheft
Die meisten Probleme entstehen nicht durch fehlende Seiten, sondern durch unklare oder falsch platzierte Inhalte.
- Lösungen statt Anforderungen. Wer im Lastenheft die Technik vorgibt, verschenkt das Wissen der Anbieter. Ausnahme: echte Vorgaben, etwa ein vorhandenes System, das angebunden werden muss.
- Unprüfbare Formulierungen. „Benutzerfreundlich“, „modern“ und „performant“ versteht jeder anders. Nennen Sie Zahlen, Beispiele oder Vergleichssysteme.
- Keine Prioritäten. Wenn alles ein Muss ist, kalkulieren Anbieter alles ein, und Sie können im Angebot nichts streichen.
- Die Nutzer nicht gefragt. Ein Lastenheft, das nur die Sicht der Projektleitung abbildet, übersieht oft die Abläufe, die im Alltag am meisten Zeit kosten.
- Nicht-funktionale Anforderungen vergessen. Datenschutz, Verfügbarkeit und Antwortzeiten bestimmen Architektur und Kosten stärker als manche Funktion.
- Fehlende Abgrenzung. Schreiben Sie auf, was nicht zum Projekt gehört. Das verhindert spätere Diskussionen über den Umfang.
- Keine Pflege. Änderungen nach der Freigabe gehören mit Datum und Version ins Dokument, sonst gelten bei der Abnahme unterschiedliche Stände.
So unterstützt Join.To.IT
Join.To.IT entwickelt seit 2012 Software, das Team sitzt in Kyjiw und arbeitet nahezu zeitgleich mit Deutschland, Österreich und der Schweiz. Wenn Sie ein Lastenheft haben, erstellen wir daraus ein Lösungskonzept mit Aufwandsschätzung. Wenn Ziele und Anforderungen noch offen sind, klären wir sie gemeinsam mit Ihnen in einer kurzen Discovery-Phase, bevor die Entwicklung beginnt. Mehr über die Zusammenarbeit erfahren Sie auf unserer Seite zum Outsourcing der Softwareentwicklung. Oder Sie schicken uns Ihr Lastenheft und wir melden uns mit Rückfragen und einer ersten Einschätzung.
FAQ
Wer schreibt das Lastenheft?
Das Lastenheft schreibt der Auftraggeber, in der Regel die Projektleitung zusammen mit den Fachabteilungen und der IT. Fehlt intern die Zeit oder die Erfahrung, kann ein Berater oder der spätere Dienstleister bei der Ausarbeitung helfen. Verantwortung und Freigabe bleiben aber beim Auftraggeber.
Wie lang sollte ein Lastenheft sein?
So lang wie nötig, damit ein Anbieter ohne Rückfragen zu den Grundlagen kalkulieren kann. Für eine überschaubare App oder ein internes Tool reichen oft wenige Seiten. Bei komplexen Systemen mit vielen Schnittstellen wird das Dokument entsprechend umfangreicher. Wichtiger als der Umfang sind eindeutige, priorisierte und prüfbare Anforderungen.
Ist ein Lastenheft rechtlich verbindlich?
Für sich allein ist das Lastenheft eine Beschreibung Ihrer Anforderungen. Verbindlich wird es, wenn der Vertrag darauf verweist oder es als Anlage aufnimmt. Meist wird dann das freigegebene Pflichtenheft zur maßgeblichen Leistungsbeschreibung. Lassen Sie die vertragliche Einbindung im Zweifel juristisch prüfen.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft stammt vom Auftraggeber und beschreibt, was erreicht werden soll. Das Pflichtenheft stammt vom Auftragnehmer und beschreibt, wie er diese Anforderungen umsetzt. Details und eine Gliederung finden Sie im Artikel zum Pflichtenheft.
Braucht man in agilen Projekten ein Lastenheft?
Ein klassisches, vollständiges Lastenheft brauchen Sie in agilen Projekten nicht. Sinnvoll ist eine kurze Fassung mit Zielen, Nutzergruppen, Rahmenbedingungen und nicht-funktionalen Anforderungen. Die einzelnen Funktionen werden als User Storys im Product Backlog gepflegt und laufend priorisiert.
Was kostet es, ein Lastenheft erstellen zu lassen?
Das hängt vom Umfang des Vorhabens und davon ab, wie viel bereits geklärt ist. Der größte Aufwand entsteht meist intern: Abläufe aufnehmen, Fachabteilungen befragen und Prioritäten abstimmen. Externe Unterstützung wird in der Regel nach Aufwand oder als fest umrissene Konzeptphase angeboten.
