The internal design document describes the detailed system and subsystem designs that will be used in developing the information system. It contains the database design, file structures, input formats, output layouts, and module processing logic to be used by the project team during system development. The sections and subsections of the internal design document may be organized, rearranged, or repeated as necessary to reflect the best organization for a particular project. The internal design document is outlined in Exhibit 6-2.
1. Introduction
a. Purpose and Scope. Provide a description of the internal design document purpose and scope in this section.
b. Organization of this Document. Describe the organization of the internal design document.
c. Points of Contact. Provide the organization 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, system developer, programmer analyst, quality assurance manager, security manager, configuration manager and other points of contact as appropriate.
d. 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, functional requirements document, data management plan, computer security plan, and external design document.
1. Introduction
a. Purpose and Scope
b. Organization of this Document c. Points of Contact
d. Project References e. Glossary
2. System Design Overview a. System Architecture b. Subsystem Architecture 3. Unit Design Organization 4. File and Data Base Design
a. Data Base Management System Files b. Non-Data Base Management System Files 5. Input and Output Design
a. System Input Design b. System Output Design 6. Detailed Module Design 7. Traceability
Exhibit 6-2: Internal Design Document Outline
e. 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 Design Overview
Describe the system and subsystem architectures and their design specifications in the this section.
a. System Architecture. Describe the system architecture and structure of the automated system. The overview information in this section may partially repeat some of the content of the external design document (e.g., the system description, the flow diagrams). Include the following in this section:
o A narrative description of the system. Describe all input and output of the system.
o A high-level system schematic to illustrate the overall architecture.
Provide the breakout of subsystems and the interfaces between subsystems within the system in this diagram or another diagram, as appropriate. Show interfaces to external systems and
telecommunications systems in the system architecture.
o A high-level process flow, data flow and control flow diagrams of flows that occur within the system architecture. The flow diagrams should trace the system operations from initial data input through final output.
o A system data dictionary that is complete up to this point in the system development process.
b. Subsystem Architecture. Define the next lower-level of design
specification for each subsystem within the system. Include the following in this section:
o A diagram of each subsystem. Provide a diagram showing the
breakout of design units within each subsystem, either on the subsystem diagram or on another diagram.
o A narrative description of each subsystem. Describe all input and output of the subsystem.
o The process flow, data flow, and control flow diagrams for flows that occur within the subsystem. The diagrams should trace the system operations from initial data input through final output.
3. Unit Design Organization
Describe the segmentation of the system into subsystems (this section may reference the external design document); segmentation of the subsystems into design units (a subsystem may map to one or more than one design unit per subsystem); and the segmentation of design units into design modules. Show the relationship between design modules and the projected actual computer program compilation units graphically or in tables. There may be one or more than one design module per program compilation unit depending on the software design approach and the computer languages used. The degree and type of modularity above may be modified as necessary for the project under development.
Use structured organization diagrams which show the various segmentation levels down to the lowest level. All features on the diagrams should have reference numbers and names. Include a narrative which expands upon and enhances the understanding of the functional breakdown.
4. File and Data Base Design
Define the final design of all DBMS files and the non-DBMS files associated with the system under development in this section. Additional information may added as required for the particular project.
a. Data Base Management System Files. Define the final design of the DBMS files and include the following information:
o The final logical design. Depending on the DBMS, third or fourth normal form table layouts, entity-relationship diagrams of the data base structure, or other logical design information should be provided.
o A physical description of the DBMS schemas, subschemas, records, sets, tables, storage page sizes, etc.
o Access methods (e.g., indexed, via set, sequential, random access, sorted pointer array, etc.).
o 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.
o Definition of the update frequency of the data base tables, views, files, areas, records, sets, data pages, etc. Estimate the number of transactions if the data base is an on-line transaction based systems.
b. Non-Data Base Management System Files. Provide the detailed description of all non-DBMS files and include the following information:
o A narrative description of the usage of each file; including whether the file is used for input, output, or both; whether this file is a temporary file; an indication of which modules read and write the file, etc.; and
o File structures. Include information that will:
- identify record structures;
- identify record keys or indexes;
- identify or reference data elements within the records;
- define record length (fixed or maximum variable length);
- define 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; and
- define the update frequency of the file. If the file is part of an on-line transaction based system, provide the estimated number of transactions per unit time, and the statistical mean, mode and distribution of those transactions.
5. Input and Output Design
Provide the detailed design of the system and subsystem inputs and outputs. Any additional information may be added to this section and may be organized
according to whatever structure best presents the system input and 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.
a. System Input Design. Describe the system input design by providing the following:
o The input media used for external data transfers. For example, electronic data interchange, magnetic tape, scanned paper, etc. If appropriate, the input record types, file structures, and data base structures provided in the File and Data Base Design section may be referenced. Define data element definitions.
o The layout of all input data screens. Provide a graphic
representation of the screen. Define or reference all data elements associated with the screen.
o Edit criteria for the data elements. The following types of edits could be performed:
- specific values;
- range of values;
- mandatory/optional;
- numeric, alphabetic values; and - length.
o Miscellaneous messages associated with screen inputs:
- copies of the form if the input data is to be 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; and
- the Privacy Act Warning incorporated into the screen flow if the system is covered by the Privacy Act.
b. System Output Design. Provide a description of the system output design. System outputs include reports, data display screens, and files.
The output files are defined in Section 4, File and Data Base Design, and may be repeated or referenced. The following should be provided, if appropriate:
o Identification of codes and names for reports and data display screens.
o Description of report and screen contents. Provide a graphic representation of the report or screen layout. Define or reference all data elements associated with the report or screen.
o Identification and description of output files.
o Description of the purpose of the output, including identification of the primary users.
o Report distribution requirements, if any.
o Description of any access restrictions or security considerations.
o Description of any form requirements.
6. Detailed Module Design
A 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 program.
Provide all of the detailed information logic,
and data necessary to correctly write source code for all modules in the system in this section. At the point at which this document is written, development of the detailed design has been completed for the modules, and that design is documented in this section.
If there is a large number of modules, or if the module documentation is bulky, place it in an appendix or in a separate document. Add additional diagrams and information if necessary to describe the module, its functions, and structure adequately. For state-of-the-art software development areas, such as expert system development and object-oriented design, industry-standard module specification practices should be followed. Include the following information in the detailed module designs:
o The layout of all input data screens.
o 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.
o Data elements, record structures, and file structures associated with module input and output.
o 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.).
o 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 here.
o Report layout.
7. Traceability
Enhance the traceability matrix created in the FRD to include features from the internal 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.
The requirements matrix may be broken up into segments. For example, a
separate matrix of the internal design document paragraphs may trace to particular paragraphs in the external design document and the functional requirements document may be provided.