0% found this document useful (0 votes)
44 views8 pages

DID Interface Design Description IDD

Uploaded by

Kamil Bocko
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
44 views8 pages

DID Interface Design Description IDD

Uploaded by

Kamil Bocko
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

helping projects succeed...

www.ppi-int.com

DATA ITEM DESCRIPTION

1. TITLE 2. Identification Number


INTERFACE DESIGN DESCRIPTION (IDD) PPA-004611-5
18 January 2018

3. DESCRIPTION/PURPOSE OF THE IDD


3.1 The Interface Design Description (IDD) describes the interface characteristics of one or more items
which may typically be referred to as systems, subsystems, Hardware Configuration Items (HWCIs),
Computer Software Configuration Items (CSCIs), manual operations or other system components. An
IDD may describe one or more interfaces.
3.2 The IDD is used in system development to communicate and control external interface design, at the
most detailed level of definition of external interfaces, and consistent with requirements contained
within the companion Interface Requirements Specification (IRS) (see PPA-002234). The IRS specifies
interface requirements; the IDD describes interface characteristics selected to meet those
requirements. The IDD can also be used to supplement the System/Subsystem Design Description
(SSDD) (see PPA-003461), Software Design Description (SDD) (see TAA-ME04-001132), or Database
Design Description (DBDD) (see TAA-ME04-001134).

4. APPLICATION/INTERRELATIONSHIP
4.1 This Data Item Description (DID) contains the format and content preparation instructions for the
data product generated by the performance of design of an item at the level of detail which permits
the item to be fabricated (hardware), coded (software) or converted to documented procedures
(manual operations).
4.2 This DID is used when the developer is tasked to define and record the interface design.
4.3 This DID may be cited in a Statement of Requirement (SOR), Statement of Work (SOW), a Contract
Data Requirements List (CDRL), within a standard invoked by a SOR or SOW, or within a plan or
procedure.
4.4 This DID incorporates and adapts some non-copyrighted material contained in the Interface Design
Description DID DI-IPSC-81436 issued by the United States Government.

5. PREPARATION GUIDELINES
5.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.
continued next page

6. SOURCE
Copyright Project Performance International. This document may be reproduced and distributed without
restriction except as below provided that all reproductions contain the original copyright statement in the
original form and location. Derivative works may be produced provided each derivative work contains a
copyright statement referring to the content in which PPI holds copyright, in a form and in a location no less
prominent than the copyright statement on the original. Copies and derivative works may not be used for the
delivery of training for profit.

Page 1 of 8
5. PREPARATION GUIDELINES (continued)
b. Alternative presentation styles. Diagrams, tables, matrices, and other presentation
styles are suitable 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 supplied in the form of a paper document or
word processing file, the document should 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 of issue,
document title; name, abbreviation, and any other identifier for the system,
subsystem, or item to which the document applies; contract number if applicable;
CDRL item number if applicable; organization for which the document has been
prepared and name and address of the preparing organization. For data supplied in
an alternative form, this information should be included on external and internal
labels or by equivalent identification methods.
d. Table of contents. When data are supplied in the form of a paper document or word
processing file, the document should contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table and annex. For
data supplied in an alternative form, this information should consist of an internal or
external table of contents containing pointers to, or instructions for, accessing, each
paragraph, figure, table and annex or their equivalents.
e. Page numbering/labeling. When data are supplied in the form of a paper document
or word processing file, each page should contain a unique page number and display
the document number, including version, volume, and date of issue, as applicable.
For data supplied in an alternative form, files, screens, or other entities should be
assigned names or numbers in such a way that desired data can be indexed and
accessed.
f. Response to tailoring instructions. When data are supplied in the form of a paper
document, paragraphs that have been tailored out of the DID should result in the
corresponding paragraph number and title in the document, followed by “Not
applicable” or alternatively, paragraph numbering may be varied to allow for the
missing paragraph. For data supplied in an alternative form, the “Not applicable”
representation may be incorporated 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, reference to an entry in that
dictionary is preferred over inclusion in the data item itself.
i. Declarative style. Where a non-declarative guidance style is used in this DID
(“should”) but a declarative style (“shall”) is required by the user of the DID, the DID
should be tailored accordingly.
j. Substitution of existing documents. Other existing documents may be substituted
for all or part of the data item if they contain the required data and are invoked in
the data item as a part of the data item.

