Wenn wir Bedürfnisse als „inhaltliches Verständnis der Funktionen“ begreifen, dann können wir in Migrations- und Integrationsprojekten einen kooperativen Prozess des Bewusstwerdens der Anforderungen beobachten, der drei Dimensionen hat:
Ein Testfall ist ein Run eines Programmteils, welcher eine Funktion vermittelt. Im produktiven Betrieb sind Runs Endkunden- oder Operatorinterventionen. Ein Run kann mit einem Fehler terminieren. Je mehr Testfälle, desto höher der Grad inhaltlichen Verständnisses, aber desto höher die Zahl manifester Fehler.
Ein mögliches Modell dieser Zusammenhänge könnte so aussehen (klicken Sie zum Vergrössern auf die Grafik):
Schon 1993 identifizierte Klaus Pohl drei Dimensionen1, das inhaltliche Verständnis der Funktionen, Grad der Dokumentation und der Grad der Übereinstimmung aller am Prozess beteiligten Stakeholder. Diese Sicht kann aber zu Verwirrungen führen. Die inhaltliche Dimension hängt natürlich vom einzelnen Stakeholder und von der in Frage stehenden Funktion ab. Vielleicht könnte man über alle Stakeholder einen Durchschnitt bilden, aber mindestens betreffend der einzelnen Funktion ist die Inhaltsdimension zu indizieren. Wie wir in Bye, bye Requirements Engineering gesehen haben, sind uns die meisten Funktionen gar nicht bewusst, so dass ein inhaltliches Verständnis von Funktion zu Funktion sehr unterschiedlich aussehen mag. Für einige Funktionen wird es gar nie ein Verständnis geben und braucht es auch gar nicht zu geben. Dadurch fällt die Übereinstimmung als Dimension weg, denn der Übereinstimmungsgrad der Funktion j ist gegeben durch den Wert u(p,j) über alle p.
1Klaus Pohl: The Three Dimensions of Requirements Engineering. CASE 1993: 275-292