EPLC_Interface_Control_Doc_v2.1.doc
DOC document 172 KB Posted
- Solicitation number
- FDA-SOL-11-1085941
About this file
EPLC Interface Control Doc
View the file
Other files
Show 40 more
Latest 50 of 56 listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Food and Drug Administration
<Project Name & Release Version #> Enterprise Performance LifeCycle
INTERFACE CONTROL DOCUMENT
Document Version Number: <#.#> Document Version Date: <mm/dd/yyyy> Notes to the Author
[This document is a template of a Interface Control 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 Interface Control 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 and
Reason for Change
| 10/29/2010 |
| 10/29/2010 |
| <Project Manager name> |
| <mm/dd/yyyy> |
| Correction made in the title page. The version should be #.# |
Table of Contents
51.0 Purpose and Scope
52.0 System Interface Details
63.0 System Interface Requirements
74.0 System Interface Specifications
75.0 System Interface Security
11Appendix D – System Interface (Details) Matrix
11System Interface (Details) Matrix
12Appendix E – System Interface Requirements Matrix
12System Interface Requirements Matrix
13Appendix F: System Interface Mapping Matrix
13System Interface Mapping Matrix
14Appendix G – System Interface Specification Matrices
14Program Design Matrix
14Database Design Matrix
15User Interface Design Matrix
15Security and Integrity Design Matrix
15System Capabilities Matrix
1.0 Purpose and Scope
The purpose of this document is to define the details of interfaces for an information system. For the <PROJECT OR SYSTEM NAME> project, the following interfaces are within the project scope:
· <SYSTEM NAME>
· <SYSTEM NAME>
· <SYSTEM NAME>
Refer to Figure 1 – System Interfaces for the <PROJECT OR SYSTEM NAME> Project, which displays all the known interfaces that are part of this project.
Figure 1 - System Interfaces for the
<PROJECT OR SYSTEM NAME> Project
2.0 System Interface Details
This section of the System Interface Document provides the data fields that the <PROJECT OR SYSTEM NAME> project’s information system will require, replace, or provide to other software applications or information systems.
[This section outlines the methods for gathering the interface details that will be recorded. Describe which tools, resources, and techniques that will be used to gather this data. Some of the sources could include
· Systems Experts – via interviews and work sessions
· System Architecture Diagram
· Database Dictionaries
Also include where these items are located (network location, Configuration Management System, etc)]
[If the System Interface Details are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the interfaces needed for the project. If such a source is not available, use the table in Appendix D.]
Refer to Appendix D for a detailed list of the interface items.
3.0 System Interface Requirements
This section of the System Interface Document provides the functional and technical requirements for each interface within the <PROJECT OR SYSTEM NAME>. The System Interface Requirements Matrix and the System Interface Mapping Matrix, both located in Appendices B and C, list the functional and technical requirements for each interface. A majority of the interfaces perform data transfers. This exchange of data between the software application or information systems should be mapped by using one or more of the following: <identify which methods will be used on the current project>
· A one-to-one correspondence between fields in the two systems
· A formula that combines the results of multiple fields in one system to derive the value for one field in the other system
· An algorithm that transforms the value of a field in one system to meet the requirements of the second system
· A lookup table
Other interface types should be documented and may include: <identify which types will be used on the current project.>
· Control Interfaces – An interface that allows one software application to operate another software application.
· Document Management Interfaces – An interface that allows a single container to hold multiple data types, and provide facilities for the exchange of information between multiple software applications using standards such as OLE and OpenDoc
· Device Management Interfaces – An interface that allows software application control of physical devices such as thermostats and lighting.
[If the System Interface Requirements and Maps are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the interfaces needed for the project. If such a source is not available, use the tables in Appendix E and F.]
Refer to Appendix E for a list of the System Interface Requirements Matrix and Appendix F for the System Interface Mapping Matrix.
4.0 System Interface Specifications
This section of the System Interface Document specifies how each interface will work, as well as the technology and approach that will be used to develop each interface. The main matrices are:
· Program Design
· Database Design
· User Interface Design
· Security and Integrity Design
· System Capabilities
The Program Design Matrix includes the hardware, communications, and third-party utilities that are used on this project. The System Capabilities Matrix should identify and show where the design meets each of the requirements.
Refer to Appendix G for a list of the approaches for gathering the interface specifications.
[If the System Interface Specifications are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the information for the project. If such a source is not available, use the tables in Appendix G.]
5.0 System Interface Security
This section describes the trust relationships that must be agreed to by the systems that are exchanging or providing data. This portion of the template must include a general information/data description, the services offered by both parties, the sensitivity of the data or information to be exchanged, the user community affected or involved, the specific information exchange security measures that will be applied, and the trusted behavior expectations of both parties (formal security policies that apply, incident reporting procedures, and audit trail responsibilities.
Refer to Appendix H <and any other appendices> for the Interconnection security agreements.
[A security agreement should be filled out for each interface. Use the agreement found in Appendix H and includes as many appendices as needed for each interface.]
APPENDIX A: Interface Control Document Approval TC "APPENDIX A: Interface Control Document Approval" \f C \l "1" [The undersigned acknowledge that they have reviewed the <Project Name> Interface Control Document and agree with the information presented within this document. Changes to this Interface Control Document will be coordinated with, and approved by, the undersigned, or their designated representatives.] Signature:
Date:
Print Name:
Title:
| Role: |
| Project Manager |
APPENDIX B: REFERENCES TC "APPENDIX B: REFERENCES" \f C \l "1" [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.
| Document Name |
| Description |
| Location |
| <Document Name and Version Number> |
| <Document description> |
| <URL to eRoom where document is located> |
APPENDIX C: KEY TERMS TC "APPENDIX C: KEY TERMS" \f C \l "1" The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.
| Term |
| Definition |
| [Insert Term] |
| <Provide definition of term and acronyms used in this document.> |
Appendix D – System Interface (Details) Matrix
[Include a copy of the following matrix for each interface.]
System Interface (Details) Matrix
| Table / Field Name |
| Schema Owner |
| Field Label |
| Data Type |
| Field Format |
| Description |
| Integrity Constraints |
| Validity Checks |
The System Interface Matrix documents the following:
· Table / Field Name – The name of the table or data field.
· Schema Owner – The name associated with the creation of the schema.
· Field Label - The label for the field commonly displayed on screens and reports.
· Data Type - The data type as defined by the software application or data dictionary.
· Field Format – The field format masks for numeric, date, character, and other field types.
· Description - A short definition of the data field contents.
· Integrity Constraints - Constraints may include: NOT NULL, UNIQUE KEY and CHECK.
· Validity Checks – The checks may include allowable values, ranges, and lookup tables
Use the System Architecture diagram as a starting point for identifying each interface. Determine the data, graphics, audio, or video format for each element, and identify the communications protocols used by each application. In most cases the interface elements will be data fields, and can be identified through data dictionary reports or other miscellaneous system documents.
Appendix E – System Interface Requirements Matrix
[Include a copy of the following matrix for each interface.]
System Interface Requirements Matrix
| Interface Type |
| Run Once or Ongoing? |
| Run Frequency (for Ongoing) |
| Sequencing Dependencies |
| External Systems Interface Requirements |
The System Interface Requirements Matrix documents the following:
· Interface Type – Identifies the interface as a Service, Controls, Management, or Device Automation interface.
· Run Once or Ongoing – Designates whether the interface will run once for conversion or be ongoing.
· Run Frequency (for Ongoing) – Designates the run frequency (online or scheduled batch process) for ongoing interfaces. Consider the volume of data, and network and hardware capabilities along with the software application / information system requirements.
· Sequencing Dependencies – Identifies the sequence and any dependencies related to an interface.
· External Systems Interface Requirements – Identifies any requirements for interfaces to external systems (OMB, HHS, etc.) Be sure to note any applicable FDA Data Standards Council data-exchange or terminology standards. [Note: A list of data-exchange and terminology standards is available from the OIM EA Team.] Appendix F: System Interface Mapping Matrix
[Include a copy of the following matrix for each interface.]
System Interface Mapping Matrix
| Table / Field Name |
| Schema Owner |
| Field Label |
| Data Type |
| Field Format |
| Mapping |
| Table |
| Field Name |
The requirements include an interface elements mapping that is builds on the Interface Elements List. Using form PKG0056, map the interface elements by completing the last three columns of the table below.
The System Interface Mapping Matrix documents the following:
· Table / Field Name – The name of the table or data field.
· Schema Owner – The name associated with the creation of the schema.
· Field Label - The label for the field commonly displayed on screens and reports.
· Data Type - The data type as defined by the software application or data dictionary.
· Field Format – The field format masks for numeric, date, character, and other field types.
· Mapping – Designates the type of mapping between the software applications / information systems (e.g., substring, one-to-one, algorithm, etc.)
· Table - The name of the table stored in the data dictionary of the other software application / information system.
· Field Name
· – The name of the data field stored in the data dictionary of the other software application / information system.
Appendix G – System Interface Specification Matrices
[Include a copy of the following matrix for each interface.]
The System Interface Specification Matrices specify how each interface will work, and the technology and approach that will be used to develop each interface. The following matrices provide the information needed to construct the ongoing interfaces:
Program Design Matrix
Hardware
Communications
Third-Party Utilities
Programming Approach
System Capability
Technology
Database Design Matrix
DBMS
Database Design Approach
Programming Approach
How the interface works
Technology
User Interface Design Matrix
Screens
Programming Approach
System Capability
Technology
Security and Integrity Design Matrix
Security Approach
Design
Programming Approach
System Capability
Technology
System Capabilities Matrix
Requirements met by Design
Programming Approach
System Capability
Technology
APPENDIX H: <System Name> and <Interfaced System> Interconnection Security Agreement Below is a copy of the <System Name> and <Interfaced System> Interconnection Security Agreement (ICA) between <System Name> and <Interfaced System>.
<OPDIV or Center>
INTERCONNECTION SECURITY AGREEMENT
BETWEEN
<System Name>
And
<Interfaced System>
SECTION 1 – INTERCONNECTION STATEMENT OF REQUIREMENTS.
The requirement for interconnection between <System Name> and the <Interfaced System> is for the express purpose of exchanging data between these applications.
SECTION 2 – SYSTEM SECURITY CONSIDERATIONS
a. General Information/Data Description.
[Provide general information of the interface between the system and what data is being exchanged.]
<System Name> and <Interfaced System> Interface
b. Technical Requirements
[Include a list and description of any technical requirements, including any triggers or calls for data that may take place.]
c. User Community.
[Specify the specific group(s) of users that will be using this interface.]
e. Information Exchange Security.
[Describe any access to exchange data between systems.]
f. Trusted Behavior Expectations.
[Describe how data is being protected and which regulations or security policies that have been adhered to.]
g. Formal Security Policy.
[List any policy documents that govern the protection of data.]
h. Incident Reporting.
[Discuss how security incidents will be reported and which guidelines for reporting are being used.]
SECTION 3 – TOPOLOGICAL DRAWINGS
[Include diagrams that represent the architecture of the interface.]
SECTION 4 – APPROVALS
[Include signatures from Project Managers for both systems.]
Signature:
Date:
Print Name:
Title:
| Role: |
| Project Manager |
Signature:
Date:
Print Name:
Title:
| Role: |
| Business Owner |
Template Version 2.1 (Last Modified on Oct 29, 2010)
PAGE
File details come from the government source that posted it. Updated .