<PROJECT NAME>

DESIGN DOCUMENT
Version <1.0>
<mm/dd/yyyy>

[Insert appropriate Disclaimer(s)]

 <Project Name>

Version History
[Provide information on how the development and distribution of the Design will be
controlled and tracked. Use the table below to provide the version number, the author
implementing the version, the date of the version, the name of the person approving the
version, the date that particular version was approved, and a brief description of the
reason for creating the revised version.]
Version Implemented Revision Approved Approval Description of
Number By Date By Date Change
1.0 <Author name> <mm/dd/yy> <name> <mm/dd/yy> <description of change>

Design Template (v1.0) Page 2 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

Notes to the Author

[This document is a template of a Design Specification document for a project. The template includes
instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the
project.
 Blue italicized text enclosed in square brackets ([text]) provides instructions to the document
author, or describes the intent, assumptions and context for content included in this document.
 Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced
with information specific to a particular project.
 Text and tables in black are provided as boilerplate examples of wording and formats that may be
used or modified as appropriate to a specific project. These are offered only as suggestions to
assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document
values. These angle brackets appear in both the body of the document and in headers and
footers. To customize fields in Microsoft Word (which display a gray background when selected)
select File->Properties->Summary and fill in the appropriate fields within the Summary and
Custom tabs.
After clicking OK to close the dialog box, update all fields throughout the document selecting
Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking
on it and pressing F9.
These actions must be done separately for any fields contained with the document’s Header and
Footer.
2. Modify boilerplate text as appropriate for the specific project.
3. To add any new sections to the document, ensure that the appropriate header and body text
styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and
Heading 3. Style used for boilerplate text is Body Text.
4. To update the Table of Contents, right-click on it and select “Update field” and choose the option -
“Update entire table”.
5. Before submission of the first draft of this document, delete this instruction section “Notes to the
Author” and all instructions to the author throughout the entire document.
Level of required documentation and management rigor
 Project management is the application of knowledge, skills, tools, and techniques to project
activities to meet project requirements. Project management is accomplished using project
management knowledge, skills, tools, and techniques. These can be applied with varying degrees
of rigor, depending on project demands. In order for projects to be successful, it is important for
the project team to diligently apply these with a degree of rigor that best promotes achievement of
the project's objectives. For example, the more risk, complexity, budget, etc a project has the
more project documentation and management rigor will be required to successfully manage and
document the intricacies of that project. To what level this rigor expands to beyond this basic
template, and is applied to the management of the project, should be at the discretion of the
project manager unless otherwise instructed. When in doubt as to what level of management
and/or documentation rigor to apply to a project, in almost all cases, more is better than less.]

Design Template (v1.0) Page 3 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

TABLE OF CONTENTS
Contents
1 INTRODUCTION......................................................................................................... 5
1.1 Purpose Of The Design Specification Document..........................................5
2 GENERAL OVERVIEW AND DESIGN GUIDELINES/APPROACH...........................5
2.1 Assumptions / Constraints / Standards.........................................................5
3 ARCHITECTURE DESIGN..........................................................................................5
3.1 Logical View..................................................................................................5
3.2 Hardware Architecture..................................................................................5
3.3 Software Architecture................................................................................... 5
3.4 Component Diagram.....................................................................................6
3.5 Security Architecture.....................................................................................6
3.6 Communication Architecture.........................................................................6
3.7 Performance................................................................................................. 6
4 SYSTEM DESIGN....................................................................................................... 6
4.1 Business Requirements................................................................................6
4.2 Design Method and Standards.....................................................................6
4.3 Programming Standards...............................................................................6
4.4 Class Diagram.............................................................................................. 7
4.5 Business Requirements................................................................................7
4.6 Database Design..........................................................................................7
4.6.1 Data Conversion......................................................................................7
4.7 Application Program Interfaces.....................................................................7
4.8 User Interface Design...................................................................................7
4.8.1 UI Design Overview.................................................................................7
4.8.2 Navigational Flow.....................................................................................7
4.8.3 Function / Screen Usage Diagrams.........................................................7
4.9 System Performance....................................................................................7

Design Template (v1.0) Page 4 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

1 INTRODUCTION
1.1 Purpose Of The DESIGN SPECIFICATION Document
[Provide the purpose of the Design Specification Document. This document should
be tailored to fit a particular project’s needs.]
The Design Specification document documents and tracks the necessary
information required to effectively define architecture and system design in order
to give the development team guidance on architecture of the system to be
developed. Design documents are incrementally and iteratively produced during
the system development life cycle, based on the particular circumstances of the IT
project and the system development methodology used for developing the system.
These documents are initially created during the Planning Phase of the project and
updated as necessary throughout the design process. The preliminary versions of
these documents are reviewed during the EPLC Stage Gate Preliminary Design
Review; the final versions are input to the EPLC project Detailed Design Review.
Its intended audience is the project manager, project team, and development
team. Some portions of this document such as the user interface (UI) may on
occasion be shared with the client/user, and other stakeholder whose
input/approval into the UI is needed.

