Häufiger Streitpunkt bei Festpreis-IT-Projekten ist die SOLL-Beschaffenheit einer Software: Welche funktionalen und nicht-funktionalen Eigenschaften waren für den festgelegten Preis eigentlich geschuldet? Dass solche Projekte später vor Gericht landen, liegt oft an einer unzureichenden technischen Leistungsbeschreibung im (Werk-)Vertrag.

Es stellt sich damit die Frage, wie der technische Teil einer vertraglichen Leistungsbeschreibung beschaffen sein muss, um seinen Zweck zu erfüllen. Es geht also – um die Abstraktheit des Themas zu verdeutlichen – um die SOLL-Beschaffenheit der Beschreibung der SOLL-Beschaffenheit eines Software-Systems.

Dabei ist in der Praxis zu beobachten, dass die technischen Dokumente, die bei Softwareprojekten üblicherweise als vertragliche Leistungsbeschreibung im Sinne dieses Beitrags verwendet werden, sowohl im Deutschen als auch in der häufigen Projektsprache Englisch jeweils mit ganz unterschiedlichen Begriffen benannt werden (ohne Anspruch auf Vollständigkeit): Lastenheft, Pflichtenheft, Fachkonzept, Anforderungsspezifikation, Lösungsdokumentation, Fachfeinkonzept, Detailed Specification, Functional Specification oder auch Software Requirements Specification.

Unabhängig von der konkreten und – wie oben dargestellt – weitgehend inkonsistenten Benennung sind für die Betrachtung in diesem Beitrag insbesondere die benötigten Inhalte und die Form der betreffenden Dokumente relevant. Beide Aspekte werden im Folgenden diskutiert, wobei zur Einheitlichkeit für die Dokumente immer der Begriff „technische Leistungsbeschreibung“ verwendet wird, da dieser ihren Zweck aus juristischer Sicht in Abgrenzung zu anderen vertraglich spezifizierten Leistungen (z.B. Zahlung des Kaufpreises) sinnvoll beschreibt.

Welche Inhalte sollte eine technische Leistungsbeschreibung haben?

Die einfache, aber leider oft unbefriedigende – da nur subjektiv zu interpretierende – Antwort auf die Frage nach den üblichen Inhalten ist:

„Die technische Leistungsbeschreibung sollte grundsätzlich alle Anforderungen des Auftraggebers enthalten,

a)      die der Auftraggeber nicht der Entscheidung des Auftragnehmers überlassen will und
b)      die nicht eindeutige, allgemein anerkannte Regeln der Technik sind.“

(typische Abgrenzung)

Das Problem mit Teil a) dieser Abgrenzung der Inhalte ist, dass die Art der Anforderungen, ihr Detailgrad und die dem Auftragnehmer bei der Umsetzung gewährten Freiheitsgrade sich von Projekt zu Projekt stark unterscheiden können. Wird ein innovatives System „auf der grünen Wiese“ (d.h. ohne vorhergehende Erfahrungen mit der entsprechenden Systemklasse) aufgesetzt, so gibt es üblicherweise eher weniger harte Rahmenbedingungen und Detailanforderungen. Viele Gestaltungsentscheidungen können noch während des Projekts flexibel getroffen werden, wobei dann die Nähe und Qualität der Zusammenarbeit zwischen Auftragnehmer und Auftraggeber während des Projekts ein wichtiger Erfolgsfaktor ist.

Wird im Gegensatz dazu ein Altsystem z.B. bei einem Technologiewechsel vom Großrechner-Host auf x86-Infrastruktur abgelöst, so gibt es üblicherweise

• eine gewisse „Bestandserwartung“ der Nutzer des Altsystems bzgl. der Ausgestaltung der Funktionalitäten, Prozesse und Benutzerschnittstellen,
• existierende Schnittstellen des Altsystems zu anderen Systemen,
• zu migrierende Altdaten und
• ggf. sogar wiederzuverwendende technische Komponenten.

Bei einem solchen „Austausch“-Projekt gibt es also zumeist sehr viel mehr Dinge, die ein Auftraggeber aufgrund bereits in der Vergangenheit für das Altsystem getroffener Gestaltungsentscheidungen im neuen Projekt nicht mehr frei wählbar lassen will und kann.

Das Problem mit den eindeutigen, allgemein anerkannten Regeln der Technik (Teil b der Abgrenzung der notwendigen Inhalte, siehe oben) ist, dass dieser Begriff in einem sich schnell verändernden Gebiet wie der Informatik für Teilbereiche eine unklare Größe sein kann. Oft gibt es alternative Vorgehensweisen und Gestaltungsmöglichkeiten, die dazu führen, dass die (im Vertrag nicht explizit geäußerten) Vorstellungen von Auftraggeber und –nehmer im Projekt auseinanderlaufen. Aspekte wie Usability (Benutzbarkeit) werden zudem oft intersubjektiv (d.h. zwischen verschiedenen Personen) unterschiedlich bewertet, so dass auch hier häufige Streitpunkte liegen.

Standards

Es gibt zwar Standards für die Inhalte technischer Leistungsbeschreibungen für Software, insbesondere die in der einschlägigen Literatur vielzitierte, aber inzwischen ersetzte Norm IEEE 830-1998 (die aktuellste Version heißt IEEE/ISO/IEC 29148-2011), die jedoch im Gegensatz zu einer verbindlichen rechtlichen Norm wie die meisten technischen Normen eher Empfehlungen und „best practices“ vermittelt. In der Einleitung steht dazu:

„Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard.” (IEEE 830-1998, Seite ii).

Die IEEE Norm gibt typische Inhalte einer “Software Requirements Specification” (SRS) mit weiterführenden Hinweisen zu Qualitätsmerkmalen an und stellt meiner Auffassung nach eine gute Ausgangsbasis für die Erstellung eines solchen Dokument dar:

„The basic issues that the SRS writer(s) shall address are the following:

a)      Functionality. What is the software supposed to do?

b)      External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?

c)      Performance. What is the speed, availability, response time, recovery time of various software functions,
etc.?

d)      Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e)      Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating environment(s)
etc.?“

(IEEE 830-1998, Seite 3).

Im Streitfall muss trotzdem für jeden vermeintlich fehlenden Inhalt nach dieser Norm geprüft werden, ob seine Aufnahme in die technische Leistungsbeschreibung im konkreten Projekt tatsächlich notwendig ist und welche Detailtiefe bei seiner Beschreibung sachgerecht ist.

Beim Vorwurf von falschen oder vergessenen Einzelanforderungen ist in Ermangelung anderer Anforderungsquellen zumeist nicht objektiv ermittelbar, ob der Kunde diese konkrete Anforderung tatsächlich so hat oder nicht. Eine Prüfung der Validität der eigentlichen Anforderungen in einer technischen Leistungsbeschreibung entzieht sich also zumeist einer objektiven Begutachtung.

Welche Form sollte eine technische Leistungsbeschreibung haben?

Wie bei den Inhalten gibt es auch bei der Form der technischen Leistungsbeschreibung eine Vielzahl von Ansätzen, die alle unterschiedliche Stärken und Schwächen haben. Ende der 90er Jahre wurde mit der Unified Modeling Language (UML) ein Standard geschaffen, der den Anspruch erhebt die besten Diagramm- und Modellierungstechniken für Systemspezifikationen der damaligen Zeit in sich zu vereinen (daher „Unified“). Aber auch dieser „Standard“ lässt noch viele Gestaltungspielräume bei der Auswahl der Diagrammtypen, der problemspezifischen Anpassung der Darstellungsform und der Ausgestaltung der eigentlichen Leistungsbeschreibung.

In der Praxis hängt der Erfolg der Form einer technischen Leistungsbeschreibung stark davon ab, ob die passende Kombination von Darstellungsformen für die wichtigsten Aspekte des geplanten Systems gefunden wird. Wenn ein Softwaresystem beispielsweise seinen primären Mehrwert aus der Verarbeitung komplexer und kritischer Realweltdaten bezieht (Beispiel: Modellierung von Finanzderivaten und ihrem jeweiligen Risikoprofil), stehen bei der Spezifikation eher Datenmodellierungsmethoden im Vordergrund. Wenn ein System seinen Mehrwert aus der Automatisierung von komplexen, stark verzweigten Geschäftsprozessen zieht (Beispiel: Logistik in der Möbelindustrie), so stehen Diagrammtypen zur Abbildung von Abläufen und Ablaufvarianten im Mittelpunkt.

Eine Projekt- bzw. Spezifikationsmethodik sollte dem Ersteller einer technischen Leistungsbeschreibung zum einen möglichst konkrete Darstellungsmöglichkeiten vorgeben, um eine gewisse Konsistenz der Art der Darstellung gerade bei großen Projekten oder innerhalb von Organisationen zu schaffen. Auf der anderen Seite sollte die Methodik jedoch flexibel genug sein, um dem Ersteller die Möglichkeit zu geben, die für den Beschreibungsgegenstand jeweils ideale Darstellungsform frei zu wählen.

Es kann also auch für die notwendige Form einer technischen Leistungsbeschreibung festgehalten werden, dass es keine einfachen, allgemeingültigen Aussagen gibt, sondern dass im konkreten Ffall die Angemessenheit der gewählten Darstellungsform im Kontext des Einzelfalls geprüft werden muss.

Die technische Leistungsbeschreibung als Grundlage für die Abnahme

Ein Indiz für eine gute technische Leistungsbeschreibung ist die Gradlinigkeit, mit der sich Abnahmetests aus der Spezifikation ableiten lassen. Wenn die Anforderungen dort konkret und klar beschrieben sind, so kann man üblicherweise schnell erkennen, welche Anforderungen besonders wichtig sind und wie man diese am zur Abnahme stehenden System überprüfen kann.

Wenn beispielsweise in der Leistungsbeschreibung nur steht „der Online-Shop muss ein sehr gute Benutzbarkeit vorweisen“, so ist die Gestaltung eines treffenden Abnahmetests problematisch. Wenn dort hingegen steht,

dass „ein technisch nicht versierter Benutzer ohne weitere Einweisung selbständig und fehlerfrei den Einkaufprozess des Shops von der Produktauswahl bis zum Abschluss des Check-outs durchlaufen können muss“,

so liegt der passende Abnahmetest schon sehr nah.

Zusammenfassung

Es gibt in der Informatik Standards, die Vorschläge für die Inhalte und Darstellungsformen von technischen Leistungsbeschreibungen in Softwareprojekten bieten. Diese Standards haben jedoch nicht den Stellenwert rechtlicher Normen (d.h. es gibt Alternativen). Zudem lassen sie dem Ersteller eines solchen Dokuments üblicherweise selbst innerhalb des Standards so große Spielräume, dass im Streitfall eine konkrete Bewertung des Einzelfalls erfolgen muss.