Pflichtenheft für Dienstplan-Software: Aufbau, Vorlage und Abgrenzung zum Lastenheft

Die maßgebliche deutsche Begriffsnorm ist DIN 69901-5:2009-01 („Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe“), die nach Angaben von DIN Media weiterhin gültig ist. Sie definiert beide Dokumente über ihren Verfasser: Das Lastenheft ist 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 aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.

Die zweite häufig zitierte Quelle ist die Richtlinie VDI 2519 Blatt 1 „Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften“ aus dem Dezember 2001. Sie stammt aus der Materialfluss- und Automatisierungstechnik und beschreibt, wie Betreiber, Planer und Hersteller ihre Anforderungen und Lösungen strukturiert austauschen. Für Software-Projekte wird daneben die internationale Norm ISO/IEC/IEEE 29148 zum Requirements Engineering herangezogen, die keine deutschen Begriffe kennt, aber dieselbe Trennung zwischen Anforderung (requirements specification) und Lösungsbeschreibung vornimmt.

Der Kern ist in allen Quellen gleich: Das Lastenheft fragt was und wofür, das Pflichtenheft antwortet wie und womit. Ein Lastenheft für Dienstplan-Software formuliert etwa „Das System muss Ruhezeitverstöße vor Veröffentlichung des Plans anzeigen“. Das Pflichtenheft beschreibt, mit welcher Regel-Engine, welchen Parametern und welcher Oberfläche der Anbieter das umsetzt – und wie der Betrieb es prüfen kann.

Eine fertige Anforderungsliste, die als Lastenheft-Grundgerüst dienen kann, enthält der Anforderungskatalog dieses Dossiers; die Fragen an die Anbieter strukturiert der 25-Fragen-Katalog.

Im Alltag werden beide Wörter oft synonym verwendet. Viele Betriebe nennen ihre eigene Anforderungsliste „Pflichtenheft“, und auch die Rechtsprechung des Bundesgerichtshofs spricht bei Software-Projekten vom „fachlichen Pflichtenheft“, wenn sie die Anforderungen des Auftraggebers meint. Für die Normlogik ist das ein Lastenheft. Wer ein Dokument bestellt oder vereinbart, sollte deshalb nicht nur den Titel, sondern Verfasser und Zweck im Vertrag festhalten: „Anforderungen des Auftraggebers“ und „Lösungsbeschreibung des Auftragnehmers“ sind eindeutiger als jedes Etikett.

Die Unterscheidung hat Folgen für die Verantwortung. Bei individuell erstellter Software liegt es nach der Rechtsprechung grundsätzlich beim Auftraggeber, seine Anforderungen zu benennen; den Anbieter trifft als Fachmann eine Beratungspflicht. Fehlt eine Spezifikation ganz, schuldet der Auftragnehmer nach einer häufig zitierten BGH-Entscheidung (Urteil vom 16. Dezember 2003, X ZR 129/01) ein System, das dem Stand der Technik bei mittlerem Ausführungsstandard entspricht – ein Maßstab, der für die Arbeitszeitregeln eines Klinikbetriebs mit Tarifvertrag kaum etwas hergibt. Kurz: Ohne Lastenheft ist ein Pflichtenheft nicht prüfbar, und ohne Pflichtenheft ist bei Entwicklungsprojekten die Abnahme Verhandlungssache.

Die folgende Gliederung ist für Dienstplan-Projekte zugeschnitten. Sie folgt der üblichen Struktur aus Zielbestimmung, Produkteinsatz, Funktionen, Daten, nicht-funktionalen Anforderungen und Abnahme, ergänzt um die Punkte, die in Dienstplan-Projekten erfahrungsgemäß den Ausschlag geben: Arbeitszeitregeln, Mitbestimmung und Auftragsverarbeitung. Jedes Kapitel nimmt die Nummer der zugehörigen Lastenheft-Anforderung auf, damit sich beide Dokumente Zeile für Zeile abgleichen lassen.

Die Beispiele sind bewusst konkret. Ein Satz wie „Das System soll gesetzeskonform planen“ lässt sich weder umsetzen noch abnehmen; „Das System zeigt vor Veröffentlichung jede Unterschreitung der Ruhezeit von 11 Stunden nach § 5 Abs. 1 ArbZG an“ dagegen schon. Wo Tarifverträge abweichende Ruhezeiten oder Ausgleichszeiträume zulassen, gehört der konkrete Tarifparagraf in Kapitel 5. Die Kapitel 9 und 10 hängen eng zusammen: Was der AV-Vertrag technisch absichert, regelt die Betriebsvereinbarung nach innen – das Pflichtenheft muss beiden entsprechen.

Die Klassifizierung der Anforderungen ist der Teil, der in Auswahlprojekten am häufigsten missglückt. Typisch sind Listen mit 120 Muss-Kriterien, von denen kein Anbieter alle erfüllt – womit das Wort „Muss“ seine Funktion verliert. Bewährt hat sich eine dreistufige Einteilung mit klaren Folgen.

