This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate

(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.

File: Design Document Template Last updated: 24 September 2018

DESIGN DOCUMENT TEMPLATE

FOR

PROJECT NAME

_______________________________________________
Project Manager Date:

______________________ ____________________
Lead Engineer Date:

_______________________________________________
Program Manager Date:

Page 1 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

Record of Reviews and Changes

Chan
ge ID or CI Date Date Com
# Reviewed A ment Signature
p
p
r
o
v
e
d

Page 2 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

TABLE OF CONTENTS
1. Scope 4
1.1. Identification 4
1.2. Document security 4
1.3. System evolution description (SV-8) 4
1.4. System technology forecast (SV-9) 4
2. System design 5
2.1. System-wide design decisions 5
2.2. System components 5
2.3. Concept of execution between system components 7
2.4. Interface design 7
3. Interface design for external interfaces 7
3.1. External interface design 8
4. Notes 10
5. Documentation and tailoring guidelines 10
5.1. Tailoring instructions 10
6. Appendixes 10

Page 3 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

All paragraphs in this document except for NOTES are mandatory for large requirements
and N/A for small.
Definitions:
Mandatory: at a minimum, information must be included; more information may be added
at Project Manager’s discretion.
A large requirement involves new development or sustainment efforts greater than 1500
work hours or crossing multiple systems.
A small requirement involves sustainment less than 1500 work hours and doesn’t cross
systems.

1. Scope

1.1. Identification
This paragraph shall contain a full identification of the system and software to which this
document applies, including, as applicable, identification number, title, abbreviation,
version number, and release number as applicable. Identification must include the
operating system platform to which this document applies. This section shall list all
applicable standards (AF, DOD, JTA, ANSI, IEEE, etc) that apply to the given design
considerations, to include the StdV-1 section from the CONOPS Para 4.3 and the SRS Para
1.1.
(NOTE: In this template there are references to certain ISP documents using the
abbreviations AV, OV, SV and StdV for All Viewpoint, Operational Viewpoint, System
Viewpoint and Standards Viewpoint. Details on these documents and the concepts guiding
their creation can be found in Department of Defense Architecture Framework (DoDAF),
v2.x. If your project is required to generate ISP documents, then the information in several
parts of this document corresponds to the ISP. In any case, if a corresponding ISP
document exists, you can reference that document instead of recreating the information.)

1.2. Document security

This paragraph shall describe any security or privacy considerations associated with its use.

1.3. System evolution description (SV-8)

This paragraph shall include the planned incremental steps toward migrating a suite of
systems to a more efficient suite, or toward evolving a current system to a future
implementation. (if applicable)

1.4. System technology forecast (SV-9)

This paragraph shall address emerging technologies and software or hardware products that
are expected to be available in a given set of timeframes, and that will affect future
development of the architecture. (if applicable)

Page 4 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

2. System design
Note: The system design presented in this section is only applicable to multiple-CI
projects. In the case of a single-CI project, replace this section with the CI design
information which would normally appear in Appendix A.

2.1. System-wide design decisions

This section shall include a functional decomposition chart detailing the functions
performed by the systems and the information flow among system functions (SV-4). This
section shall include a Physical Data Model that illustrates the physical implementation of
the information of the Logical Data Model, e.g., message formats, file structures, physical
schema (DIV-2). This section shall be divided into paragraphs as needed to present system-
wide design decisions, that is, decisions about the system's behavioral design (how it will
behave, from a user's point of view, in meeting its requirements, ignoring internal
implementation) and other decisions affecting the selection and design of system
components. If all such decisions are explicit in the requirements or are deferred to the
design of the system components, this section shall so state. Design decisions that respond
to requirements designated critical, such as those for safety, security, or privacy, shall be
placed in separate subparagraphs. If a design decision depends upon system states or
modes, this dependency shall be indicated. Design conventions needed to understand the
design shall be presented or referenced. Examples of system-wide design decisions are the
following:
This paragraph shall include an identification of systems and system components and their
interfaces, within and between nodes (SV-1).
2.1.1. Design decisions regarding the inputs the system will accept and the outputs
it will produce, including interfaces with other systems, configuration items,
and users. (For detailed interface information, refer to the applicable Interface
Requirements Agreement (IRA)).
2.1.2. Design decisions on system behavior in response to each input or condition,
including actions the system will perform, response times and other
performance characteristics, description of physical systems modeled, selected
equations, algorithms, rules, and handling of disallowed inputs or conditions.
2.1.3. Design decisions on how system databases and data files will appear to the
user. If part or all of this information is given in Database Specifications
(DSs), they may be referenced.
2.1.4. Selected approach to meeting safety, security, and privacy requirements
2.1.5. Other system-wide design decisions made in response to requirements, such
as selected approach to providing required flexibility, availability, and
maintainability.

