[See the last page for template assistance.]

System Design Document

<Project/Sub-project Title>

<Office/Group>

Prepared for

University Information Technology Services

Babbidge Library, Storrs CT

369 Fairfield Rd, Unit 2209

Storrs, CT 06269-2209

File Name: sdlc_SystemDesignDocument.dotx

Overview

The System Design Document describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interfaces, detailed design, processing logic, and external interfaces.

TABLE OF CONTENTS

1	INTRODUCTION	4

1.1	Purpose and Scope	4

1.2	Project Executive Summary	4

1.2.1	System Overview	4

1.2.2	Design Constraints	4

1.2.3	Future Contingencies	4

1.3	Document Organization	4

1.4	Points of Contact	4

1.5	Project References	5

1.6	Glossary	5

2	SYSTEM ARCHITECTURE	5

2.1	System Hardware Architecture	5

2.2	System Software Architecture	5

2.3	Internal Communications Architecture	5

3	FILE AND DATABASE DESIGN	5

3.1	Database Management System Files	6

3.2	Non-Database Management System Files	6

3.3	Data Conversion Objectives	6

3.3.1	Assumptions	7

3.3.2	Constraints	7

3.3.3	Risks	7

3.4	Data Conversion Strategy	7

3.4.1	Conversion Scope	7

3.4.2	Conversion Approach	7

3.5	Roles and Responsibilities	8

3.6	Conversion Schedule	8

3.7	Data Quality Assurance and Control	8

4	Data Conversion preparation	9

4.1	Prerequisites	9

4.2	Backup Strategy	9

4.3	Restore Process	9

5	HUMAN-MACHINE INTERFACE	9

5.1	Inputs	9

5.2	Outputs	10

6	DETAILED DESIGN	10

6.1	Hardware Detailed Design	10

6.2	Software Detailed Design	11

6.3	Internal Communications Detailed Design	11

7	EXTERNAL INTERFACES	12

7.1	Interface Architecture	12

7.2	Interface Detailed Design	12

8	SYSTEM INTEGRITY CONTROLS	13

9	Implementation signoff	14

INTRODUCTION

Purpose and Scope

This section provides a brief description of the Systems Design Document’s purpose and scope.

Project Executive Summary

This section provides a description of the project from a management perspective and an overview of the framework within which the conceptual system design was prepared. If appropriate, include the information discussed in the subsequent sections in the summary.

System Overview

This section describes the system in narrative form using non-technical terms. It should provide a high-level system architecture diagram showing a subsystem breakout of the system, if applicable. The high-level system architecture or subsystem diagrams should, if applicable, show interfaces to external systems. Supply a high-level context diagram for the system and subsystems, if applicable. Refer to the requirements trace ability matrix (RTM) in the Functional Requirements Document (FRD), to identify the allocation of the functional requirements into this design document.

Design Constraints

This section describes any constraints in the system design (reference any trade-off analyses conducted such, as resource use versus productivity, or conflicts with other systems) and includes any assumptions made by the project team in developing the system design.

Future Contingencies

This section describes any contingencies that might arise in the design of the system that may change the development direction. Possibilities include lack of interface agreements with outside agencies or unstable architectures at the time this document is produced. Address any possible workarounds or alternative plans.

Document Organization

This section describes the organization of the Systems Design Document.

Points of Contact

This section provides the organization code and title of the key points of contact (and alternates if appropriate) for the information system development effort. These points of contact should include the Project Manager, System Proponent, User Organization, Quality Assurance (QA) Manager, Security Manager, and Configuration Manager, as appropriate.

Project References

This section provides a bibliography of key project references and deliverables that have been produced before this point.

Glossary

Supply a glossary of all terms and abbreviations used in this document. If the glossary is several pages in length, it may be included as an appendix.

SYSTEM ARCHITECTURE

In this section, describe the system and/or subsystem(s) architecture for the project. References to external entities should be minimal, as they will be described in detail in Section 6, External Interfaces.

