Architecture/Module Specifications/Design

As has been discussed in class, you have substantial flexibility in choosing the specific form for the content of your deliverables. Below is a list of items that should be included in your third deliverable.

Due Date


Document Contents


Expand your introduction to discuss your specific approaches to the design of the system.


This will basically be the same as in your original document. Make sure it describes what steps or actions you took to understand each technology or software. If you make changes to this section, add text describing why the change was necessary, and why it more accurately reflects your new understanding. If your understanding hasn't changed, then this section does not need to be different.

Project Plan

This will be an iterative expansion of your previous submission. Expand your project plan to represent how you have accomplished the work so far. Expand your task network or work breakdown structure to the level of detail needed to complete this task. Based on the work you have done, revise your estimates on how much your team can accomplish and deliver. If you make changes, add text describing why the change was necessary or why it will improve the ability of your team to accomplish the work you have proposed.


This will basically be the same as in your previous document. If any requirements are changed, added or deleted, make this explicit. Describe why the requirement was changed/added/deleted and by whom ( customer, developer, etc.). Again make sure your requirements meet the objectives of completeness, understandbility, utility, no ambiguity, consistency. If your requirements have not changed, then this section may be identical to what you submitted earlier.

Architecture/Module Specifications

  1. Architecture Overview
    1. Architectural Style
      What style of architecture did you adopt? Provide a reference to a defining document.
    2. System Architecture Overview
      This is the place for your "one great diagram" that shows how your system is built. You might want to use more than one diagram, to show, e.g., some different abstractions of the design (such as a data flow view, a layers of abstraction view, or an OS process view)
    3. Component Narrative -- what each subsystem means
    4. Major Limitations on the Current Design
  2. Modules/Objectives
    1. List of Objects within your system
    2. For each module/object, provide a Class Specification
      1. Name
      2. Definition - what it is/does
      3. Narrative/Comment, How it works
      4. What are the object's APIs? E.g., using Java terminology
        1. public
        2. private
        3. protected
      5. Data - What state does it keep, what variables? Who has the access to it?
      6. How does it fit into the inheritance/with/uses heirarchy?
      7. Constraints - what constraints are there for this object/module?
      8. Cardinality - How many will there be?
    3. Other useful diagrams : Uses, Composed-of, API's Class-Category Diagrams, Design Class diagrams, or other useful diagrams.
    4. Design Object Scenario. Pick one object/ module and show the complete implementation detail of a key mechanism.
  3. File Structure and Global Data - how will your objects / modules be kept, sub-directories, Makefiles , etc.
  4. Requirements Cross Reference - what objects/modules satisfy what requirements? Make a table, make a table, make it complete and consistent.
  5. Testing Plan - How and when will you test it?
  6. Demonstration Plan - How and what will you demonstrate?

5. Documentation

  1. List the documents you have developed during this phase of the project.
  2. Reference Documents
    List here the major sources of information that you will be using during the remainder of the project.