2.2. System components

This paragraph shall:

Page 5 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

2.2.1. Identify the components of the system (Hardware Configuration Items

(HWCIs), CIs, and manual operations). Each component shall be assigned a
project-unique identifier.
2.2.2. Show the static (such as "has a" and "is a") relationship of the components.
Multiple relationships may be presented, depending on the selected design
methodology.
2.2.3. State the purpose of each component and identify the system requirements
and system-wide design decisions allocated to it.
2.2.4. Identify each component's development status and type, if known (such as
new development, existing component to be reused as is, existing design to be
reused as is, existing design or component to be re-engineered, component to
be developed for reuse, component planned for Build N, etc.) For existing
designs or components, the description shall provide identifying information,
such as name, version, documentation references, location, etc.
2.2.5. For each computer system or other aggregate of computer hardware
resources identified for use in the system, describe its computer hardware
resources (such as processors, memory, input and output devices, auxiliary
storage, and communications and network equipment). Each description shall,
as applicable, identify the configuration items that will use the resource,
describe the allocation of resource utilization to each CI that will use the
resource (for example, 20% of the resource's capacity allocated to CI 1, 30%
to CI 2), describe the conditions under which utilization will be measured, and
describe the characteristics of the resource:
2.2.5.1. Descriptions of computer processors shall include, as applicable,
manufacturer name and model number, processor speed or capacity,
identification of instruction set architecture, applicable compiler, word
size (number of bits in each computer word), character set standard (such
as ASCII, EBCDIC), and interrupt capabilities.
2.2.5.2. Descriptions of memory shall include, as applicable, manufacturer
name and model number and memory size, type, speed, and
configuration (such as 256K cache memory, 16MB RAM (4MB x 4)).
Descriptions of input and output devices shall include, as applicable,
manufacturer name and model number, type of device, and device speed
or capacity.
2.2.5.3. Descriptions of auxiliary storage shall include, as applicable,
manufacturer name and model number, type of storage, amount of
installed storage, and storage speed.
2.2.5.4. Descriptions of communications and network equipment, such as
modems, network interface cards, hubs, gateways, cabling, high speed
data lines, or aggregates of these or other components, shall include, as
applicable, manufacturer name and model number, data transfer rates and

Page 6 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

capacities, network topologies, transmission techniques, and protocols

used.
2.2.5.5. A Systems Communication Description Template shall be produced.
This template shall depict the physical nodes and their related
communications lay downs.
2.2.5.6. Each description shall also include, as applicable, growth
capabilities, diagnostic capabilities, and any additional hardware
capabilities relevant to the description.
2.2.6. Present a specification tree for the system; that is, a diagram that identifies
and shows the relationships among the planned specifications for the system
components.

2.3. Concept of execution between system components

