"I think there's a world market for maybe five computers."
(dt.: "Ich denke, es gibt einen Weltmarkt für vielleicht fünf Computer.")
(Thomas Watson, IBM chairman, 1943)

Anforderungen fixieren

Ganz wichtig ist, dass die gestellten Anforderungen in Form von Anforderungslisten und Anforderungsbeschreibungen fixiert werden, damit sie beispielsweise als Anlage in das spätere Angebot der Realisierung aufgenommen werden können. Denn wenn es am Ende des Projekts um die Abnahme und Bezahlung geht, muss gegen diese Anforderungen getestet werden. Sehen Sie es mal anders herum: Wenn Sie nicht wissen, was gefordert wurde, wie wollen Sie dann wissen, was bezahlt werden muss und wie wollen Sie überhaupt wissen, wann Ihr Projekt zu Ende ist?

Grundsätzlich sollte beachtet werden, dass Spezifikationslücken einen Spielraum für den Entwickler darstellen: Wird nur angegeben, was realisiert werden muss und nicht, wie es realisiert werden muss, kann sich der Entwickler den einfachsten Weg aussuchen. Dieser Weg wird dann sicherlich die fachlichen Anforderungen des Kunden erfüllen, aber vielleicht nicht gerade die Variante repräsentieren, die sich der Kunde immer vorgestellt hat - aber vielleicht wegen des hohen Aufwands leider nicht als Anwendungsfälle spezifizieren wollte. Wenn also bei der Analyse der Anforderungen Anwendungsfallbeschreibungen erstellt werden, sollten diese im Interesse beider Parteien als Leistungsbeschreibung beim Angebot für die Realisierungsphase verwendet werden.

Bei wesentlichen und vor allem offensichtlichen Auslassungen wird jeder Richter darauf pochen, dass Sie als Auftragnehmer von der Lücke wussten und eine Pflicht zur Forderung nach Ausbesserung der Spezifikationen hatten. In diesem Fall ist die Nicht-Spezifikation ein klarer Vorteil für den Kunden! Wenn der Kunde also ein "Kennzahlensystem" fordert, keine weiteren Details liefert und später - entgegen Ihrer Meinung als Auftragnehmer - annimmt, dass eine Trendanalyse doch wohl selbstverständlich dazu gehört, dann hat wohl der Auftragnehmer schlechte Karten, weil er eine präzisere Beschreibung des Satzes "Die Software muss ein Kennzahlensystem enthalten" hätte fordern müssen. Beide Parteien sollten ein Interesse an einer dauerhaften guten Beziehung haben, der Auftraggeber wegen einer guten Betreuung in der Wartungsphase und der Auftragnehmer wegen Folgeaufträge und einer guten Referenz. Es sollten also beide bestrebt sein, solche Lücken zu füllen.

Aber bleiben wir zunächst noch beim "was" (also den Anforderungen), bevor wir zum "wie" (also den Anwendungsfallbeschreibungen und Prototypen) kommen. Sie sollten insbesondere alle funktionalen (fachlichen) Anforderungen möglichst knapp aber präzise schriftlich formulieren, um genau den von der Software abzubildenden Weltausschnitt des Kunden zu bestimmen. Die technischen Anforderungen sind meist sehr genau bekannt, schnell aufgeschrieben und auch sehr stabil.

Was auch immer Sie in die Hand bekommen und wie auch immer der Kunde Ihnen die Anforderungen offeriert: Sie sollten als Anbieter in diesem Gespräch noch keinen Preis für die Pre-Analyse nennen, auch keinen Rahmen. Stattdessen sollten Sie sich mit Ihren Kollegen über die erste grob notierte Anforderungsliste unterhalten und die übergebenen Unterlagen sichten, um die Informationen, die Sie zu dieser Zeit haben, hinreichend beleuchtet zu haben. Achten Sie dabei auch auf die Präzision, Stabilität, Lückenhaftigkeit und Widersprüchlichkeit der Informationen und Eindrücke, die Sie gewonnen haben. Denn das sind alles Indizien dafür, wie die Pre-Analyse ablaufen könnte. Als Kunde sollten Sie auf jeden Fall darauf achten, ob Ihnen das schriftliche Festpreisangebot für die Pre-Analyse zeitnah zugestellt wird; denn wenn das schon nicht klappt, was soll dann aus Ihrem Projekt werden?