System Design Document Template

Version 1.0

Approved By:
____________________________ ___________________________

Program Manager Quality Assurance

System Design Document Template V1.0 July 25, 2010

REVISION HISTORY
Revision Version Description of Change Changed By Effective
Date
1 1.0 Template LCS, LLC
2
3

Note: Some areas of this template suggest including the requirement ID with the design
element. This could create additional work in updating the design document if there are
subsequent requirements changes. If you are using an automated requirements
repository, it is better to include only the design element ID in the document. The
requirement can be located using traceability from the design element to the requirement
if the repository is well-maintained. The compliance matrix can be printed with
requirement and design IDs as well as the requirements text to assist the reader.

There may be more sections in this template than desired in your SDD. Some may be
removed, changed, or merged depending on your system or organizational requirements.

Ludwig Consulting Services, LLC

System Design Document Template V1.0 July 25, 2010

TABLE OF CONTENTS
1 INTRODUCTION.......................................................................................................6
1.1 Overview..................................................................................................................6
1.2 Scope........................................................................................................................6
1.3 Background..............................................................................................................6
1.4 References................................................................................................................6
1.5 Assumptions and Constraints..................................................................................6
1.6 Document Overview................................................................................................7
2 METHODOLOGY......................................................................................................7
2.1 System Design Framework......................................................................................7
2.2 System Design Alternatives.....................................................................................8
2.3 Risks........................................................................................................................8
2.4 Updated Requirements Compliance Matrix............................................................8
3 ROLES AND RESPONSIBILITIES MATRIX..........................................................8
4 SYSTEM DESCRIPTION...........................................................................................8
4.1 System Software Architecture.................................................................................8
4.2 System Technical Architecture................................................................................9
4.3 System Hardware Architecture................................................................................9
4.4 External Interfaces...................................................................................................9
5 SUBSYSTEM SPECIFICATIONS...........................................................................10
5.1 Subsystems............................................................................................................10
6 TECHNICAL SPECIFICATIONS............................................................................13
6.1 Module...................................................................................................................13
7 DATA ARCHITECTURE.........................................................................................13
7.1 Database and File Architecture..............................................................................13
7.2 Data Dictionary......................................................................................................14
7.3 Data Conversion....................................................................................................14
8 SECURITY................................................................................................................15
8.1 User Level Permissions.........................................................................................15
8.2 Control Points........................................................................................................15
8.3 Vulnerabilities........................................................................................................15
9 OPERATIONAL CONSIDERATIONS....................................................................15
9.1 Audit Trail.............................................................................................................15
System Design Document Template V1.0 July 25, 2010

9.2 Recoverability........................................................................................................16
9.3 Failure Contingencies............................................................................................16
9.4 System Availability...............................................................................................16
9.5 Capacity.................................................................................................................16
9.6 Performance and Timing.......................................................................................16
9.7 Data Retention.......................................................................................................17
9.8 Error Handling.......................................................................................................17
9.9 Validation Rules....................................................................................................17
9.10 Conventions/Standards..........................................................................................17
9.11 Adaptability...........................................................................................................17
APPENDIX A - ACRONYM LIST..................................................................................18
APPENDIX B – GLOSSARY...........................................................................................19
APPENDIX C – REQUIREMENTS COMPLIANCE MATRIX.....................................20
System Design Document Template V1.0 July 25, 2010

List of Exhibits

Exhibit 3: Sample Subsystem Diagram.............................................................................10

Exhibit 4: Sample Module Diagram..................................................................................11
Exhibit 5: Sample Sub Module Diagram...........................................................................11
Exhibit 6: Sample Sub Module Diagram with Web Page Template.................................12
Exhibit 7: Sample User Interface Page..............................................................................12
Exhibit 8: Data Element Matrix.........................................................................................12
System Design Document Template V1.0 July 25, 2010

1 INTRODUCTION
Provide a high-level overview of the system and include additional information that may
be appropriate. The SDD is the system development blueprint that describes the system
in detail. The details of the SDD are developed to the requirements and show traceability
back to those requirements.

1.1 Overview
Describe briefly the structure of the document. Describe the system to be implemented.
Since the SDD is a statement of how the system will perform, the SDD commits
developers to the design.

1.1 Scope
Discuss what the document does and does not address.

1.2 Background
Discuss the organization for which the system is being developed, including its major
responsibilities. Provide additional information to give the reader some context for the
system, for example the capabilities gap the new or revised system will overcome or the
strategic goals the system is intended to fulfill.

