Pflichtenhefte gestern und heute
Herr Prof. Schneider hat in seinem jüngsten Post (Schneider, CRonline Blog v. 25.5.2012) unter anderem das Thema „Pflichtenheft“ angesprochen und die Fragen aufgeworfen, wie dieses Institut des IT-Vertragsrecht in den Zeiten agiler Vorgehensweisen wie Scrum zu bewerten ist und ob sich Wesentliches bei der Natur eines Pflichtenheftes geändert hat.
Änderung der Natur des Pflichtenheftes?
Aus technischer Sicht ist die Antwort auf diese Frage ganz klar: Nein, es hat sich nichts Wesentliches daran geändert. Wenn ein Auftraggeber in der Praxis ein individuell entwickeltes oder als Standardsoftware stark angepasstes Softwaresystem zu einem festen Preis erwerben will, so muss an irgendeiner Stelle ausreichend genau beschrieben werden, welche Eigenschaften dieses System später haben soll. Erst dann wird sich ein Lieferant oder Software-Entwickler, aber auch der Auftraggeber selbst, auf das Projekt als Festpreisprojekt einlassen wollen. In Ermangelung konkreterer Vereinbarungen gibt es für die Ausgestaltung von Softwareanforderungsdokumenten allgemeine Normen wie z.B. die IEEE 830. Auch in der Fachliteratur (z.B. in Sommerville "Software Engineering 8") gibt es ausführliche Beschreibungen, wie ein solches Dokument auszusehen hat. An der Gültigkeit dieser Standards hat sich auch durch moderne Entwicklungsmethodiken nichts Grundlegendes geändert.
Ob man das in den Vertrag einbezogene Dokument nun „Pflichtenheft“, „Lastenheft“, „Fachkonzept“, „Leistungsbeschreibung“, „Feinkonzept“, „Anforderungsspezifikation“ oder auch „Fachfeinspezifikation“ nennt, ist sekundär – wichtig sind die vertraglich vereinbarte Verbindlichkeit für beide Seiten im weiteren Projektverlauf, die festgelegten Inhalte und natürlich die Verständlichkeit des Dokuments.
Pflichtenheft und agiles Programmieren
Wenn – was in der Praxis häufig vorkommt (siehe Stiemerling, "Das IT-Projekt im Konflikt mit dem vertraglich definierten Regelwerk", ITRB 2010, 289-291) – wesentliche Anforderungen zu Projektbeginn noch unsicher sind, bieten sich agile Projektmethodiken wie Scrum an, um diese Anforderungen im Projektverlauf zu konkretisieren. In diesem Fall kann zumindest bei Projektbeginn noch kein abschließendes Pflichtenheft vorliegen, so dass eine Festpreisvereinbarung naturgemäß schwierig ist. Wenn – auch in einem „agilen“ Projekt – dann ein Punkt erreicht ist, in dem die Anforderungen ausreichend konkret sind, so dass der Anbieter bereit ist, einen Festpreis für den restlichen Projektverlauf anzubieten, kommt das Pflichtenheft wieder in der bekannte Rolle ins Spiel.
Eine Besonderheit gibt es in diesem Fall dann doch: Da gerade bei agilen Methoden oft mit verschiedenen Arten von Prototypen gearbeitet wird, könnten diese dann zu einem bestimmten Zeitpunkt ebenfalls Teil des Pflichtenheftes werden. Wenn man beispielsweise im ersten, agilen Projektteil einen Oberflächenprototypen gebaut hat, könnte dieser (z.B. auf CD-ROM gebrannt) Teil des Vertrages für den zweiten, festpreisbasierten Projektteil werden und die klassische Beschreibung der Benutzerschnittstelle nach den oben angegebenen Standards zumindest in Teilen ersetzen.