CS130 Project, Part 3

(updated 10/20/2003)

Design Document

Due Tuesday, October 28, 2003

Introduction

For this portion of the project, you will assemble an architectural design document that fully satisfies the revised and approved requirements from Part 1 of your project.  This deliverable will consist of two primary components: a design specification (consisting of a high-level architectural design and module specifications) and an integration test plan.  The design should describe all system level objects/tasks, operations, the relationships between those objects/tasks, and external interaction with the environment as well as object class specifications that further detail the object design.  The integration test plan must cover all interactions between modules/objects by applying functional test heuristics (black box) to each module/class interface in the design specification and developing a test plan for each interaction between modules and/or objects.

Your document must specify the correspondence between the requirements specification and your design. You may show this correspondence any way you feel is appropriate (e.g., make notations throughout your document or using a table that cross-references paragraph numbers).

Developing the software design will undoubtedly reveal inadequacies in previous documents. Please note these problems and what was done to solve them.

Keep in mind that key objectives of a design document are to: In addition, keep in mind that a design document should exhibit the following qualities: Document Contents

1. Table of contents

2. Introduction
Provides a brief overview of the system from the perspective of the system architect.

3. Architecture
Explains the main architectural style used by the system and why this style was shosen
Presents the high-level architecture and what each subsystem means or does
Discusses the rationale for the architecture

4. Component Design
Describes each component in your design; as needed, subdivide components.  Each module of the system must be described in this section.  Four aspects of each module should be described:
1. Purpose of the module:  Specify which part of the requirements document it addresses.
2. Constraints on the modules (as needed): Describe performance or platform constraints when relevant.
3. Provided interface (i.e., public methods that a given module will provide to others): Define the interface by listing all its methods with descriptive names.  The definition includes the names of the methods, their parameters, and their return types.  Provide a short commentary describing each of the methods (i.e., what it does).
4. Required interface (i.e., public methods from other modules that this module will be calling): Define the required interface by listing all its modules/methods.  Note that every one of the modules/methods listed should be described elsewhere in this document, either as part of the design which you are creating or else as an externally provided service.  Similarly, note that the details of those modules/methods are associated with their appearance elsewhere in the document (i.e., under the module to which they belong).

5. Integration Test Plan
Includes an integration test plan capable of demonstrating that the design meets the functionality specified in the requirements. Test cases should cover each module/object and module/object interaction specified in the design. You should consider each module/object as a subsystem and apply functional (black box) test heuristics (such as input/output coverage and error/exception coverage) to the parameters identified in each operation in the interface. In addition, you should develop a test case for each module/object interaction.

6. Tracking and Control Mechanisms
Configuration Management: how will your modules/objects be managed?

Requirements Cross Reference: what modules/objects satisfy what requirements?


7. Modifications to Prior Documents
If any requirements changed, were added or deleted, this is the place to make this explicit. Highlight why the requirement was changed/added/deleted and by whom (customer, developer, etc.). Make sure your requirements meet the objectives of completeness, understandability, utility, unambiguity, and consistency. If your requirements have not changed, then this section should be identical to what you submitted earlier.

8. Glossary
Defines any terms used in the specifications above. This portion of the document may be written as an extension to the glossary submitted with the requirements, or may be a distinct set that only defines terms local to the design phase.

9. Additional Information
This section is reserved for any additional documentation developed during this phase of the project. Specifically, if during the course of developing the architecture your understanding of the various technologies involved in the project changed, or you discovered items that were not documented but which are important, include that information here.

Also list here the major background sources that you used during this phase or any that you plan to use during the remainder of the project. This includes references to similar systems and/or procedures.



Acknowledgement:
  The project assignments are extensively based on those of Professor Richard Taylor at UCI.