Der zweite Schritt beinhaltet eine einzige Aktivität, nämlich die ,,Bedeutung``der Objekte und Klassen aus dem ersten Schritt festzulegen. Hier arbeitet der Software-Ingenieur wie ein Außenstehender: er sieht die Objekte und Klassen nur von außen, d.h. ihre Schnittstelle, und versucht festzustellen, was man mit diesen Dingen tun kann und wie sie andere Objekte manipulieren und verwenden können.
Dieser Schritt ist viel schwieriger als der erste und man benötigt viel mehr Zeit für seine Ausführung. Das ist die Phase des Projekts, wo hitzige Debatten geführt werden, wo gejammert, mit den Zähnen geknirscht, geschimpft wird und wo wüste Verwünschungen ausgesprochen werden. Die relevanten Objekte und Klassen zu finden ist einfach, über ihre Schnittstellen zu entscheiden schwierig. Hier beginnen im objekt-orientierten Entwurfsprozeß sich wiederholende Phasen. Wenn man sich über die Schnittstelle eines Objektes einigt, so kann das bewirken, daß sich die von anderen ändern. Es sei aber darauf hingewiesen, daß sich die wesentlichen Abstraktionen nicht mehr ändern, nur die Grenzen zwischen ihnen werden verschoben.
Dieser Schritt wurde in unserem Index-Beispiel nicht konsequent bis zum (bitteren) Ende ausgeführt, sondern es wurden nur ein paar Operationen aufgezählt, aus denen der Titelmodul bestehen könnte. Aber auch dort sieht man schon die Problematik: Ist es etwa notwendig, auf Buchstaben-Ebene hinunter zu gehen, oder genügt es, sich auf die Wort-Ebene zu beschränken?
In diesem Schritt gewinnt die Dokumentation wesentlich an Bedeutung. Hier ist es äußerst wichtig, alle Schritte des Entwurfsprozesses genau festzuhalten. Als Endresultat sollten, wenn man plant in Ada zu implementieren, Spezifikationsteile von Ada-Paketen zur Verfügung stehen.