J016 RIPSA Tech Description DIDs.doc

DATA ITEM DESCRIPTION

3. Description/Purpose

3.1 The System Design Description (SDD) describes the system- or subsystem-wide design and the architectural design of a system or subsystem. The SDD may be supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs) as described in Block 7 below.

3.2 The SDD, with its associated IDDs and DBDDs, is used as the basis for further system development.

TBD

7. Application/Interrelationship

This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by specific and discrete task requirements as delineated in the contract. This DID is used when the developer is tasked to define and record the design of a system or subsystem. Design pertaining to interfaces may be presented in the SDD or in IDDs. The Contract Data Requirements List (CDRL) should specify whether deliverable data are to be delivered on paper or electronic media; are to be in a given electronic form (such as ASCII, CALS, or compatible with a specified word processor or other support software); may be delivered in developer format rather than in the format specified herein; and may reside in a computer-aided software engineering (CASE) or other automated tool rather than in the form of a traditional document.

N/A

A001

10. Preparation Instructions

10.1 General instructions.

a. Automated techniques – Use of automated techniques is encouraged. The term "document" in this DID means a collection of data regardless of its medium.

b. Alternate presentation styles – Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required by this DID can be made more readable using these styles.

c. Title page or identifier – When data are delivered in the form of a traditional document, the Document must include a title page containing, as applicable: document number; volume number; version/revision indicator; security markings or other restrictions on the handling of the document; date; document title; name, abbreviation, and any other identifier for the system, subsystem or item to which the document applies; contract number; CDRL item number; organization for which the document has been prepared; name and address of the preparing organization; and distribution statement. For data delivered in an alternative form, this information must be included on external and internal labels or by equivalent identification methods.

d. Table of contents – When data are delivered in the form of a traditional document, the document must contain a table of contents providing the number, title, and page number of each titled paragraph, figure, table, and appendix. For data delivered in an alternative form, this information must consist of an internal or external table of contents containing pointers to, or instructions for accessing, each paragraph, figure, table, and appendix or their equivalents.

Substitution of existing documents - Commercial or other existing documents may be substituted for all or part of the document if they contain the required data.

10.2 Content requirements – The numbers shown designate the paragraph numbers to be used in the document. Each such number is understood to have the prefix "10.2" within this DID. For example, the paragraph numbered 1.1 is understood to be paragraph 10.2.1.1 within this DID.

1.

Scope – This section must be divided into the following paragraphs.

1.1 Identification – This paragraph must contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System overview – This paragraph must briefly state the purpose of the system to which this document applies. It must describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support organizations; identify current and planned operating sites; and list other relevant documents.

1.3 Document overview – This paragraph must summarize the purpose and contents of this document and must describe any security or privacy considerations associated with its use.

2.

Referenced documents – This section must list the number, title, revision, and date of all documents referenced in this document. This section must also identify the source for all documents not available through normal Government stocking activities.

3.

System-wide design decisions – This section must 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 must so state. Design decisions that respond to requirements designated critical, such as those for safety, security, or privacy, must be placed in separate subparagraphs. If a design decision depends upon system states or modes, this dependency must be indicated. Design conventions needed to understand the design must be presented or referenced. Examples of system-wide design decisions are the following:

Preparation Instructions Continued a.