1.3 References
List key documents that support the SDD. Include meeting summaries, white paper
analyses, standards, and related deliverables, as well as preceding documentation that
provides information for its development. Keep it brief, details or a long list can go in an
appendix. Pointing to documents that are frequently updated rather than including the
information here (such as the risk register) will ensure this document remains current.

1.2 Assumptions and Constraints

Contractual or task level assumptions and/or constraints that are preconditions to
preparation of the design should be spelled out here.

1.2.1 Assumptions
State assumptions associated with the system development. Assumptions are future
situations beyond the control of the project, whose outcomes influence the success of a
project.

1.3.1 Constraints
State constraints associated with development of the system. Constraints are conditions
outside the control of the project that limit design alternatives. Constraints exist because
of real business conditions. For example, a delivery date is a constraint if there are real
consequences that will happen as a result of not meeting the date. Preferences are
arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if included
in the SDD, should be noted as such. Constraints can be broadly categorized as technical
and non-technical. The following are examples of both types of constraints:
System Design Document Template V1.0 July 25, 2010

1. Government regulations
2. Technical standards imposed on the solution (for example, specific technology
required by the enterprise architecture)
3. Strategic decisions

1.4 Document Overview

Provide a guide to the document organization, the sections and their titles.

2 METHODOLOGY
Describe the approach used to develop the components of the SDD. If a particular
methodology was followed, name it. This section is often omitted from an SDD.

2.1 System Design Framework

The design effort transforms the detailed, defined requirements into complete, detailed
specifications that direct development and testing. Design decisions detail how the
system will meet the defined functional, physical, interface, security, and data
requirements. At the end of the design process the design is baselined.
The general system characteristics are defined during design. The operating system is
established and the automated system packaged into major design subsystems. Inputs
and outputs of each subsystem are defined, interfaces to external systems are designed,
and administrative activities are established. Security and auditing needs are also
addressed.
A more detailed structure of the system is then created based on the subsystems identified
by the general characteristics. Each subsystem is partitioned into one or more design
units, or modules. The process is described in a structure chart, flowchart, action diagram,
pseudo code, or other acceptable format for each design unit, or module. Detailed logic
specifications are written for each module described and data usage is physically defined
to the elemental level. Functions requiring user input and approval are completed in this
activity.
Throughout the design phase there are a series of check point and review processes. The
design is reviewed to verify that it has the following characteristics:
1. Is directly traceable to the requirements.
2. Describes how the capabilities defined by the requirements will be implemented.
3. Describes design considerations such as computer hardware, operating system,
and database design.
The SDD includes:
1. User, human/computer interface design
2. System architecture
3. Detailed system design
4. Data base design including a physical data model and data dictionary
System Design Document Template V1.0 July 25, 2010

5. External interface design

1.5 System Design Alternatives

Discuss viable design alternatives that were considered. If the status quo (current system,
no changes) is not viable, state why. This is a concise, high level discussion that points
out the major viable alternatives that were discussed during the design process. Discuss
the risks and benefits of each, including the assessment of the design review of each
alternative achieving the goals discussed in the background.

1.6 Risks
Discuss risks in the design of the system that affect future work and the contingency
plans if the risk occurs. Risks should be in the risk register, and this document included
in the reference list.

1.7 Updated Requirements Compliance Matrix

Functional requirements are baselined after the approval of the Functional Requirements
Document (FRD). If requirements must be changed (which can occur at any time during
the system life cycle), they must go through the configuration management process.
After approval of the change, a minor baseline is created (this is the modified baseline,
for example, from version 1.0 to 1.1).
The compliance matrix is updated to add the SDD elements. After the design is
approved, it is baselined and any changes to it must also go through the configuration
management process. The compliance matrix, updated with design elements, would be
attached to the SDD for review and its version identified. As there are possible changes
after SDD approval, the reference document section should state the location of the
requirements repository (if there is one) so that future system developers can locate the
current version. Ideally, the SDD will be updated to reflect changes.

3 ROLES AND RESPONSIBILITIES MATRIX

The roles and responsibilities of the team are sometimes included in the SDD.

4 SYSTEM DESCRIPTION
Describe the system in narrative form using non-technical terms.

4.1 System Software Architecture

Provide an overview of system software architecture and organization and a high-level
diagram illustrating the subsystems and show interfaces to external systems and
relationships between the system and user organizations.

4.2 System Technical Architecture

Describe and diagram the technical platform(s) that will be used to build the. If different
subsystems use different technical platforms, describe each platform and relate it to the
appropriate subsystem.
System Design Document Template V1.0 July 25, 2010

4.3 System Hardware Architecture

