DI-SESS-82466A

Software Systems Product Design (SSPD)

Describes the system-wide design decisions, architectural design, and detailed design of the training system, providing the acquirer visibility into the design content and support for further training system development.

Approval DateApril 22, 2025

AMSC NumberN10553

Preparing ActivityAS

Project NumberSESS-2025-021

OPR—

DTIC Applicable—

GIDEP Applicable—

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

DI-SESS-82036DI-SESS-82466

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Software Systems Product Design (SSPD) describes the system-wide design decisions, the architectural design, and the detailed design of the training system. The SSPD includes detailed description of the system being developed, procured, maintained, or reused that is generated by specific and discrete task requirements as delineated in the contract.

The SSPD is an engineering Data Item Description (DID) that provides the acquirer visibility into the design content, provides information needed for technical support, and forms the basis for further training system development.

This DID contains the format, content, and intended use information for the data deliverable resulting from the work task described in the solicitation.

Preparation Instructions

1Referenced documentsNot applicable.

2FormatThe SSPD shall be in contractor format.

3ContentThe SSPD shall contain the following:

3.1Title pageThe SSPD shall have a title page providing the following information, as applicable:

3.1.1Document identification numbering

3.1.2Volume number

3.1.3Version or revision indicator

3.1.4Security classification

3.1.5Release date

3.1.6Document title

3.1.7Name of the training system to which this SSPD applies

3.1.8Name of each of the SIs to which this SSPD applies

3.1.9Contract number

3.1.10Contract Data Requirements List (CDRL) item Number

3.1.11Organization for which the document has been prepared

3.1.12Distribution statement

3.1.13Controlled Unclassified Information (CUI)

3.1.14Export-Control warning

3.1.15Destruction notice

3.2Record of changesThe SSPD shall have a record of change from the previous document submission. Each submission shall append the changes to the record of changes section. The submissions shall have track changes turned on to record edits made in the document.

3.3Table of contentsThe SSPD shall have a table of contents providing the number, title, and page number for each titled paragraph, figure, table, and appendix.

3.4Page numberingEach page shall have a unique page number and include the document number, document version, volume, and date, as applicable.

3.5StylesDiagrams, tables, and other presentation styles are acceptable substitutes for text when the data required by this DID can be made more readable using these styles.

3.6Multiple paragraphs and subparagraphsAny section, paragraph, or subparagraph may be written as multiple paragraphs or subparagraphs to enhance readability.

3.7Duplicated contentAny section, paragraph, or subparagraph shall include dissimilar information to avoid the duplication of information.

3.8Design conventionsDesign conventions used within the SSPD to convey the design information shall be described or referenced.

3.9Substitution of existing documentsExisting documents may be substituted for part of the SSPD provided those documents contain the required information as defined by this DID and do not convey additional distribution restrictions to the SSPD. The substitution of existing documents shall be included in the SSPD either as an appendix to supplement the SSPD or as a separate document.

3.10Document topics and numberingThe following paragraph titles and content shall be included in the SSPD.

3.11Content Requirements

3.11.1ScopeThis section shall be divided into the following paragraphs:

3.11.1.1IdentificationThis paragraph shall fully identify the training system to which this SSPD applies, including as applicable, identifying number(s), title(s), abbreviation(s), acronym(s), version number(s), release number(s), and other identifying information.

3.11.1.2System overviewThis paragraph shall summarize the purpose of the training system to which this SSPD applies. It shall describe the general nature of the training system; summarize the training system development history; identify the project sponsor, acquirer, user(s), developer(s), and support agencies; identify current and planned operating sites; and list relevant documents.

3.11.1.3Document overviewThis paragraph shall summarize the purpose of this SSPD and describe the security or privacy considerations associated with its use.

3.11.2Referenced MaterialThis section shall list the title, number, revision, and date of the documents referenced within the SSPD. This section shall identify the source(s) for the documents not available through normal Government procuring activities.

3.11.3Hardware Product(s)This section shall describe the physical environment in which the system must operate. This section shall include the physical resources and hardware components of each subsystem. This section shall identify a list of the planned hardware part numbers from the original equipment manufacturer (OEM) required to satisfy the design. The information for this section shall be divided into the following paragraphs and subparagraphs:

3.11.3.1Identify the hardware components of each subsystemEach hardware component shall be assigned a project-unique identifier.

3.11.3.2Hardware design decisions made in response to requirementssuch as selected approach to providing required flexibility, availability, and maintainability.

3.11.3.3Show bidirectional traceability between the hardware components and hardware requirements

3.11.3.4Show the relationship(s) of the hardware componentsMultiple relationships may be presented, depending on the selected design methodology.

3.11.3.5State the purpose of each hardware componentand identify the requirements and system-wide design decisions allocated to it.