Design decisions regarding inputs the System will accept and outputs it will produce, including interfaces with other systems, HWCIs, Systems, and users (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Interface Design Descriptions (IDDs), they may be referenced.

b.

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 unallowed inputs or conditions.

c.

Design decisions on how system databases/data files will appear to the user (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Database Design Descriptions (DBDDs), they may be referenced.

d.

Selected approach to meeting safety, security, human factors and privacy requirements.

e.

Design and construction choices for hardware or hardware-software systems, such as physical size, color, shape, weight, materials, and markings

f. Other System-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.

4.

System architectural design – This section must be divided into the following paragraphs to describe the system architectural design. If part or all of the design depends upon system states or modes, this dependency must be indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design must be presented or referenced.

Note: For brevity, this section is written in terms of organizing a system directly into Hardware Configuration Items (HWCIs), Computer Software Configuration Items (CSCIs), and manual operations, but should be interpreted to cover organizing a system into subsystems, organizing a subsystem into HWCIs, CSCIs, and manual operations, or other variations as appropriate.

4.1 System components – This paragraph must:

a.

Identify the components of the system (HWCIs, CSCIs, and manual operations). Each component must be assigned a project-unique identifier. Note: a database may be treated as a CSCI or as part of a CSCI.

b.

Show the static (such as "consists of") relationship(s) of the components. Multiple relationships may be presented, depending on the selected design methodology.

c.

State the purpose of each component and identify the system requirements and system-wide design decisions allocated to it. (Alternatively, the allocation of requirements may be provided in 5.a.)

d.

Identify each component's development status/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 reengineered, component to be developed for reuse, component planned for Build N, etc.) For existing design or components, the description must provide identifying information, such as name, version, documentation references, location, etc.

e. 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/output devices, auxiliary storage, and communications/ network equipment). Each description must, as applicable, identify the configuration items that will use the resource, describe the allocation of resource utilization to each CSCI that will use the resource (for example, 20% of the resource's capacity allocated to CSCI 1, 30% to CSCI 2), describe the conditions under which utilization will be measured, and describe the characteristics of the resource:

1) Descriptions of computer processors must include, as applicable, manufacturer name and model number, processor speed/capacity, identification of instruction set architecture, applicable compiler(s), word size (number of bits in each computer word), character set standard (such as ASCII, EBCDIC), and interrupt capabilities.

Preparation Instructions Continued

2) Descriptions of memory must 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)).

3) Descriptions of input/output devices must include, as applicable, manufacturer name and model number, type of device, and device speed/capacity.

4) Descriptions of auxiliary storage must include, as applicable, manufacturer name and model number, type of storage, amount of installed storage, and storage speed.

5) Descriptions of communications/network equipment, such as modems, network interface cards, hubs, gateways, cabling, high speed data lines, or aggregates of these or other components, must include, as applicable, manufacturer name and model number, data transfer rates/capacities, network topologies, transmission techniques, and protocols used.

6) Each description must also include, as applicable, growth capabilities, diagnostic capabilities, and any additional hardware capabilities relevant to the description.

4.2 Concept of execution – This paragraph must describe the concept of execution among the system components. It must include diagrams and descriptions showing the dynamic relationship of the software units, that is, how they will interact during System operation, including, as applicable, flow of execution control, data flow, operating system and application layer software features, dynamically controlled sequencing, state transition diagrams, timing diagrams, priorities among units, handling of interrupts, timing/sequencing relationships, exception handling, concurrent execution, dynamic allocation/deallocation, dynamic creation/deletion of objects, processes, tasks, and other aspects of dynamic behavior.

4.3 Interface design – This paragraph must be divided into the following subparagraphs to describe the interface characteristics of the system components. It must include both interfaces among the components and their interfaces with external entities such as other systems, configuration items, and users. If part or all of this information is contained in Interface Design Descriptions (IDDs), in section 5 of the SDD, or elsewhere, these sources may be referenced.

4.3.1 Interface identification and diagrams – This paragraph must state the project-unique identifier assigned to each interface and must identify the interfacing entities (systems, configuration items, users, etc.) by name, number, version, and documentation references, as applicable. The identification must state 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). One or more interface diagrams must be provided, as appropriate, to depict the interfaces.

4.3.2 (Project‑unique identifier of interface – This paragraph (beginning with 4.3.2) must identify an interface by project‑unique identifier, must briefly identify the interfacing entities, and must be divided 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 SDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics must be stated as assumptions or as "When [the entity not covered] does this, [the entity that is covered] will ...." This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description must include the following, as applicable, presented in any order suited to the information to be provided, and must 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):

a. Priority assigned to the interface by the interfacing entity(ies)

b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.) to be implemented c.

Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

