Basics of software design documentation
Filed Under Document, Design, Techniques, Process, Development | Posted on September 20, 2007
Designing software is an exercise in managing complexity. The complexity exits within the software design itself, within the software organization of the company, and within the industry as a whole. Software design is a difficult and error prone process. For many projects, software is so complex that there are plenty of different design aspects and their resulting design views. In order to deal with the complexity, software is designed in layers. When a programmer is worrying about the detailed design of one module, there are probably hundreds of other modules and thousands of other details that he can not possibly worry about at the same time. To optimize this process, we need to accept that the goal of any engineering design project is the production of some documentation. Out of these, the actual design documents are the most important.
And what is the Design Document ?
A design document is a description of a software product that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project. It usually accompanies an architecture diagram and has pointers to the detailed feature specifications of smaller pieces of the design. A design document is practically required to coordinate a large team under a single vision.
A design document needs to be stable reference, and outline all parts of the software and how they will work. The document should give a fairly complete description while maintaining a high-level view of the software.
The Design Document combines specifications, concepts, analyses, diagrams, and schematics to convey the technical and operational requirements of am IT system. The Design Document, used in conjunction with the Functional Requirements Document, provides a system specification of all user requirements. It also reflects the user’s perspective of the system design. Design documentation involves documenting designs for the various design documents.
What needs should a design document meet ?
It should be able to adequately serve as training material for new project members, imparting to them enough information and understanding about the project implementation, so that they are able to understand what is being said in design meetings, and won’t feel as if they are drowning when they are first asked to create or modify source code. It should serve as “objective evidence” that the designers and/or implementors are following through on their commitment to implement the functionality described in the requirements specification.
Top Level Breakup of the Design Document
The Software Design Document (SDD) is a comprehensive software design model consisting of four distinct but interrelated activities: data design, architectural design, interface design, and procedural design.
The SDD contains the following documents:
1. Data Design: The Data Design describes structures that reside within the software. Attributes and relationships between data objects dictate the choice of data structures.
2. Architecture Design: The Architecture Design uses information flow characteristics, and maps them into the program structure. Transformation mapping method is applied to exhibit distinct boundaries between incoming and outgoing data. The Data Flow diagrams allocate control input, processing, and output along three separate modules.
3. Interface Design: The Interface Design describes internal and external program interfaces as well as the design of human interface. Internal and external interface design are based on the information obtained from the analysis model.
4. Procedural Design: The Procedural Design describes structured programming concepts using graphical, tabular, and textual notations. These design mediums enable the designer to represent procedural detail that facilitates translation to code. This blueprint for implementation forms the basis for all subsequent software engineering work.
Leave a Reply