3.11.3.6Identify each hardware component's development status(such as new development, existing hardware component to be reused as is, existing design to be reused as is, existing design or hardware component to be modified, hardware component to be developed for reuse, hardware component planned for Build X, etc.). For existing design or hardware components, the description shall provide identifying information, such as name, version, series, documentation references, location, etc.

3.11.3.7For each hardware component identified for use in each of the subsystems, describe its hardware resources(i.e., the processors, memory, IO devices, data storage, 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 subsystem that will use the resource (e.g., 20% of the resource's capacity allocated to the subsystem 1, 30% to subsystem 2), describe the conditions under which utilization will be measured, and describe the characteristics of the resource:

3.11.3.7.1Descriptions of computer processorsshall include, as applicable, manufacturer name and model number, and processor speed.

3.11.3.7.2Descriptions of memoryshall include, as applicable, manufacturer name and model number and memory size, type, speed, and configuration (i.e., 256MB cache memory, 16GB RAM (4GB x 4)).

3.11.3.7.3Descriptions of IO device(s)shall include, as applicable, manufacturer name and model number, type of device, and device speed and capacity.

3.11.3.7.4Descriptions of storageshall include, as applicable, manufacturer name and model number, type of storage, amount of installed storage, and storage speed.

3.11.3.7.5Descriptions of the network equipmentsuch as network interface cards, hubs, gateways, cabling, high speed data lines, or aggregates of these or other hardware components, shall include, as applicable, manufacturer name and model number, data transfer rates, capacities, network topologies, transmission techniques, and protocols used.

3.11.3.7.6Each descriptionshall also include, as applicable, growth capabilities, diagnostic capabilities, and any additional hardware capabilities relevant to the description.

3.11.4Tradeoff AnalysisThis section shall provide a tradeoff analysis that includes decisions that involve procurement costs, maintenance costs, diminishing or losing on quality, quantity, or property of a set or design in return for gains in other aspects. The section shall include different design concepts and decisions made on the selected designs.

3.11.5Data Rights Assertion List Design ChangesThis section shall identify the rights in technical data, the rights in other than commercial computer software, and the rights in other than commercial computer software documentation as specified in DFARS clauses 252.227-7013 and 252.227-7014. This section shall identify and highlight any data rights assertion changes since contract award and the basis for the assertion and rationale for the assertion change.

3.11.6SI-wide design decisionsThis section shall identify every SI and describe every SI-wide design decision. An SI is an aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process and SI-wide design decisions are those that impact the design of one or more SIs. Supporting rationale shall be included for the SI-wide design decisions that are not explicitly driven by the specified requirements. SI-wide design decisions in response to the requirements shall be identified. The following SI-wide design decisions shall be included as applicable:

3.11.6.1Decisions related to behavior(s) and action(s) in response to each input, state, or condition

3.11.6.2Decisions related to response time and other performance characteristics

3.11.6.3Decisions related to data rights

3.11.6.4Decisions that address critical requirementssuch as safety, cybersecurity or privacy.

3.11.6.5Decisions that depend upon, or are related to, specific training system states or modes

3.11.6.6Decisions regarding each SI's interface with users

3.11.6.7Decisions regarding each SI's inputs and outputs with other distributed training networks (or environment)

3.11.6.8Decisions regarding each SI's inputs and outputs with other SIs

3.11.6.9Decisions regarding each SI's inputs and outputs with hardware configuration items (HWCIs)

3.11.6.10Decisions related to the modeling of the physical platform operational equipment (OE)

3.11.6.11Decisions related to the selection of equations, algorithms, and rules

3.11.6.12Decisions related to the probability of kill, damage assessment, or dead reckoning

3.11.6.13Decisions on the selection of an interoperability standard for distributed simulation

3.11.6.14Decisions related to the handling of improper, un-allowed, and incorrect inputs or conditions

3.11.6.15Decisions regarding how information, data, and databases appear to the user

3.11.6.16Decisions made in response to the requirementssuch as stability, availability, and supportability.

3.11.6.17Decisions related to programming language selection

3.11.6.18Decisions related to the reuse of previously constructed source code

3.11.6.19Decisions related to the implementation of Artificial Intelligence (AI)

3.11.6.20Other SI-Wide design decisions

3.11.7Software Product(s)This paragraph shall identify all commercial and noncommercial software, such as the operating system, hardware device drivers, virtualization technology, computer software, and computer databases for each computational device that stores or processes data. Release date and version number shall be listed for each software item.

3.11.8SI architectural design

3.11.8.1If any part of the architectural design depends upon system states or modesthis dependency shall be indicated within the architectural design.

3.11.8.2If architectural design information is duplicated in more than one paragraphpresent the information once and reference the other paragraphs.

3.11.9SI structure and hierarchy

3.11.9.1This paragraph shall identify the software components (SCs) and the software units (SUs) that comprise the SI for each of the SIsAn SU is defined as the lowest software element and an SC is collection of SUs.

3.11.9.2Each SU shall be assigned a unique project identifierSCs may occur at different levels of a hierarchy within the SI, and the SSPD may refer to SUs by any naming convention that is consistent with the design methodology being used.

3.11.9.3This paragraph shall show the relationship and hierarchy of the SUs that make up the SIMultiple relationships may be presented, depending on the selected design methodology. For example, in an object-oriented design, this relationship may be presented using class diagrams and object structures as well as module and process architectures of the SI.

3.11.9.4This paragraph shall state the purpose of each SU

3.11.9.5This paragraph shall identify each of the SI-wide design decisions applicable to each SU

3.11.9.6This paragraph shall identify the software requirement(s) allocated to each SU

3.11.9.7This paragraph shall identify each SUs development statussuch as new, reused, and modified software. Reused and modified software shall have identifying information such as the original software name/identifier, vendor/source, version, supporting documentation references, etc.

3.11.9.8This paragraph shall describe the allocation of the SI to HWCI(s)

3.11.9.9This paragraph shall describe each of the SI's planned utilization of computer hardware resourcessuch a processor capacity, memory capacity, disk storage capacity, input/output device capacity, and network capacity.

3.11.9.9.1This description shall cover the spare resourcing requirements affecting the SI

3.11.9.9.2The assumptions and conditions on which the utilization data are based shall be describedsuch as during typical usage, worst-case usage, and specific conditions.

3.11.9.9.3Special considerations affecting utilizationsuch as multiprocessors and the use of virtual memory, shall be described.

3.11.9.9.4The utilization shall be described with units of measuresuch as a percent of processor capacity, cycles per second, gigabytes of memory, and kilobytes per second.

3.11.10Concept of executionThis section shall describe the concept of execution among the SUs comprising of the SI for each SI. Diagrams and descriptions shall show the dynamic relationship of the SUs during the operation of the SI. Descriptions of execution flow control, data flow, dynamically controlled sequencing, state transition diagrams, priorities among SUs, interrupt handling, timing & sequencing relationships, exception handling, concurrent execution, and other aspects of dynamic behavior, shall be included as applicable.

3.11.11Interface designThe following subparagraphs shall describe each of the interfaces among the SUs and their interfaces with internal and external interfaces, such as users, other SIs, HWCIs, and other systems.

3.11.11.1Interface identification diagramsEach interface description shall include:

3.11.11.1.1Interface name

3.11.11.1.2Project unique interface identifier

3.11.11.1.3Purpose or type of interface

3.11.11.1.4Priority

3.11.11.1.5Identify the interfacing entity (SU, user, other SIs, HWCIs, and other systems) by its name, number, version, and documentation referenceas applicable.

3.11.11.1.6State which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified(thus having interface requirements imposed on them).

3.11.11.1.7One or more interface diagram(s), as necessary, to depict the interface functionality

3.11.11.1.8Characteristics of the individual data elements provided by the interfaceas applicable:

3.11.11.1.8.1Non-technical data element name (descriptive name)

3.11.11.1.8.2Project unique identifier

3.11.11.1.8.3Technical data element name (e.g. variable name)

3.11.11.1.8.4Data type (e.g. string, integer, float, array, Boolean)

3.11.11.1.8.5Size and format/structure

3.11.11.1.8.6Unit of measure (e.g. seconds, knots, m/s, feet, millibars, degrees)

3.11.11.1.8.7Valid range (enumeration of possible values) (e.g. 00.0 - 99.9; "N, S, E, W", True/False)

3.11.11.1.8.8Accuracy (how correct)

3.11.11.1.8.9Precision (number of significant digits)

3.11.11.1.8.10Priority

3.11.11.1.8.11Timing / frequency

3.11.11.1.8.12Bandwidth / data volume

3.11.11.1.8.13Source (setting or sending entity)

3.11.11.1.8.14Destination (using or receiving entity)

3.11.11.1.8.15Safety, cybersecurity, and privacy constraints

3.11.11.1.9Characteristics of the aggregate data assemblies(e.g., displays, reports, messages, records, arrays, etc., as applicable:

3.11.11.1.9.1Non-technical data assembly name

3.11.11.1.9.2Project unique identifier

3.11.11.1.9.3Data assembly technical name (e.g. record or data structure name used in the code or database)

3.11.11.1.9.4Data elements and their structure/format in the data assembly

3.11.11.1.9.5Data storage medium (e.g. disk, memory)

3.11.11.1.9.6Structure of data elements on or in the storage medium

3.11.11.1.9.7Visual and auditory characteristics of outputting data on displays, reports, messages, etc.such as colors, layouts, fonts, icons, tones, beeps, etc.

3.11.11.1.9.8Relationships between and among other data assemblies

3.11.11.1.9.9Priority

3.11.11.1.9.10Timing / frequency

3.11.11.1.9.11Bandwidth / data volume

3.11.11.1.9.12Source (setting or sending entity)

3.11.11.1.9.13Destination (using or receiving entity)

3.11.11.1.9.14Safety, cybersecurity, and privacy constraints

3.11.11.1.10Characteristics of the interface communication methodsas applicable (Note: Publicly available commercial, and industry standard communication methods may be defined by reference to their documented standard):

3.11.11.1.10.1Project unique identifier

3.11.11.1.10.2Communication link characteristics

3.11.11.1.10.3Communication medium

3.11.11.1.10.4Message or data format

3.11.11.1.10.5Flow control mechanism

3.11.11.1.10.6Data transfer rate (e.g., bandwidth)

3.11.11.1.10.7Synchronous or asynchronous

3.11.11.1.10.8Data transfer interval (e.g., period of transmission)

3.11.11.1.10.9Data routing or addressing mechanism

3.11.11.1.10.10Safety, cybersecurity, and privacy constraints

3.11.11.1.11Characteristics of protocols used by the interfaceas applicable, (Note: Publicly available commercial, and industry standard protocols may be defined by reference to their documented standard):

3.11.11.1.11.1Project unique identifier

3.11.11.1.11.2Technical protocol name

3.11.11.1.11.3Protocol layer used

3.11.11.1.11.4Protocol priority

3.11.11.1.11.5Protocol standard

3.11.11.1.12Physical and other interface characteristicsas applicable:

3.11.11.1.12.1Connector / plug type

3.11.11.1.12.2Communication distance limitations

3.11.11.1.12.3Safety, cybersecurity, and privacy constraints

3.11.12Detailed Design

3.11.12.1This section shall be divided into paragraphs that describe the detailed design of each SU comprising the SI for each SI

3.11.12.2This section shall include bidirectional traceability between the software requirements allocated to each SU, and those requirements allocated to the SI

3.11.12.3The detailed design of each SU shall contain the information necessary to construct the source code that performs the SUs functions as described

3.11.12.4Software unit, or group of unit's unique identifier

3.11.12.4.1This paragraph shall identify a SU by its project unique identifier and shall describe the detailed design of the unit

3.11.12.4.2Alternatively, this paragraph may identify a group of related SUs and describe the detailed design of those SUs in subparagraphsNaming conventions used to group and organize SUs shall be described.

3.11.12.4.3Additional paragraphs and subparagraphs, as applicable, shall be created to describe the SUs

3.11.12.4.4Each SU detailed design description shall include the following informationas applicable:

3.11.12.4.4.1Unit level design decisionssuch algorithms and equations used; response times; handling of improper, un-allowed, and incorrect inputs or conditions; and other decisions similar to those applicable to SI-wide decisions.

3.11.12.4.4.2Constraints, limitations, or unique capabilities and features of the SU design

3.11.12.4.4.3If the SU contains logic, describe the logic to be used by the SUincluding the following:

3.11.12.4.4.3.1Conditions in effect within the SU when execution is initiated

3.11.12.4.4.3.2Conditions under which control is passed to other SUs

3.11.12.4.4.3.3Responses (outputs) and response times to each input, including data conversion, renaming, and data transfer operations

3.11.12.4.4.3.4Sequence of operations and dynamically controlled sequencing during the SU's executionincluding the method and logic of that control.

3.11.12.4.4.3.5Input and output validation checking logic

3.11.12.4.4.3.6Exception and error handling

3.11.12.4.4.4If the SU design contains, receives, or outputs data, a description of its inputs, outputs, other data elements, or aggregate data assemblies shall be provided

3.11.12.4.4.5If the SU design contains local data, describe that dataas applicable.

3.11.12.4.4.6If the SU is a database, then a reference shall be provided to the interface characteristics or provide it here

3.11.13Additional Design ContentThis section shall describe additional design content not included in other sections that were generated by specific and discrete task requirements as delineated in the contract. This section shall also include the derived design content not included in other sections that are not explicitly stated yet are required to satisfy one or more of the requirements.

3.11.14Software AssuranceThis section shall describe the merging of cybersecurity requirements into the software design and the decisions made for minimizing exposure to the vulnerabilities. This section shall describe the methods for handling the impact to the software design of emerging cybersecurity requirements.

3.11.15NotesThis section shall provide an alphabetic listing of acronyms, abbreviations, and their meaning as used in this SSPD list of terms and definitions needed to understand the SSPD or the appendices.

3.11.16AppendixesAppendixes 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. Appendixes shall be lettered alphabetically (A, B, etc.)

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer