The parts below the dotted line are the main subjects of this presentation. The most evident feature of the object-oriented approach has been the long analysis phase. In a rigorous design this is as it should be, but it demands that the external requirements for the software be defined early. This has been a weakness in the GBT project, so the designers have been forced to proceed with rough requirements and modify and add to them as the project has progressed. The advantage of early requirements is a more coherent design, and considerable effort has been expended trying to reap this benefit.
Comprehensive requirements are very hard for future users to write.
Formal requirements demand a certain amount of abstraction that is quite different from how software is used. It seems fair to say that object-oriented design adds another layer of abstraction and, hence, another language barrier to the communication between user and designer. One of the roles that I have played in this project is translator between the user and software domains. Still, most of the effort of ferreting out requirements has fallen on the designers. A common method for converging on users' requirements is by building prototypes that the user can comment on and then iterate a number of times until the prototypes are acceptable.