EPLC_System_Design_Doc_v . .doc

System Design Document

Food and Drug Administration

<PROJECT NAME & RELEASE VERSION>

Enterprise Performance LifeCycle

SYSTEM DESIGN

Document Version Number: <1.0> Document Version Date: <mm/dd/yyyy>

Notes to the Author

[This document is a template of a System Design Document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.

· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

· Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

· Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.

After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.

These actions must be done separately for any fields contained with the document’s Header and Footer.

2. Modify boilerplate text as appropriate for the specific project.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.

VERSION HISTORY

[Provide information on how the development and distribution of the System Design Document will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.] Version Number Implemented

By Revision

Date Approved

By Approval

Date Description of Change

Table of Contents

51.0

INTRODUCTION

51.1

PURPOSE AND SCOPE

51.2

PROJECT EXECUTIVE SUMMARY

51.2.1

SYSTEM OVERVIEW

51.2.2

DESIGN CONSTRAINTS

61.2.3

FUTURE CONTINGENCIES

61.3

POINTS-OF-CONTACT

61.4

GLOSSARY

62.0

SYSTEM ARCHITECTURE

72.1

WORKFLOW DIAGRAMS

72.2

SYSTEM HARDWARE ARCHITECTURE

72.3

SYSTEM SOFTWARE ARCHITECTURE

72.4

INTERNAL COMMUNICATIONS ARCHITECTURE

73.0

DATABASE AND FILE SYSTEM DESIGN

83.1

DATABASE MANAGEMENT SYSTEM (DBMS)

83.2

NON-DATABASE MANAGEMENT SYSTEM FILES

94.0

DETAILED DESIGN

94.1

HARDWARE DETAILED DESIGN

104.2

SOFTWARE DETAILED DESIGN

104.3

DATABASE DETAILED DESIGN

114.4

NETWORK DETAILED DESIGN

115.0

USER INTERFACE(S)

115.1

INPUTS

125.2

OUTPUTS

126.0

EXTERNAL INTERFACES

126.1

INTERFACE ARCHITECTURE

126.2

APPLICABLE DATA-EXCHANGE AND TERMINOLOGY STANDARDS

136.3

INTERFACE DETAILED DESIGN

137.0

SYSTEM INTEGRITY CONTROLS

14APPENDIX A: SYSTEM DESIGN DOCUMENT APPROVAL

15APPENDIX B: REFERENCES

16APPENDIX C: KEY TERMS

1.0 INTRODUCTION

[This document includes the definition and description of the operations, interfaces, performance, and quality assurance requirements of the software and databases that are being developed. Initially this document serves as the method for recording the preliminary design plans. As the design and development phases progress this document is updated so that by the implementation of the system, this documents represent the system as it is built.]

1.1 PURPOSE AND SCOPE

[This subsection of the System Design Document provides a brief description of the document's purpose and scope.]

1.2 PROJECT EXECUTIVE SUMMARY

[This subsection of the System Design Document provides a high-level description of the project as well as an overview of the framework in which the system design was prepared. If appropriate, include the information discussed in the subsequent sections in the summary.]

1.2.1 SYSTEM OVERVIEW

[This subsection should describe the business mission and goals being supported by this system. It should also describe the purpose and functionality of the system in non-technical terms. As well as provide high-level system architecture diagrams that show each subsystem and the interfaces to external systems. Provide an explanation on how the functional requirements will be allocated during development.

Refer to the Requirements Traceability Matrix to provide a high-level context diagram for the system and subsystem. Reference the System Boundary Document and the Project Management Plan document, if applicable.]

1.2.2 DESIGN CONSTRAINTS

[This subsection describes any constraints that will influence the system design. Reference any trade-off analyses conducted such as possible conflicts with other systems. Also note the assumptions made in developing the system design to overcome these constraints.

· Examples of architectural constraints could include: safety, security, or privacy restrictions, required use of existing systems, products, legacy components, or infrastructure, as well as the need for portability, distribution, and reuse.

· Examples of project constraints could include: limitations on design and implementation strategies, lack of development tools, understaffed team, or a compressed schedule.]

1.2.3 FUTURE CONTINGENCIES

[This subsection describes any situations that could occur that would potentially change the system development strategy. Address any possible workarounds or alternatives to the identified situations. Possibilities include failure to obtain interface agreements with outside agencies in time, withdrawal of funding or staff, or a significant change in scope.]

1.3 POINTS-OF-CONTACT

[This subsection of the System Design Document identifies the key points-of-contact (and alternates if appropriate) for the information system development effort. These points-of-contact should include the Business Sponsor, Project Manager, Quality Assurance (QA) Manager, Information System Security (ISS) Manager, Configuration Manager, and User Organization, as appropriate. Reference the Project Management Plan, if applicable.]

Business Sponsor

Project Manager

QA Manager

ISSO

Configuration Manager

User Organization

1.4 GLOSSARY

[This subsection of the System Design Document includes all terms and abbreviations used in this document. If the glossary is several pages in length, it may be included as an appendix. If terms and acronyms are listed in a separate document, reference that document’s name and location here.]

2.0 SYSTEM ARCHITECTURE

[This subsection of the System Design Document describes 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. Explain what elements are contained within the architecture.]

2.1 WORKFLOW DIAGRAMS

[This subsection of the System Design Document describes the system's decomposition into workflow processes. Organize the subsection to indicate which processes interact. Describe the main modes of communication between processes, such as message passing, human intervention, etc. Workflow diagrams should be included to clarify complex interactions.]

2.2 SYSTEM HARDWARE ARCHITECTURE

[This subsection of the System Design Document describes the overall system infrastructure, servers, routers, switches, etc., in which this system will operate. Include a list of infrastructure components with a brief description of each item. If necessary, include diagrams showing any deviations from the FDA’s Enterprise Architecture (EA) standards. If appropriate, use additional sections to address each subsystem.]

2.3 SYSTEM SOFTWARE ARCHITECTURE

[This subsection of the System Design Document describes the structure of the overall system software. The description should provide a list with a functional explanation for the modules (this could include databases, functions, subroutines, or classes), computer languages, and software engineering tools (with a brief description of the function of each item) used in this system. The description can be structured using organization diagrams/object-oriented diagrams that show the various segmentation levels at the lowest level. All features on the diagrams should have reference numbers and names and include a narrative that expands on and enhances the understanding of the functional breakdown. If appropriate, use subsections to address each module.]

2.4 INTERNAL COMMUNICATIONS ARCHITECTURE

[This subsection of the System Design Document describes the overall communications within the system, including, Intranets, Internet, WANs, etc. Provide a diagram depicting the communications path(s). If appropriate, use subsections to address each communication segment being employed.]

3.0 DATABASE AND FILE SYSTEM DESIGN

[This subsection of the System Design Document describes the overall file structure of the system, including both database files and non-database files. Additional information may be added as required for the particular project. The main output of this section is to produce a comprehensive data dictionary that shows the data element by name, type, length, source, validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs, aliases, and description. The data dictionary can either be entered here or it can be included as an appendix. Consult with the Database Administrator (DBA) when preparing this section.]

3.1 DATABASE MANAGEMENT SYSTEM (DBMS)

[This subsection of the System Design Document describes the design of the database including the following information:

· Entity-Relationship diagrams that describe the relationships and contents of the database tables.

· Data Dictionary describing the schemas, sub-schemas, records, sets, tables, storage page sizes, etc.

· Estimate of the projected 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.

· Describe all business rules, administrative rights and privileges, policies, and protection measures to be employed.

Refer to the Data Dictionary as needed.]

3.2 NON-DATABASE MANAGEMENT SYSTEM FILES

[This subsection of the System Design Document provides a detailed description of all non-DBMS files. Provide a narrative description of the purpose of each non-DBMS file that includes the following:

· The file usage (input, output, or both)

· The file status (temporary vs. permanent file)

· The file generation source (which modules read, write, or modify the file)

· The file structure (refer to the Data Dictionary as needed)

Provide the following file structure information, as appropriate:

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

4.0 DETAILED DESIGN

[This subsection of the System Design Document provides the information needed by the system development team to produce a functional system. If needed, this subsection addresses the detailed procedures for integrating COTS packages into a single system. Each detailed requirement should map back to the System Requirements Specification, and the mapping should be presented as an update to the Requirements Traceability Matrix. Include the Requirements Traceability Matrix as an appendix to this document.]

4.1 HARDWARE DETAILED DESIGN

[This subsection of the System Design Documents provides detailed information about the hardware and other infrastructure components that are needed for this system. This should identify each hardware component and detail the specific configuration needed on each item. This can be operating systems, system settings, software installed, backup software, anti-virus, terminal services, SMS, etc. For each item identified specify a version and license number if applicable. Refer to additional project documentation as applicable.

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. If there are many components, or if the component documentation is extensive, place it in an appendix or reference a separate document. If necessary, add additional diagrams and information to adequately describe each component and its functions. 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

· Video Card]

4.2 SOFTWARE DETAILED DESIGN

[This subsection of the System Design Document provides detailed information about the logic and data structure needed to completely create scripts or source code for the system (and/or integrate COTS software programs). A software module is the lowest level of design granularity in the system. Depending on the software development approach, there may be multiple modules. If the module documentation is extensive, place it in an appendix or a separate reference document. If necessary add additional diagrams and information 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.]

4.3 DATABASE DETAILED DESIGN

[This subsection provides detailed information about the logical, functional, and data structures needed to completely create the system’s database.

· Describe each data field to be developed and its characteristics (size, type, etc)

· Describe each table to be developed and the fields each table will contain. State any specific restrictions on use of each table, if applicable.

· Describe the relationships among the tables

· Identify key fields, foreign keys, etc in sufficient detail to enable a final logical design to be developed.

· Include Entity-Relationship diagrams or other depictions to clarify explanations.]

4.4 NETWORK DETAILED DESIGN

[This subsection of the System Design Document provides detailed information about the requirements to correctly build and/or procure the network components for the system. If the system includes more than one network there may be a requirement for to exchange information, provide commands, or support input/output functions. Include the following information in the detailed designs (as appropriate):

· The number of servers and clients to be accessed by each network

· Specifications for bus timing requirements and bus control

· Format(s) for data being exchanged between components

· Diagrams showing connectivity, the direction of data flow (if applicable), and locations of network interfaces. The information should provide enough detail to support the procurement of hardware to complete the installation at a given location

· LAN/WAN topology]

5.0 USER INTERFACE(S)

[This subsection of the System Design Document provides the detailed designs for the system and subsystem user interfaces. Any additional information may be added to this section and may be organized according to whatever structure best presents the input and output requirements. 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.]

5.1 INPUTS

This subsection of the System Design Document describes the system’s input methods related 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, Database and File System Design, may be referenced. Include data element definitions, or refer to the data dictionary.

Provide the layout and images of all user interfaces. Define the data elements associated with each screen or Graphical User Interface (GUI), by referencing the data dictionary. Define edit criteria, including specific values, range of values, mandatory/optional, alphanumeric values, and length. Address controls that prevent edit bypassing.

Discuss the miscellaneous messages associated with user interactions, 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

· Incorporation of the Privacy Act statement into the screen flow, if the system is covered by the Privacy Act. ]

5.2 OUTPUTS

[This subsection of the System Design Document describes of the system output design. Show a mapping to the high-level data flows described in Section 1.2.1. System outputs include reports 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 displays

· Description of report and screen contents (provide an image of each layout and define all data elements associated with the layout or reference the data dictionary)

· Description of the purpose and destination/user of each output

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

· Description of any access restrictions or security considerations.]

6.0 EXTERNAL INTERFACES

[This subsection of the System Design Document describes the interface(s) between this system and other systems and/or subsystem(s), from the point of view of the system being developed. Other systems are those not within the scope of the system under development, regardless whether the other systems are managed by the FDA or another agency.]

6.1 INTERFACE ARCHITECTURE

[This subsection of the System Design Document describes 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 or reference diagrams that depict the path(s) between the systems. These should map to the context diagrams in Section 1.2.1. If appropriate, use subsections to address each interface being implemented.]

6.2 APPLICABLE DATA-EXCHANGE AND TERMINOLOGY STANDARDS

[This subsection of the System Design Document describes the data-exchange and terminology standards utilized for information transfer between the system being developed and other systems; for example, exchanges with external agencies or pharmaceutical companies, etc. Include the data-exchange and terminology standards being utilized. [Note: For a readily available list of data-exchange and terminology standards, contact the OIM EA Team.] Provide or reference diagrams that depict which data-exchange and terminology standards apply to the path(s) between the systems. These should map to the context diagrams in Section 1.2.1.]

6.3 INTERFACE DETAILED DESIGN

[This subsection of the System Design Document provides detailed information about the interface requirements to correctly format, transmit, and/or receive data across the interface. For each system that provides an information exchange with the system under development, there is a requirement for rules governing 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 system protocols; include the content and format of the information to be included in the initial exchange, 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

· State whether a trust relationship must exist between systems to exchange data and the nature of the interconnection.]

7.0 SYSTEM INTEGRITY CONTROLS

[This subsection of the System Design Document covers the system integrity controls. Sensitive systems that contain information for which the loss, misuse, modification of, or unauthorized access to that information could affect the national interest, the conduct of Federal programs, or the privacy to which individuals are entitled under Section 552a of Title 5, U.S. Code, but that has not been specifically authorized under criteria established by an Executive Order or an act of Congress to be kept classified in the interest of national defense or foreign policy.

Developers of sensitive FDA information systems need to develop specifications for the minimum levels of control in accordance with NIST SP 800-30 and NIST SP 800-26.]

APPENDIX A: SYSTEM DESIGN DOCUMENT APPROVAL

The undersigned acknowledge that they have reviewed the <Project Name> System Design Document and agree with the information presented within this document. Changes to this System Design Document will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature:

Date:

Print Name:

Title:

APPENDIX B: REFERENCES

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Template Version 2.0 (Last Modified on Mar 27, 2009)