Outline of the Design Specification Document

The design document if the culmination of your team's effort to describe the software artifact. Its focus is on the information needed by the programmer who will work individually on various parts with the document providing all the needed guidance to insure that the parts will fit together. The design document thus does not stand alone, but supplements the earlier descriptions which served to satisfy the user that the right product was being planned, and the designer that the necessary functionality was understood. Therefore your document can be more tabular than narrative. However, it must have at least four sections and Appendices.

Section 1: Tabulation of components. The implementation should be designed to engage the whole team in parallel work, and therefore the design consists primarily in breaking the product into code components which must be constructed by the implementation team. The breaking process may closely or vaguely follow the architectural diagram which described the product in terms of subsystems. I anticipate that there will be on the order of 30-50 code components (modules) counting each screen and assuming that each screen interacts with several other components, many of them custom designed to perform the screen's function. The tabulation entry for a component will give the component a name, provide a sentence description of the component's purpose, list its inputs and its outputs (its interfaces), and label its risk. The labels will be STRAIGHTFORWARD, COMPLEX, AND UNCLEAR (the algorithms or internal data formats for this component are not yet well understood). However the components are listed (alphabetical by name is recommended), the component description is intended to suggest "bottom up" assembly of the product. Only the components which must be built and those which exist but must be substantially modified appear in the list. There will be other components, for example dialog boxes, which will come with the programing language environment (section 3).

Section 2: Data descriptions. Two tables must be constructed, the first of data items (fields whose values are input or calculated and which are displayed on the printer or the screen), and the second of data aggregates (database tables). A data item is named, its internal and external representation indicated, and whether it is isolated or part of an aggregate. Occasionally a data item will be replicated through several variables, and in that case it has a list a aliases. Sometimes the data item changes internal representation and other times its displayed representation is different from its internal representation. Such circumstances should be flagged. They are listed alphabetically by name. NOT INCLUDED are internal counters, flags, temporary storage locations, etc. A data aggregate is named by its internal file or table name, and shows the record structure of the aggregate, both data fields and association fields (links, keys, etc.). Each aggregate has a repetition factor (the number of rows, the number of records, etc.)

Section 3: Implementation language and tools. [I have been led to believe that both projects will be done in Visual Basic]. The components provided by the language or its libraries are listed here (usually GUI components and data base services). An assessment of the benefits of using this language for implementation follows (show how and where it will ease the implementation) including a discussion of any drawbacks (such as size of the resulting code, speed, licensing, etc.)

Section 4: Schedule: In tabular form list the modules to be constructed (section 1), the effort in person days estimated in producing and testing the module, and the precedence order of the module (what components will already be available to help in testing the module). This listing is most naturally produced by enumerating first those modules without dependence on others, then those which depend on those listed, until all components have been accounted for. You should also schedule "dummy" activities which take up time to integrate components into subsystems and insert those activities in the list. Finally, add two columns in which you specify a start date and a finish date (delivery of the tested component, or completion of integration of the subsystem) for each entry. These dates should all be in the interval January 13 to April 2, 1998, but could start sooner. These dates should be chosen to conform to the dependencies and to the estimated effort (recognizing that no one has whole person days to devote to implementation).

The schedule table will therefore have the form:

ID Module/Activity Name Effort (PD) Prereq. Module ID's Start Date Delivery Date

Appendices:

A. Examples of every input form associated with the new system

B. Examples of every report produced by the new system.

C. Picture of all screens (in tree order (pre-order traversal)).

It should be obvious that the sections of this document can be worked on in parallel, and that some of the information has already been presented in the earlier reports. This report digs for a new level of specificity suitable to guide programmers