2 GENERAL OVERVIEW AND DESIGN GUIDELINES/APPROACH

This section describes the principles and strategies to be used as guidelines when
designing and implementing the system.
2.1 Assumptions / Constraints / Standards
[Describe any general design assumptions / constraints / standards related to any
of the project’s design]

3 ARCHITECTURE DESIGN
This section outlines the system and hardware architecture design of the system
that is being built.
[Describe the system architecture, how the application interacts with other
applications. Not necessarily how the application itself works but, how the
appropriate data is correctly passed between applications.]
3.1 Logical View
[Insert any related logical views or provide a reference to where they are stored.]
3.2 Hardware Architecture
[Insert any related hardware architecture documents or provide a reference to
where they are stored.]
3.3 Software Architecture
[Insert any software architecture documents or provide a reference to where they
are stored.]

Design Template (v1.0) Page 5 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

3.4 Component Diagram

[Insert the Component diagram on the project.]
3.5 Security Architecture
[Insert any related security architecture documents, including integrity controls, or
provide a reference to where they are stored.]
3.6 Communication Architecture
[Insert any related communication architecture documents or provide a reference
to where they are stored.]
3.7 Performance
[Insert any performance documents or provide a reference to where they are
stored.]

4 SYSTEM DESIGN
[This and the following section should provide sufficient information for a developer
to produce the system. The detailed content will depend upon the approach to the
design process that is to be used.
According to one source there are over 30 different object design methodologies
and notations of which UML is perhaps the best known.
If the project is to follow the traditional waterfall approach, its documentation will
differ from a development approach based on RAD or DSDM. Moreover, an OOD
based philosophy for the design using UML would be different from one based on
another design methodology such as SSADM or Yourdon. Depending upon the
approach to be taken the software may be produced using coding statements or it
may be automatically generated by an application development tool or a mixture of
both]
4.1 Business Requirements
[Insert any related project business requirements or provide a reference to where
they are stored.]
4.2 Design Method and Standards
[The design method used should be named and referenced. A brief description
may be added to aid readers not familiar with the method. Any deviations and
extensions of the method should be explained and justified.]
4.3 Programming Standards
[ Insert the project programming standards Whatever languages or standards are
chosen, the aim should be to create a convenient and easily usable method for
writing good-quality software. If an application development tool is used there may
be other conventions that need to be defined, e.g. color schemes.
When programming in any new language, a standard for its use should be written
to provide guidance for programmers. This standard may be referenced or
included here.]

Design Template (v1.0) Page 6 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

4.4 Class Diagram

[Insert the Class diagram on the project.]
4.5 Business Requirements
[Insert any related project business requirements or provide a reference to where
they are stored.]
4.6 Database Design
[Insert any documents describing any necessary database design guidelines or
provide a reference to where they are stored.]
4.6.1 Data Conversion
[Insert any documents describing any necessary data conversions or provide a
reference to where they are stored.]
4.7 Application Program Interfaces
[Insert any application program interface documents or provide a reference to
where they are stored.]
4.8 USER INTERFACE DESIGN
[Insert any user interface design documents or provide a reference to where they
are stored.]
4.8.1 UI Design Overview
[Insert mockups and screen layouts.]
4.8.2 Navigational Flow
[Insert any Navigational diagram.]
4.8.3 Function / Screen Usage Diagrams
4.8.3.1 Use Cases Diagrams
[Insert any Use Cases diagrams.]
4.8.3.2 Activity Diagrams
[Insert any Activity diagrams.]
4.8.3.3 Sequence Diagrams
[Insert any Sequence diagrams.]
4.9 System Performance
[Insert any system performance documents or provide a reference to where they
are stored.]

Design Template (v1.0) Page 7 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

Appendix A: Design Specification Approval

The undersigned acknowledge that they have reviewed the <Project Name>
Design Specification and agree with the information presented within this
document. Changes to this Design Specification will be coordinated with, and
approved by, the undersigned, or their designated representatives.
[List the individuals whose signatures are desired. Examples of such individuals
are Business Owner, Project Manager (if identified), and any appropriate
stakeholders. Add additional lines for signature as necessary.]

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Design Template (v1.0) Page 8 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX B: REFERENCES
[Insert the name, version number, description, and physical location of any
documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Name Description Location
<Document Name and <Document description> <URL or Network path where document
Version Number> is located>

Design Template (v1.0) Page 9 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms
relevant to the content presented within this document.
Term Definition
[Insert Term] <Provide definition of term and acronyms used in this document.>

Design Template (v1.0) Page 10 of 10

[Insert appropriate disclaimer(s)]