Lastenheft und Pflichtenheft richtig einsetzen

Das Projektteam erwartet eine neue Anwendung, der Fachbereich hat seine Wünsche in Präsentationen gesammelt und der Anbieter legt ein Angebot vor. Spätestens jetzt entsteht häufig ein gefährlicher Satz: „Das war doch selbstverständlich mitgemeint.“ Genau an dieser Stelle helfen Lastenheft und Pflichtenheft. Sie machen aus Erwartungen überprüfbare Vereinbarungen und schaffen eine belastbare Grundlage für Vertrag, Projektsteuerung und Abnahme.

Lastenheft und Pflichtenheft erfüllen unterschiedliche Aufgaben

Die Begriffe werden im Alltag oft ungenau verwendet. Für die Vertragsarbeit ist ihre Funktion wichtiger als ihre Bezeichnung. Entscheidend ist, dass klar dokumentiert wird, wer welche Anforderung formuliert, wer die Umsetzung konkretisiert und welches Dokument am Ende verbindlich gilt.

Das Lastenheft beschreibt grundsätzlich die Sicht des Auftraggebers. Es beantwortet vor allem diese Fragen:

• Welches fachliche Problem soll gelöst werden?
• Welche Ziele verfolgt das Unternehmen?
• Welche Prozesse, Nutzergruppen und Systeme sind betroffen?
• Welche Anforderungen sind zwingend und welche lediglich wünschenswert?
• Welche rechtlichen, organisatorischen und technischen Rahmenbedingungen gelten?

Das Pflichtenheft beschreibt demgegenüber die Lösungssicht des Auftragnehmers. Es zeigt, wie der Anbieter die Anforderungen erfüllen will. Dazu gehören typischerweise:

• die konkrete Systemarchitektur und Konfiguration,
• Schnittstellen und Datenflüsse,
• Rollen und Berechtigungen,
• technische Voraussetzungen,
• Projektvorgehen und Liefergegenstände,
• Testfälle sowie Abnahmekriterien.

In der Praxis erstellt nicht jedes Projekt beide Dokumente in Reinform. Bei Standardsoftware, SaaS Leistungen oder kleineren Anpassungen kann eine strukturierte Leistungsbeschreibung mit Fachkonzept, Konfigurationsdokumentation und Testkatalog ausreichen. Trotzdem musst du die beiden Blickwinkel sauber abdecken: Was wird benötigt und wie wird die geschuldete Leistung konkret erbracht?

Wer liefert welches Dokument?

Als Auftraggeber solltest du die Verantwortung für die fachlichen Anforderungen nicht vollständig an den Anbieter delegieren. Du kennst deine Prozesse, Ziele, Daten und internen Rahmenbedingungen. Ein Anbieter kann diese Informationen strukturieren und durch Fragen präzisieren, aber er kann deine Geschäftsentscheidung nicht ersetzen.

Ein praxistaugliches Vorgehen sieht häufig so aus:

Dokument oder Inhalt	Typische Verantwortung des Auftraggebers	Typische Verantwortung des Auftragnehmers
Fachliche Ziele und Prozesse	beschreibt Ziele, Prioritäten und Nutzungsszenarien	hinterfragt Unklarheiten und weist auf Umsetzungsrisiken hin
Muss Anforderungen	legt fest, was zwingend erfüllt sein muss	bestätigt, ob und wie die Anforderungen erfüllt werden
Lösungskonzept	prüft die Eignung für den eigenen Betrieb	erstellt die technische und organisatorische Konkretisierung
Schnittstellen und Daten	stellt Informationen zu Quellsystemen, Datenqualität und Zugängen bereit	beschreibt Anbindung, Mapping, Fehlerbehandlung und Tests
Abnahmekriterien	definiert fachlich relevante Erfolgskriterien	entwickelt prüfbare Testfälle und Nachweise

Wichtig ist die Mitwirkungspflicht des Auftraggebers. Wenn der Anbieter auf Daten, Entscheidungen, Testpersonen oder Zugänge angewiesen ist, müssen diese Beiträge konkret beschrieben sein. Formulierungen wie „Der Kunde wirkt angemessen mit“ helfen im Konfliktfall kaum. Besser ist es, Verantwortliche, benötigte Unterlagen, Bereitstellungstermine und Folgen verspäteter Mitwirkung festzuhalten.

Der Auftragnehmer sollte wiederum erkennbare Widersprüche und Lücken ansprechen. Das gilt besonders, wenn Anforderungen technisch nicht umsetzbar, wirtschaftlich unverhältnismäßig oder mit anderen Vorgaben unvereinbar sind. Diese Klärung gehört in die Angebots und Vertragsphase, nicht in die Abnahme.