Vier Formulierungsregeln machen Anforderungen prüfbar: eine Anforderung pro Zeile, ein Akteur und ein Verb („Die Teamleitung kann …“, „Das System verhindert …“), messbare Werte statt Adjektive (Zahl, Frist, Format) und eine Prüfmethode je Muss-Kriterium (Demo, Testszenario, Dokument). Muss-Kriterien gehören in der Auswahl als Ausschlussfilter vor die Bewertung; wie Soll- und Kann-Kriterien danach gewichtet werden, zeigt die Nutzwertanalyse.

Das klassische Pflichtenheft stammt aus Entwicklungsprojekten: Der Auftragnehmer baut etwas, und das Pflichtenheft beschreibt, was er bauen wird. Die meisten Dienstplan-Lösungen werden heute jedoch als Software as a Service gemietet. Der Anbieter entwickelt für den einzelnen Kunden nichts Neues; er stellt ein fertiges Produkt bereit, das für alle Kunden gleich ist und laufend weiterentwickelt wird. Ein individuelles Pflichtenheft für 50 oder 500 Beschäftigte zu schreiben, wäre für den Anbieter unwirtschaftlich – und für den Kunden wenig wert, weil das Produkt sich mit jedem Release ändert.

Auch rechtlich passt das Werkvertragsdenken nicht. Der BGH hat die Bereitstellung von Software über das Netz bereits 2006 im Kern dem Mietrecht zugeordnet (Urteil vom 15. November 2006, XII ZR 120/04, zum Application Service Providing); seit dem 1. Januar 2022 ordnet § 548a BGB an, dass die Vorschriften über die Miete von Sachen auf die Miete digitaler Produkte entsprechend anzuwenden sind. Eine Abnahme im Sinne von § 640 BGB kennt das Mietrecht nicht. Sie kommt bei SaaS nur für zusätzlich beauftragte Werkleistungen in Betracht – etwa eine individuelle Schnittstelle oder eine Datenmigration – oder wenn die Parteien ein Abnahmeverfahren vertraglich vereinbaren.

Der wichtigste Baustein ist die Erfüllungsmatrix. Sie ersetzt die Lösungsbeschreibung des Pflichtenhefts, ohne dass der Anbieter ein eigenes Dokument verfassen muss: Er beantwortet das Lastenheft Zeile für Zeile, und diese Antworten werden Vertragsbestandteil. Wichtig ist die Unterscheidung zwischen „im Standard“ und „per Konfiguration“: Beides ist ohne Programmierung möglich, aber nur das Erste funktioniert ab dem ersten Tag ohne Einrichtungsaufwand. „Geplant“ oder „auf der Roadmap“ ist dagegen keine Erfüllung und sollte bei Muss-Kriterien wie „nicht erfüllt“ gewertet werden.

Die Abnahmekriterien verlagern sich bei SaaS in die Testphase. Statt am Ende einer Entwicklung abzunehmen, prüft der Betrieb vor Vertragsschluss mit eigenen Daten: Lassen sich die drei schwierigsten Schichtmodelle abbilden? Erkennt das System den Ruhezeitverstoß zwischen Spät- und Frühdienst? Kommt der Lohnexport im erwarteten Format an? Jedes Muss-Kriterium bekommt ein Testszenario mit erwartetem Ergebnis; bestanden ist der Test, wenn das Ergebnis eintritt, nicht wenn die Demo überzeugend wirkte. Die meisten Anbieter bieten dafür kostenlose Testzeiträume an, beim Testsieger dieses Dossiers, Aplano, etwa 14 Tage im Pro-Umfang ohne Kreditkarte. Das reicht für die Muss-Szenarien, wenn sie vor dem Teststart feststehen.

Ein Sonderfall sind öffentliche Auftraggeber. Nach § 121 Abs. 1 GWB ist der Auftragsgegenstand in der Leistungsbeschreibung so eindeutig wie möglich zu beschreiben, damit die Angebote vergleichbar sind; sie enthält Funktions- oder Leistungsanforderungen oder eine Beschreibung der zu lösenden Aufgabe. Diese Leistungsbeschreibung entspricht funktional dem Lastenheft. Für Cloud-Leistungen einschließlich SaaS stellt der Bund seit 2022 die mit dem Branchenverband Bitkom abgestimmten Vertragsbedingungen EVB-IT Cloud bereit, in denen die Leistungsbeschreibung als eigene Anlage geführt wird.

Für ein typisches Auswahlprojekt mit SaaS-Anbietern ergibt sich daraus eine Abfolge in sechs Schritten. Sie ist auch dann sinnvoll, wenn der Betrieb klein ist und das Lastenheft nur drei Seiten umfasst.

Zwei Punkte entscheiden über die Belastbarkeit. Erstens muss der Betriebsrat bei Dienstplan-Software, die Arbeitszeiten erfasst oder auswertet, nach § 87 Abs. 1 Nr. 6 BetrVG zustimmen; die Unterrichtung nach § 90 BetrVG gehört deshalb in Schritt 1, nicht in Schritt 6. Zweitens sollten die Antworten aus der Erfüllungsmatrix ausdrücklich als Vertragsanlage vereinbart werden – sonst gilt im Streitfall nur die allgemeine Leistungsbeschreibung, in der die zugesagte Detailfunktion möglicherweise nicht vorkommt. Wie sich die Kosten der Varianten über die Laufzeit vergleichen lassen, zeigt die Gesamtkostenrechnung.