This section shall describe the concept of execution among the system components. It shall
include diagrams and descriptions showing the dynamic relationship of the components;
that is, how they will interact during system operation, including, as applicable: flow of
execution control, data flow, dynamically controlled sequencing, state transition diagrams,
timing diagrams, priorities among components, handling of interrupts, timing and
sequencing relationships, exception handling, concurrent execution, dynamic allocation or
de-allocation, dynamic creation or deletion of objects, processes, tasks, and other aspects of
dynamic behavior. This section shall also include a Systems Matrix showing the
relationships between the various systems in the given architecture. The Matrix can be
designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing
interfaces, etc. (SV-3). This section shall contain a system data exchange matrix; detailing
of data exchanges between system elements applications and hardware allocated to system
elements (SV-6). This section shall also contain a System Performance Parameters Matrix,
if applicable. A System Performance Parameters Matrix details the performance
characteristics of each system hardware and software elements, for the appropriate
timeframe (SV-7). Furthermore, this section shall include a list of any constraints that are
imposed on the system’s functionality due to some aspect of systems design or
implementation, a graphic detailing the responses of the system to events, and system-
specific refinements of critical sequences of events described in the operational viewpoint.
(SV-10 (a, b, c)) and services viewpoint (SvcV-10 (a, b, c)).

2.4. Interface design

This section shall contain a high-level description of interfaces between system
components. If design depends on system states or modes, this dependency shall be
identified. Diagrams may be included, as desired. This section can be omitted if this
information is incorporated into the previous paragraph.

3. Interface design for external interfaces

This section shall describe the interface characteristics of one or more systems, subsystems,
configuration items, manual operations, or other system components with external
interfaces. If part or all of the design depends upon system states or modes, this

Page 7 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

dependency shall be indicated. If design information falls into more than one paragraph, it
may be presented once and referenced from the other paragraphs. If part or all of this
information is documented elsewhere, it may be referenced. Design conventions needed to
understand the design shall be presented or referenced.

3.1. External interface design

This paragraph shall identify system or CI external interface characteristics.
Project-unique identifier of interface
There shall be an instance of this paragraph for each interface. Each paragraph shall
identify a system or CI external interface by project-unique identifier, shall briefly identify
the interfacing entities, and shall be subdivided into subparagraphs as needed to describe
the interface characteristics of one or both of the interfacing entities. If a given interfacing
entity is not covered by this DD (for example, an external system) but its characteristics
need to be mentioned to describe interfacing entities that are, these characteristics shall be
stated as assumptions or as "When (the entity not covered) does this, the (the entity not
covered) will." This paragraph may reference other documents (such as data dictionaries,
standards for communication protocols, and standards for user interfaces) in place of
stating the information here. The design descriptions shall include the following, as
applicable, presented in any order suited to the information to be provided, and shall note
any differences in these characteristics from the point of view of the interfacing entities
(such as different expectations about the size, frequency, or other characteristics of data
elements):
3.1.1. Priority assigned to the interface by the interfacing entities
3.1.2. Type of interface (such as real-time data transfer, storage-and-retrieval of
data, etc.) to be implemented
3.1.3. Characteristics of individual data elements that the system or CI must
provide, store, send, access, and receive, etc., such as:
3.1.3.1. Names or identifiers
3.1.3.1.1. Project-unique identifier
3.1.3.1.2. Non-technical (natural-language) name
3.1.3.1.3. DoD standard data element name
3.1.3.1.4. Technical name (e.g., variable or field name in code or database)
3.1.3.1.5. Abbreviation or synonymous names
3.1.3.2. Data type (alphanumeric, integer, etc.)
3.1.3.3. Size and format (such as length and punctuation of a character
string)
3.1.3.4. Units of measurement (such as meters, dollars, nanoseconds)
3.1.3.5. Range or enumeration of possible values (such as 0-99)
3.1.3.6. Accuracy (how correct) and precision (number of significant digits)

Page 8 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

3.1.3.7. Priority, timing, frequency, volume, sequencing, and other

