03 SDD Solution Design Document

Solution Design
Document (SDD)
Project Name:
Project Code:
Version:
Author:
Position:
Phone:
1.
[Full Name]
[8 character Code]
X.X
[Your Name]
[Your Position]
[Your Phone Number]
Email: [Your Email Address]
[Company]
Page 22 of 22
SDD [Client / Project]
Document History
Version
1.0
Responsible
Date
Notes
*** End of
Revision List
***
Table 1Document History
1.
Contact for Enquiries and Proposed Changes
If you have any questions regarding this document contact:

Name:
Designation:
Phone:
Email:
Marc Dimmick
System Business Anaylsis
(08) 6216 6335
Marc.dimmick@dcp.wa.gov.au
If you have a suggestion for improving this document, complete and forward a copy of Suggestions
for Improvements to Documentation.
2.
Record of Issues
The Record of Issues reflects revisions to this template. This information should be deleted from
your document.
Ver
1.0
1.1
1.2
1.3
Date
12 Apr 2006
8 Jun
23 Nov 06
19 Jul 2007
[Company]
Nature of Amendment
Initial Document
Update Layout and style sheet
Update Layout and Style
Update Corporate Logo
Page 22 of 22
2.
Guidelines for completion of this Document:

Consultants are required to gathering and documenting requirements in consultation with project
stakeholders. Overall Responsibility for this lies with the project lead.
This template ensures that the essential details pertaining to this Requirements document a clear and
unambiguous statement of Functional and Non-Functional Requirements.
This document is used in development, testing, quality assurance, project management, and related
project functions.
Items in squared brackets are to be replaced with appropriate contents. For example, [Project Manager]
should be replaced by the name of the Project Manager.
This template provides a recommended structure and format along with sample contents, explanatory
notes and questions to guide and prompt the author.
Please delete these notes and other guidelines from the actual document. They are meant for your
information only. These are given in this colour and font.
If a section/ subsection are not applicable, do not delete it. Instead, mention as such and explain why it is
not applicable. Remember to run a spell check.
It is preferable to use date with month name rather than month number to avoid confusion (use Jan 2,
2006 or 2 Jan 2006, instead of 1/2/2006 or 2/1/2006)
This document contains pre-formatted styles for headings. To convert a line into heading, select the line
and choose BS Heading 1, BS Heading 2, etc., as appropriate from the style drop down adjacent to the
font drop down box
Table of Contents
1
Document History
1.1
1.2
2
3
Contact for Enquiries and Proposed Changes

Record of Issues
Guidelines for completion of this Document:

[Client / Project]
3.1
3.2
3.3
Purpose
Project Overview and Status
Project Objectives / Problem Statement
Project Scope
Architectural Overview
5.1
Target Interfaces
[Company]
7
7
7
7
7
Key Architectural issues

Architectural Risks and Assumptions
9
9
Solution Description
7.1
7.2
6
6
6
Architectural Decisions
6.1
6.2
3
6
4.1.1
Inclusions
4.1.2
Exclusions
4.1.3
Phasing if required
4.2
Key Stakeholders
4.3
Project Related and Other Reference Documents
2
2
10
Component Model
Re-use of components
10
10
Page 22 of 22
7.3
Information Model
7.3.1
Information and Data Characteristics
7.4
Infrastructure Model
7.5
Integration and Network Design
7.6
Security Architecture
7.6.1
Application Security
7.6.2
Operational Security
System Requirements
10
11
11
11
11
11
12
13
8.1
[system / component name]
8.1.1
Relevant Flow Chart
8.1.2
Solution Architecture Requirements
8.1.3
Design Description
13
13
13
13
Implementation and Migration
14
9.1
Architecture Migration Plan
9.1.1
Migration Plan
9.1.2
List Dependencies
9.2
GLOSSARY
10
functional Requirements
15
Requirement [Function 1 Title]

