Software Design Specification Templates
[Project ]
SoftwareDesign Specification
CxTemp_SoftwareDesignSpecification.doc
Draft X
May 13, 2011
[ Organization Name ]
[ Paste Your Organization’s Logo Here ]
Revisions
| Version | Primary Author(s) | Description of Version | Date Completed |
| Draft Type and Number | Full Name | Information about the revision. This table does not need to be filled in whenever a document is touched, only when the version is being upgraded. CxPattern_RevisionHistory provides details on CxOne’s recommended way to handle document revisions. | 00/00/00 |
The paragraphs written in the “Comment” style are for the benefit ofthe person writing the document and should be removed before the document isfinalized.
This template serves as a basis for a Software DesignSpecification.
Designs for software systems should be customized to the needsproject building the system. This template is only a starting point; mostprojects should not constrain their system design to a single document. Wedo so here for convenience, to show in one place a broad but shallow stroke ofthe type of design information the projects should capture.
Thus although it isorganized such that it can be a single stand-alone document, the material inthis template is intended to be repackaged into multiple documents,reorganized, and augmented for the needs of each project.
A formulaic approach to design will seldom yield the best results.This template does not imply that a single document should contain all designinformation or that the approach and structure for a design described here isthe best for any given situation. Instead this template provides a basicstarting point that will work well in many situations.
See CxGuide_SoftwareDesignSpecification for a detaileddescription of how to utilize this template. The CxOne design checklistsprovide supporting information about what software designs should cover andwhat improves the quality of designs.
See CxGuide_CxOneArtifact for details on how to utilize theadvanced features of CxOne artifact templates.
Contents
1.4Definitions and Acronyms. 1
2.5 Risksand Volatile Areas. 2
3.2Subsystem, Component, or Module 1..n. 3
4.1 View /Model Element 1..n. 4
1 Introduction
This space may be used to provide an introduction for thedesign and ties to other project materials.
1.1 System Overview
Brief high-level description of system structure,functionality, interactions with external systems, system issues, etc.
1.2 Design Map
Summarize theinformation contained within this document or the family of design artifacts.Define all major design artifacts and/or major sections of this document and ifappropriate, provide a brief summary of each. Discuss any significantrelationships between design artifacts and other project artifacts.
1.3 Supporting Materials
(Optional) – Note any references or related materials here.CxOne materials are normally referenced in-line.
1.4 Definitions and Acronyms
(Optional) – List any project definitions and acronymsintroduced to the project by this design. Do not repeat items covered in theCxOne definitions and acronyms document or in a global project definitions andacronyms document.
2 Design Considerations
This section describes issues that need to be addressed orresolved prior to or while completing the design as well as issues that mayinfluence the design process.
2.1 Assumptions
Describe any assumption, background, or dependencies of thesoftware, its use, the operational environment, or significant project issues.
2.2 Constraints
Describe any constraints on the system that have a significantimpact on the design of the system. (e.g. technology constraints, performancerequirements, end user characteristics, validation requirements, projectconstraints, etc.)
2.3 System Environment
Describe the hardware and software that the system mustoperate in and interact with.
2.4 Design Methodology
(Optional) -Summarize the approach that will be used to create and evolve the designs forthis system. Cover any processes, conventions, policies, techniques or other issueswhich will guide design work.
2.5 Risks and Volatile Areas
(Optional) - Describe any notably volatile or risky areas ofthe system and not any special strategies taken to mitigate risks or preparefor changes.
3 Architecture
The architectureprovides the top level design view of a system and provides a basis for moredetailed design work. Normally the architecture will be split out into a moredetailed stand-alone document, as described in CxTemp_Architecture and CxGuide_Architecture.
Relevant CxOneMaterials: CxCheck_Architecture, CxCheck_Design
3.1 Overview
This section provides a high level overviewof the structural and functional decomposition of the system. Focus on how andwhy the system was decomposed in a particular way rather than on details of theparticular components. Include information on the major responsibilities androles the system (or portions thereof) must play.
3.2 Subsystem, Component, orModule 1..n
Describe an element(subsystem, component, module, etc.) from architecture in further detail. Whenappropriate, include information on how the element is further broken down andthe interactions and relationships between these subcomponents.
3.2.1 Sub Element 1..n
If appropriate,describe a sub element in further detail.
3.3 Strategies
This sectiondescribes the design strategies or decisions that impact the overallorganization of the system. Includes information about key abstractions,methods, mechanisms, etc. which are used in the system architecture. Errorhandling strategies are a common example.
3.3.1 Strategy 1..n
Describe the strategyused or decision made. Include information on the alternatives considered andthe reasons for their rejection.
4 High Level Design
This sectiondescribes in further detail elements discussed in the Architecture. Normallythis section would be split into separate documents for different areas of thedesign.
High-level designsare most effective if they attempt to model groups of system elements from anumber of different views.
Relevant CxOneMaterials: CxCheck_HighLevelDesign, CxCheck_Design
4.1 View / Model Element 1..n
Provide a descriptionand diagrams of a system element or set of elements that describes a clearlydefined view or model of the entire system or a subset of the system.
5 Low Level Design
This section provides low-level design descriptions thatdirectly support construction of modules. Normally this section would be splitinto separate documents for different areas of the design.
Relevant CxOne Materials: CxCheck_LowLevelDesign,CxCheck_Design
5.1 Module 1..n
Provide or reference a detailed description and diagrams ofthis software module.
6 User Interface Design
This section provides user interface design descriptions thatdirectly support construction of user interface screens.
Relevant CxOne Materials: CxCheck_UserInterfaceDesign,CxCheck_Design
6.1 ApplicationControl
Detail the common behavior that all screens will have. Common look and feel details such as menus,popup menus, toolbars, status bar, title bars, drag and drop mouse behaviorshould be described here.
6.2 Screen1..n
Illustrate all major user interface screens and describe thebehavior and state changes that the user will experience.
A screen transition diagram or table can optionally be createdto illustrate the flow of control through the various screens.