Document Title:  Requirements for the project design document

Author:  Bob Matthews

Purpose:  This document provides a set of standards for the design document produced as a part of the group project in CSci 340, Fall 2003.

Change History: 

• 11/08/04 Class discussion

Important idea:  The design document is not complete until you could swap it with that of another project, and the other project team could  implement a product  from your design.

Although the projects for this class should take an object-oriented approach, there are several ways this could be done.  For that reason, the structure of this document is left fairly open with the exception of the standard first several sections which are described further on in this document.

Recall that Sommerville (page 77) divides the design process into the following phases:

• Architectural design: Identify sub-systems
• Abstract specification: Specify sub-systems
• Interface design: Describe sub-system interfaces
• Component design: Decompose sub-systems into components
• Data structure design: Design data structures to hold problem data
• Algorithm design: Design algorithms for problem functions

Please work to organize your design document as much as possible around these principles. If you can use the six bullet items above as sections (remembering to number them in your document), so much the better.

I would prefer that you take an object-oriented approach to your design.  In particular, you should probably include:

• List of objects, attributes, and services (use UML for all this).
  • Aggregation hierarchy
  • Inheritance hierarchy
  • Object relationship diagrams
  • Objects should be documented in a data dictionary which should include
  • Object specifications (attributes and operations)
  • An alphabetical list of attributes and the object(s) to which they belong
  • An alphabetical list of operations and the object(s) to which they belong.
  • See the chapter in Sommerville on object oriented design.
• Actors and use cases
  • Sequence diagrams / collaboration diagrams
  • State transition diagrams
  • Activity diagrams
  • Others as appropriate
  • Use cases should be documented in at least
  • Use case specifications (follow the outline given in the slides)
  • Use case diagrams
  • Activity diagrams

Use the standard UML for an object-oriented design..

If you have decided on an iterative development strategy the final design document will not be ready until the project is.  What I need in that case for the design document submission would be detailed iteration planning (what is to be done in each iteration, what risks will be addressed and how they will be addressed) together with the design appropriate to the first iteration.  I would then need a copy of the current design document after each iteration (recall that part of the reason for scheduled milestone documents is to keep track of progress). 

Finally, please make your documents professional. Part of your grade on the documents will depend on the appearance, organization and attention to clear writing in your documents. The following sections should appear at the start of  your document in the order given.

Document Title

Design Document for the XYZZ project

Authors

Your names here together with email addresses.

Purpose of the document

Include, in your own words, the purpose of a design document.

Change History

This should be a list of each change to the document together with the date the change was made and the reason for the change (i.e., respond to client's or reviewer's comments). The first entry should be the date on which the document was first turned in to me.

Table of Contents

I use \LaTeX for much of my writing, and would be happy to give an hour's lesson in its use. I'm sure that any word processor you use will have some provision for table of contents (though I've never learned how to do it in MS Word, I'm afraid).

Section 1: Introduction

Brief description of the problem this system solves, and how it will solve the problem. Include a discussion of the design approach adopted, and why you decided to do things this way.