Describe the overall system hardware/communications and its organization. Include a list
of hardware components, a brief description of each item, and diagrams showing
connectivity.
Provide a description of the equipment required to operate the system. Include
descriptions of the equipment presently available, as well as a more detailed description
of the characteristics and impact of new equipment necessary for system operation. If the
equipment documentation is extensive, put the information in an appendix or referenced
as a separate document. Add diagrams and information to describe each component and
its functions. Follow industry-standard component specification practices. Include the
following information in the detailed equipment component designs:
A. Memory and/or storage space requirements
B. Processor requirements (speed and functionality)
C. Graphical representation depicting the number of hardware items (for example,
monitors, printers, servers, input/output devices), and the relative positioning of the
components to each other

4.4 External Interfaces

Describe interfaces with other application software units, including those of other
operational capabilities internal and external. For each interface, specify the following
information:
A. Name of application
B. Owner of application, if external
C. Details of interface
D. Type of interface, such as interfaces to other software units
E. Description of operational implications of data transfer, including security
considerations
F. Data transfer requirements to and from the software unit, including data content,
format, and sequence
G. Formats of data for both the sending and receiving systems, including the data item
names, codes, or abbreviations that are to be interchanged
H. Interface procedures
I. Interface equipment
J. Data conversion requirements

5 SUBSYSTEM SPECIFICATIONS
List and describe subsystems to establish a reference within the document. For web based
systems, different web pages can be categorized as a subsystem. Provide a diagram, such
as a hierarchical structure chart, that depicts the flow and mapping of the entire system.
System Design Document Template V1.0 July 25, 2010

Include graphics of relationships of user organizations to major system components. To

aid in identifying the set of requirements represented by those diagrams, it is
recommended that the requirement number(s) be provided.

5.1 Subsystems

5.1.1 Subsystem Description #1

Provide a description of the subsystem and present the logical flow of the subsystem
through the use of charts and diagrams such as structure charts, information architecture
diagrams, interaction design diagrams, and wireframes. When feasible, the charts and
diagrams should include a reference to their high level requirement(s). The charts and
diagrams must provide an integrated presentation of the subsystem dynamics, entrances
and exits, and interfaces with other software units. Supplement the representation with a
program design language presentation, a narrative presentation, or a combination of the
two.

Exhibit 3: Sample Subsystem Diagram

Subsystem 1
Req 1.1

Module 1 Module 2 Module 3 Module 4

Req 1.1.1 Req 1.1.2 Req 1.1.3 Req 1.1.4

5.1.2 Master List of Modules

List modules in the subsystem and provide a brief description of each module. If there
are no modules within the subsystem, this section may be omitted.

5.1.3 Modules
Repeat module sections and subsections as needed to describe the system.

5.1.3.1 Module Description

Provide a description for each module within the subsystem and explain its function. Use
a chart or diagram to show the breakdown of any sub modules that exist within the
module. If possible, provide the number for the requirement the module represents.
System Design Document Template V1.0 July 25, 2010

Exhibit 4: Sample Module Diagram

Module 1
Req 1.1.1

Sub-Module Sub-Module Sub-Module Sub-Module

1 2 3 4
Req 1.1.1.1 Req 1.1.1.2 Req 1.1.1.3 Req 1.1.1.4

5.1.3.2 Master List of Sub-Modules

Provide a diagram or narrative list of all sub-modules for each module. If the module
includes user interfaces (i.e., web pages), provide the interaction architecture (IA)
diagram or an interaction design diagram showing the navigation or flow of screens (sub-
modules) within the module and if applicable, the requirement numbers they represent.

Exhibit 5: Sample Sub Module Diagram

Review/
Select Display
Option 1 Information Confirm
Parameter Opt 1
1

Sub Module Return to

Selection Enter
Req 1.1.1.3 Display Certify Sub Module
Updated Req 1.1.1.3
Summary
Information

Review/
Display Confirm
Select
Information Opt 2
Option 2
Parameter
2

Popups Attchmnts
System Design Document Template V1.0 July 25, 2010

Exhibit 6: Sample Sub Module Diagram with Web Page Template

5.1.3.3 Sub-Module

5.1.3.3.1 Sub-Module Description

Provide a brief description of the sub-module. Repeat this section for multiple sub-
modules.

5.1.3.3.2 User Interface

Provide the detailed design of the user interface of a sub-module (e.g., screen/page design
or report) and if possible, the requirement number that the interface represents. For each
field or label on the screen or report, define all data elements using the following table
format.

Exhibit 7: Sample User Interface Page

Include a screen print of the user interface.

Exhibit 8: Data Element Matrix

Label Table Data Element Edits/Comments

Name Name

For screens, describe surface edits for data entry fields (e.g., Required, Must be ‘1’ or ‘2’,
etc.). For screens and reports, include comments such as “Derived”, “Display Only”, etc.
System Design Document Template V1.0 July 25, 2010