constraints, such as whether the data element may be updated and
whether business rules apply
3.1.3.8. Security and privacy constraints
3.1.3.9. Sources (setting or sending entities) and recipients (using or
receiving entities)
Characteristics of data element assemblies (records, messages, files, arrays, displays,
reports, etc.) that the interfacing entities must provide, store, send, access, receive, etc.,
such as:
(1) Names or identifiers
(a) Project-unique identifier
(b) Non-technical (natural language) name
(c) Technical name (e.g., record or data structure name in code or database)
(d) Abbreviations or synonymous names
(2) Data elements in the assembly and their structure (number, order, grouping)
(3) Medium (such as disk) and structure of data elements and assemblies on the
medium
(4) Visual and auditory characteristics of displays and other outputs (such as colors,
layouts, fonts, icons and other display elements, beeps, lights)
(5) Relationships among assemblies, such as sorting and access characteristics
(6) Priority, timing, frequency, volume, sequencing, and other constraints, such as
whether the assembly may be updated and whether business rules apply
(7) Security and privacy constraints
(8) Sources (setting or sending entities) and recipients (using or receiving entities)
Characteristics of communication methods that the interfacing entities must use for the
interface, such as:
(1) Project-unique identifiers
(2) Communication links, bands, frequencies, media and their characteristics
(3) Message formatting
(4) Flow control (such as sequence numbering and buffer allocation)
(5) Data transfer rate, whether periodic or aperiodic, and interval between transfers
(6) Routing, addressing, and naming conventions
(7) Transmission services, including priority and grade
(8) Safety, security, and privacy considerations, such as encryption, user
authentication, compartmentalization, and auditing

Page 9 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

3.1.4. Characteristics of protocols the system must use for the interface, such as:
3.1.4.1. Project-unique identifier
3.1.4.2. Priority or layer of the protocol
3.1.4.3. Packeting, including fragmentation and re-assembly, routing, and
addressing
3.1.4.4. Legality checks, error control, and recovery procedures
3.1.4.5. Status, identification, and any other reporting features
3.1.5. Other characteristics, such as physical compatibility of the interfacing
entities (dimensions, tolerances, loads, plug compatibility, etc.), voltages, etc.

4. Notes
This section shall contain any general information that aids in understanding this document
(e.g., background information, rationale). Ensure that all definitions of terms used in all
products are captured in the Integrated Dictionary. (AV-2)

5. Documentation and tailoring guidelines

5.1. Tailoring instructions

For each paragraph within this document which is tailored out, mark the appropriate cell in
the "Project Tailor" column with an "X". Use the "Comments" column to justify the
decision to tailor out the paragraph.

6. Appendixes
The design for each CI will be documented in its own appendix. Appendixes shall be
lettered alphabetically (A, B, etc.).
Note: When a project consists of a single CI, there is no need to relegate CI design to an
appendix. Instead, replace the System Design section with the CI design that would
normally appear in Appendix A.
Additional appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would
normally have been provided. Appendixes may be bound as separate documents for ease in
handling.

Page 10 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