System Hardware Architecture

In this section, describe the overall system hardware and organization. Include a list of hardware components (with a brief description of each item) and diagrams showing the connectivity between the components. If appropriate, use subsections to address each subsystem.

System Software Architecture

In this section, describe the overall system software and organization. Include a list of software modules (this could include functions, subroutines, or classes), computer languages, and programming computer-aided software engineering tools (with a brief description of the function of each item). Use structured organization diagrams/object-oriented diagrams that show the various segmentation levels down to the lowest level. All features on the diagrams should have reference numbers and names. Include a narrative that expands on and enhances the understanding of the functional breakdown. If appropriate, use subsections to address each module.

Note: The diagrams should map to the FRD data flow diagrams, providing the physical process and data flow related to the FRD logical process and data flow.

Internal Communications Architecture

In this section, describe the overall communications within the system; for example, LANs, buses, etc. Include the communications architecture(s) being implemented, such as X.25, Token Ring, etc. Provide a diagram depicting the communications path(s) between the system and subsystem modules. If appropriate, use subsections to address each architecture being employed.

Note: The diagrams should map to the FRD context diagrams.

FILE AND DATABASE DESIGN

Interact with the Database Administrator (DBA) when preparing this section. The section should reveal the final design of all database management system (DBMS) files and the non-DBMS files associated with the system under development. Additional information may add as required for the particular project. Provide a comprehensive data dictionary showing data element name, type, length, source, validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs, aliases, and description. Can be included as an appendix.

Database Management System Files

This section reveals the final design of the DBMS files and includes the following information, as appropriate (refer to the data dictionary):

Refined logical model; provide normalized table layouts, entity relationship diagrams, and other logical design information

A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page sizes, etc.

Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)

Estimate of the DBMS file size or volume of data within the file, and data pages, including overhead resulting from access methods and free space

Definition of the update frequency of the database tables, views, files, areas, records, sets, and data pages; estimate the number of transactions if the database is an online transaction-based system

Non-Database Management System Files

In this section, provide the detailed description of all non-DBMS files and include a narrative description of the usage of each file—including 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). As appropriate, the file structure information should:

Identify record structures, record keys or indexes, and reference data elements within the records

Define record length (fixed or maximum variable length) and blocking factors

Define file access method—for example, index sequential, virtual sequential, random access, etc.

Estimate the file size or volume of data within the file, including overhead resulting from file access methods

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

Data Conversion Objectives

In this section provide a detailed description of any data that will need to be converted from one format to another. The plan describes the overall approach, assumptions, and processes that will be used in the data conversion. It includes an inventory and cross reference of source and target data elements, schema, metadata and all self-describing files; process for data extraction, transformation and loading for each data source; tools needed to execute the conversion; and strategy for data quality assurance and control.

Assumptions

Describe any assumptions or dependencies regarding the data conversion effort. These may concern such issues as: related software or hardware, operating systems, end-user characteristics, and/or the data that must be available for the conversion.

Constraints

This section identifies any limitation that must be taken into consideration prior to the Data Conversion from the old to the new product or IT system.

Risks

Describe any risks associated with the data conversion and proposed mitigation strategies. Include any risks that could affect conversion feasibility, technical performance of the converted system, the conversion schedule, costs, backup and recovery procedures, etc.

Data Conversion Strategy

Conversion Scope

Provide a rationale for the conversion and a general description of the boundaries of the data conversion effort. This may include, but not be limited to, specific system functions affected and functions/data not affected/converted. Provide a high-level mapping of the data and data types to be converted or migrated to the new system (e.g., the amount, type, and quality of the data; the original and target sources and formats; and any cross-reference complexities.)

Conversion Approach

Describe the approach that will be used to extract, transform/cleanse and load data from the source to target destinations during the conversion/migration process. The following should be considered and addressed in this section and/or appropriate subsections, if applicable:

Identify if the conversion process will be implemented in phases or stages, and if so, identify which components will undergo conversion in each phase.