Anforderungen so formulieren, dass sie prüfbar sind

Die häufigste Schwäche eines Lastenhefts sind unklare Begriffe. Aussagen wie „intuitive Bedienung“, „hohe Performance“, „vollständige Integration“ oder „rechtskonforme Verarbeitung“ können sinnvoll sein, reichen als Vertragsanforderung aber nicht aus. Sie lassen offen, was konkret geschuldet ist und wie die Erfüllung nachgewiesen wird.

Eine gute Anforderung enthält mindestens fünf Elemente:

1. Ausgangssituation: Für welchen Prozess oder welche Nutzergruppe gilt die Anforderung?
2. Leistung: Was muss das System oder der Dienst konkret tun?
3. Bedingung: Unter welchen Voraussetzungen oder in welchem Umfang muss dies funktionieren?
4. Messgröße: Woran wird die Erfüllung objektiv gemessen?
5. Nachweis: Wie wird die Anforderung getestet oder dokumentiert?

Statt „Das System muss schnell sein“ könntest du etwa festhalten: „Bei einer Suche nach Kundendaten mit den definierten Suchfeldern wird die Ergebnisliste unter den vereinbarten Testbedingungen innerhalb der festgelegten Antwortzeit angezeigt.“ Ergänze dann Testdaten, Testumgebung und zulässige Ausnahmen.

Statt „Die Anwendung muss an das ERP System angebunden werden“ sollte beschrieben werden, welche Daten ausgetauscht werden, welches System führend ist, wann die Übertragung erfolgt, wie Fehler erkannt werden und wer sie bearbeitet. Auch Berechtigungen, Protokollierung und die Behandlung fehlerhafter Datensätze gehören häufig dazu.

Für jede Anforderung empfiehlt sich eine eindeutige Kennung. So kannst du Anforderungen im Pflichtenheft, in Testfällen, im Abnahmeprotokoll und in Änderungsanträgen zweifelsfrei zuordnen. Eine einfache Nummerierung verhindert später viel Sucharbeit.

Prioritäten und Leistungsgrenzen sichtbar machen

Nicht jede Anforderung hat dieselbe Bedeutung. Ohne Priorisierung entsteht schnell der Eindruck, alles sei gleich zwingend. Das gefährdet Budget, Terminplanung und Abnahme.

Bewährt hat sich eine Einteilung in:

• Muss Anforderungen: Ohne diese Anforderungen ist der vereinbarte Zweck nicht erreicht.
• Soll Anforderungen: Diese Anforderungen sind wichtig, dürfen aber nur nach klarer Vereinbarung verschoben oder durch eine gleichwertige Lösung ersetzt werden.
• Kann Anforderungen: Diese Punkte sind optional und werden nur umgesetzt, wenn sie ausdrücklich beauftragt sind.
• Nicht geschuldete Leistungen: Hier hältst du bewusst fest, was nicht zum Leistungsumfang gehört.

Gerade der letzte Punkt wird oft übersehen. Bei Einführungsprojekten sind beispielsweise Datenbereinigung, Erstellung fachlicher Inhalte, Schulung aller Nutzer, Migration historischer Altdaten oder Anpassungen an Drittsystemen häufig konfliktträchtig. Wenn solche Aufgaben nicht geschuldet sind, sollte das deutlich dokumentiert sein. Wenn sie geschuldet sind, brauchen sie einen klaren Umfang und ein eigenes Abnahmekriterium.

Das Pflichtenheft vertraglich verbindlich einbinden

Ein gutes Dokument verhindert nur dann Streit, wenn seine Rolle im Vertrag eindeutig geregelt ist. Lege daher fest, ob das Lastenheft, das Pflichtenheft oder beide Dokumente verbindliche Vertragsbestandteile werden. Ein Dokument, das nur als Projektunterlage herumgereicht wird, schafft keine sichere Leistungsgrundlage.

Im Vertrag solltest du insbesondere regeln:

• die genaue Bezeichnung, Version und das Datum jedes Dokuments,
• die Rangfolge bei Widersprüchen zwischen Vertrag, Angebot, Lastenheft und Pflichtenheft,
• das Verfahren zur Freigabe des Pflichtenhefts,
• die Folgen, wenn der Anbieter von einer Anforderung abweichen will,
• die Zuordnung von Anforderungen zu Meilensteinen und Abnahme,
• den Umgang mit Änderungen nach Vertragsabschluss.

