Lastenheft & Pflichtenheft für Software: Der vollständige Leitfaden für KMU

Wenn ein mittelständisches Unternehmen individuelle Software entwickeln lassen möchte – sei es ein digitales Buchungssystem, ein Kundenportal oder eine Branchenlösung –, steht früher oder später die Frage im Raum: Brauchen wir ein Lastenheft? Ein Pflichtenheft? Beides? Und wer schreibt das eigentlich?

Lastenheft und Pflichtenheft Software gehören zu den wichtigsten Dokumenten in jedem IT-Projekt. Sie definieren, was gebaut werden soll und wie es gebaut werden soll. Fehlen sie oder sind sie unvollständig, entstehen Missverständnisse, Kostenfallen und Projekte, die am Ende nicht das liefern, was sich alle vorgestellt haben.

Dieser Leitfaden erklärt klar und praxisnah, was Lastenheft und Pflichtenheft voneinander unterscheidet, wie KMU beide Dokumente aufbauen, welche Fehler typisch sind – und wann Sie eine externe Unterstützung bei der Erstellung brauchen.

Was ist ein Lastenheft? Definition und Zweck

Das Lastenheft (englisch: Requirements Specification oder Statement of Work) beschreibt aus der Sicht des Auftraggebers, was eine Software leisten soll. Es beantwortet die Frage: Was brauche ich?

Das Lastenheft ist ein Dokument, das Sie als Auftraggeber – also als Unternehmen – schreiben oder in Auftrag geben. Es enthält keine technischen Lösungsansätze, sondern beschreibt fachliche Anforderungen, Ziele und Rahmenbedingungen.

Typische Inhalte eines Lastenhefts