Identify what data related to specific business processes will be converted first.

Describe any automated data conversion tools that will be used (e.g., Extract, Transform, and Load (ETL) tools).

Identify and describe any part of the conversion process that will be performed manually.

Identify and describe any custom-developed conversion programs that will be needed, and associated performance tuning.

Identify criteria for a Go/No-Go decision.

Identify staffing approach.

Identify if parallel runs of the old and new systems will be necessary during the conversion process, or if there will be a one-time cut-over to the new system.

Identify whether data availability and use should be limited during the conversion process.

Describe security and privacy controls required for the conversion process.

Describe the disposition of obsolete or unused data that is not converted

Identify the retention policy for the data that has been converted in case of fall-back and have to rerun the conversion process.

Consider NARA retention policies...

Roles and Responsibilities

List all stakeholders and document their roles and responsibilities in the conversion process.

Conversion Schedule

Provide a schedule of conversion activities to be accomplished in accordance with this Data Conversion Plan. Show the required tasks in chronological order, with beginning and ending dates of each task, the key person(s) responsible for the task, dependencies, and milestones. If appropriate, tables and/or graphics may be used to present the schedule. Ensure that this information is appropriately integrated into the overall project schedule. The schedule should be as comprehensive as possible; however, the schedule may be revised as needed at later points in the lifecycle. Rather than providing this schedule in the table below, the schedule may be added as an Appendix and may be developed in a project management tool.

Data Quality Assurance and Control

Identify the types of data quality problems that may occur, including but not limited to the following considerations:

data type redefinitions (e.g., alphas in dates and numbers, embedded information in codes and intelligent keys, implied content);

garbled content (e.g., multiple uses for a single field, freeform text values, corrupted data, un-initialized data);

invalid record relationships (e.g., broken chains in set relationships, orphan records (on natural key), mismatched keys (set vs. natural key));

invalid content (e.g., values out of defined range, code fields not on a valid list of values or lookup table, blank fields (optionally), inconsistent use of defaults);

context changes (e.g., import of external data, historic changes to operational parameters (system upgrades), synchronization timing of duplicated denormalized data); and

Behavior issues (e.g., variations in actual data from planned constraints of size, data type, validation rules, and relationships).

Describe the strategy to be used to ensure data quality before and after all data conversions. Also describe the approach to data scrubbing and quality assessment of data before they are moved to the new or converted system. Describe the manual and/or automated controls and methods to be used to validate the conversion and to ensure that all data intended for conversion have been converted. Describe the process for data error detection and correction, and the process for resolving anomalies.

Data Conversion preparation

Prerequisites

Describe all preparatory and/or initiation processes that must be completed prior to data conversion. Describe specific data preparation requirements. If the data will be transported from the original system, provide a detailed description of the data handling, conversion, and loading procedures. If the data will be transported using machine-readable media, describe the characteristics of that media. Identify any support materials needed for the conversion process.

Backup Strategy

Describe how the source and target data baselines will be created and managed prior to any manipulation or migration. Also describe backups that may occur incrementally while stepping through the process of preparing, moving, and manipulating the data during conversion.

Restore Process

Describe the process to restore the source data if the need to revert to a previous back-up is identified at any point during the conversion process.

HUMAN-MACHINE INTERFACE

This section provides the detailed design of the system and subsystem inputs and outputs relative to the user/operator. Any additional information may be added to this section and may be organized according to whatever structure best presents the operator input and output designs. Depending on the particular nature of the project, it may be appropriate to repeat these sections at both the subsystem and design module levels. Additional information may be added to the subsections if the suggested lists are inadequate to describe the project inputs and outputs.

Inputs

This section is a description of the input media used by the operator for providing information to the system; show a mapping to the high-level data flows described in Section 1 .2.1, System Overview. For example, data entry screens, optical character readers, bar scanners, etc. If appropriate, the input record types, file structures, and database structures provided in Section 3, File and Database Design, may be referenced. Include data element definitions, or refer to the data dictionary.