1) Names/identifiers

a) Project-unique identifier

b) Non-technical (natural-language) name

c) Data element name

d) Technical name (e.g., variable or field name in code or database)

e) Abbreviation or synonymous names

2) Data type (alphanumeric, integer, etc.)

3) Size and format (such as length and punctuation of a character string)

4) Units of measurement (such as meters, dollars, nanoseconds)

5) Range or enumeration of possible values (such as 0-99)

6) Accuracy (how correct) and precision (number of significant digits)

7) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply

8) Security and privacy constraints

9) Sources (setting/sending entities) and recipients (using/receiving entities) d.

Characteristics of data element assemblies (records, messages, files, arrays, displays, reports, etc.) that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

Non-technical (natural language) name

Technical name (e.g., record or data structure name in code or database)

Abbreviations or synonymous names

Data elements in the assembly and their structure (number, order, grouping)

Medium (such as disk) and structure of data elements/assemblies on the medium

Visual and auditory characteristics of displays and other outputs (such as colors, layouts, fonts, icons and other display elements, beeps, lights)

Relationships among assemblies, such as sorting/access characteristics

Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply e.

Characteristics of communication methods that the interfacing entity(ies) will use for the interface, such as:

Project-unique identifier(s)

Communication links/bands/frequencies/media and their characteristics

Message formatting

Flow control (such as sequence numbering and buffer allocation)

Data transfer rate, whether periodic/aperiodic, and interval between transfers

Routing, addressing, and naming conventions

Transmission services, including priority and grade

Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing

Preparation Instructions Continued f.

Characteristics of protocols that the interfacing entity(ies) will use for the interface, such as:

Priority/layer of the protocol

Packeting, including fragmentation and reassembly, routing, and addressing

Legality checks, error control, and recovery procedures

Synchronization, including connection establishment, maintenance, termination

Status, identification, and any other reporting features g.

Other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, etc.)

5.

Requirements traceability – This section must contain:

a.

Traceability from each system component identified in this SDD to the System requirements allocated to it. (Alternatively, this traceability may be provided in 4.1.)

b.

Traceability from each System requirement to the system components to which it is allocated.

7.

Notes – This section must contain any general information that aids in understanding this document (e.g., background information, glossary). This section must include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.

A.

Appendixes – Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, data). As applicable, each appendix must 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 must be lettered alphabetically (A, B, etc.).

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

DATA ITEM DESCRIPTION

3. Description/Purpose

The Software Design Description Document (SSDD) describes the design of a Software Configuration Item (SCI). It describes the SCI-wide design decisions, the SCI architectural design, and the detailed design, including interface design, needed to implement the software. The SSDD is used as the basis for implementing the software. It provides the acquirer visibility into the design and provides information needed for software support.

TBD

7. Application/Interrelationship

This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by specific and discrete task requirements as delineated in the contract. This DID is used when the developer is tasked to define and record the design of a SCI. Design pertaining to interfaces may be presented in the SSDD or in IDDs. The Contract Data Requirements List (CDRL) should specify whether deliverable data are to be delivered on paper or electronic media; are to be in a given electronic form (such as ASCII, CALS, or compatible with a specified word processor or other support software); may be delivered in developer format rather than in the format specified herein; and may reside in a computer-aided software engineering (CASE) or other automated tool rather than in the form of a traditional document.

N/A

A002

10. Preparation Instructions

10.1 General instructions.

a. Automated techniques – Use of automated techniques is encouraged. The term "document" in this DID means a collection of data regardless of its medium.

b. Alternate presentation styles – Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required by this DID can be made more readable using these styles.

c. Title page or identifier – When data are delivered in the form of a traditional document, the Document must include a title page containing, as applicable: document number; volume number; version/revision indicator; security markings or other restrictions on the handling of the document; date; document title; name, abbreviation, and any other identifier for the system, subsystem or item to which the document applies; contract number; CDRL item number; organization for which the document has been prepared; name and address of the preparing organization; and distribution statement. For data delivered in an alternative form, this information must be included on external and internal labels or by equivalent identification methods.

