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.

Die fehlerträchtigste Schwachstelle im Verlauf eines Software-Entwicklungsprojekts liegt also in der Phase der Anforderungserhebung und damit an der Schnittstelle zwischen IT und Fachabteilung. Eine Lösung dieses Problems sieht Golze in einem methodischen Ansatz, zum Beispiel in einem Referenzmodell, das die Beteiligten für eine Anwendung bauen. Vereinfacht bedeutet dies, dass im Laufe eines Arbeitstags eine Liste sämtlicher Aktivitäten, die zur Bewältigung einer bestimmten Aufgabe nötig sind, erstellt und innerhalb einer Baumstruktur abgelegt wird. Als nächstes hängt man hinter jeden dieser Arbeitsschritte die entsprechenden Anforderungen an. Ein simples Beispiel wäre: Zur Aktivität "Kunde anlegen" gehören die Requirements "Name", "Ort", "Straße" etc.

Der eigentliche Clou kommt in einem dritten Schritt: Um die Qualität der Requirements zu erhöhen, schlägt man den Business-Anwendern vor, zusätzlich zur Anforderung zu formulieren, wann diese aus seiner Sicht erfüllt ist. Golze bezeichnet diesen Teil des Referenzmodells als Proof- oder Checkpoints beziehungsweise als Akzeptanzregeln. Eine Regel könnte im genannten Beispiel sein, dass der Vorname gegen die Anrede geprüft wird. Damit würden bereits in dieser frühen Phase die Kriterien für den späteren User-Acceptance-Test festgelegt.