Wer zu spät testet, verschleudert Geld

Lückenhafte Beschreibung

Unter solchen Voraussetzungen fällt die Praxis ziemlich ernüchtern aus. Das erste Problem taucht bereits auf, wenn die Projektbeteiligten der IT die Anforderungen der Fachabteilung aufnehmen. Weil ihm die Routine seiner Arbeitsschritte selbstverständlich geworden ist, ist der Business-Kollege selten in der Lage, alle Anforderungen exakt zu formulieren, will diese aber sehr wohl in der späteren Anwendung abgebildet finden. Auf Basis dieser lückenhaften Beschreibung erstellen die IT-ler mit Hilfe von Requirement-Werkzeugen eine unter Umständen mehrere hundert Seiten umfassende Spezifikation, die zur Absegnung wiederum der Fachabteilung vorgelegt wird.

Doch die kann mit der Dokumentation nur wenig anfangen, weil die "Sprache" der Tools weitgehend der von Softwarearchitekten entspricht. Die Fachabteilung selbst hat keine Chance, mit den Requirement-Werkzeugen zu arbeiten, so Golzes Urteil. Trotzdem wird die Spezifikation unterschrieben, denn vor der Live-Schaltung gibt es ja ohnehin noch den User-Acceptance-Test, wo man fehlende oder anders gewollte Funktionen reklamieren kann. Was an Fehlern später im reinen Entwicklungsprozess entsteht, ist eher marginal, so Golze.