document must contain a table of contents providing the number, title, and page number of each titled paragraph, figure, table, and appendix. For data delivered in an alternative form, this information must consist of an internal or external table of contents containing pointers to, or instructions for accessing, each paragraph, figure, table, and appendix or their equivalents.

Preparation Instructions Continued

e. Page numbering/labeling – Each page must contain a unique page number and display the document number, including version, volume, and date, as applicable. For data in a database or other alternative form, files, screens, or other entities must be assigned names or numbers in such a way that desired data can be indexed and accessed.

f.

Response to tailoring instructions – If a paragraph is tailored out of this DID, the resulting document must contain the corresponding paragraph number and title, followed by "This paragraph has been tailored out." For data in a database or other alternative form, this representation need occur only in the table of contents or equivalent.

g. Multiple paragraphs and subparagraphs – Any section, paragraph, or subparagraph in this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h. Standard data descriptions – If a data description required by this DID has been published in a standard data element dictionary specified in the contract, reference to an entry in that dictionary is preferred over including the description itself.

i. Detail design descriptions – Including input and output definitions must be located in headers of code modules to the maximum extent practical. The SSDD must also contain a detailed description of the component interfaces between developed software/firmware components and standard Commercial Off-the-Shelf (COTS) components. For the purposes of this contract, Contractor-developed software/firmware required for the RIPSA approved design architecture is not considered proprietary and must be provided with unlimited rights to the Government.

j. Data items must conform to standards of IEEE 1016-1998, Sections 5, 6, and Annex A.

10.2 Content requirements – The numbers shown designate the paragraph numbers to be used in the document. Each such number is understood to have the prefix "10.2" within this DID. For example, the paragraph numbered 1.1 is understood to be paragraph 10.2.1.1 within this DID.

1.

Scope – This section must be divided into the following paragraphs.

1.1 Identification – This paragraph must contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System overview – This paragraph must briefly state the purpose of the system and the software to which this document applies. It must describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support organizations; identify current and planned operating sites; and list other relevant documents.

1.3 Document overview – This paragraph must summarize the purpose and contents of this document and must describe any security or privacy considerations associated with its use.

2.

Referenced documents – This section must list the number, title, revision, and date of all documents referenced in this document. This section must also identify the source for all documents not available through normal Government stocking activities.

3.

SCI-wide design decisions – This section must be divided into paragraphs as needed to present SCI-wide design decisions, that is, decisions about the SCI'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 SCI. If all such decisions are explicit in the SCI requirements or are deferred to the design of the SCI's software units, this section must so state. Design decisions that respond to requirements designated critical, such as those for safety, security, human factors or privacy, must be placed in separate subparagraphs. If a design decision depends upon system states or modes, this dependency must be indicated. Design conventions needed to understand the design must be presented or referenced. Examples of SCI-wide design decisions are the following:

Preparation Instructions Continued a.

