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 [email protected]

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

SDD – [Client / Project]

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

Contact for Enquiries and Proposed Changes Record of Issues

2 2

2

Guidelines for completion of this Document:

3

3

[Client / Project]

6

3.1 3.2 3.3

4

Purpose Project Overview and Status Project Objectives / Problem Statement

Project Scope

7

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

5

Architectural Overview 5.1

6

[Company]

7 7 7 7 7

8

Target Interfaces

8

Architectural Decisions 6.1

6 6 6

9

Key Architectural issues

9

Page 22 of 22

SDD – [Client / Project]

6.2

7

Architectural Risks and Assumptions

9

Solution Description

10

7.1 Component Model 7.2 Re-use of components 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

8

System Requirements

10 10 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

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 Requirement – [Function 2 Title] 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

14 14 14 14

17

Data Applications Third party

17 17 17

Design

12.1 12.2 12.3 12.4

18

Colours Look and Feel Usability Issues Audience

18 18 18 18

13

Performance

19

14

Data Migration and Conversion

20

15

APPENDICES

21

15.1 15.2

16

Definitions Attachments

21 21

Sign-off list

22

[Company]

Page 22 of 22

SDD – [Client / Project]

Tables Table 1Document History Table 2 - Project Objectives / Problem Statements Table 3 -Key Stakeholders 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 11 - Functional Requirements Table 12 - Definitions Table 13 - Attachments

[Company]

Page 22 of 22

2 6 7 7 9 9 9 13 14 15 16 21 21

SDD – [Client / Project]

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

SDD – [Client / Project]

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

[Company]

Page 22 of 22

SDD – [Client / Project]

5.

Table 4 -Project Related and Other Reference Documents

[Company]

Page 22 of 22

SDD – [Client / Project]

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

SDD – [Client / Project]

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.

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.

Forecasting Portal

7.

Table 7 - Architectural Risks and Assumptions

[Company]

Page 22 of 22

SDD – [Client / Project]

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: ●

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:

2.

●

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

[Company]

Page 22 of 22

SDD – [Client / Project]

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. 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

[Company]

Page 22 of 22

SDD – [Client / Project]

The purpose of this section is to describe the security controls that will be incorporated into the solution.

Application Security

1.

Describe the following: ●

Authentication. How will users authenticate to the system, describe detailed password rules. Describe where external authentication infrastructure is being used, eg account-01.

●

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

SDD – [Client / Project]

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 client’s 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

SDD – [Client / Project]

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

SDD – [Client / Project]

functional Requirements 1.

Requirement – [Function 1 Title]

Title BR-FID

Flow of Events

Goal

Subfunction s,

99

F R I D

Priority

1

Phase

9

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

Page 22 of 22

SDD – [Client / Project]

Preconditio ns

[Company]

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 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

Page 22 of 22

SDD – [Client / Project]

Post Conditio ns

[Company]

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 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

Page 22 of 22

SDD – [Client / Project]

User Interface

Busines s Rules

[Company]

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 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

Page 22 of 22

SDD – [Client / Project]

Related Flow Chart or Process es

Issues

Referenc es

Notes

[Company]

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 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

Page 22 of 22

SDD – [Client / Project]

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 same as for their staff acco unt. Table 10 - Functional Requirements

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.

Outputs

3.

Screens

4.

Reports

5.

Requirement – [Function 2 Title]

Title BR-FID

Flow of

[Company]

99

F R I D

Priority

1

Phase

9

Step

Page 22 of 22

SDD – [Client / Project]

Events

Goal

Subfunction s,

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: The User is regist ered or logge d in alrea dy. The soluti on will reco gnise

Page 22 of 22

SDD – [Client / Project]

Preconditio ns

[Company]

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 d exist befor e the proc ess can be exec uted eg: User has a runni ng drift

Page 22 of 22

SDD – [Client / Project]

Post Conditio ns

User Interface

[Company]

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 privil eges Refer ence to UI proto type or speci fic scree n and UI relat

Page 22 of 22

SDD – [Client / Project]

Busines s Rules

Related Flow Chart or Process es

[Company]

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 notify sys admi n. This is optio nal. List all Flow Chart s, inclu de,

Page 22 of 22

SDD – [Client / Project]

Issues

Referenc es

Notes

[Company]

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 and avail able infor matio n or optio ns for comp letion of the task. Eg:

Page 22 of 22

SDD – [Client / Project]

user nam e and pass word will be the same as for their staff acco unt. Table 11 - Functional Requirements

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.

Outputs

7.

Screens

11.

Reports

[Company]

Page 22 of 22

SDD – [Client / Project]

Inputs 1.

Data

2.

Applications

12.

Third party

[Company]

Page 22 of 22

SDD – [Client / Project]

Design 1.

Colours

2.

Look and Feel

3.

Usability Issues

13.

Audience

[Company]

Page 22 of 22

SDD – [Client / Project]

Performance 14. Outline the performance capabilities and constraints of the solution.

[Company]

Page 22 of 22

SDD – [Client / Project]

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

SDD – [Client / Project]

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

SDD – [Client / Project]

Sign-off list

Project Lead

_____________________

____/____/______

_____________________

____/____/______

_____________________

____/____/______

_____________________

____/____/______

[Position Title] Consultant [Position Title] xxxxx [Position Title]

XXXXX (Development Mgr)

[Company]

Page 22 of 22

SDD – [Client / Project]