Die Rangfolge ist besonders wichtig. Sonst kann eine allgemeine Vertragsklausel eine detaillierte Anforderung ungewollt verdrängen oder umgekehrt. Häufig bietet sich an, dass individuell ausgehandelte Vertragsregelungen Vorrang haben. Danach folgen die konkret vereinbarten Leistungsdokumente. Allgemeine Geschäftsbedingungen sollten nicht stillschweigend fachliche Spezifikationen überlagern.

Achte auch darauf, dass ein Pflichtenheft nicht durch bloße Übersendung verbindlich wird. Vereinbare einen Freigabeprozess mit benannten Ansprechpartnern. Die Freigabe sollte ausdrücklich dokumentiert werden. Vorher muss der Auftraggeber ausreichend Zeit haben, offene Punkte zu prüfen, insbesondere Schnittstellen, Datenschutz, Berechtigungen, Betriebsanforderungen und Testkonzept.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Änderungen brauchen ein kontrolliertes Verfahren

Während der Umsetzung entstehen fast immer neue Erkenntnisse. Das ist normal. Problematisch wird es, wenn Anforderungen informell in Besprechungen, Tickets oder E Mails verändert werden. Dann ist später kaum noch feststellbar, ob es sich um eine geschuldete Leistung, eine Klarstellung oder eine zusätzliche Beauftragung handelt.

Vereinbare deshalb ein Änderungsverfahren. Jeder Änderungsantrag sollte mindestens enthalten:

• Beschreibung der gewünschten Änderung,
• betroffene Anforderungen und Dokumentversionen,
• Auswirkungen auf Preis, Termine, Ressourcen und Betrieb,
• Auswirkungen auf Tests und Abnahme,
• Entscheidung der berechtigten Ansprechpartner,
• Zeitpunkt der Wirksamkeit.

Wichtig ist der Grundsatz: Eine Änderung wird erst verbindlich, wenn sie nach dem vereinbarten Verfahren freigegeben wurde. Das schützt beide Seiten. Du vermeidest Zusatzforderungen für bloße Konkretisierungen. Der Anbieter muss umgekehrt keine zusätzlichen Leistungen ohne geklärten Aufwand erbringen.

Abnahme bereits beim Schreiben mitdenken

Lastenheft und Pflichtenheft sind nicht nur Planungsdokumente. Sie entscheiden maßgeblich darüber, ob du eine Leistung abnehmen musst oder Mängel rügen kannst. Jede Muss Anforderung sollte deshalb auf einen konkreten Testfall verweisen oder selbst einen enthalten.

Lege für die Abnahme fest:

• welche Testumgebung verwendet wird,
• welche Testdaten und Testfälle gelten,
• wer testet und wer Ergebnisse dokumentiert,
• wie Fehler klassifiziert werden,
• welche Fehler die Abnahme verhindern,
• innerhalb welcher Frist Mängel gemeldet und behoben werden,
• welche Nachweise der Anbieter liefern muss.

Vermeide eine Abnahme nach bloßem Eindruck. Die Aussage „Der Fachbereich ist zufrieden“ kann ein zusätzliches positives Signal sein, ersetzt aber keine nachvollziehbaren Kriterien. Ebenso problematisch ist eine automatische Abnahme ohne ausreichend definierte Prüfmöglichkeit.

Checkliste vor Vertragsunterzeichnung

Prüfe vor der Unterschrift mindestens diese Punkte:

• Sind Geschäftsziele, Prozesse und Nutzergruppen verständlich beschrieben?
• Hat jede wesentliche Anforderung eine Kennung, Priorität und einen Prüfmaßstab?
• Sind Schnittstellen, Datenverantwortung und Mitwirkungspflichten konkret geregelt?
• Ist erkennbar, welche Leistungen ausdrücklich nicht geschuldet sind?
• Sind Lastenheft und Pflichtenheft mit Version und Datum als Vertragsbestandteile benannt?
• Gibt es eine klare Rangfolge der Vertragsdokumente?
• Ist die Freigabe des Pflichtenhefts geregelt?
• Gibt es ein verbindliches Verfahren für Änderungen?
• Lassen sich die Muss Anforderungen durch Testfälle und Abnahmekriterien nachweisen?
• Sind Verantwortlichkeiten für Entscheidungen, Tests und Abnahme eindeutig zugeordnet?

Ein Lastenheft muss nicht lang sein, und ein Pflichtenheft muss nicht technisch überladen sein. Beide Dokumente müssen vor allem eindeutig, vollständig genug und überprüfbar sein. Wenn du Anforderungen konsequent mit Vertragsbindung, Änderungsprozess und Abnahmekriterien verknüpfst, wird aus einer vagen Projektidee ein steuerbarer Leistungsumfang.