Design decisions regarding inputs the SCI will accept and outputs it will produce, including interfaces with other systems, HWCIs, SCIs, and users (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Interface Design Descriptions (IDDs), they may be referenced.

b.

Design decisions on SCI behavior in response to each input or condition, including actions the SCI will perform, response times and other performance characteristics, description of physical systems modeled, selected equations/algorithms/rules, and handling of unallowed inputs or conditions. The selected algorithms must include time of arrival calculations, time synchronization, and target tracker.

c.

Design decisions on how databases/data files will appear to the user (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Database Design Descriptions (DBDDs), they may be referenced.

d.

Selected approach to meeting safety, security, human factors and privacy requirements.

e.

Other SCI-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.

For proposed modifications to commercial software, include alternatives reviewed, cost, schedule, and risk analysis in the justification 4.

SCI architectural design – This section must be divided into the following paragraphs to describe the SCI architectural design. If part or all of the design depends upon system states or modes, this dependency must be indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design must be presented or referenced.

4.1 SCI components – This paragraph must:

a.

Identify the software units that make up the SCI. Each software unit must be assigned a project-unique identifier. Note: A software unit is an element in the design of a SCI; for example, a major subdivision of a SCI, 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 SCI or as a software unit. The SSDD may refer to software units by any name(s) consistent with the design methodology being used.

b.

Show the static (such as "consists of") relationship(s) 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 SCI).

c.

State the purpose of each software unit and identify the SCI requirements and SCI-wide design decisions allocated to it. (Alternatively, the allocation of requirements may be provided in 6.a.)

d.

Identify each software unit's development status/type (such as new development, existing design or software to be reused as is, existing design or software to be reengineered, software to be developed for reuse, software planned for Build N, etc.) For existing design or software, the description must provide identifying information, such as name, version, documentation references, library, etc.

e. Describe the SCI's (and as applicable, each software unit's) planned utilization of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage capacity, and communications/network equipment capacity). The description must cover all computer hardware resources included in resource utilization requirements for the SCI, in system-level resource allocations affecting the SCI, 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 SSDD, this paragraph may reference that source.

Included for each computer hardware resource must be:

1) The SCI 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)

4) The units of measure used (such as percentage of processor capacity, cycles per second, bytes of memory, kilobytes per second)

The level(s) at which the estimates or measures will be made (such as software unit, SCI, or executable program)

Identify the program library in which the software that implements each software unit is to be placed.

4.2 Concept of execution – This paragraph must describe the concept of execution among the software units. It must include diagrams and descriptions showing the dynamic relationship of the software units, that is, how they will interact during SCI operation, including, as applicable, flow of execution control, data flow, operating system and application layer software features, dynamically controlled sequencing, state transition diagrams, timing diagrams, priorities among units, handling of interrupts, timing/sequencing relationships, exception handling, concurrent execution, dynamic allocation/deallocation, dynamic creation/deletion of objects, processes, tasks, and other aspects of dynamic behavior.

4.3 Interface design – This paragraph must be divided into the following subparagraphs to describe the interface characteristics of the software units. It must include both interfaces among the software units and their interfaces with external entities such as systems, configuration items, and users. If part or all of this information is contained in Interface Design Descriptions (IDDs), in section 5 of the SSDD, or elsewhere, these sources may be referenced.

4.3.1 Interface identification and diagrams – This paragraph must state the project-unique identifier assigned to each interface and must identify the interfacing entities (software units, systems, configuration items, users, etc.) by name, number, version, and documentation references, as applicable. The identification must state 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). One or more interface diagrams must be provided, as appropriate, to depict the interfaces.

4.3.2 (Project‑unique identifier of interface – This paragraph (beginning with 4.3.2) must identify an interface by project‑unique identifier, must briefly identify the interfacing entities, and must be divided 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 SSDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics must be stated as assumptions or as "When [the entity not covered] does this, [the entity that is covered] will ...." This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description must include the following, as applicable, presented in any order suited to the information to be provided, and must 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):

a. Priority assigned to the interface by the interfacing entity(ies)

b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.) to be implemented c.

Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

Non-technical (natural-language) name

Data element name

Technical name (e.g., variable or field name in code or database)

e) Abbreviation or synonymous names

Data type (alphanumeric, integer, etc.)

Size and format (such as length and punctuation of a character string)

Units of measurement (such as meters, dollars, nanoseconds)

Range or enumeration of possible values (such as 0-99)

Accuracy (how correct) and precision (number of significant digits)

Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply

9) d.

Characteristics of data element assemblies (records, messages, files, arrays, displays, reports, etc.) that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

Non-technical (natural language) name

Technical name (e.g., record or data structure name in code or database)

Abbreviations or synonymous names

Data elements in the assembly and their structure (number, order, grouping)

Medium (such as disk) and structure of data elements/assemblies on the medium

Visual and auditory characteristics of displays and other outputs (such as colors, layouts, fonts, icons and other display elements, beeps, lights)

Relationships among assemblies, such as sorting/access characteristics

Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply

Characteristics of communication methods that the interfacing entity(ies) will use for the interface, such as:

Communication links/bands/frequencies/media and their characteristics

Message formatting

Flow control (such as sequence numbering and buffer allocation)

Data transfer rate, whether periodic/aperiodic, and interval between transfers

Routing, addressing, and naming conventions

Transmission services, including priority and grade

Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing

Characteristics of protocols that the interfacing entity(ies) will use for the interface, such as:

Priority/layer of the protocol

Packeting, including fragmentation and reassembly, routing, and addressing

Legality checks, error control, and recovery procedures

Synchronization, including connection establishment, maintenance, termination

Status, identification, and any other reporting features g.

Other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, etc.)

5.

SCI detailed design – This section must be divided into the following paragraphs to describe each software unit of the SCI. If part of all of the design depends upon system states or modes, this dependency must be indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design must be presented or referenced. Interface characteristics of software units may be described here, in Section 4, or in Interface Design Descriptions (IDDs). Software units that are databases, or that are used to access or manipulate databases, may be described here or in Database Design Descriptions (DBDDs).

(Project-unique identifier of a software unit, or designator of a group of software units). This paragraph must identify a software unit by project-unique identifier and must describe the unit. The description must include the following information, as applicable. Alternatively, this paragraph may designate a group of software units and identify and describe the software units in subparagraphs. 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 b.

Any constraints, limitations, or unusual features in the design of the software unit c.

The programming language to be used and rationale for its use if other than the specified SCI language d.

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 e.

If the software unit contains, receives, or outputs data, a description of its inputs, outputs, and other data elements and data element assemblies, as applicable. Paragraph 4.3.x of this DID provides a list of topics to be covered, as applicable. Data local to the software unit must be described separately from data input to or output from the software unit. If the software unit is a database, a corresponding Database Design Description (DBDD) must be referenced; interface characteristics may be provided here or by referencing section 4 or the corresponding Interface Design Description(s) (IDD).

f.

If the software unit contains logic, the logic to be used by the software unit, including, as applicable:

Conditions in effect within the software unit when its execution is initiated

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

Sequence of operations and dynamically controlled sequencing during the software unit's operation, including:

The method for sequence control

The logic and input conditions of that method, such as timing variations, priority assignments

Data transfer in and out of memory

The sensing of discrete input signals, and timing relationships between interrupt operations within the software unit

5) Exception and error handling

6.

Requirements traceability – This section must contain:

a.

Traceability from each software unit identified in this SSDD to the SCI requirements allocated to it. (Alternatively, this traceability may be provided in 4.1.)

b.

Traceability from each SCI requirement to the software units to which it is allocated.

7.

Notes – This section must contain any general information that aids in understanding this document (e.g., background information, glossary). This section must include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.

A.

Appendixes – Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, data). As applicable, each appendix must 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 must be lettered alphabetically (A, B, etc.).

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

DATA ITEM DESCRIPTION

3. Description/Purpose

3.1 The Software Interface Control Document (ICD) describes the interface characteristics of one or more Computer Software Configuration Items (CSCIs). An ICD may describe any number of interfaces.

3.2 The ICD can be used to supplement the System Description Document (SDD), Software Design Description (SSDD), and Database Design Description (DBDD). The ICD serves to communicate and control interface design decisions.

TBD

7. Application/Interrelationship

7.1 This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by specific and discrete task requirements as delineated in the contract.

7.2 This DID is used when the developer is tasked to define and record the interface design of one or more CSCIs.

7.3 The ICD specifies interface requirements and describes interface characteristics selected to meet those requirements. The ICD can be used to supplement the SSDD, SDD, or DBDD.

7.4 The Contract Data Requirements List (CDRL) should specify whether deliverable data are to be delivered on paper or electronic media; are to be in a given electronic form (such as ASCII, CALS, or compatible with a specified word processor or other support software); may be delivered in developer format rather than in the format specified herein; and may reside in a computer-aided software engineering (CASE) or other automated tool rather than in the form of a traditional document.