www.ppi-int.com
Page 2 of 8
5.2 Acronyms
Acronyms used in this document shall be interpreted as follows:
CDRL Contract Data Requirements List
CSCI Computer Software Configuration Item
DBDD Database Design Description
DID Data Item Description
HWCI Hardware Configuration Item
IDD Interface Design Description
IRS Interface Requirements Specification
SDD Software Design Description
SOR Statement of Requirement
SOW Statement of Work
SSDD System/Subsystem Design Description
5.3 Abbreviations
Abbreviations used in this document shall be interpreted as follows:
SI International System of Units
5.4 Foreword
Developing the IDD in accordance with this DID will assist in the management and execution of
system and software developments, in situations where characteristics of an interface are not fully
specified by interface requirements, i.e. are not specified at a level of detail sufficient for fabrication
or coding, as applicable. In order to execute a project effectively, development teams often need to
concurrently develop systems that share an interface. These teams must make interface design
decisions that are consistent, and to a matching level of detail. When the IDD is populated as
specified by this DID with information reflecting interface design decisions based on sound
engineering judgement, the probability that the interfacing systems will interface correctly, and
therefore be able to interoperate correctly, is increased. Stakeholder involvement to validate
interface design decisions is encouraged. It is further recommended that any potential to use
industry-recognized standards for the type of interface that is the subject of the IDD be considered.
The IDD additionally serves a purpose after completion of initial development of interfacing systems.
That is, the IDD serves to define the interface characteristics needed of any form-fit-and-functionally
equivalent replacement system.
5.5 Content Requirements
Content requirements begin on page 5. The numbers shown designate the paragraph numbers to be
used in the document. Each such number is understood to have the prefix "5.5" within this DID. For
example, the paragraph numbered 1.1 is understood to be paragraph 5.5.1.1 within this DID.

www.ppi-int.com
Page 3 of 8
TABLE OF CONTENTS
1. INTRODUCTION AND SCOPE 5
1.1 Identification 5
1.2 Background and Intended Use 5
1.3 Interface(s) Overview 5
1.4 Document Overview and Use 5
2. APPLICABLE AND REFERENCED DOCUMENTS 5
2.1 Applicable Documents 5
2.2 Other Referenced Documents 5
3. DEFINITIONS, ACRONYMS AND ABBREVIATIONS 5
3.1 Definitions 5
3.2 Acronyms 5
3.3 Abbreviations 6
4. INTERFACE DESIGN 6
4.1 Interface Identification and Diagrams 6
4.x (Project-Unique Identifier of Interface) 6
5. REQUIREMENTS TRACEABILITY 8
6. NOTES 8
A. ANNEXES 8

www.ppi-int.com
Page 4 of 8
1. INTRODUCTION AND SCOPE
This section should be divided into the following paragraphs.
1.1 Identification
This paragraph should contain a full identification of the interfacing items and the interface(s) to
which the IDD applies, including, as applicable, identification number(s), title(s), abbreviation(s),
version number(s) and release number(s). Where the interfacing items to which the IDD applies
includes variants of the items, the above information should be provided for each variant.
1.2 Background and Intended Use
This paragraph should briefly state the intended use of the interfacing items to which the document
applies, relating them to the interface described by the IDD. The paragraph should describe the
general nature of the items and the interface(s), summarize the history of item development,
operation, and maintenance (if any); and identify, as applicable, the project sponsor, acquirer,
developer, user and support organizations.
1.3 Interface(s) Overview
This paragraph should summarize the requirements, the design and any other significant features of
the interface(s) as described in the remainder of the IDD.
1.4 Document Overview and Use
This paragraph should summarize the purpose and contents of the IDD and should describe any
security or privacy considerations associated with its use.
2. APPLICABLE AND REFERENCED DOCUMENTS
This section should list the number, title, revision and date of each document referenced in the SDD.
This section should also identify the source of each document not available through normal channels.
2.1 Applicable Documents
This paragraph should list each document which is invoked in whole or in part within the SDD as a
part of the interface design description.
2.2 Other Referenced Documents
This paragraph should list each document which is referenced in the IDD but which does not form a
part of the design description.
3. DEFINITIONS, ACRONYMS AND ABBREVIATIONS
This section should be divided into the following paragraphs.
3.1 Definitions
This paragraph should list alphabetically and define each word or term used in the IDD for which
reliance on dictionary definitions or usage in a relevant technical community is not appropriate. As a
guide, terms which are not likely to be in the vocabulary of the intended users of the IDD, terms
which have multiple dictionary meanings but only a single IDD meaning, specialist technical terms
and terms which are used with special meanings should be defined in this paragraph.
Alternatively, this paragraph may specify by name and issue a suitable technical dictionary or other
reference publication to be used in the interpretation of terms used in the IDD and which meets the
criteria above for definition of terms.
3.2 Acronyms
This section should list alphabetically each acronym used in the IDD, together with the acronym’s
expanded meaning.