Outputs
Screens
Reports
Outputs
Screens
Reports
15
15
15
15
15
16
16
16
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
11
Inputs
11.1
11.2
11.3
12
17
17
17
Design
18
Colours
Look and Feel
Usability Issues
Audience
18
18
18
18
Performance
Data Migration and Conversion
APPENDICES
15.1
15.2
16
17
Data
Applications
Third party
12.1
12.2
12.3
12.4
13
14
15
14
14
14
14
19
20
21
Definitions
Attachments
21
21
Sign-off list
22
Tables
Table 1Document History
Table 2 - Project Objectives / Problem Statements
Table 3 -Key Stakeholders
[Company]
Page 22 of 22
2
6
7
Table 4 -Project Related and Other Reference Documents

Table 5 - Architectural Decisions
Table 6 -Key Architectural Issues
Table 7 - Architectural Risks and Assumptions
Table 8 - Relevant Flow Charts
Table 9 - Glossary
Table 10 - Functional Requirements
Table 12 - Definitions
Table 13 - Attachments
[Company]
Page 22 of 22
7
9
9
9
13
14
15
16
21
21
3.
1.
[Client / Project]
Purpose
The primary purpose of this document is to communicate the essential elements of the overall solution so
that business implications can be assessed and understood, and so that the design activities in
Build/Acquire can proceed if the initiative is approved.
Insert description of technical development and what will be achieved upon successful implementation of
the solution described in this document.
2.
Project Overview and Status

Provide the background and context of the initiative, and its current status from a project perspective.
The current status should also include any significant risks or issues that may be relevant to the design.
3.
Project Objectives / Problem Statement

Provide a brief overview of the objectives of the project, eg, an overview of a new product or a new
feature, or a new support system, etc. Include a brief summary of the business need and drivers behind
the initiative, as well as enterprise, design and standards constraints. EG, include forecast growth, peak
traffic/transaction volumes, and reference market projections, etc. Refer to the BRD for detail.
Alternatively the objective may be best described as an initiative to solve a problem. The table below
provides a suggested format for the problem statement.
The problem of
Affects
The impact of which is
A successful solution would
4.
Table 2 - Project Objectives / Problem Statements
[Company]
Page 22 of 22
Project Scope
Insert a statement that describes the project scope.
1.
Inclusions
2.
Exclusions
3.
Phasing if required
2.
Key Stakeholders
Area / Position
Business Stakeholders
Name / Role
Contact Number
Technology
Stakeholders
Operations
Stakeholders
Table 3 -Key Stakeholders
3.
Project Related and Other Reference Documents

List all the references that were used in coming up with this document.
Document ID
Project Related
Documents
Title / Description / Location
Other Reference
Documents
5.
Table 4 -Project Related and Other Reference Documents
[Company]
Page 22 of 22
Architectural Overview
Insert architectural diagram of systems, interfaces and information flows of the planned solution.
Number each interface for reference below.
1.
Target Interfaces
Key
Eg. 1
[Company]
Interface
Eg. Solomon, Startrack
Purpose/Description
E.g. Existing interface, provides end of day manifest information
for shipping purposes.
Page 22 of 22
6.
Architectural Decisions
Include a summary of significant decisions made in deriving the solution here.
Architectural Decision Identifier
Description
Eg.
How will invoicing occur for returned orders?
AD-01
Invoicing will occur through a daily batch process between
AD-02
Table 5 - Architectural Decisions
1.
Key Architectural issues
Issue Identifier
ISS 01
System(s) Impacted
Identify system(s)
impacted by system
name as described in
this document
Description
Issue to be documented in this
section eg
Owner
Owner of the issue
who will be managing
it to resolution
Status
Closed/Open
01/01/2003: It is not clear

whether XXX will generate
error message axe.
ISS 02
.
Table 6 -Key Architectural Issues
2.
Architectural Risks and Assumptions
Key architectural risks and assumptions are as follows:

NB, risks to be managed by project risk management
Risk Assumption
System(s) Impacted
AR 01
Identify system(s)
impacted by system name
as described in this
document
Eg.
Forecasting Portal
7.
Description
Eg. It is assumed that the migration to Microsoft .Net Framework for