5.1.3.3.3 Sub-Module Logic

Describe the logic of each software unit or module in the subsystem in narrative. This
section is intended for end-users to understand. Do not use technical terms or reference
software objects (e.g., stored procedures, Java beans, servlets, etc.

6 TECHNICAL SPECIFICATIONS
The intended audience of this section is the developer. Provide detailed technical design
specifications that permit the developer to code. The section will be organized by sub-
module within its parent module. The detailed design specifications are provided in each
component section for each component of a sub-module. Provide the detailed design of
shared, common sub-modules in a “Module “1 – N”” section labeled “Common Sub-
Modules”. NOTE: The format of this section is flexible since it is dependent upon the
technical platform environment, tool(s) used for the technical design, and the
methodology. Use outputs from tools where appropriate.

6.1 Module

Provide a brief description of the module. Repeat section and sub-sections as needed. A
more detailed description will be provided in Section 5.1.3.1. The purpose of the section
is mainly to provide a framework to logically describe and list the sub-modules.

6.1.1 Sub-Module
Provide a technical overview of the sub-module using a narrative description
accompanied by a diagram showing the relationships between all components within the
sub-module.

6.1.1.1 Component

Provide a technical description of the component. Repeat this section as needed. Items
included in the description are dependent upon the type of component (e.g., stored
procedure, template, etc.). For all component types, provide the name, type, definition,
location, constraints, and logic (either narrative or pseudo code). Include items such as
input parameters, output parameters/result sets, and tables/files accessed as appropriate.

7 DATA ARCHITECTURE

7.1 Database and File Architecture

Describe the final design of the system database management system (DBMS) and the
non-DBMS files. This can be included as an appendix.

7.1.1 Database Management System Architecture

Describe the final design of the database and include the following information (refer to
the data dictionary):
System Design Document Template V1.0 July 25, 2010

A. The physical data model including normalized table layouts and an entity relationship
diagram (ERD).
B. A description of the DBMS schemas, sub-schemas, records, sets, tables storage page
sizes, etc.
C. Describe database connectivity method (e.g., ODBC).
D. Estimate of the database size or volume of data within the file and data pages,
including overhead resulting from access methods and free space.
E. Definition of the update frequency of the database tables, views, files, areas, records,
sets, and data pages. Estimate the number of database transactions.
F. Describe how permissions will be accommodated (e.g., user groups).
G. List and reference the documentation of the DBMS utility software available to
support the use or maintenance of the database.

7.1.2 Non-Database Management System Files

Provide a detailed description of non-DBMS files and include a narrative description of
the usage of each file, include if the file is used for input, output, or both. If this file is a
temporary file, an indication of which modules read and write the file, etc., and file
structures (refer to the data dictionary).
A. The file structure should:
1. Identify record structures, record keys or indexes, and reference data elements
within the records.
2. Define record length (fixed or maximum variable length).
3. Estimate the file size or volume of data within the file including overhead
resulting from file access methods.
4. Define the update frequency of the file. If the file is part of an online transaction-
based system, provide the estimated number of transactions per unit time, and the
statistical mean, mode, and distribution of those transactions.

7.2 Data Dictionary

Provide a comprehensive data dictionary detailing data element name, type, length,
source, validation rules, maintenance (i.e., create, read, update, and delete capability),
data stores, outputs, aliases, null/not null status, and description. This can be included as
an appendix.

7.3 Data Conversion

Describe the data conversion process from the old to the new system. If there is a
separate Data Conversion Plan, provide a brief description of the data conversion
approach in this document and refer to the Data Conversion Plan.
System Design Document Template V1.0 July 25, 2010

8 SECURITY
Security is often an ignored area of a system, being added on rather than built in. In
today’s environment, security must be addressed early in the system life cycle. Describe
the use and management of integrity and access controls that apply to the physical
components such as schema, sub-schema, partitions or physical files, records or tables,
sets or relations, and data elements. Provide the security standard the system must meet,
e.g., NIST or other standard or point to the security requirements ID numbers based on
these standards.

8.1 User Level Permissions

Identify user roles and permissions. Describe use of permissions for that particular
module, including the user levels that are available, and the authority that grants those
permissions. Discuss differences between internal and external use of the module if
applicable. List the data that is classified as private and unavailable to the public user.

8.2 Control Points

Identify the control points in the system. A control point is an application or a physical
device that regulates which users have access to specific information and resources. A
firewall is an excellent example of a control point. Additionally, show the relationship of
security control points to each other in the system. For example, a proxy or web server
may communicate to another server (domain controller) to validate the authentication of
users accessing web content on a third server.

8.3 Vulnerabilities
Describe potential vulnerabilities that exist in the system. Vulnerability is a design,
implementation, or operational condition inherent in the application or system that causes
error, loss, or compromise of information or denial of service. Vulnerability may include,
but not limited to dialup access, file uploads/downloads, logon screens or public web
sites.

9 OPERATIONAL CONSIDERATIONS
Provide design-related information for operational considerations of the system. If the
operational considerations have already been provided or addressed in another section or
separate document, give a reference to that section or document rather than replicate the
information.

9.1 Audit Trail

Describe audit trails to be built into the system. Audit trails enable the system to track
and maintain a history of certain actions or behaviors by the users. This includes tracking
mechanisms built into the system, including logs that keep track of submissions made by
the users, changes or edits made by the user and any errors generated by the system.
System Design Document Template V1.0 July 25, 2010

9.2 Recoverability
Describe the system recovery design, for example, database mirroring, switchover,
automatic system re-boot, graceful shutdown/start up, etc. Do not include recovery
process steps performed manually by operators or system administrators

9.3 Failure Contingencies

Discuss alternative courses of action to be taken to satisfy requirements if the proposed
system fails or refer to the business continuity and contingency Plan. Include:
A. Backup, alternative requirements for ensuring the continued success of system
functions.
B. Fallback techniques for ensuring the continued satisfaction of the specific system
requirements. Fallback indicates the use of another system or manual methods to
satisfy the system requirements. For example: the fallback techniques for an
automated system might be manual manipulation and recording of data.
C. Degraded modes of operation, and if applicable, state the priorities for restoring the
essential functional processing steps in the event that full processing capability is not
available.

9.4 System Availability

Describe how system design reflects requirements for system availability. Identify and
describe the major factors related to application availability, such as hardware,
communications, other. If applicable, specify the design for systems with limited
availability, and restricted hours of operation. For example, describe how the design
addresses user attempts to access the system during the period of downtime. Also
describe the design that would accommodate temporary shutdowns for enhancements or
routine maintenance.

9.5 Capacity
Describe capacities and expected volumes of data that will reside on the host hardware.
Then describe the design decisions that were made and/or strategies that were identified
to satisfy the expected capacity requirements. Examples include, system memory
requirements, hard drive space.

9.6 Performance and Timing

Describe the design decisions and/or strategies that were identified to satisfy the expected
performance and timing requirements; include the reasoning employed for the design
decisions made. The design should reflect performance and timing requirements for the
following:
A. Throughput time
B. Response time to queries and to updates of the data files
C. Sequential relationship of system functions
D. Priorities imposed by types of input and changes in modes of operation
System Design Document Template V1.0 July 25, 2010

E. Timing requirements for the range of traffic load under varying operating conditions

9.7 Data Retention

Describe how data retention requirements are addressed. Describe storage requirements
for retained data. Include auxiliary storage medium such as tape, external hard drives, or
DVD R/RW etc. and an estimate of the size of permanent or temporary storage that is
required. This section should also outline the process for cataloging and storing the data.

9.8 Error Handling

Describe general error handling routines and procedures. This may include, but is not
limited to standard screen and database errors. Also, describe how the system will
process application errors and any subsequent interaction with users. Include or reference
any standards or conventions that will be used.

9.9 Validation Rules

If applicable, describe additional system validation design not addressed in Section 7.2
Data Dictionary or elsewhere.

9.10 Conventions/Standards
Describe the system conventions and standards followed in the design. For example: If
Microsoft standards are followed for Windows, IEEE for data formats, Section 508
compliance for accessibility, etc.

9.11 Adaptability
Describe the design decisions and/or strategies that were identified to meet the
capabilities that will be incorporated into the system, giving it the flexibility to adapt to
changing requirements, such as anticipated operational changes, interaction with new or
improved systems, and planned periodic upgrades. Components and procedures designed
for the system that are most likely to change must be identified.
System Design Document Template V1.0 July 25, 2010

APPENDICES

APPENDIX A - ACRONYM LIST

Provide the expanded name or title for the acronyms and abbreviations used in the
document.
System Design Document Template V1.0 July 25, 2010

APPENDIX B – GLOSSARY
Provide a glossary of unique or special terms used in the SDD.
System Design Document Template V1.0 July 25, 2010

APPENDIX C – REQUIREMENTS COMPLIANCE MATRIX

Attached the compliance matrix. Requirements and their unique identifiers appearing in
the body of the SDD must appear verbatim in the RCM. If the requirement is deleted or
changed, these sections must also be reviewed and possibly updated.