www.ppi-int.com
Page 5 of 8
3.3 Abbreviations
This section should list alphabetically each abbreviation used in the IDD, together with the
abbreviation’s expanded meaning, except that abbreviations within the International System of Units
(SI) should not be listed.
4. INTERFACE DESIGN
This section should be divided into the following paragraphs to describe the interface characteristics
of one or more interfaces of systems, subsystems, configuration items, manual operations, or other
system components. If design information falls into more than one paragraph, the information may
be presented once and referenced from the other paragraphs. If part or all of this information is
documented elsewhere, the information may be invoked by reference. Design conventions needed
to understand the design should be presented or referenced.
4.1 Interface Identification and Diagrams
For each interface identified in 1.1, this paragraph should state the project-unique identifier assigned
to the interface and should identify the interfacing entities (systems, configuration items, users, etc.)
by name, number, version, and documentation references, as applicable. The identification should
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 should be provided, as
appropriate, to depict the interfaces.
4.x (Project-Unique Identifier of Interface)
This paragraph (beginning with 4.2) should identify an interface by project-unique identifier, should
briefly identify the interfacing entities, and should 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 should 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
should include the following, as applicable, presented in any order suited to the information to be
provided, and should 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 mechanical, real-time data transfer, storage-and-retrieval of data, etc.)
to be implemented;
c. characteristics of individual data elements carried by the interface that the interfacing
entity(ies) will provide, store, send, access, receive, etc., such as:
(i) names/identifiers:
(a) project-unique identifier;
(b) non-technical (natural-language) name;
(c) standard data element name;
(d) technical name (e.g., variable or field name in code or database);
(e) abbreviation or synonymous names;
(ii) data type (alphanumeric, integer, etc.);

www.ppi-int.com
Page 6 of 8
(iii) size and format (such as length and punctuation of a character string);
(iv) units of measurement (such as meters, dollars, nanoseconds);
(v) range or enumeration of possible values (such as 0-99);
(vi) accuracy (how correct) and precision (number of significant digits);
(vii) priority, timing, frequency, volume, sequencing, and other constraints, such as whether
the data element may be updated and whether business rules apply;
(viii) security and privacy constraints;
(ix) 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:
(i) names/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;
(ii) data elements in the assembly and their structure (number, order, grouping);
(iii) medium (such as disk) and structure of data elements/assemblies on the medium;
(iv) visual and auditory characteristics of displays and other outputs (such as colors, layouts,
fonts, icons and other display elements, beeps, lights);
(v) relationships among assemblies, such as sorting/access characteristics;
(vi) priority, timing, frequency, volume, sequencing, and other constraints, such as whether
the assembly may be updated and whether business rules apply;
(vii) security and privacy constraints;
(viii) sources (setting/sending entities) and recipients (using/receiving entities);
e. characteristics of communication methods that the interfacing entity(ies) will use for the
interface, such as:
(i) project-unique identifier(s);
(ii) communication links/bands/frequencies/media and their characteristics;
(iii) message formatting;
(iv) flow control (such as sequence numbering and buffer allocation);
(v) data transfer rate, whether periodic/aperiodic, and interval between transfers;
(vi) routing, addressing, and naming conventions;
(vii) transmission services, including priority and grade;
(viii) safety/security/privacy considerations, such as encryption, user authentication,
compartmentalization, and auditing;
f. characteristics of protocols the interfacing entity(ies) will use for the interface, such as:
(i) project-unique identifier(s);
(ii) priority/layer of the protocol;

www.ppi-int.com
Page 7 of 8
(iii) packeting, including fragmentation and reassembly, routing, and addressing;
(iv) legality checks, error control, and recovery procedures;
(v) synchronization, including connection establishment, maintenance, termination;
(vi) status, identification, and any other reporting features; and
g. other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions,
tolerances, loads, voltages, plug compatibility, etc.).
5. REQUIREMENTS TRACEABILITY
This paragraph should contain:
a. traceability from each interface covered by this IDD to the interfacing entity requirement(s)
addressed by the entity's interface design; and
b. traceability from each requirement of an interfacing entity that affects an interface covered in
the IDD to the interfacing entities that address the requirement.
6. NOTES
This section should contain any general information that aids in understanding this document (e.g.,
background information, rationale).
A. ANNEXES
Annexes may be used to provide information published separately for convenience in document
maintenance (e.g., charts, classified data). As applicable, each annex should be referenced in the
main body of the document where the data would normally have been provided. Annexes may be
bound as separate documents for ease in handling. Annexes should be lettered alphabetically (A, B,
etc.).
Appendices may be used to annexes. Appendices should be numbered numerically (1, 2, etc.).

www.ppi-int.com
Page 8 of 8

You might also like