this portal will not impact the functionality of systems interfacing to
this portal currently.
Table 7 - Architectural Risks and Assumptions
[Company]
Page 22 of 22
Solution Description
This section describes the High Level solution in terms of the systems/components and how each
component interacts with other systems/components.
1.
Component Model
Include and describe the component model of the design.
A component is any deployable element of architecture. It is characterised by its behavior or function as
exposed or expressed via an external interface. Components can be decomposed or aggregated into
other components. Examples include a program, a software module, a system, a data repository, a
network element, etc. Each component can utilise the services provided by other components, as well as
provide services of its own.
The component model describes how sets of components participate in defining the design. It includes
static and dynamic relationships and interactions between components. The model documentation
typically includes a number of diagrams expressing the different kinds of relationships for example,
dependency relationships, usage relationships, interaction and timing relationships, etc. Where the
solution has been partitioned, the individual subsets of the component model must be clearly defined, and
the assignment to the respective providers identified. Each subset will subsequently be the subject of a
Design Component Specification and is usually defined by the Client(s) based on which he provides a
cost and time estimate to a confidence level specified by the Project Manager.
It is useful to recognise the following interface categories:
2.
User Interfaces those interactions which exist to enable human interaction with the system;
Application Services Interfaces those interactions which enable the application services
provided by one system to be utilized by another in an automated manner;
Operational Interfaces those interactions which are used to manage and operate the systems
environment, including monitoring, recovery and exception management;
System Synchronization Services Interfaces those interactions that are used to maintain
persistent reference and state information integrity across multiple systems in a synchronised
manner.
In specifying interfaces and services, it is important to understand that there are two important
cases:
Functional Services this case involves services that are primarily stateless, and there is a
one-to-one correspondence between interface and service. Each such service can be described
independently.
Process Services this involves services that implement a process, and behaviour is
dependent upon previous activity. Typically, a single process may involve many interface calls
calls are sometimes referred to as triggers and in this case it is necessary, not only to describe
each of the interfaces but also the state behaviour of the process itself.
Re-use of components
It is important to identify services, components, code, documentation, etc that are candidates for
corporate reuse and to design and maintain baseline documentation in a way that enables that re-use at
minimized cost. In this section describe what has been achieved in reuse, and any issues arising.
3.
Information Model
Include (or reference) and describe the information model pertinent to the solution.
The Information Model covers a structured view of the business, system and state information that is the
subject of the design. The information model does not need to address objects or data which are not
exposed (or likely to be exposed) externally.
[Company]
Page 22 of 22
For data management intensive solutions such as those Databases of Record, this part of the solution will
form a significant proportion of the total, and may actually be contained in separate documentation that is
explicitly referenced by title, date and version.
Whilst the information passed and returned by each interface is described in the Component Model, in
most cases it is also appropriate to describe the consolidated information model.
Where the solution has been partitioned, the individual subsets of the information model must be clearly
defined, and the assignment to the respective providers identified.
Information and Data Characteristics
1.
Regardless of the complexity or size of the information model, define the required non-functional
characteristics of the model elements (or groups of elements). The characteristics to be addressed may
include, but are not limited to:
4.
Persistence indicate which elements of the model must persist beyond a transaction or
session, including the conditions under which persistence may no longer be required, and the
period of persistence;
Size indicate the anticipated number of instances of each element;
Security and Privacy indicate which elements are of a particularly sensitive nature requiring
specific access or disclosure measures, or privacy constraints;
Legal and Regulatory indicate which elements require specific data retention, archiving, audit
trail logging, or other measures to meet legal or regulatory obligations. All legal and regulatory
requirements concerning information or data should be identified as being as such even if listed
under other topic headings (e.g. privacy requirements imposed by a government regulator should
be identified as being legal and regulatory requirements even if they are listed under security and
privacy);
Integrity indicates any specific integrity or validity requirements associated with the information
elements.
Infrastructure Model
For IT systems an infrastructure model may be required where the underlying servers, storage media, etc,
are defined. (In IBM terms - the operations model)
5.
Integration and Network Design

