Das Unangenehme zugleich vorweg: Es ist für Anwender wie Auftragnehmer oftmals ebenso arbeitsreich wie mühevoll, ein wirklich brauchbares Pflichtenheft zu erstellen. Und für beide Parteien liegen in einem solchen Werk, ist es dann endlich fertig, gleichermaßen Chancen wie Risiken.

Zur Anschauung folgendes Beispiel: Ein Webauftritt soll auf ein einheitliches Content Management System umgestellt werden. Der Kunde, beispielsweise Betreiber eines technisch veralteten und visuell wenig ansprechenden Shopsystems, hat sich informiert und ist auf das Open-Source-System TYPO3 aufmerksam geworden. Zusammen mit seinen Mitarbeitern erarbeitet er ein so genanntes Lastenheft (auch grobes Pflichtenheft genannt), in dem er versucht, die Forderungen an das zu erstellende System aus seiner eigenen Sicht als Anwender einschließlich aller Randbedingungen zu beschreiben. Die Palette dieser Forderungen kann inhaltlich von der Forderung nach möglichst geringen Umsetzungs- und Lizenzkosten, einem ausgereiften und professionellen Warenkorbsystem, der Einbindung von Kreditkarte und Bankeinzug als Zahlungsweisen für klassische Produkte bis hin zu an die verschiedenen Produkttypen angepassten Lieferkosten und vielen weiteren denkbaren Sonderfeatures reichen. Das Lastenheft definiert insoweit ganz grob, was für eine Aufgabe vorliegt und legt die Rahmenbedingungen dar.

Wohin die Reise geht …

Darauf aufbauend wird im Rahmen eines so genannten Pflichtenheftes ein „Fachfeinkonzept“ erstellt, in dem ebenso detailreich wie inhaltlich erweiternd die Realisierungsforderungen vertraglich bindend beschrieben werden. Das OLG Düsseldorf hatte bereits im Jahre 1993 die zentrale Funktion eines solchen Pflichtenheftes hervorgehoben, mit dem der Leistungsinhalt konkretisiert, also festgelegt wird, welche bestimmte Einzelleistungen das Programm mit welchen Mitteln unter welchen Voraussetzungen und mit welchen Vorgaben erbringen soll.

Um keine Missverständnisse aufkommen zu lassen: In dieser Phase geht es in erster Linie um eine präzise, nachvollziehbare und vollständige Beschreibung der geplanten Leistung. Technische Festlegungen über die Benennung der zu Grunde liegenden Betriebs- und Wartungsumgebung hinaus, also in die Tiefe gehende technische Spezifikationen, Ausführungen zum technischen Design insgesamt sowie die Erarbeitung von konkreten Lösungsansätzen für erwartete Implementierungsprobleme sind hier in der Regel nicht oder nur bedingt mit umfasst.

Wer schreibt …

Das Pflichtenheft informiert auf Grundlage von Informationen des zukünftigen Anwenders über die Anforderungen an ein Programm. Dementsprechend obliegt es auch diesem, das Pflichten-

heft zu erstellen. Mangels ausreichender EDV-Kenntnisse und wegen damit einhergehender fehlender Vorstellungen von technisch denkbaren Handlungsoptionen wird der Besteller aber oftmals kaum in der Lage sein, ein präzises Pflichtenheft allein auszuarbeiten. Eine Mitwirkung des Softwareherstellers als Fachinstanz ist notwendig, insbesondere dann, wenn die Vorstellungen des zukünftigen Anwenders sehr lückenhaft, laienhaft oder sonst wie unpräzise sind. Der Hersteller hat hier dafür zu sorgen, dass Unklarheiten, etwaige Widersprüche etc. aufgeklärt werden.

Versäumt er dies, kann er sich später nicht auf Fehler im Pflichtenheft berufen, sondern muss damit rechnen, dass das erstellte Werk unter Umständen als „mangelhaft im Sinne des Werkvertragsrechtes“ gilt. Das kann schwerwiegende Folgen zum Beispiel hinsichtlich der Vergütung haben. Auf der anderen Seite haftet der Hersteller aber nicht für jede Ungenauigkeit im Pflichtenheft, so etwa dann nicht, wenn der Besteller subjektive Begrifflichkeiten zur Mitteilung seiner Leistungserwartungen verwendet (Beispiel: „Wesentlich ist die schnelle Weiterleitung der Daten.“). In derartigen Fällen ist grundsätzlich ein Programm entsprechend „dem Stand der Technik bei mittlerem Ausführungsstandard“ geschuldet.