• Projektziel und Hintergrund: Warum wird die Software entwickelt? Welches Problem soll gelöst werden?
• Ist-Situation: Wie läuft der betroffene Prozess heute ab?
• Zielgruppe / Nutzer: Wer arbeitet mit der Software?
• Funktionale Anforderungen: Was soll die Software können? (z. B. „Kunden sollen Termine online buchen können")
• Nicht-funktionale Anforderungen: Geschwindigkeit, Verfügbarkeit, Sicherheit, Skalierbarkeit
• Schnittstellen: Zu welchen bestehenden Systemen muss die Software eine Verbindung haben?
• Rahmenbedingungen: Budget, Zeitplan, gesetzliche Vorgaben (z. B. DSGVO)
• Abnahmekriterien: Wann gilt das Projekt als erfolgreich abgeschlossen?

Wichtig: Das Lastenheft enthält kein Wie, sondern nur das Was. Technische Architekturentscheidungen gehören nicht hierher.

Was ist ein Pflichtenheft? Definition und Zweck

Das Pflichtenheft (englisch: Functional Specification oder Technical Specification) ist die Antwort des Auftragnehmers – also der Softwareagentur oder des Entwicklungspartners – auf das Lastenheft. Es beschreibt, wie die geforderten Anforderungen technisch umgesetzt werden.

Das Pflichtenheft ist ein verbindliches Dokument, das häufig Vertragsbestandteil ist. Aus ihm leiten sich Zeitplan, Ressourcen und Budgetrahmen ab.

Typische Inhalte eines Pflichtenhefts

• Systembeschreibung: Überblick über die geplante Architektur
• Technologiestack: Welche Technologien, Frameworks und Datenbanken werden eingesetzt?
• Detaillierte Funktionsbeschreibungen: Konkrete Umsetzung jeder fachlichen Anforderung
• Datenmodelle: Welche Daten werden gespeichert? In welcher Struktur?
• Schnittstellen-Spezifikationen: Wie werden externe Systeme angebunden? (z. B. REST API, Webhooks)
• Benutzerrollen und Berechtigungen: Wer darf was sehen und tun?
• Sicherheitskonzept: Authentifizierung, Verschlüsselung, Datenschutz
• Test- und Abnahmekonzept: Wie wird die Qualität geprüft?
• Projektplan und Meilensteine

Lastenheft vs. Pflichtenheft: Der Unterschied auf einen Blick

Warum sind beide Dokumente für KMU so wichtig?

Viele mittelständische Unternehmen unterschätzen den Wert dieser Dokumente. Gerade wenn erstmals individuelle Software beauftragt wird, neigen Auftraggeber dazu, die Anforderungen mündlich zu schildern oder in einer knappen E-Mail zusammenzufassen. Das führt erfahrungsgemäß zu drei typischen Problemen:

1. Scope Creep: Der Projektumfang wächst unkontrolliert, weil Anforderungen unklar definiert waren.
2. Missverständnisse: Auftraggeber und Auftragnehmer haben dasselbe Wort unterschiedlich verstanden.
3. Streit bei der Abnahme: Ohne schriftliche Abnahmekriterien gibt es keine objektive Grundlage, ob die Software die Anforderungen erfüllt.

Ein gut ausgearbeitetes Lastenheft reduziert diese Risiken erheblich. Es zwingt beide Seiten, vor Projektstart zu klären, was wirklich gebraucht wird – und was nicht.

Schritt für Schritt: So erstellen KMU ein Lastenheft

Schritt 1: Projektziel klar definieren

Formulieren Sie in zwei bis drei Sätzen, welches geschäftliche Problem die Software lösen soll. Vermeiden Sie dabei technische Begriffe.

Beispiel: „Wir möchten unseren Buchungsprozess für Kursangebote digitalisieren. Aktuell nehmen wir Buchungen per E-Mail und Telefon entgegen, was zu Doppelbuchungen und hohem Verwaltungsaufwand führt. Eine Software soll Buchungen automatisch verwalten und den Kunden eine Bestätigung schicken."

Schritt 2: Ist-Situation dokumentieren

Beschreiben Sie den aktuellen Prozess so konkret wie möglich. Welche Schritte gibt es? Welche Werkzeuge werden genutzt (Excel, E-Mail, Papier)? Wo entstehen Reibungsverluste?

Schritt 3: Nutzergruppen definieren

Wer arbeitet mit der Software? Unterscheiden Sie zwischen verschiedenen Rollen: Endkunden, Mitarbeiter, Administratoren, externe Partner.

Schritt 4: Anforderungen sammeln und priorisieren

Nutzen Sie Workshops mit den betroffenen Mitarbeitern. Sammeln Sie alle Anforderungen und priorisieren Sie sie nach dem MoSCoW-Prinzip:

• Must have: Ohne diese Funktion ist das Projekt wertlos
• Should have: Wichtig, aber kein Show-Stopper
• Could have: Wünschenswert, falls Zeit und Budget reichen
• Won't have (this time): Bewusst ausgeklammert für spätere Versionen

Schritt 5: Schnittstellen und Integrationsbedarf klären

Welche bestehenden Systeme soll die neue Software anbinden? ERP, CRM, Buchhaltungssoftware, Zahlungsanbieter? Notieren Sie für jede Integration, welche Daten ausgetauscht werden sollen.

Schritt 6: Rahmenbedingungen festhalten

• Geplantes Budget (zumindest eine Größenordnung)
• Gewünschter Go-Live-Termin
• Datenschutzanforderungen (DSGVO, Branchenspezifika)
• Hosting-Präferenzen (Cloud, On-Premise)
• Geräte und Betriebssysteme der Nutzer

Schritt 7: Abnahmekriterien definieren

Formulieren Sie messbare Kriterien, anhand derer Sie später feststellen können, ob die Software Ihre Anforderungen erfüllt. Das schützt beide Seiten.

Checkliste: Diese Inhalte sollte Ihr Lastenheft haben

• Projektziel und geschäftlicher Hintergrund
• Ist-Prozess und Problemanalyse
• Nutzergruppen und Benutzerrollen
• Funktionale Anforderungen (priorisiert nach MoSCoW)
• Nicht-funktionale Anforderungen (Performance, Verfügbarkeit, Sicherheit)
• Schnittstellen zu anderen Systemen
• Datenmengen und Skalierungsanforderungen
• Regulatorische Anforderungen (DSGVO, branchenspezifische Gesetze)
• Budget- und Zeitrahmen
• Abnahmekriterien
• Glossar (Fachbegriffe aus Ihrem Unternehmen erläutern)

Praxisbeispiel: Lastenheft und Pflichtenheft bei einem realen Buchungssystem-Projekt

Wie der Prozess in der Praxis funktioniert, zeigt das Projekt MobiKart: Ein Betreiber einer Kartbahn wollte sein bestehendes System zur Buchungsverwaltung komplett erneuern – von der Online-Buchung für Kunden über die Slot-Verwaltung bis hin zur Kassenfunktion vor Ort.

Im ersten Schritt wurde gemeinsam ein Lastenheft erarbeitet. Zentrale Anforderungen des Auftraggebers waren:

• Kunden sollen Slots online buchen und sofort bezahlen können
• Das Personal soll Buchungen in einer Übersicht verwalten und Änderungen vornehmen können
• Die Kasse vor Ort soll Buchungen abrufen und Zusatzprodukte abrechnen
• Das System soll skalierbar sein für weitere Standorte

Darauf aufbauend entstand das Pflichtenheft: SW Business Solutions entschied sich für Next.js als Frontend-Framework, NestJS für die Backend-API und MongoDB als Datenbank. Für Zahlungen wurde eine Integration mit einem Zahlungsanbieter spezifiziert, die Slot-Buchungslogik als eigenes Modul konzipiert.

Das Ergebnis ist heute das Produkt MobiKart – Kartbahn-Buchungssystem, das genau auf diese Anforderungen zugeschnitten ist. Der strukturierte Prozess aus Lastenheft → Pflichtenheft → Umsetzung war der Schlüssel, dass am Ende alle Beteiligten mit dem Ergebnis zufrieden waren.

Häufige Fehler beim Erstellen von Lastenheft und Pflichtenheft

Fehler 1: Lösungen statt Anforderungen beschreiben

Viele Auftraggeber schreiben ins Lastenheft bereits technische Lösungen: „Wir brauchen eine MySQL-Datenbank." Das schränkt den Auftragnehmer unnötig ein und verhindert bessere technische Entscheidungen. Beschreiben Sie stattdessen das Problem.

Fehler 2: Anforderungen nicht priorisieren

Ohne Priorisierung behandeln Entwickler alle Anforderungen als gleich wichtig. Das führt dazu, dass unwichtige Features viel Zeit fressen, während kritische Kernfunktionen halbherzig umgesetzt werden.

Fehler 3: Stakeholder nicht einbeziehen

Das Lastenheft wird oft nur von der Geschäftsführung erstellt – ohne die Mitarbeiter, die später täglich damit arbeiten. Die kennen aber die Prozesse am besten und wissen, was wirklich gebraucht wird.

Fehler 4: Abnahmekriterien vergessen

Ohne klare Abnahmekriterien endet das Projekt im besten Fall in Endlosschleifen, im schlechtesten Fall vor Gericht. Definieren Sie vorab: Was muss die Software können, damit Sie die Abnahme unterschreiben?

Fehler 5: Das Pflichtenheft zu früh einfordern

Manche Auftraggeber verlangen das Pflichtenheft schon vor dem Vertragsschluss als Teil des Angebots. Das ist verständlich, aber nicht immer realistisch: Ein gutes Pflichtenheft erfordert Zeit und Aufwand – und dieser Aufwand muss vergütet werden.

Wann brauchen KMU professionelle Unterstützung?

Nicht jedes mittelständische Unternehmen hat intern die Kapazität oder das Know-how, ein vollständiges Lastenheft zu erstellen. Das ist kein Versagen – sondern Realität. Professionelle Unterstützung lohnt sich vor allem dann, wenn:

• Sie erstmals individuelle Software beauftragen
• Das Projekt komplex ist (viele Schnittstellen, mehrere Benutzergruppen, hohe Sicherheitsanforderungen)
• Interne Ressourcen fehlen, um Anforderungsworkshops durchzuführen
• Sie sicherstellen möchten, dass das Lastenheft vertraglich wasserdicht ist

SW Business Solutions bietet im Rahmen der Beratung & Planung eine strukturierte Anforderungsanalyse an, die sowohl Lastenheft als auch die Basis für das Pflichtenheft umfasst. Mehr dazu, wann sich der Schritt zur individuellen Softwareentwicklung wirklich lohnt, lesen Sie in unserem separaten Ratgeber.

Lastenheft und Pflichtenheft im agilen Umfeld

In klassischen Wasserfallprojekten sind Lastenheft und Pflichtenheft unverzichtbar – und müssen vollständig sein, bevor die Entwicklung beginnt. In agilen Projekten (Scrum, Kanban) ist die Herangehensweise flexibler:

Statt eines monolithischen Lastenhefts arbeiten agile Teams mit User Stories: kurzen Anforderungsbeschreibungen aus Nutzerperspektive. Das Product Backlog ersetzt dabei das klassische Lastenheft. Das Pflichtenheft wird durch technische Spezifikationen und Architekturentscheidungen ersetzt, die inkrementell entstehen.

Das bedeutet aber nicht, dass auf Dokumentation verzichtet wird. Im Gegenteil: Ein agiles Projekt ohne Struktur ist kein agiles Projekt – es ist ein unkontrolliertes Chaos. Auch hier braucht es zu Projektbeginn eine klare Vision, definierte Ziele und erste Priorisierungen.

Tipp: Viele IT-Projekte für KMU profitieren von einem hybriden Ansatz: Ein kompaktes Lastenheft als Projektrahmen, kombiniert mit agiler Umsetzung in Sprints.

Norm und Standards: Was sollten KMU wissen?

In Deutschland orientiert sich die Erstellung von Lastenheften und Pflichtenheften häufig an der VDI/VDE-Richtlinie 3694 (Anforderungen an Automatisierungssysteme). Diese ist ursprünglich aus dem Maschinenbau stammend, wird aber als allgemeine Orientierung auch für IT-Projekte genutzt.

Für reine Softwareprojekte relevanter ist das IEEE 830-Format (Recommended Practice for Software Requirements Specifications), das international verbreitet ist und klare Strukturvorgaben macht.

Als KMU müssen Sie diese Normen nicht kennen oder strikt einhalten. Sie helfen aber als Orientierung, wenn Sie ein vollständiges und professionelles Dokument erstellen möchten.

Lastenheft und Pflichtenheft: Vertragsrechtliche Bedeutung

Beide Dokumente sind nicht nur Planungsinstrumente, sondern haben erhebliche vertragsrechtliche Bedeutung:

Das Lastenheft definiert, was der Auftragnehmer schuldet. Das Pflichtenheft, sofern es Vertragsbestandteil ist, legt fest, wie diese Schuld erfüllt wird. Weicht die fertige Software vom Pflichtenheft ab, liegt ein Mangel vor, der zur Nachbesserung oder Minderung berechtigt.

Umgekehrt gilt: Fordert ein Auftraggeber nach Projektstart Funktionen ein, die weder im Lastenheft noch im Pflichtenheft stehen, handelt es sich um eine Änderungsanforderung (Change Request) – und die kostet extra.

Diese Klarheit schützt beide Seiten: das KMU vor Mehrkosten und den Dienstleister vor unbezahlter Mehrarbeit.

Welche Tools helfen bei der Erstellung?

Für die Erstellung von Lastenheft und Pflichtenheft brauchen Sie keine spezielle Software. Folgende Werkzeuge haben sich in der Praxis bewährt:

Zusammenfassung: Das Wichtigste auf einen Blick

• Lastenheft: Auftraggeber beschreibt das Was – fachliche Anforderungen, Ziele, Rahmenbedingungen
• Pflichtenheft: Auftragnehmer beschreibt das Wie – technische Umsetzung, Architektur, Schnittstellen
• Beide Dokumente sind Planungs- und Rechtsdokumente
• KMU sollten das Lastenheft vor der Angebotseinholung erstellen
• Priorisierung nach MoSCoW und klare Abnahmekriterien sind essenziell
• In agilen Projekten ersetzen User Stories und Backlogs die klassischen Dokumente – aber nicht die Struktur
• Bei komplexen Projekten lohnt sich professionelle Unterstützung bei der Anforderungsanalyse

Wer individuelle Software entwickeln lässt, investiert Geld und Vertrauen. Ein sauber erstelltes Lastenheft und ein präzises Pflichtenheft sind die Versicherung, dass diese Investition das erwartete Ergebnis liefert.

Haben Sie ein Softwareprojekt geplant und möchten strukturiert in die Anforderungsphase einsteigen? Wir helfen Ihnen dabei – von der ersten Idee bis zur abnahmereifen Software.