Applies to an IT systems design where the underlying communications network must be defined. Define
the conceptual aspects of network or integration mechanisms required to interconnect components. The
Component Model addresses interface mechanisms, principally from an application or service level
perspective. Here is included additional information relating to the communication mechanisms, protocols
or network models. Typically, details of this subsection are further developed as part of the Integration
Specification.
Both functional and non-functional characteristics of integration and network behaviour should be
included.
6.
Security Architecture
The purpose of this section is to describe the security controls that will be incorporated into the solution.
Application Security
1.
Describe the following:
[Company]
Authentication. How will users authenticate to the system, describe detailed password rules.
Describe where external authentication infrastructure is being used, eg account-01.
Page 22 of 22
Authorisation. Describe the categories of users and the functionality they will have. Include all
users, customers, staff, operations staff supporting the platform
Audit/Logging. Describe what will be logged and describe any external auditing or logging
platforms being used
Operational Security
2.
Describe at a high level any security related process and how the system will support these processes:
8.
How do users register or enrol with the service? How are authentication credentials issued and
reset?
How are users access rights determined and implemented? Will approval processes for user
access be developed, if so by whom?
How are users access rights revoked?
Cryptographic key management processes
Security Incident Response process
Vulnerability management including application of patches and vulnerability assessments
Special information classification and handling processes
[Company]
Page 22 of 22
System Requirements
[system / component name]
1.
Complete one per system/component
Relevant Flow Chart
1.
Flow Chart ID
Flow Chart Name
FCXX
Table 8 - Relevant Flow Charts
Solution Architecture Requirements
2.
The purpose of this section is to define the specific, well-formed requirements for impacted systems, and
partition them in a manner that will facilitate design definition.
When creating Architectural Requirements, each verifiable requirement defined in this section should be
contained in a separate paragraph.
The source of all raw requirements should be captured in the Requirements Traceability Matrix, along with
the cross-reference to the labelled requirements in this section.
This section contains the specific solution architecture requirements for [System/Component Name].
Design Description
3.
9.
This section details the clients design response pertaining to the specific system/component that is to be
delivered. If a specification document has been referenced in this section, ensure the relevant document
has been attached in the appendix section of this document.
[Company]
Page 22 of 22
Implementation and Migration

Address the overall approach to implementation. This would include strategy for migration from existing
processes and systems, as well as data migration considerations. Typically this section will define phases
of implementation that would minimise the impact on business operation whilst providing additional
business value with each phase.
1.
Architecture Migration Plan

Migration Plan
1.
Insert an Architecture Migration Plan. This plan should address the overall approach to implementation of
the new architecture and complement the details written in section 6 Implementation and Migration.
Examples of the types of information which may be found here are:
the sequencing of the migration

new infrastructure requirements
list of any potential technology or infrastructure retirements caused by this plan
business impacts
plan for data migration
List Dependencies
2.
This section should contain any dependencies of the plan from the section above. All issues and risks
identified should be managed via the [Company] issues and risk management processes.
All Assumptions of this plan and dependencies should list listed in the section Architectural Risks and
Assumptions.
2.
GLOSSARY
Term / Acronym
Table Data
Definition / Expansion / Description