APPENDIX A
DESIGN OF CI < insert applicable CI number >
A.1 Identification. This paragraph shall contain a full identification of CI to which this
section applies, including, as applicable, identification number, title, abbreviation, version
number, and release number.
A.2 CI-wide design decisions. This section shall include a functional decomposition chart
detailing the functions performed by the system and the information flow among system
functions (SV-4). This section shall also include an identification of system and system
components and their interfaces, within and between nodes (SV-1). (Note: The SV-1 and
SV-4 listed here are not the same as the SV-1 and SV-4 listed in the System Design section.
The System-Wide Design Decisions paragraph refers to how the system relates to other
systems within the architecture. In this section SV-1 and SV-4 need to be reproduced with
a reference to how sub-systems and components relate to each other and the system as a
whole). This section shall include a Physical Data Model that illustrates the physical
implementation of the information of the Logical Data Model, e.g., message formats, file
structures, physical schema (DIV-2). This section shall be divided into paragraphs as
needed to present CI-wide design decisions, that is, decisions about the CI's behavioral
design (how it will behave, from a user's point of view, in meeting its ++++++++
+requirements, ignoring internal implementation) and other decisions affecting the
selection and design of the software units that make up the CI. If all such decisions are
explicit in the requirements or are deferred to the design of the software units, this section
shall so state. Design decisions that respond to requirements designated critical, such as
those for safety, security, or privacy, shall be placed in separate subparagraphs. If a design
decision depends upon system states or modes, this dependency shall be indicated. Design
conventions needed to understand the design shall be presented or referenced. Examples of
CI-wide design decisions are the following:
a. Design decisions regarding inputs the CI will accept and outputs it will produce,
including interfaces with other systems, HWCIs, configuration items, and users. (for
detailed interface information, refer to the applicable IRAs).
b. Design decisions on CI behavior in response to each input or condition, including
actions the CI will perform, response times and other performance characteristics,
description of physical systems modeled, selected equations, algorithms, rules, and
handling of non-allowed inputs or conditions.
c. Design decisions on how databases and data files will appear to the user. If part or
all of this information is given in Database Specifications (DSs), they may be referenced.
d. Selected approach to meeting safety, security, and privacy requirements.
e. Other CI-wide design decisions made in response to requirements, such as selected
approach to providing required flexibility, availability, and maintainability.
A.3 Preliminary Design
A.3.1 Software Unit Identification. This paragraph shall:

Page 11 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