Provide the layout of all input data screens or graphical user interfaces (GUTs) (for example, windows). Provide a graphic representation of each interface. Define all data elements associated with each screen or GUI, or reference the data dictionary.

This section should contain edit criteria for the data elements, including specific values, range of values, mandatory/optional, alphanumeric values, and length. Also address data entry controls to prevent edit bypassing.

Discuss the miscellaneous messages associated with operator inputs, including the following:

Copies of form(s) if the input data are keyed or scanned for data entry from printed forms

Description of any access restrictions or security considerations

Each transaction name, code, and definition, if the system is a transaction-based processing system

Outputs

This section describes of the system output design relative to the user/operator; show a mapping to the high-level data flows described in Section 1.2.1. System outputs include reports, data display screens and GUIs, query results, etc. The output files are described in Section 3 and may be referenced in this section. The following should be provided, if appropriate:

Identification of codes and names for reports and data display screens

Description of report and screen contents (provide a graphic representation of each layout and define all data elements associated with the layout or reference the data dictionary)

Description of the purpose of the output, including identification of the primary users

Report distribution requirements, if any (include frequency for periodic reports)

Description of any access restrictions or security considerations

DETAILED DESIGN

This section provides the information needed for a system development team to actually build and integrate the hardware components, code and integrate the software modules, and interconnect the hardware and software segments into a functional product. Additionally, this section addresses the detailed procedures for combining separate COTS packages into a single system. Every detailed requirement should map back to the FRD, and the mapping should be presented in an update to the RTM and include the RTM as an appendix to this design document.

Hardware Detailed Design

A hardware component is the lowest level of design granularity in the system. Depending on the design requirements, there may be one or more components per system. This section should provide enough detailed information about individual component requirements to correctly build and/or procure all the hardware for the system (or integrate COTS items).

If there are many components or if the component documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each component and its functions, adequately. Industry-standard component specification practices should be followed. For COTS procurements, if a specific vendor has been identified, include appropriate item names. Include the following information in the detailed component designs (as applicable):

Power input requirements for each component

Signal impedances and logic states

Connector specifications (serial/parallel, 11-pin, male/female, etc.)

Memory and/or storage space requirements

Processor requirements (speed and functionality)

Graphical representation depicting the number of hardware items (for example, monitors, printers, servers, I/O devices), and the relative positioning of the components to each other

Cable type(s) and length(s)

User interfaces (buttons, toggle switches, etc.)

Hard drive/floppy drive/CD-ROM requirements

Monitor resolution

Software Detailed Design

A software module is the lowest level of design granularity in the system. Depending on the software development approach, there may be one or more modules per system. This section should provide enough detailed information about logic and data necessary to completely write source code for all modules in the system (and/or integrate COTS software programs).

If there are many modules or if the module documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each module, its functionality, and its hierarchy. Industry-standard module specification practices should be followed. Include the following information in the detailed module designs:

A narrative description of each module, its function(s), the conditions under which it is used (called or scheduled for execution), its overall processing, logic, interfaces to other modules, interfaces to external systems, security requirements, etc.; explain any algorithms used by the module in detail

For COTS packages, specify any call routines or bridging programs to integrate the package with the system and/or other COTS packages (for example, Dynamic Link Libraries)

Data elements, record structures, and file structures associated with module input and output

Graphical representation of the module processing, logic, flow of control, and algorithms, using an accepted diagramming approach (for example, structure charts, action diagrams, flowcharts, etc.)

Data entry and data output graphics; define or reference associated data elements; if the project is large and complex or if the detailed module designs will be incorporated into a separate document, then it may be appropriate to repeat the screen information in this section

Report layout

Internal Communications Detailed Design

If the system includes more than one component there may be a requirement for internal communications to exchange information, provide commands, or support input/output functions. This section should provide enough detailed information about the communication requirements to correctly build and/or procure the communications components for the system. Include the following information in the detailed designs (as appropriate):

The number of servers and clients to be included on each area network

Specifications for bus timing requirements and bus control

Format(s) for data being exchanged between components

Graphical representation of the connectivity between components, showing the direction of data flow (if applicable), and approximate distances between components; information should provide enough detail to support the procurement of hardware to complete the installation at a given location

LAN topology

EXTERNAL INTERFACES

External systems are any systems that are not within the scope of the system under development, regardless whether the other systems are managed by the State or another agency. In this section, describe the electronic interface(s) between this system and each of the other systems and/or subsystem(s), emphasizing the point of view of the system being developed.

Interface Architecture

In this section, describe the interface(s) between the system being developed and other systems; for example, batch transfers, queries, etc. Include the interface architecture(s) being implemented, such as wide area networks, gateways, etc. Provide a diagram depicting the communications path(s) between this system and each of the other systems, which should map to the context diagrams in Section 1.2.1. If appropriate, use subsections to address each interface being implemented.

Interface Detailed Design

For each system that provides information exchange with the system under development, there is a requirement for rules governing the interface. This section should provide enough detailed information about the interface requirements to correctly format, transmit, and/or receive data across the interface. Include the following information in the detailed design for each interface (as appropriate):

The data format requirements; if there is a need to reformat data before they are transmitted or after incoming data is received, tools and/or methods for the reformat process should be defined

Specifications for hand-shaking protocols between the two systems; include the content and format of the information to be included in the hand-shake messages, the timing for exchanging these messages, and the steps to be taken when errors are identified

Format(s) for error reports exchanged between the systems; should address the disposition of error reports; for example, retained in a file, sent to a printer, flag/alarm sent to the operator, etc.

Graphical representation of the connectivity between systems, showing the direction of data flow

Query and response descriptions

If a formal Interface Control Document (ICD) exists for a given interface, the information can be copied, or the ICD can be referenced in this section.

SYSTEM INTEGRITY CONTROLS

Sensitive systems use information for which the loss, misuse, modification of, or unauthorized access to that information could affect the conduct of State programs, or the privacy to which individuals are entitled.

Developers of sensitive State systems are required to develop specifications for the following minimum levels of control:

Internal security to restrict access of critical data items to only those access types required by users

Audit procedures to meet control, reporting, and retention period requirements for operational and management reports

Application audit trails to dynamically audit retrieval access to designated critical data

Standard Tables to be used or requested for validating data fields

Verification processes for additions, deletions, or updates of critical data

Ability to identify all audit information by user identification, network terminal identification, date, time, and data accessed or changed.

System Design signoff

The terms and conditions of the Functional Requirements Document apply in full to the services and products provided under the Implementation Plan.

[Client name]	[Services provider name]
Full name	Full name
Title	Title
Signature	Signature
Date	Date

Revision History

Version	Date	Summary of Changes	Author	Revision Marks (Yes/No)
0.1	Initial revision.

[Note: This template is provided to assist authors with the UITS SDLC.

Blue or black text within arrow brackets (< >) should be customized before publishing this document. Be sure to change the color of the text to black before publishing this document.

Blue text within square brackets ([ ]) provides instructions and guidance and should be deleted before publishing this document.

This document uses automatic fields:

Viewing Automatic Fields
If you cannot see the automatic fields in this document, select Tools>Options, and then choose the View tab; in the Field Shading drop-down list, choose Always.

Customizing Automatic Fields
To customize the automatic fields in this document, select File>Properties and then replace the information in brackets (< >) with the appropriate information for this document; be sure to also customize the Custom properties by choosing the Custom tab, selecting a property, changing its value, and then clicking Modify. Repeat this for each custom field. Click OK to close the dialog.

Updating Automatic Fields
You can update the automatic fields with new, customized information by selecting Edit>Select All (or Ctrl+A) and then pressing F9, or by simply clicking on a field and pressing F9. This must be done separately for Headers and Footers (View>Header and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]