Table Data
10. Table 9 - Glossary
[Company]
Page 22 of 22
functional Requirements
1.
Title
BR-FID
Flow of
Events
Goal
Subfunction
s,
99
F
R
I
D
Priority
Phase
Step
s of
the
requi
reme
nt.
Desc
ribe
them
as a
bullet
ed/
num
bere
d list
the
outco
me
of
this
set of
actio
ns eg
User
is
Logg
ed
on to
Solut
ion
FID
Title
Assumpt
ions
[Company]
Any
assu
mptio
ns
oper
ating
in the
exec
ution
of
the
functi
on
eg:
Page 22 of 22
Preconditio
ns
[Company]
The
User
is
regist
ered
or
logge
d in
alrea
dy.
The
soluti
on
will
reco
gnise
each
indivi
dual
s
rights
. If
the
user
cann
ot be
identi
fied
the
soluti
on
will
notify
admi
n.
The
soluti
on
auto
matic
ally
save
s the
sessi
on
settin
gs.
What
are
the
requi
reme
nts
for
this
flow
chart
to
run,
list of
condi
tions
that
shoul
Page 22 of 22
Post
Conditio
ns
[Company]
d
exist
befor
e the
proc
ess
can
be
exec
uted
eg:
User
has a
runni
ng
drift
sessi
on
and
has
acce
ssed
the
soluti
on.
User
has
acce
ss
rights
.
User
has
been
adde
d to
the
list of
users
.et
c.
What
state
the
soluti
on is
in
after
the
proc
ess
runs
eg:
User
has
acce
ss to
the
appli
catio
n
accor
ding
to his
Page 22 of 22
User
Interface
Busines
s Rules
[Company]
privil
eges
Refer
ence
to UI
proto
type
or
speci
fic
scree
n
and
UI
relat
ed
notes
What
condi
tions
apply
to
the
functi
on?
Any
dom
ain
speci
fic
know
ledge
or
algori
thms
or
valid
ation
rules
(rele
vant
to
this
usecase)
eg.
After
three
unsu
cces
sful
atte
mpts
at log
in the
soluti
on
will
lock
the
user
out
and
Page 22 of 22
Related
Flow
Chart or
Process
es
Issues
Referenc
es
Notes
[Company]
notify
sys
admi
n.
This
is
optio
nal.
List
all
Flow
Chart
s,
inclu
de,
exten
d or
speci
alise
this
Flow
Chart
or
relat
ed
Flow
Chart
s
Clarif
icatio
ns
requi
red
from
user.
Any
quest
ions
relat
ed to
the
Flow
Chart
Requ
irem
ent
#,
Docu
ment
s,
Pers
ons
Any
notes
whic
h
may
help
to
clarif
y the
proc
ess
Page 22 of 22
and
avail
able
infor
matio
n or
optio
ns
for
comp
letion
of
the
task.
Eg:
user
nam
e
and
pass
word
will
be
the
same
as
for
their
staff
acco
unt.
The above grid is to be used for every function identified.

If needed copy flow chart from BRD into this section of the document.
2.
3.
4.
5.
Outputs
Screens
Reports
Title
BR-FID
Flow of
Events
[Company]
99
F
R
I
D
Priority
Phase
Step
s of
the
requi
reme
nt.
Desc
ribe
them
Page 22 of 22
Goal
Subfunction
s,
as a
bullet
ed/
num
bere
d list
the
outco
me
of
this
set of
actio
ns eg
User
is
Logg
ed
on to
Solut
ion
FID
Title
Assumpt
ions
[Company]
Any
assu
mptio
ns
oper
ating
in the
exec
ution
of
the
functi
on
eg:
The
User
is
regist
ered
or
logge
d in
alrea
dy.
The
soluti
on
will
reco
gnise
each
indivi
dual
s
rights
. If
the
user
Page 22 of 22
Preconditio
ns
[Company]
cann
ot be
identi
fied
the
soluti
on
will
notify
admi
n.
The
soluti
on
auto
matic
ally
save
s the
sessi
on
settin
gs.
What
are
the
requi
reme
nts
for
this
flow
chart
to
run,
list of
condi
tions
that
shoul
d
exist
befor
e the
proc
ess
can
be
exec
uted
eg:
User
has a
runni
ng
drift
sessi
on
and
has
acce
ssed
the
soluti
Page 22 of 22
Post
Conditio
ns
User
Interface
Busines
s Rules
[Company]
on.
User
has
acce
ss
rights
.
User
has
been
adde
d to
the
list of
users
.et
c.
What
state
the
soluti
on is
in
after
the
proc
ess
runs
eg:
User
has
acce
ss to
the
appli
catio
n
accor
ding
to his
privil
eges
Refer
ence
to UI
proto
type
or
speci
fic
scree
n
and
UI
relat
ed
notes
What
condi
tions
apply
to
the
Page 22 of 22
Related
Flow
Chart or
Process
es
[Company]
functi
on?
Any
dom
ain
speci
fic
know
ledge
or
algori
thms
or
valid
ation
rules
(rele
vant
to
this
usecase)
eg.
After
three
unsu
cces
sful
atte
mpts
at log
in the
soluti
on
will
lock
the
user
out
and
notify
sys
admi
n.
This
is
optio
nal.
List
all
Flow
Chart
s,
inclu
de,
exten
d or
speci
alise
this
Flow
Chart
or
relat
Page 22 of 22
Issues
Referenc
es
Notes
[Company]
ed
Flow
Chart
s
Clarif
icatio
ns
requi
red
from
user.
Any
quest
ions
relat
ed to
the
Flow
Chart
Requ
irem
ent
#,
Docu
ment
s,
Pers
ons
Any
notes
whic
h
may
help
to
clarif
y the
proc
ess
and
avail
able
infor
matio
n or
optio
ns
for
comp
letion
of
the
task.
Eg:
user
nam
e
and
pass
word
will
be
the
Page 22 of 22
same
as
for
their
staff
acco
unt.
The above grid is to be used for every function identified.

