Notes:

Design documents are produced both by the core team and the domain teams. The core team document defines the interfaces between domains. Its OIGs only shows messages between objects in different domains. These objects define the {\em interface classes} in each domain and the operations they need. A domain team starts with the interface class diagram for its domain and its set of requirements and does a similar job, but now showing all classes in the domain.

Each diagram, class and operation may be annotated within StP. A general introduction for the design document and introductions for each of the major sections may be written, and a design document generated automatically from the StP repository. As fragments of code can be stored in StP, everything can in principle be generated from it. However most people prefer to work on the code of a class directly once the skeleton of the class has been generated with the annotations for the class and operations appearing as comments in the code. We consider reverse engineering to be a legitimate way to proceed, especially for making small changes to the system, so we have developed a strategy for taking code and generating a revised design document from this. Class interfaces are extracted from the code and comments in the code used to refresh the annotations. Inconsistencies with OIGs and requirements will be spotted by the document generator, and it is the responsibility of those preparing the design document to reconcile the diagrams. We have successfully carried out code reviews of some of our prototype code, working electronically without meetings. We are about to try out a similar design review procedure and see if it is possible to assess a design with just the information in the generated document.