The Art Of Software Development (part 2): Designing For Simplicity - Drawing Class
(Page 4 of 7 )

Typically, a software design document contains the following sections,each of which is designed to address different components of thesoftwarearchitecture:

1. Introduction: This section provides an introduction to the softwarebeing developed, together with background, scope, definitions andreferences.
2. Application overview: This discusses the application to be developedin general, together with a broad description of software concepts andfunctions.
3. Constraints, considerations and goals: This section describes theconstraints and guidelines to be kept in mind when designing theapplication. It includes details about the hardware and softwareavailable, the development and execution environment, user profiles,performance and security considerations, data storage and formatconstraints, together with a list of important rules to be kept in mindwhile designing the software (and the basis of each).
4. Design strategy: This section provides information on the programmingparadigms used when designing the software. It includes information onthe IDE or programming language used, the techniques used for datastorage, interprocess communication, flow control, exception handling,resource management, garbage collection and traffic management.
5. System architecture: This contains high-level architectural diagramsof the system design, together with descriptions of the components usedand their relationships via a modeling language. A description of thevarious modules that make up the system is also included.
6. Component architecture: Each of the modules that makes up the systemneeds to be described in greater detail. This section may therefore befurther split into sub-sections, each one containing a detaileddescription of the internals of the various modules that make up theoverall system. These details include information on the purpose of eachcomponent, its functions, its data input and output formats, its inputand output interfaces, its internal business logic, and its interactionwith other components. You can include pseudo-code wherever needed toensure that the details are clearly communicated.

This document serves as the basis for the developer or developmentteam's efforts, and should be reviewed at least once to identify andcorrect design flaws, if any exist, before beginning work.

Next: All Used Up >>
 

More Practices Articles
More By Vikram Vaswani, (c) Melonfire

Comments On: The Art Of Software Development (part 2): Designing For Simplicity

>>> Be the FIRST to comment on this article!