N/A

A003

10. Preparation Instructions

10.1 General instructions.

a. Automated techniques – Use of automated techniques is encouraged. The term "document" in this DID means a collection of data regardless of its medium.

b. Alternate presentation styles – Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required by this DID can be made more readable using these styles.

c. Title page or identifier – When data are delivered in the form of a traditional document, the Document must include a title page containing, as applicable: document number; volume number; version/revision indicator; security markings or other restrictions on the handling of the document; date; document title; name, abbreviation, and any other identifier for the system, subsystem or item to which the document applies; contract number; CDRL item number; organization for which the document has been prepared; name and address of the preparing organization; and distribution statement. For data delivered in an alternative form, this information must be included on external and internal labels or by equivalent identification methods.

document must contain a table of contents providing the number, title, and page number of each titled paragraph, figure, table, and appendix. For data delivered in an alternative form, this information must consist of an internal or external table of contents containing pointers to, or instructions for accessing, each paragraph, figure, table, and appendix or their equivalents.

e. Page numbering/labeling – Each page must contain a unique page number and display the document number, including version, volume, and date, as applicable. For data in a database or other alternative form, files, screens, or other entities must be assigned names or numbers in such a way that desired data can be indexed and accessed.

f.

Response to tailoring instructions – If a paragraph is tailored out of this DID, the resulting document must contain the corresponding paragraph number and title, followed by "This paragraph has been tailored out." For data in a database or other alternative form, this representation need occur only in the table of contents or equivalent.

g.

Multiple paragraphs and subparagraphs – Any section, paragraph, or subparagraph in this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

Standard data descriptions – If a data description required by this DID has been published in a standard data element dictionary specified in the contract, reference to an entry in that dictionary is preferred over including the description itself.

i.

Substitution of existing documents - Commercial or other existing documents may be substituted for all or part of the document if they contain the required data.

Preparation Instructions Continued

Content requirements – The numbers shown designate the paragraph numbers to be used in the document. Each such number is understood to have the prefix "10.2" within this DID. For example, the paragraph numbered 1.1 is understood to be paragraph 10.2.1.1 within this DID.

1.

Scope – This section must be divided into the following paragraphs.

1.1 Identification – This paragraph must contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System overview – This paragraph must briefly state the purpose of the system and the software to which this document applies. It must describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support organizations; identify current and planned operating sites; and list other relevant documents.

1.3 Document overview – This paragraph must summarize the purpose and contents of this document and must describe any security or privacy considerations associated with its use.

2.

Referenced documents – This section must list the number, title, revision, and date of all documents referenced in this document. This section must also identify the source for all documents not available through normal Government stocking activities.

3.

Interface design. This section must be divided into the following paragraphs to describe the interface characteristics of one or more systems, subsystems, configuration items, manual operations, or other system components. If part or all of the design depends upon system states or modes, this dependency must 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 must be presented or referenced.

3.1 Interface identification and diagrams. For each interface identified in 1.1, this paragraph must state the project-unique identifier assigned to the interface and must identify the interfacing entities (systems, configuration items, users, etc.) by name, number, version, and documentation references, as applicable. The identification must state 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). One or more interface diagrams must be provided, as appropriate, to depict the interfaces.

3.x (Project-unique identifier of interface). This paragraph (beginning with 3.2) must identify an interface by project-unique identifier, must briefly identify the interfacing entities, and must be divided 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 IDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics must be stated as assumptions or as "When [the entity not covered] does this, [the entity that is covered] will ...." This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description must include the following, as applicable, presented in any order suited to the information to be provided, and must 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):

Preparation Instructions Continued

a. Priority assigned to the interface by the interfacing entity(ies)

b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.) to be implemented

c. Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

1) Names/identifiers

a) Project-unique identifier

b) Non-technical (natural-language) name

c) DoD standard data element name

d) Technical name (e.g., variable or field name in code or database)

e) Abbreviation or synonymous names

2…