The Detailed Design Description provides the details of the project. This means all of the details of all of the different parts of the software you are developing will be shown here. The idea is that from any part of this document, a new person to the project could read the design description, and from that begin coding on some segment, either a module, a function, a class, or some other subdivision. Thus, there should be enough detail in this document to accomplish that task.

If you use the Architectural design document as a starting point, you are almost halfway to the result you want. You can fill in the details that are missing from the top-level view, and then re-iterate through a few times, filling in more detail during each iteration. As you refine the design, adding more and more detail, you will eventually reach the level you need so as to have fully specified the "how" of the system. And, indeed, this is the place for the "how". Remember in the SRS, the focus was on "what you are going to build", here the focus is on "how you are going to build it".

The document should be structured as follows (sections are explained below):

            7.0  Detailed Design Specification
            7.1      Introduction
            7.2      Detailed Design Description
            7.2.1    CSC 1 Descriptions
            7.2.1.1  CSU 1 Description
                           .
                           .
                           .
            7.2.1.n  CSU n Description

                <similar sections for all CSCs 1 through m-1>

            7.2.m    CSC m Descriptions
            7.2.m.1  CSU 1 Description
                           .
                           .
                           .
            7.2.m.n  CSU n Description
            7.3      Database CSU Design Description (if applicable)
            7.3.1    CSU 1 Description
                           .
                           .
                           .
            7.3.n    CSU n Description
            7.4      Detailed Interface Descriptions

         

The introductory paragraph should describe the project and gives an outline of the rest of the Detailed Design Description section. It is a bare minimal sketch of this section. Just make it something like the introduction sections of the other deliverables.

This is the introduction to the section. Put in text something like:

The following sections contain the descriptions of the details of the design of the <your project name here> CSCI. The design is systematically described in terms of the CSCs for the project, and the CSUs for each CSC.

Be sure to include enough detail so that someone can start coding modules from the descriptions in this section. Use LOTS of UML diagrams here. Detailed class diagrams, with all the various trimmings, state diagrams, activity diagrams, a package diagram, and sequence diagrams are all good ideas to use in these sections. Be sure to use text to explain how everything works; don't just rely on the diagrams to tell the entire story!

This is the introduction section for the first CSC. It is expected that you will have multiple CSCs in your project, so you will need one of these sections for each CSC. The material in this section presents the detailed design at the CSC level, meaning you will provide lower level details of how the various parts of this CSC relate to each other and how they operate together. This is where you will put most of your diagrammatic information, along with text explaining the diagrams. For example, in a Client CSC for a client-server application this section should probably have:

• A class diagram showing the different classes, including some (but not all) of the major methods and class fields
• A sequence diagram or an activity diagram showing processing flow between the parts; possibly multiple sequence diagrams would be needed to show different operations
• A state diagram showing the various states of this CSC and the events which cause the transition between the states

There will be one of these sections for each CSC in the project.

This section contains the details of one Computer Software Unit, or "module" of the project. A module may contain more than one class, but usually in object oriented design, a module will be a single class. It is this section in which you provide the specific details of the overall goal, function, or use of the class, detailed explanations of the use and operation of every method, and information about every field in the class. No specific information is required on the relationship of this class to other classes in the project or even in the same CSC — that information is provided elsewhere in the document (in the CSC section as described above).

There will be one of these sections for each CSU in each and every CSC of the project. For example, if you have four CSCs, there will be four CSC sections, and each of those sections will have sub-sections like this one for the CSUs that are a part of it.

This is really just another one of the CSC sections, but the focus is specifically on detailed design of the datbase portion of the project. In this section you will need a complete Entity Relationship Diagram (ERD) for the database, along with a data dictionary.

CSU design descriptions for databases include any classes that are developed specifically for access to the database, as well as diagrams showing flows and/or states of the database system. If is good to include the data creation ad data manipulation language details as well, to make the translation to database code as simple as possible.

This section is dedicated to the details of interface design. Again, this is not about the "Java interfaces" interpretation of the word, but instead is about the way the parts of the project communicate and pass data between each other. For example, the details of any specific intra-segment protocols will be in diagrams and explanatory text in this section.

In general, if a section spans more than two pages, break it into subsections and add sub-headings. Include examples as needed to clarify the details of your project. If there are terms that might be unfamiliar to the reader, begin to create a glossary which defines those terms and include it as an appendix to your SDF.

Try to write the users manual with a novice user in mind. Don't assume that the user who reads your manual will know all about software, applications, or even running the computer; things that we as programmers feel are self-evident are often totally lost on even some experienced users. For example, a description of closing a window shouldn't say "close the window", it should read more like "close the window by clicking on the 'X' in the box in the upper left-hand corner of the frame."

Entries in the project SDF table of contents should be generated for the Detailed Design document. These entries should match the section titles listed above and in the table of contents at the bottom of the Course Overview page.

Next Document