If needed copy flow chart from BRD into this section of the document.
6.
7.
11.
Outputs
Screens
Reports
[Company]
Page 22 of 22
Inputs
1.
2.
12.
Data
Applications
Third party
[Company]
Page 22 of 22
Design
1.
2.
3.
13.
Colours
Look and Feel
Usability Issues
Audience
[Company]
Page 22 of 22
Performance
14. Outline the performance capabilities and constraints of the solution.
[Company]
Page 22 of 22
Data Migration and Conversion

15. If an application is to be modified, indicate here if any data conversions are required on existing data
records. If a new application is replacing an existing application, indicate here what data migration /
conversion is required
[Company]
Page 22 of 22
APPENDICES
List those documents which would be useful for the reader of the Architectural Design Document
Definitions
1.
The following words, acronyms and abbreviations are referred to in this document.
Term
Definition
Table 12 - Definitions
2.
Attachments
Document Number
Title
16. Table 13 - Attachments
[Company]
Page 22 of 22
Sign-off list
Project Lead
[Position Title]
_____________________
____/____/______
Consultant
[Position Title]
_____________________
____/____/______
xxxxx
[Position Title]
_____________________
____/____/______
XXXXX
(Development Mgr)
_____________________
____/____/______
[Company]
Page 22 of 22

03 SDD Solution Design Document

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

03 SDD Solution Design Document

Загружено:

Авторское право:

Доступные форматы

Solution Design

Email: [Your Email Address]

SDD [Client / Project]

Contact for Enquiries and Proposed Changes

If you have any questions regarding this document contact:

SDD [Client / Project]

Guidelines for completion of this Document:

Contact for Enquiries and Proposed Changes

Guidelines for completion of this Document:

Key Architectural issues

SDD [Client / Project]

Implementation and Migration

Requirement [Function 1 Title]

SDD [Client / Project]

Table 4 -Project Related and Other Reference Documents

SDD [Client / Project]

Project Overview and Status

Project Objectives / Problem Statement

Table 2 - Project Objectives / Problem Statements

SDD [Client / Project]

Project Related and Other Reference Documents

Title / Description / Location

Table 4 -Project Related and Other Reference Documents

SDD [Client / Project]

SDD [Client / Project]

Architectural Decision Identifier

Table 5 - Architectural Decisions

Key Architectural issues

01/01/2003: It is not clear

Architectural Risks and Assumptions

Key architectural risks and assumptions are as follows:

Eg. It is assumed that the migration to Microsoft .Net Framework for

Table 7 - Architectural Risks and Assumptions

SDD [Client / Project]

SDD [Client / Project]

Information and Data Characteristics

Integration and Network Design

Describe the following:

SDD [Client / Project]

SDD [Client / Project]

Complete one per system/component

Relevant Flow Chart

Flow Chart Name

Table 8 - Relevant Flow Charts

Solution Architecture Requirements

SDD [Client / Project]

Implementation and Migration

Architecture Migration Plan

the sequencing of the migration

Definition / Expansion / Description

10. Table 9 - Glossary

SDD [Client / Project]

Requirement [Function 1 Title]

SDD [Client / Project]

SDD [Client / Project]

SDD [Client / Project]

SDD [Client / Project]

SDD [Client / Project]

The above grid is to be used for every function identified.

SDD [Client / Project]

SDD [Client / Project]

SDD [Client / Project]