Die Ausarbeitung des Pflichtenheftes kann aber auch vertraglich (und gegen Kostenerstattung!) dem Hersteller auferlegt werden. Dieser hat dann auf der Grundlage der derzeitigen betrieblichen Abläufe beim Anwender die zu entwickelnde Software so weit zu konkretisieren, dass sie später hieran gemessen werden kann. Dabei ist aber zu berücksichtigen, dass sich der Inhalt der jeweiligen Leistungspflicht nicht nur isoliert aus dem Pflichtenheft, sondern grundsätzlich auch aus anderen Umständen, insbesondere aus der Art der gestellten Aufgabe, ergeben kann. Sorgfalt bei der Erstellung ist auf jeden Fall aber zwingend angezeigt, denn aufgrund der Schriftlichkeit hat das Pflichtenheft einen wichtigen Argumentations- und Beweiswert. So ist es regelmäßig Grundlage der werkvertraglich erforderlichen Abnahmeprüfung.

In der Praxis ist es sinnvoll, dass der Besteller zunächst seine „Wünsche“ grob schriftlich darlegt und sich dann involvierte Personen des Bestellers wie Herstellers zu einem Kick-Off-Meeting zusammenfinden. Hierbei geht es dann darum, einerseits im persönlichen Austausch die Grundzüge des Softwareprojekts zu bestimmen und das Projekt in dieser Phase bereits in das rechte Fahrwasser zu bringen – und auf diesem Wege zugleich hilfreiche persönliche Kommunikationswege zu erschließen.

Wurde das Pflichtenheft letztlich maßgeblich durch den Hersteller verfasst, sollte diese Leistungsbeschreibung unbedingt noch vom Auftraggeber auf Richtigkeit und Vollständigkeit überprüft und mit seinem Zustimmungsvermerk versehen werden. Sollten nämlich später auftretende Änderungswünsche über das Fixierte hinaus geäußert werden, wird dies im Regelfall auch zu gesonderten Termin- und Preisvereinbarungen führen, ohne dass dann langwierige Diskussionen erforderlich sind.

Welchen Anforderungen zu genügen ist …

–
einige Gliederungsbeispiele hat Herr Prof. Dr. Klüver von der Fachhochschule Augsburg zusammengestellt [1]. Aufbau wie konkreter Inhalt des zu erstellenden Pflichtenheftes sind daher im Grundsatz frei gestaltbar, Berücksichtigung finden sollten aber Ausführungen zu

• Zielbestimmungen, d.h. der Abgrenzung unabdingbarer Leistungen, die das Produkt in jedem Fall erfüllen muss, von Wunschkriterien, deren Erfüllung angestrebt wird, von auszuschließenden Kriterien, die bewusst nicht erreicht werden sollen.
• Fachlichen Spezifikationen (Funktionalitäten, Informationsbedarf und -fluss, Verarbeitungsregeln, Schnittstellen, Zuverlässigkeit, Benutzerfreundlichkeit, Portabilität etc.)
• Technischen Spezifikationen (programmtechnischen Vorgaben, Vorgaben aufgrund der Hard- und Softwareumgebung, Dokumentationsanforderungen etc.)

Nicht zuletzt kommt dem Pflichtenheft eine nicht zu unterschätzende Bedeutung zur Überprüfung der ordnungsgemäßen Vertragserfüllung durch einen Softwarehersteller zu.

Das Gesetz normiert es zweifelsfrei: Der Unternehmer hat dem Besteller das Werk frei von Sach- und Rechtsmängeln zu verschaffen. Frei von Sachmängeln ist demnach ein Werk vor allem dann, wenn es die vereinbarte Beschaffenheit hat.

