The external design document describes the requirements, operating environment and design characteristics for an information system. The external design document is used in conjunction with the functional requirements document to provide a complete system specification of all user requirements for the system. The external design document includes all information required for the review and approval of the project development during the external design as outlined in Exhibit 6-1.
1. Introduction
a. Purpose and Scope. Provide a description of the external design document purpose and scope in this section.
b. Project Executive Summary. Provide a description of the project from a management perspective. Provide an overview of the framework within which the high-level system design took place. Include the following information in the summary if appropriate.
(1) System Overview. Describe the system in narrative form using non-technical terms. 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 show interfaces to external systems, if applicable. Provide a high-level data flow diagram for the system and subsystems, if
applicable.
(2) Design Constraints. Describe any constraints in the system design. Describe any assumptions made by the project team in developing the system design.
1. Introduction
a. Purpose and Scope
b. Project Executive Summary (1) System Overview (2) Design Constraints (3) Future Contingencies c. Organization of this Document d. Points of Contact
e. Project References f. Glossary
2. System and Subsystem Specification a. System/Subsystem Overview b. Specification Model
(1) Process Model
(a) Manual Components (b) Automated Components (2) Logical Data Model
(3) Physical Data Model c. External System Interfaces d. Data Communications Interfaces e. Data Control and Audits
3. Procedural Requirements 4. Traceability
Figure 6-1: External Design Document Outline
(3) Future Contingencies. Describe any contingencies that might arise in the design of the system.
c. Organization of this Document. Describe the organization of the external design document.
d. Points of Contact. Provide 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, project sponsor and/or functional manager, project user, quality assurance manager, security manager, and configuration manager, as appropriate.
e. Project References. Provide a bibliography of key project references and deliverables which have been produced prior to this point. For example, these references might include the project plan, feasibility study, cost-benefit analysis, acquisition plan, quality assurance plan, configuration management plan, data management plan, and functional requirements document.
f. Glossary. Provide a glossary of all terms and abbreviations used in the document. If the glossary is several pages in length, it may be placed as an appendix.
2. System and Subsystem Specifications
Describe the system and subsystem specifications for the project in this section.
Provide a summary of the intended capability of system and subsystems in terms of major components (specification model, manual components, automated
components, interfaces, networks, and audits). Add as much detail as necessary to fully define all external specifications that will satisfy the system design objectives.
a. System and Subsystem Overview. This overview supplements the project executive summary with the following additional technical details.
o A narrative description of the preliminary design of the system
identified in the project executive summary with a detailed description of each subsystem.
o High-level diagrams of each subsystem with more detail than the diagrams in the project executive summary, if more detail is known at this point.
o A matrix of requirements versus design components.
b. Specification Model. Describe the specification model in terms of a work flow model, logical data model, and physical data model, if appropriate.
Include the following data.
(1) Process Model. Provide work flow or process flow diagrams that were used to define the sequence of work activities within the processes being automated. Provide the parts of the work flow or process flow that will remain as manual processes graphically, if possible. Provide the lowest level (greatest detail) of processes developed at this point. The manual and automated parts of the work flow or process flow are discussed in more details below.
If the work flow or process flows have been developed in detail in the functional requirements document, those sections may be referenced here. It may be appropriate to repeat the diagrams here.
(a) Manual Components. Describe the processes that will be accomplished manually. Include a discussion of the analyses performed to identify alternatives for manual components; a matrix of the manual components and the requirements addressed by them; and references to other documents which will offer greater detail on manual activities, such as procedures manual.
(b) Automated Components. Describe the automated support offered to the user, i.e., the parts of the work flows or process flows that are being automated. Include a
discussion of the analyses performed to identify alternatives for software components; and a matrix of software
components and the requirements addressed by the
components.
(2) Logical Data Model. Provide detailed data flow diagrams, data element definitions for items on the data flow diagrams, input and output data flow diagrams, and control flow diagrams, if
appropriate. Where appropriate, provide the following:
o Data flow diagrams, which are at a greater level of detail (for the lower level, more detailed processes) than provided in the project executive summary. Provide data dictionary definitions for the data elements within the data flows. This may replicate some of the information contained in the functional requirements document.
o Input and output designs - the data flow summaries and layouts for each automated system input and output declared on the subsystem level data flow diagrams.
o Provide control flow diagrams if the system is an on-line transaction processing data base system or other system that allows system data flows and controls flows to be specified, structured, and manipulated separately.
o Develop a logical data model for subsystems in accordance with the data administration guidelines.
o For data base management systems, include additional logical diagrams; i.e., entity-relationship diagrams, table structures, etc.
(3) Physical Data Model. Describe the physical record and file
structures. For conversion applications and maintenance of existing systems, a physical data model would exist. Identify the change to be made for implementation in the Internal Design Phase. If available, provide:
o For DBMSs, a physical description of the DBMS schemas, subschemas, records, sets, tables, files, etc.,
for DBMSs. Provide physical size and storage requirements for both online and offline.
o For non-DBMSs, the file organization (e.g., sequential, index sequential, and random access file structures).
Provide the record layout, and projected file volume of data.
Define the transfer medium (e.g., tape or disk).
c. External System Interfaces. Address the design of interfaces to external systems. Reference the external interface requirements sections of the functional requirements document. Also provide diagrams of the interfaces at the subsystem level; file, record, table, and data base schema structures involved in the interface of both the external system and the system under development; definitions for data elements involved in external interfaces;
and access control features of the external system and the system under development.
d. Data Communications Interfaces. Provide a logical and physical specification of any interface to data communications networks. Provide diagrams of the interfaces to the network(s) when feasible. Describe or reference the hardware and software of the communications network itself.
e. Data Control and Audits. Describe the audit trails which will enable the user to track any one transaction from its original source to final storage in some given data base or file, and from output back to its original source.
Describe the user data interfaces as they relate to the preservation of control.
3. Procedural Requirements
Address all system procedural requirements from a user's perspective. Describe how the data is entered into the automated system; describe how file recovery or reconstruction will take place; and address full backup procedures in case of a total or partial system failure or central shutdown which should reference the
contingency plan.
4. Traceability
Enhance the traceability matrix created in the FRD to include features from the external design which address user requirements. This matrix begins with the user
requirements and assists in tracing how the requirements are addressed in
subsequent phases and documents, such as the external design document, internal design document and test plans.