| Next revision | Previous revision |
| design:gen_proc:design_doc [2010/04/05 15:03] – created jeff | design:gen_proc:design_doc [2020/11/19 14:21] (current) – external edit 127.0.0.1 |
|---|
| |
| ====== Design Document ====== | ====== Design Document ====== |
| | [[http://www.cmcrossroads.com/bradapp/docs/sdd.html|Opinion]] |
| | |
| [[http://gamasutra.com/features/20070220/bateman_01.shtml|Professional's Opinion]] | [[http://gamasutra.com/features/20070220/bateman_01.shtml|Professional's Opinion]] |
| |
| |
| [[http://www.ca3d-engine.de/wiki/modding:create_a_game_design_document|Another Professional's Opinion]] | [[http://www.ca3d-engine.de/wiki/modding:create_a_game_design_document|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. |
| |
| ===== Overview ===== | ===== Overview ===== |
| Example sections are below. | Example sections are below. |
| |
| ==== Component ==== | ==== Component Name ==== |
| A detailed definition of a component. Think of a component as a single aspect of the overall system. The description of a component will go from the high level of the user interface down to the functions that it implements. | |
| | === Classification === |
| | |
| | The kind of component, such as a subsystem, module, class, package, function, file, etc. .... |
| | |
| | === Definition === |
| | |
| | The specific purpose and semantic meaning of the component. This may need to refer back to the requirements specification. |
| | |
| | === Responsibilities === |
| | |
| | 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. |
| | |
| | === Constraints === |
| | |
| | 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.) |
| | |
| | === Uses/Interactions === |
| | |
| | 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. |
| | |
| | === Resources === |
| | |
| | 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. |
| | |
| | === Interface/Exports === |
| |
| === Data Structures === | 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). |
| This is a strick definition of the data structures used throughout the system. | |
| |
| === User Interface === | * functionName - High leve description of the function. |
| This is a description of how the user will interact with the software. There should be some comps showing what the UI would look like. If this is a headless component, document the exposted functionality. For example is it commandline and what are the arguments, or is it a library and what are the functions. This section will also contain the use case diagrams. | * 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. |
| |
| ===== Task Schedule ===== | ===== Task Schedule ===== |