a. Identify the software units that comprise the CI. Each software unit shall be assigned
a project-unique identifier.
Note: A software unit is an element in the design of a CI; for example, a major subdivision
of a CI, a component of that subdivision, a class, object, module, function, routine, or
database. Software units may occur at different levels of a hierarchy and may consist of
other software units. Software units in the design may or may not have a one-to-one
relationship with the code and data entities (routines, procedures, databases, data files, etc.)
that implement them or with the computer files containing those entities. A database may
be treated as a CI or as a software unit. The DD may refer to the software units by any
name consistent with the design methodology being used. Refer to the Definition of Terms
Lexicon and Work Breakdown Structure (WBS) Definitions for a graphic depiction and
discussion of the relationships of software units.
b. Show the static (such as "consists of") relationship of the software units. Multiple
relationships may be presented, depending on the selected software design methodology
(for example, in an object-oriented design, this paragraph may present the class and object
structures, as well as the module and process architectures of the CI).
c. State the purpose of each software unit and identify the CI requirements and CI-wide
design decisions allocated to it.
d. Identify each software unit's development status or type (such as new development,
existing design or software to be reused as is, existing design or software to be re-
engineered, software to be developed for reuse, software planned for Build N, etc.) For
existing design or software, the description shall provide identifying information, such as
name, version, documentation references, library, etc.
e. Describe the CI’s (and as applicable, each software unit's) planned utilization of
computer hardware resources (such as processor capacity, memory capacity, input and
output device capacity, auxiliary storage capacity, and communications and network
equipment capacity). The description shall cover all computer hardware resources included
in resource utilization requirements for the CI, in system-level resource allocations
affecting the CI, and in resource utilization measurement planning in the Software
Development Plan. If all utilization data for a given computer hardware resource are
presented in a single location, such as in one DD, this paragraph may reference that source.
Included for each computer hardware resource shall be:
(1) The CI requirements or system-level resource allocations being satisfied
(2) The assumptions and conditions on which the utilization data are based (for
example, typical usage, worst-case usage, assumption of certain events)
(3) Any special considerations affecting the utilization (such as use of virtual memory,
overlays, or multiprocessors or the impacts of operating system overhead, library software,
or other implementation overhead)
f. The units of measure used (such as percentage of processor capacity, cycles per
second, bytes of memory, kilobytes per second)

Page 12 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

g. The level at which the estimates or measures will be made (such as software unit, CI,
or executable program)
h. Identify the program library in which the software that implements each software
unit is to be placed.
A.3.2 Concept of Execution Between Software Units. This section shall describe the
concept of execution among the software units. It shall include diagrams and descriptions
showing the dynamic relationship of the units, that is, how they will interact during CI
operation, including, as applicable: flow of execution control, data flow, dynamically
controlled sequencing, state transition diagrams, timing diagrams, priorities among
components, handling of interrupts, timing and sequencing relationships, exception
handling, concurrent execution, dynamic allocation or de-allocation, dynamic creation or
deletion of objects, processes, tasks, and other aspects of dynamic behavior. This section
shall also include a Systems Matrix showing the relationships among the various systems in
the given architecture. The matrix can be designed to show relationships of interest, e.g.,
system-type interfaces, planned vs. existing interfaces, etc. (SV-3). This section shall
contain a system data exchange matrix; detailing of data exchanges among system elements
applications and hardware allocated to system elements (SV-6). This section shall also
contain a System Performance Parameters Matrix, if applicable. A System Performance
Parameters Matrix details the performance characteristics of each system hardware and
software elements, for the appropriate timeframe (SV-7). Furthermore, this section shall
include a list of any constraints that are imposed on the system’s functionality due to some
aspect of system’s design or implementation, a graphic detailing the responses of the
system to events, and system-specific refinements of critical sequences of events described
in the operational viewpoint (SV-10 (a, b, c)). (Note: The SV-3 and SV-10 listed here are
not the same as the SV-3 and SV-10 listed in the System Design section. The System
Design section refers to how the system relates to other systems within the architecture. In
this appendix, SV-3 and SV-10 need to be reproduced with a reference to how sub-systems
and components relate to each other and the system as a whole).
A.3.3 Interface Design. This section shall contain a high-level description of interfaces
between software units and with external systems. If design depends on system states or
modes, this dependency shall be identified. Diagrams may be included, as desired. For
more detailed information, the reader will be referred to the applicable IRAs. This section
can be omitted if this information is incorporated into the previous paragraph.
A.4 Detailed Design.
This section shall be divided into the following paragraphs to describe each software unit
of the CI (one paragraph per software unit). Design conventions needed to understand the
design shall be presented or referenced.
A.4.x < Project-unique identifier of software unit “x” >. There shall be an instance of this
paragraph for each software unit. Each paragraph shall identify a software unit by a
project-unique identifier and shall describe the unit. The description shall include the
following information, as applicable. Software units that contain other software units may
reference the descriptions of those units rather than repeating information.
a. Unit design decisions, if any, such as algorithms to be used, if not previously selected

Page 13 of 14
 This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.
File: Design Document Template Last updated: 24 September 2018

b. Any constraints, limitations, or unusual features in the design of the software unit
-The programming language to be used and rationale for its use if other than the specified
CI language
c. If the software unit consists of or contains procedural commands (such as menu
selections in a database management system (DBMS) for defining forms and reports, on-
line DBMS queries for database access and manipulation, input to a graphical user
interface (GUI) builder for automated code generation, commands to the operating system,
or shell scripts), a list of the procedural commands and reference to user manuals or other
documents that explain them.
d. If the software unit contains, receives, or outputs data, provide a description of its
inputs, outputs, and other data elements and data element assemblies, as applicable. Data
local to the software unit shall be described separately from data input to or output from the
software unit. If the software unit is a database, a corresponding DS shall be referenced;
interface characteristics may be provided here.
e. If the software unit contains logic, the logic to be used by the software unit,
including, as applicable:
(1) Conditions in effect within the software unit when its execution is initiated
(2) Conditions under which control is passed to other software units
(3) Response and response time to each input, including data conversion, renaming,
and data transfer operations
(4) Sequence of operations and dynamically controlled sequencing during the
software unit's operation, including:
(a) The method for sequence control
(b) The logic and input conditions of that method, such as timing variations,
priority assignments
(c) Data transfer in and out of memory
(d) The sensing of discrete input signals, and timing relationships between
interrupt operations within the software unit
(5) Exception and error handling

Page 14 of 14