Design Document

Opinion

Professional's Opinion

Another Professional's Opinion

Another Professional's Opinion

Any art assets will be created at this phase to help define what the software design will be. The art assets do not need to be finalized at this time, but close enough so that there will not be any requirments creep.

This should be based on the work stated in the concept document.

This is a comprehensive list of tasks the satisfy the requirements. Each task will have it's own section with use case diagrams and functional level of detail.

Example sections are below.

The kind of component, such as a subsystem, module, class, package, function, file, etc. ….

The specific purpose and semantic meaning of the component. This may need to refer back to the requirements specification.

The primary responsibilities and/or behavior of this component. What does this component accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components, this may need to refer back to the requirements specification.

Any relevant assumptions, limitations, or constraints for this component. This should include constraints on timing, storage, or component state, and might include rules for interacting with this component (encompassing preconditions, postconditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.)

A description of this components collaborations with other components. What other components is this entity used by? What other components does this entity use (this would include any side-effects this entity might have on other parts of the system)? This concerns the method of interaction as well as the interaction itself. Object-oriented designs should include a description of any known or anticipated subclasses, superclasses, and metaclasses.

A description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.

The set of services (resources, data, types, constants, subroutines, and exceptions) that are provided by this component. The precise definition or declaration of each such element should be present, along with comments or annotations describing the meanings of values, parameters, etc. …. For each service element described, include (or provide a reference) in its discussion a description of its important software component attributes (Classification, Definition, Responsibilities, Constraints, Composition, Uses, Resources, Processing, and Interface).

• functionName - High leve description of the function.
  • Inputs - a description fo the inputs that this function will need to preform it's operation. These are not necessarily parameters being passed into the function, they could be cless member variables.
  • Processing - Describe the algorithm that this function preforms.
  • Outputs - Describe the outputs that will happen. These are either the return values and/or the class member variables that are effected by this function.

Reference to the project managment software (dotproject). Possible house the gant chart.