Im Rahmen dieser Darstellung ist es nicht möglich, die rechtlichen Dimensionen der juristischen Begrifflichkeit des „Sachmangels“ auszuleuchten. Grundsätzlich liegt ein Sachmangel aber immer dann vor, wenn die Ist-Beschaffenheit von der Soll-Beschaffenheit abweicht. Letztere ist nach der jeweils vereinbarten Beschaffenheit der Sache zu bestimmen. Es liegt auf der Hand, dass es in der Praxis schwierig ist, diese vereinbarte Beschaffenheit festzustellen. Probate Ansatzpunkte bei der Klärung dieser Fragestellung kann ein verfasstes Pflichtenheft bieten, denn hier sind ja nicht nur die Programmspezifikationen zusammengefasst, sondern auch in beweisgeeigneter Schriftform fixiert.

Wer garantiert, haftet …

Mit weitreichenden Folgen – der Besteller kann, wenn Mangelhaftigkeit vorliegt, Nachbesserung über Aufwendungsersatz, Vergütungsminderung bis hin zu Rücktritt vom Vertrag sowie gegebenenfalls Schadensersatz geltend machen.

Auf eines sollte noch hingewiesen werden, insbesondere für die Fälle, in denen der Hersteller das Pflichtenheft formuliert: Die Grenze von der „engagierten“ Leistungsbeschreibung zur Garantiehaftung ist oftmals fließend. Allgemein gehaltene Angaben zur Sache reichen in der Regel nicht aus, um Anhaltspunkte für einen besonderen Einstandswillen zu liefern, sehr detaillierte Eigenschaftsumschreibungen, die über das übliche Regelmaß deutlich hinausgehen, können hingegen bereits auf eine solche selbstständige Garantieübernahme hindeuten. Eine gewisse Zurückhaltung und Vorsicht ist daher bei der Formulierung durchaus angezeigt, auch wenn man den Kunden besonders beeindrucken will.

In Zusammenhang mit der gerichtlichen Geltendmachung von entsprechenden Ansprüchen stellt sich häufig die Frage, wer eigentlich im Falle eines etwaigen Softwaremangels den Beweis, dass eben ein solcher Mangel vorliegt, zu erbringen hat. Im Grundsatz gilt Folgendes: Vor Abnahme des Werkes hat der Hersteller zu beweisen, dass die Software mangelfrei ist; nach erfolgter Abnahmeerklärung hat der Besteller umgekehrt den Beweis zu führen, dass die Software mit einem Mangel behaftet ist. Das Pflichtenheft, also der detaillierte Anforderungskatalog, stellt hier eine adäquate „Prüfungsvorlage“ dar: Erfüllt die erstellte Software die an sie gestellten, schriftlich fixierten Anforderungen oder nicht?

Wird übrigens kein Pflichtenheft ausgearbeitet und lassen sich auch durch sorgfältige Auswertung von Korrespondenzen und Zeugenaussagen vereinbarte Spezifikationen nicht zweifelsfrei ermitteln, muss das Programm keinen besonderen Anforderungen genügen, sondern lediglich dem Stand der Technik bei einem mittleren Ausführungsstandard entsprechen. Ob dies der Fall ist, klärt im Streitfall ein Sachverständiger im Auftrag der Parteien oder im Rahmen eines etwaigen gerichtlichen Beweisverfahrens.

Zusammenfassend kann festgehalten werden, dass die Erstellung eines Pflichtenheftes für den Hersteller wie Anwender mit Chancen wie Risiken verbunden ist, wobei die Vorteile für beide Seiten zu überwiegen scheinen. Der Besteller und zukünftige Anwender kann mit dem Pflichtenheft seine Vorstellungen konkretisieren und schriftlich fixieren. Der Hersteller hält einen konkreten Katalog in den Händern, den es bei der Programmierung abzuarbeiten bzw. zu berücksichtigen gilt und der zugleich einen Schutz vor etwaig überzogenen oder zusätzlichen Erwartungen des Bestellers bietet, die nicht oder nicht so Gegenstand des Zusammenwirkens waren.

Im Rahmen eines solchen Beitrags können aus der Natur der Sache nur Grundzüge dargestellt werden. Die Investition, sich im Vorfeld rechtlich beraten zu lassen, um den Besonderheiten des Einzelfalles Rechnung zu tragen, wird sich oftmals als hilfreich erweisen.