You are on page 1of 229

IVNL-STD-498

5 December 1994
Superseding
DOD-STD-2167A
29 February 1988
DOD-STD-7935A
31 October 1988
DOD-STD-1703(NS)
12 February 1987

MILITARY

SOFTWARE
AND

AMSC

NO. N7069

STANDARD

DEVELOPMENT

DOCUMENTATION

AREA:

lPSC/MCCR

DISTRIBUTION STATEMEN1 A. A[]proved for pubhc release; (iIstrlbutlon is unlimlted,

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
FOREWORD
This Military Standard
Department of Defense.
1.

IS approved

for use by all Departments

and Agencies

of the

2.
Beneficial comments (recommendations,
additions, deletions) and any pertinent data
which may be of use in improving this document should be addressed to SPAWAR 10-12,
2451 Crystal Drive (CPK-5), Arlington, VA 22245-5200.
The comments may be submitted
by letter or by using the Standardization Document Improvement Proposal (DD Form 1426)
appearing at the end of this document.
This standard merges DO D-STD-21 67A and DOD-STD-7935A
todeflne a set of activities
3.
and documentation suitable for the development of both weapon systems and Automated
Information Systems. A conversion guide from these standards to MI L-STD-498 is provided
in Appendix 1.
Other changes include improved compatibility
with incremental and
evolutionary
development
models; improved compatibility
with non-hierarchical
design
methods; improved compatibility with computer-aided software engineering (CASE) tools;
alternatives
to, and more flexibility in, preparing documents; clearer requirements for
incorporating reusable software; introduction of software management indicators; added
This
emphasis on software supportability; and improved links to systems engineering.
standard supersedes DOD-STD-21

67A, DOD-STD-7935A,

and DOD-STD-1

703 (NS).

4.
This standard can be applied in any phase of the system life cycle. It can be applied to
contractors,
subcontractors,
or Government
in-house agencies performing
software
For uniformity, the term acquirer is used for the organization requiring the
development.
technical effort, the term developer for the organization performing the technical effort, and
the term contract for the agreement between them. The term software development is
used as an inclusive term encompassing new development, modification, reuse, reengineering,
maintenance, and all other activities resulting in software products.
This standard is not intended to specify or discourage the use of any particular software
5.
The developer is responsible for selecting software development
development method.
methods that support the achievement of contract requirements.
6.
This standard implements the development and documentation processes of lSO/lEC DIS
12207.
It interprets all applicable clauses in MIL-CI-9858A
(Quality Program Requirements)
and ISO 9001 (Quality Systems) for software.
7,
This standard includes all activities pertaining to software development.
It invokes no
other standards. h can be applied on its own or supplemented with other standards, such as
those identified in Section 6. If other standards are applied, the acquirer is responsible for
resolving any conflicts that arise.
8.
Data Item Descriptions (DIDs) applicable to this standard are listed in Section 6. These
DIDs describe the information required by this standard.
This standard and its Data Item Descriptions (DIDs) are meant to be tailored by the
9.
acquwer to ensure that only necessary and cost-effective
requirements are imposed on
software development efforts. General tailoring guidance can be found in Section 6 and in
DOD-HDBK-248.
Tailoring guidance specific to this standard can be found in Appendixes G
and H and in guidebooks and handbooks planned for this standard.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

__

MIL-STD-498
CONTENTS
paraaraDh
~
1.

SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ., . . . .
1.2.1
Organizations and agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Contract-specific application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
1.2.3
Tailoring . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .. . . . . . . . . . . . .
1.2.4
Interpretation of selected terms . . . . . . . . . . . . . . . . . . . . . . .
....
1.2.4.1
Interpretation of system ., , , , . . . . ., . . . . . . . .
.
...
1.2.4.2
Interpretation of participate in system development
....
1.2.4.3
Interpretation of develop, define,* etc . . . . . . . .
.
. . .
1.2.4.4
Interpretation of record
.
.
. .
1.3
Order of precedence
.,..,...........~~~j~j~:
~~:.......
. . . . . . . . . . . .

2.

REFERENCED DOCUMENTS

3.

DEFINITIONS

4.

GENERAL REQUIREMENTS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..8
4.1
Software development process . . . . . . , . . . . . . . . . . . . .
4.2
General requirements for software development
. . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. ..
4.2.1
Software development methods ... . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2
Standards for software products,
. . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3
Reusable software products
. . . . . . . . . . . . . . . . . . . . . . . . . . ...8
4.2,3.1
Incorporating reusable software products , . . . . . . . . . . .
4,2.3.2
Developing reusable software products . . . . . . . . . . . . . .
4.2.4
Handling of critical requirements
. . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.5
4.2.6
4.2.7
5.

1
1
1

1
1
1
1
1

2
2
2
2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8
8
8
8
9
9

4.2.4.1
Safety assurance . . . . . . .. o....
. . . . . . . . . . . . . ...9
4.2.4.2
Security assurance . . . . . . , . . . . . . .
9
4.2.4.3
privacy assurance . . . . . . . . . . . . . . . . . . . . . .. . . ..9
. . . . . . . . .
4.2.4.4
Assurance of other critical requirements
. . . . . . . .
Computer hardware resource utilization. . . . . . . . . . , . . . . . . ~ ~ . . .1:
Recording rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. 10
Access for acquirer review . . . . . , . . . . . . . . . . . .
. . . . . . . . . . . 10

DETAILED REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
...
.,
5.1
Project planning and oversight
. . . . . . . . . . . . . . . . . . . . . . ., ...
. . . . . .....
5.1,1
Software development planning . . . . . . . . . . . . . . . .
. . . . . . . . . .
5.1.2
CSCl test planning . . . . . . . . . . . . . . . . . .
.
5.1.3
System test planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
5.1.4
Software installation planning . . . . . . . . . . . . . .
. . . . . . . . . .
5.1.5
Software transition planning . . . . . . . . . . . . . .....
., ...
. . . . .
5.1.6
Following and updating plans . . . . . . . . . . . . . . . . .
. . . . . . . . . .
5.2
Establishing a software development environment
., . . . . . . . . . .
5.2.1
Software engineering environment . . . . . , ~ ~ :: ~ .. .
5.2.2
Software test environment
. . . . . . . . . . . , , , . . . . . . . . . . . . . . .
5,2.3
Software development library . . . . . . . . . . . , . . . . . . . . . . . . . . .
. . . . . . . . . .

Ill
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

11

12
12
12
12
12
12
13
13
13
13
13

MIL-STD-498
CONTENTS

- Continued
m

Paraararlh

5.2.4
Software development files....
. . . . . . . . . . . . . . . . . . . . . ...13
Non-cleliverable software
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.5
13
System requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.
,4
5.3
Analysis of user input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,4
5.3.1
Operational concept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...14
5.3.2
System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,4
5.3.3
System design . . . . . . . . . . ..t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,4
5.4
5.4,1
System-wide design decisions.
. . . . . . . . . . . . . . . . . . . . . . . . .
5,4.2
System architectural design . . . . . . . . . . . . . . . . . . . ...-...
~~
5.5
Software requirements analysis
. . . . . . . . . . . . . . . . . . . . . . ..)4
. ...
,5
Software design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,5
5.6
5.6.1
CSC1-wide design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CSCl architectural design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~
5.6.2
5.6.3
CSCl detailed design . . . . . . . . . . . . ...-...........
,6
Software implementation and unit testing
. . . . . . . . . . . . . . . . . . . . . . . .
5.7
5.7.1
Software implementation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.7.2
Preparing for unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
,6
5.7.3
Performing unit testing
. . . . . . . . . . . . . . . . . ..).
.. l .16
5.7.4
Revision and retesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.5
Analyzing and recording unit test results . . . . . . . . . . . . . . . . . . . 16
16
5.8
Unit integration and testing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8.1
Preparing for unit integration and testing . . . . . . . . . . . . . . . . . . . 17
Performing unit integration and testing . . . . . . . . . . . . . . . . . . . . 17
5.8.2
5.8.3
Revision and retesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.8.4
Analyzing and recording unit integration and test results . . . . . . . . 17
17
CSCl qualification testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9
5.9.1
Independence in CSCI qualification testing . . . . . . . . . . . . . . . . . . 17
5.9.2
Testing onthetarget
computer system . . . . . . . . . . . . . . . . . . . . 17
5.9.3
Preparing for CSCI qualification testing . . . . . . . . . . . . . . . . , . . . 17
5.9.4
Dryrunof
CSCl qualification testing . . . . . . . . . . . . . . . . . . . . . . 18
5.9.5
Performing CSCI qualification testing
. . . . . . . . . . . . . . . . . . . . . 18
5.9.6
Revision and retesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.9.7
Analyzing and recording CSCI qualification test results . . . . . . . . . 18
5.10 CSCl/HWCl integration and testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~
5.10.1
Preparing for CSC1/HWCl integration and testing
. . . . . . . . . . . . .
5.10.2
Performing CSCUHWCI integration and testing . . . . . . . . . . . . . . . 18
18
5.10.3
Revision and retesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10.4
Analyzing and recording CSC1/HWCl integration and test results . . 19
5.11 SYstem WJaIification testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.11.1
Independence in system qualification testing . . . . . . . . . . . . . . . . 19
5.11.2
Testing onthetarget
computer system . . . . . . . . . . . . . . . . . . . . 19
5.11.3
Preparing for system qualification testing . . . . . . . . . . . . . . . . . . . 19
5.11.4
Dryrunof
system qualification testing
. . . . . . . . . . . . . . . . . . . . 19
5.11.5
Performing system qualification testing . . . . . . . . . . . . . . . .
19
5.11.6
Revision and retesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.11.7
Analyzing and recording system qualification test results . . . . . . . . 20

iv

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
CONTENTS

- Continued

E!am

ParaaraDh
5.12

Preparing for software use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...20


5.12.1
Preparing the executable software
. . . . . . . . . . . . . . . . . . ., . . .
5.12.2
Preparing version descriptions for user sites . . . . . . . . . . . . . . . . .
5.12.3
Preparing user manuals.
. . . . . . . . . . . . . . . . . . . . . . . . ... ...20
5.12.3.1
Software user manuals, . . . . . . . . . . . . . . . . . . . . . . .
5.12.3.2
Software input/output manuals . . . . , . . . , . . . . . . . . .
5.12.3.3
Software center operator manuals , . . . . . . . . . . . . . . .
5.12.3.4
Computer operation manuals . . . . . . . . . . . . . . . . . . . .
5.12.41
nstallation at user sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...21
5.13 Preparing for software transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13.1
Preparing the executable software
. . . . . . . . . . . . . . . . . . . . . . .
5.13.2
Preparing source fries . . . . . . . . . . . . . . . . . . . . . . . . . .,, . ...21
5.13.3
Preparing version descriptions for the support site . ., , ., . . . , . .
5.13.4
Preparing the as built CSCI design and reiated information
, . . . .
5.13.5
Updating the system design description . . . . . . . . . . . . ., . . . . . .
5.13.6
Preparing support manuais . . . . . . . . . . . . . . . . . . . . . . . . . . ...22
5.13.6.1
Computer programming manuais . . . . . . . . . . . . . . . . .
5.13.6.2
Firmware support manuais . . . . . . . . . . . . . . . . . . . . .
5.13.7
Transition to the designated support site . . . . . . . . . . . . . . . . . . .
5.14 Software configuration management
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.14.1
Configuration identification
. . . . . . . . ., . . . . . . . . . . . . . . . . . .
5.14.2
Configuration control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...23
5.14.3
Configuration status accounting . . . . . . . . . . . . . . . . . . . . . . . . .
5.14.4
Configuration audits..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . ...23
5.14.5
Packaging, storage, handling, and delivery . . . . . . . . . . . . . . . . . .
5.15 Software product evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.15.1
In-process and final software product evaluations . . . . . . . . . . . . .
5.15.2
Software product evaluation records . . . . . . . . . . . . . . . . . . . . . .
5.15.3
Independence in software product evaluation . . . . . . . . . . . . . . . .
5.16 Software quality assurance
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.16.1
Software quaiity assurance evaluations . . . . . . . . . . . . . . . . . . . .
5.16.2
Software quality assurance records . . . . . . . . . . . . . . . . . . . . . . .
5.16.3
Independence in software quality assurance . . , . , . . . . . . . . . . . .
5.17 Corrective action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.17.1
Probiem/change reports . . . . . . . . . .,, . . . . . . . . . . . . . . . . ...25
5.17.2
Corrective action system.,,..,..
. . . . . . . . . . . . . . . . . . . . . .
5.18 Joint technical andrnanagement
reviews . . . . . . . . . . . . . . . . . . . . . . . . .
5.18.1
Joint technical reviews,
. . . . . . . . . . . . . . . . . . . . . . . . . . . ...26
5.18.2
Joint management reviews
. . . . . . . . . . . . . . . . . . . . . . . . . ...26
5.190ther
activities .,.......
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.19.1
Risk management
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...26
5.19.2
Software management indicators . . . . . . . . . . . . . . . . . . . . . . . .
5.19.3
Security and privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ..27
5.19.4
Subcontractor management
. . . . . . . . . . . . . . . . . . . . . . . . . . ..27
5.19.5
Interface with software lV&V agents
. . . . . . . . . . . . . . . . . . . . .
5.19.6
Coordination with associate developers . . . . . . . . . ., . . . . . . . . .
5,19.7
Improvement of project processes
. . . . . . . . . . . . . . . . . . . . . . .

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

20
20
20
20
21
21
21
21
21
21
22
22
22
22
23
23
23
23
24
24
24
24
24
24
24
25
25
25
25

26
27

27
27
27

MIL-STD-498
CONTENTS

6.

- Continued

NOTES...............
s.

Intended use . . . . . . . . . . . . ...o.oc..-..I


6.1
6.2
Data requirements . . . . . . . . . . . . . . . . . . . . . . .
6.3
Relationship between standard and CDRL . . . . . .
6.4
Delivery of tool contents
. . . . . . . . . . . . . . . . . .
6.5
Tailoring guidance,
. . . . . . . . . . . . . . . . . . . . . .
6.6
Cost/schedulereporting
. . . . . . . . . . . . . . . . . . .
6.7
Related standardization documents
. . . . . . . . . . .
6.8
Subject term (key word) listin9 .....................

.. O

h-
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . , . . . . . ...29
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . ...29
. . . . . . . . . . . . . . . . . .
. . . .. ....29

::
28
29
29
29

APPENDIXES

!329!2
A

LIST OFACRONYMS
. . . . . . . . .
A.1
Scope . . . . . . . . . . . . . . .
A.2
Applicable documents
. . .
A.3
Acronyms . . . . . . . . . . . .

INTERPRETING MIL-STD-498
FOR INCORPORATION
OF REUSABLE
SOFTWARE PRODUCTS
. . . . . . . . . . . . . . . . . . . . . . . . . . ., . . . . . ...33
B.1
Scope . . . . . . . . . . . . . . . . . . ......-.............
. . . . 33
B.2
Applicable documents
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...33
Evaluating reusable software products . . . . . . . . . . . . . . . . . . . . . . 33
0.3
Interpreting MIL-STD-498
activities for reusable software
6.4
products . . . . . . . . . . . . . . . . .....................
...
33

CATEGORY AND PRIORITY CLASSIFICATIONS


FOR PROBLEM
Scope . . . . . . . . . . . . . . .
...f...................
C.1
C.2
Applicable documents
. . . . . . . . . . . . . . . . . . . . . . .
C.3
Classification by category . . . . . . . . . . . . . . . . . . . . .
C.4
Classification byptiotity
. . . . . . . . . . . . . . . . . . . . . .

SOFTWARE PRODUCT EVALUATIONS


D.1
Scope . . . . . . . . . . . . . . . . .
0.2
Applicable documents
. . . . .
0.3
Required evaluations
. . . . . .
D.4
Criteria definitions
.,......

.
.
.
.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
-. .- a s . . . . . . . . . . . . . . . . . . . . . . . ~~
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
. .....................
..-..

.
.
.
.

. . . . . . . .
......................
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .

CANDIDATE JOINT MANAGEMENT


REVIEWS . . .
E.1
Scope . . . . . . . . . . . . .
....o....c....
E.2
Applicable documents
. . . . . . . . . . . . . . .
Assumptions . . . . . . . . . . . . . . . . . . . . . .
E.3
Candidate reviews . . . . . . . . . . . . . . . . . .
E.4

REPORTING
36
. . . . ~~
. . . . . . . . . .
. . . . . . . ...36
. . . . . . . ...36

. . . . . . . . . . . . . . .
.
. . . . . . . . . . . . . . .
. . . . . . ...........~~
. . . . . . . . . . . . . . .

. . .38
. . . ~~
. . .
. . .

. . . . . . . . . . . . . . . . . . 44
.c~~
. . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . ...44
. . . . . . . . . . . . . . . ...44

vi

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498

CONTENTS

- Continued

APPENDIXES
~

&UMlL!&
F

CANDIDATE MANAGEMENT
INDICATORS
. .
F.1
Scope . . . . . . . . . . . . . . . . . . . . . . . .
F.2
Applicable documents
. . . . . . . . . . . .
F.3
Candidate indicators . . . . . . . . . . . . . .

GUIDANCE ON PROGRAM STRATEGIES, TAILORING, AND BUILD


PLANNING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.1
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...47
G.2
Applicable documents
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...47
G.3
Candidate program strategies
. . . . . . . . . . . . . . . . . . . . . . . . . ...47
G.4
Selecting inappropriate
program strategy
. . . . . . . . . . . . . . . . . . .
G.5
Relationship of MlL-STD-498to
program strategies . . . . . . . . . . . . .
G.6
Planning software builds andtailoting
MIL-STD-498
. . . . . . . . . . . . .

INDEX

GUIDANCE ON ORDERING DELIVERABLES


H.1
Scope . . . . . . . . . . . . . . . . . . . . .
H.2
Applicable documents
. . . . . . . . .
H.3
Ordering deliverables
.,....
. . . .
H.4
Scheduling deliverables .,...
. . . .
H.5
Format of deliverables
. . . . . . . . .
H.6
Tailoring the Dads . . . . . . . . . . . .
CONVERSION GUIDE FROM
1.1
Scope . . . . . . . . . . .
1.2
Applicable documents
1.3
Mapping ofkeyterms
1.4
Mapping of Dads,
. .

.
.
.
.
.
.

DOD-STD-2167A
. . . . . . . . . . .
. . . . . . . . . .
...,..
. . . . .
. . . . . . . . . . .

. . . . .
. . . . .
. . . . .
. . . . .

. .
. .
. .
. .

. . .
. . .
. . .
. . .

. . . . .
. . . . .
. . . . .
. . . . .

. . . . . . 46
. . . ...46
. . . ...46
. . . ...46

. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

AND
. . .
. . .
. . .
. . .

.
.
.
.

DOD-STD-7935A
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

.
.
.
.

.
.
.
.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

48
48
48

. . . 56
. . . 56
...56
...56
...56
...56
...56

. . . .
. . . .
. ...57
. . . .
. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

47

57
57
57
57
61

MIL-STD-498
CONTENTS

- Continued

FIGURES

!3!u

Ew!2
1

One possible mapping of MIL-STD-498

Related standardization

Interpreting

Categories to be used for classifying

Priorities to be used for classifying

problems

. . . . . . . . . . . . . . . . . . . . . . 37

Software

evaluation

criteria . . . . . . . . . . . . . . . . . 39

Key features of three DOD program strategies

Sample risk analysis for determining

One possible way of applying MIL-STD-498


to the Grand Design
program strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

One possible way of applying MIL-STD-498


to the Incremental
program strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

51

One possible way of applying MIL-STD-498


to the Evolutionary
program strategy..........,..
. . . . . . . . . . . . . . . . . . . . . . . . . . ...

52

10

1?

documents

MI L-STD-498

activities to multiple builds . . .

. . . 11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

for incorporation

products and associated

of reusable software

problems in software

. . . . . . . . 34

products

. . . . . . 37

. . . . . . . . . . . . . . . . . . . . . 47

the appropriate

program strategy

12

One possible way of applying MIL-STD-498

to a reengineering

13

Example of build planning for a MIL-STD-498

14

Mapping of key terms

15

Mapping of DOD-STD-7935A

16

Mapping of DOD-STD-21

17

Mapping of MIL-STD-498
DIDs to DOD-STD-21 67A and
DOD-STD-7935A
DADS......,..
. . . . . . . . . . . . . . . . . . ......

project

project

. . . . 49

. . . . 53

. . . . . . . . . . . . . . . . 54

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....

57

DIDs to MIL-STD-498

DIDs

. . . . . . . . . . . . . 58

67A DIDs to MIL-STD-498

DIDs

. . . . . . . . . . . . . 59

Vlll

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

.60

MIL-STD-498
1. SCOPE
1.1
&QQS.Q.
The purpose of this standard
software development and documentation.

1.2

Ar)Dlicat ion.

MIL-STD-498

is to establish

uniform

requirements

for

is intended to be applied as follows.

1.2.1
Qraanizat ions and aa reement~.
This standard can be applied to contractors,
subcontractors, or Government in-house agencies performing software development,
For
uniformity, the term acquirer is used for the organization requiring the technical effort,
developer for the organization performing the technical effort, contract for the agreement
between these parties, Statement of Work* (SOW) for the list of tasks to be performed by
the developer, Contract Data Requirements List (CDRL) for the list of deliverable software
products, and subcontractor for any organization tasked by the developer to perform part
of the required effort. Software development is used as an inclusive term encompassing
new development, modification, reuse, reengineering, maintenance, and all other activities
resulting in software products.
1.2.2
Contract-sDec ific a f.mlication. This standard is invoked by citing it on a contract.
It
applies to each software product and to each type of software covered by the contract,
regardless of storage medium, to the extent specified in the contract. Examples of types of
software include deliverable versus non-deliverable, software designed to meet user needs
versus software in the engineering and test environments, and software designed to meet one
user need versus software designed to meet another. The acquirer is expected to specify the
types of software to which the standard applies and to tailor the standard appropriately for
each type of software.
If the standard is invoked without such a statement of selective
application, it will be understood to apply in its entirety to all deliverable software, with
requirements concerning the software development environment applicable to the software
development environment for the deliverable software. While this standard is written in terms
of Computer Software Configuration Items (CSCIS), it may be applied to software not
designated as a CSCI, with the term CSCI interpreted appropriate y. Software installed in
firmware is subject to all of the aforementioned provisions. This standard does not apply to
the hardware element of firmware.
1.2.3
Tailorinq. This standard and its Data Item Descriptions (DIDs) are meant to be tailored
for each type of software to which they are applied. While tailoring is the responsibility of the
acquirer, suggested tailoring may be provided by prospective and selected developers.
General tailoring guidance can be found in Section 6 and in DO D-HDBK-248.
Tailoring
guidance specific to this standard can be found in Appendixes G and H and in guidebooks and
handbooks planned for this standard.
1.2.4
Intermetat ion of selected te rm$. The following terms have a special interpretation
used in this standard.
1.2.4,1
a.

Intemreta tion of svste m. The following

interpretations

as

apply:

The term system, as used in this standard, may mean: (1 ) a hardware-software


system (for example, a radar system) for which this standard covers only the software
portion, or (2) a software system (for example, a payroll system) for which this
standard governs overall development.

1
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
b.

If a system consists of subsystems, all requirements in this standard concerning


systems apply to the subsystems as well. If a contract is based on alternatives to
systems and subsystems, such as complex items, the requirements in this standard
concerning the system and its specification apply to these alternatives and their
specifications.

1.2.4.2
Interoretat ion of f)articiQate in svste m de veloDmen~. The term participate in
paragraphs regarding system-level activities is to be interpreted as follows: If the software
covered by this standard is part of a hardware-software
system for which this standard covers
only the software portion, the term participate is to be interpreted as take part in, as
described in the software development plan. If the software (possibly with its computers)
is considered to constitute a system, the term participate is to be interpreted as be
responsible for.
1.2.4.3
lnteroretat ion of develoc), define, etc. Throughout this standard, requirements
to develop, define, establish, or identify information are to be interpreted to include
new development, modification, reuse, reengineering, maintenance, or any other activity or
combination of activities resulting in software products.
1.2.4.4
Interwetat ion of record. Throughout this standard, requirements to record
information are to be interpreted to mean set down in a manner that can be retrieved and
viewed. The result may take many forms, including, but not limited to, hand-written notes,
hard-copy or electronic documents, and data recorded in computer-aided software engineering
(CASE) and project management tools.
1.3
Order of mecedenc~.
In the event of conflict between the requirements of this
standard and other applicable standardization documents, the acquirer is responsible for
resolving the conf Iicts.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
2,

REFERENCED DOCUMENTS

This section does not apply to this standard, since no documents are referenced in Sections
3, 4, or 5. Section 6 contains a list of standardization documents that may be used with this
standard.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
3.

DEFINITIONS

Note: In addition to the definitions provided here, Section 1 describes MIL-STD-498S


interpretation or special usage of the following terms: acquirer, contract, Contract Data
Requirements List, define, develop, developer, establish, identify, participate, record,
software development, Statement of Work, subcontractor, subsystem, and system.
3.1
AcceDta rice. An action by an authorized representative of the acquirer by which the
acquirer assumes ownership of software products as partial or complete performance of a
contract.
Acauirer.
3.2
organization.

An organization

that

procures software

products

for itself or another

Aomcwal. Written notification by an authorized representative of the acquirer that a


3.3
developers plans, design, or other aspects of the project appear to be sound and can be used
as the basis for further work. Such approval does not shift responsibility from the developer
to meet contractual requirements.
Architecture.
3.4
The organizational structure of a system or CSCI,
components, their interfaces, and a concept of execution among them,

identifying

its

develotrer.
An organization
that is neither prime contractor
nor
3.5
Associate
subcontractor to the developer, but who has a development role on the same or related
system or project.
Behavioral des ian. The design of how an overall system or CSCI will behave, from a
3.6
users point of view, in meeting its requirements, ignoring the internal implementation of the
system or CSCI. This design contrasts with architectural design, which identifies the internal
components of the system or CSCI, and with the detailed design of those components.
3.7
Build. (1) A version of software that meets a specified subset of the requirements that
the completed software will meet.
(2) The period of time during which such a version is
developed. Note: The relationship of the terms build and version is up to the developer;
for example, it may take several versions to reach a build, a build may be released in several
parallel versions (such as to different sites), or the terms may be used as synonyms.
3.8

co mfwte r database.

See database.

Devices capable of accepting and storing computer data,


3.9
0 mrmte r hardware.
executing a systematic sequence of operations on computer data, or producing control
outputs. Such devices can perform substantial interpretation, computation, communication,
control, or other logical functions.
3.10
~omrwter
enable computer
3.11

Droa ram. A combination of computer instructions and data definitions that


hardware to perform computational or control functions.

comD uter Software.

See software.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
3.12
Comtwter S oftware Co nfia uration Item (Csc l). An aggregation of software that
satisfies an end use function and is designated for separate configuration management by the
acquirer. CSCIS are selected based on tradeoffs among software function, size, host or target
computers, developer, support concept, plans for reuse, criticality, interface considerations,
need to be separately documented and controlled, and other factors.
3.13
co nfia uration Item. An aggregation of hardware, software, or both that satisfies an
end use function and is designated for separate configuration management by the acquirer.
3.14
Databas~. A collection of related data stored in one or more computerized files in a
manner that can be accessed by users or computer programs via a database management
system.
3.15
-base
management svste m. An integrated set of computer programs that provide
the capabilities needed to establish, modify, make available, and maintain the integrity of a
database.
Jleliverable so ftware moduc$. A software product that is required by the contract to
3.16
be delivered to the acquirer or other designated recipient.
3.17
-.
in response to
elaborations of
requirement to
decisions about

Those characteristics of a system or CSCI that are selected by the developer


the requirements.
Some will match the requirements; others will be
requirements, such as definitions of all error messages in response to a
display error messages; others will be implementation
related, such as
what software units and logic to use to satisfy the requirements,

3.18
PeveloD er. An organization that develops software products (develops may include
new development, modification, reuse, reengineering, maintenance, or any other activity that
results in software products). The developer may be a contractor or a Government agency.
3.19
Poc~ ment /do cumentat ion. A collection of data, regardless of the medium on which
it is recorded, that generally has permanence and can be read by humans or machines.
3.20
~Vah,lation.
criteria.

The process of determining

whether

an item or activity meets specified

3.21
Firmware. The combination of a hardware device and computer instructions
computer data that reside as read-only software on the hardware device.
3.22
l+a rdware C onficwration lte m (HWCl~. An aggregation of hardware
end use function and is designated for separate configuration management

and/or

that satisfies an
by the acquirer.

3.23
jnde~ endent verific ation and validat ion (lV&V[.
Systematic evaluation of software
products and activities by an agency that is not responsible for developing the product or
performing the activity being evaluated.
lV&V is not within the scope of this standard.
3.24
Interface. In software development, a relationship among two or more entities (such
as CSCI-CSCI, CSCI-HWCI, CSC1-user, or software unit-software unit) in which the entities
share, provide, or exchange data. An interface is not a CSCI, software unit, or other system
component; it is a relationship among them.

5
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
3.25
)0 int review. A process or meeting involving representatives of both the acquirer and
the developer, during which project status, software products, and/or project issues are
examined and discussed.
A software product that is not required by the
3.26
Non-deliverable software moduc~.
contract to be delivered to the acquirer or other designated recipient.
An organized set of activities
3.27
Proce~.
the software development process.

performed for a given purpose; for example,

3.28
Qua lifica tion test ing, Testing performed to demonstrate
or a system meets its specified requirements,

to the acquirer that a CSCI

The process of examining and altering an existing system to


3.29
Reermineerinq.
reconstitute it in a new form. May include reverse engineering (analyzing a system and
producing a representation at a higher level of abstraction, such as design from code),
restructuring (transforming a system from one representation to another at the same level of
abstraction),
redocumentation
(analyzing
a system and producing user or support
documentation),
forward engineering (using software products derived from an existing
system, together with new requirements, to produce a new system), retargeting (transforming
a system to install it on a different target system), and translation (transforming source code
from one language to another or from one version of a language to another).
3.30
Rea uiremen~, (1) A characteristic that a system or CSCI must possess in order to be
acceptable to the acquirer. (2) A mandatory statement in this standard or another portion of
the contract.
A software product developed for one use but having
3.31
Reusable s oftware moduct.
other uses, or one developed specifically to be usable on multiple projects or in multiple roles
on one project, Examples include, but are not limited to, commercial off-the-shelf software
products, acquirer-furnished software products, software products in reuse libraries, and preEach use may include all or part of the software
existing developer software products.
product and may involve its modification.
This term can be applied to any software product
(for example, requirements, architectures, etc.), not just to software itself.
3.32
software.
Computer programs and computer databases.
Note:
Although some
definitions of software include documentation, MIL-STD-498
limits the definition to computer
programs and computer databases in accordance with Defense Federal Acquisition Regulation
Supplement 227.401.
software de veloDment. A set of activities that results in software products. Software
3.33
development may include new development, modification, reuse, reengineering, maintenance,
or any other activities that result in software products.
software
A repository for material pertinent to the
3.34
de veloDment file (SDF1.
Contents typically include (either directly or
development of a particular body of software.
by reference) considerations, rationale, and constraints related to requirements analysis,
design, and implementation;
developer-internal
test information; and schedule and status
information.
3.35
so ftware development Iibrarv (S DL1. A controlled collection of software, documentation, other intermediate and final software products, and associated tools and procedures
used to facilitate the orderly development and subsequent support of software.
6

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
3,36
so ftware development moces~.
user needs into software products.

An organized set of activities performed to translate

As
3.37
software e nainee ring. In general usage, a synonym for software development.
used in this standard, a subset of software development consisting of all activities except
The standard makes this distinction for the sole purpose of giving
qualification testing.
separate names to the software engineering and software test environments.
3.38
The facilities, hardware, software, firmware,
so ftware e naine erirw environment.
procedures, and documentation
needed to perform software engineering.
Elements may
include but are not limited to computer-aided software engineering (CASE) tools, compilers,
assemblers,
linkers, loaders, operating
systems,
debuggers,
simulators,
emulators,
documentation tools, and database management systems.
3.39
~ftware
woduct.
Software or associated information created, modified, or incorporated to satisfy a contract. Examples include plans, requirements, design, code, databases,
test information, and manuals.
3.40

software

auality.

The ability of software

to satisfy its specified requirements.

3.41
so ftware SUDI)Orl. The set of activities that takes place to ensure that software
installed for operational use continues to perform as intended and fulfill its intended role in
system operation. Software support includes software maintenance, aid to users, and related
activities.
3.42
software svst em. A system consisting solely of software
equipment on which the software operates.

and possibly the computer

3.43
so ftware test e nvironme n~. The facilities, hardware, software, firmware, procedures,
and documentation needed to perform qualification, and possibly other, testing of software.
Elements may include but are not limited to simulators, code analyzers, test case generators,
and path analyzers, and may also include elements used in the software engineering
environment.
The set of activities that enables responsibility for software
3.44
so ftware t ransition.
development to pass from one organization, usually the organization that performs initial
software development, to another, usually the organization that will perform software support.
3.45
so ftware unit. An element in the design of a CSCI; for example, a major subdivision
of a CSCI, 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.
3.46

~uDDo rt (0 f software~,

3.47

Transition

3.48

~~ fini i n

(of software).
f

rnm

See software

support,

See software

transition.

in hi

. See Appendix A.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
4.

GENERAL REQUIREMENTS

4.1
so ftware develotrment mocess. The developer shall establish a software development
process consistent with contract requirements.
The software development process shall
include the following major activities, which may overlap, may be applied iteratively, may be
applied differently to different elements of software, and need not be performed in the order
listed below. Appendix G provides examples. The developers software development process
shall be described in the software development plan.
Project planning and oversight (section 5.1 )
Establishing a software development environment (5.21
System requirements analysis (5.3)
System design (5.4)
::
e. Software requirements analysis (5. 5)
f.
Software design (5.6)
9. Software implementation and unit testing (5. 7)
h. Unit integration and testing (5.8)
i.
CSCI qualification testing (5.9)
CSC1/HWCl
integration and testing (5. 10)
j.
k. System qualification testing (5. 11 )
1. Preparing for software use (5. 12)
m. Preparing for software transition (5. 13)
no Integral processes:
1) Software configuration management (5.14)
2)
Software product evaluation (5. 15)
3)
Software quality assurance (5.16)
4)
Corrective action (5.17)
5)
Joint technical and management reviews (5.18)
6)
Other activities (5.19)
a.
b.

The developer shall meet the


4.2
Ge neral reau irements for software develoDmen~.
following general requirements in carrying out the detailed requirements in section 5 of this
standard.
The developer shall use systematic, documented
4.2.1
so ftware develoc)ment methods.
These methods shall be described in, or
methods for all software development activities.
referenced from, the software development plan.
4,2.2
Sta ndards for software woducts. The developer shall develop and apply standards for
representing requirements, design, code, test cases, test procedures, and test results. These
standards shall be described in, or referenced from, the software development plan.
4,2.3

Reusable so ftwwe

moduct~.

The developer shall meet the following

requirements.

The developer shall identify and evaluate


4.2.3.1
Incort)oratinu reusable software moduc~.
reusable software products for use in fulfilling the requirements of the contract. The scope
of the search and the criteria to be used for evaluation shall be as described in the software
development plan. Reusable software products that meet the criteria shall be used where
practical. Appendix B provides required and candidate criteria and interprets this standard for
incorporation of reusable software products, Incorporated software products shall meet the
data rights requirements in the contract.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
During the course of the contract, the
4.2.3.2
Jleve Ioc)irm reusab Ie so ftware r)roduc~.
developer shall identify opportunities fordeveioping
software products for reuse and shall
Opportunities that provide cost
evaluate the benefits and costs of these opportunities.
benefits and are compatible with program objectives shall be identified to the acquirer.
Note: In addition, the developer
products specifically for reuse.
4.2.4

may be required by the contract

Hendlimr of critical reau iremen~.

to develop software

The developer shall meet the following requirements.

4.2.4.1
~afetv assu rancQ. The developer shall identify as safety-critical those CSCIS or
portions thereof whose failure could lead to a hazardous system state (one that could result
in unintended death, injury, loss of property, or environmental harm).
If there is such
software, the developer shall develop a safety assurance strategy, including both tests and
analyses, to assure that the requirements, design, implementation, and operating procedures
for the identified software minimize or eliminate the potential for hazardous conditions. The
strategy shall include a software safety program, which shall be integrated with the system
The developer shall record the strategy in the software
safety program if one exists.
development plan, implement the strategy, and produce evidence, as part of required software
products, that the safety assurance strategy has been carried out.
4.2.4.2
*CU ritv assu rance. The developer shall identify as security-critical those CSCIS or
portions thereof whose failure could lead to a breach of system security.
If there is such
software, the developer shall develop a security assurance strategy to assure that the
requirements, design, implementation, and operating procedures for the identified software
minimize or eliminate the potential for breaches of system security. The developer shall record
the strategy in the software development plan, implement the strategy, and produce evidence,
as part of required software products, that the security assurance strategy has been carried
out .
4.2.4.3
Privacv assu ranc~. The developer shall identify as privacy-critical those CSCIS or
portions thereof whose failure could lead to a breach of system privacy.
If there is such
software, the developer shall develop a privacy assurance strategy to assure that the
requirements, design, implementation, and operating procedures for the identified software
minimize or eliminate the potential for breaches of system privacy. The developer shall record
the strategy in the software development plan, implement the strategy, and produce evidence,
as part of required software products, that the privacy assurance strategy has been carried
out .
4.2.4.4
Assurance of other critical reau irement~. If a system relies on software to satisfy
other requirements deemed critical by the contract or by system specifications, the developer
shall identify those CSCIS or portions thereof whose failure could lead to violation of those
critical requirements;
develop a strategy to assure that the requirements,
design,
implementation, and operating procedures for the identified software minimize or eliminate the
potential for such violations; record the strategy in the software development plan; implement
the strategy; and produce evidence, as part of required software products, that the assurance
strategy has been carried out.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
co m cmter hardware re~ rce ut ilizat ion. The developer shall analyze contract require4.2.5
ments concerning computer hardware resource utilization (such as maximum allowable use
of processor capacity, memory capacity, input/output device capacity, auxi~iary storage device
capacity, and communications/network
equipment capacity).
The developer shall allocate
computer hardware resources among the CSCIS, monitor the utilization of these resources for
the duration of the contract, and reallocate or identify the need for additional resources as
necessary to meet contract requirements.
4.2.6
Reco rdina rationalQ. The developer shall record rationale that will be useful to the
support agency for key decisions made in specifying, designing, implementing, and testing the
software.
The rationale shall include trade-offs considered, analysis methods, and criteria
used to make the decisions. The rationale shall be recorded in documents, code comments,
or other media that will transition to the support agency. The meaning of key decisions and
the approach for providing the rationale shall be described in the software development plan.
4.2.7
Access for acau irer review, The developer shall provide the acquirer or its authorized
representative
access to developer and subcontractor
facilities, including the software
engineering and test environments, for review of software products and activities required by
the contract.

10

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.

DETAILED REQUIREMENTS

The order of the requirements in this section is not intended to specify the order in which they
must be carried out. Many of the activities may be ongoing at one time; different software
products may proceed at different paces; and activities specified in early subsections may
depend on input from activities in later subsections. If the software is developed in multiple
builds, some activities may be performed in every build, others may be performed only in
selected builds, and activities and software products may not be complete until several or all
builds are accomplished.
Figure 1 provides an example of how each activity may be applied
in one or more builds. Non-mandatory notes throughout section 5 tell how to interpret each
A project involving a single build will
activity on a project involving multiple builds,
accomplish all required activities in that build. Appendix G provides guidance for planning
apply to each build, and scheduling these activities.
builds, determining which activities

Builds
Activity

Build1

Build2

Build3

Build 4

5.9 CSCI qualificationtesting

5.10 CSC1/HWClintegrationand testing

5.1

Project planning and oversight

5.2

Establishing a software

5.3

System requirements

5.4

System design

5.5

Software

requirements

5.6

Software

design

5.7

Software

implementation

5.8

Unit integration

development

environment

analysis

analysis

and unit testing

and testing

5.11

System qualification

testing

5.12

Preparing for software

use

5.13

Preparing for sottware

transition

Integral processes:
x

product evaluation

quality assurance

5.14

Software

configuration

5.15

Software

5.16

Software

5.17

Corrective

management

action

5.18

Joint technical and management

5.19

Other activities

reviews

FIGURE 1. gne ROSSible maf)D ina of MIL-STD-498

act ivities to multide

11

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

bu ilds.

MIL-STD-498
5.1
Proiect 1)Iannina and oversiah~.
The developer shall perform
oversight in accordance with the following requirements.

project planning and

Note: If a system or CSCI is developed in multiple builds, planning for each build should
be interpreted to include: a) overall planning for the contract, b) detailed planning for the
current build, and c) planning for future builds covered under the contract to a level of
detail compatible with the information available.
5.1.1
so ftware de veioc)ment r)lanning. The developer shall develop and record plans for
conducting the activities required by this standard and by other software-related requirements
in the contract. This planning shall be consistent with system-level planning and shall include
all applicable items in the Software Development Plan (SDP) DID (see 6.2).
Note 1: The wording here and throughout MIL-STD-498
is designed to: 1) Emphasize that
the development and recording of planning and engineering information is an intrinsic part
of the software development process, to be performed regardless of whether a deliverable
is required; 2) Use the DID as a checklist of items to be covered in the planning or
engineering activity; and 3) Permit representations other than traditional documents for
recording the information (e.g., computer-aided software engineering (CASE) tools).
Note 2: If the CDRL specifies delivery of the information generated by this or any other
paragraph, the developer is required to format, assemble, mark, copy, and distribute the
deliverable in accordance with the CDRL. This task is recognized to be separate from the
task of generating and recording the required information and to require additional time and
effort on the part of the developer.
Note 3: The software development plan covers all activities required by this standard.
Portions of the pfan may be bound or maintained separately if this approach enhances the
usability of the information.
Examples include separate plans for software quality
assurance and software configuration management.
5.1.2
~scl test DIanning. The developer shall develop and record plans for conducting CSCI
qualification testing. This planning shall include all applicable items in the Software Test Plan
(STP) DID (see 6.2).
5.1.3
Syste m test DIanning. The developer shall participate in developing and recording plans
for conducting system qualification testing. For software systems, this planning shall include
all applicable items in the Software Test Plan (STP) DID {see 6.2). (The intent for software
systems is a single software test plan covering both CSCI and system qualification testing. )
5.1.4
Softwa re installation DIanninq. The developer shall develop and record plans for
performing software installation and training at the user sites specified in the contract. This
planning shall include all applicable items in the Software Installation Plan (SIP) DID (see 6.2).
The developer shall identify all software development
5.1.5
so ftware transition danninq.
resources that will be needed by the support agency to fulfill the support concept specified
in the contract, The developer shall develop and record plans identifying these resources and
describing the approach to be followed for transitioning deliverable Items to the support
agency. This planning shall include all applicable items in the Software Transition Plan (STrP)
DID (see 6.2).

12

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.1,6
Fo Ilowina and t.mdat ina dan$. Following acquirer approval of any of the plans in this
section, the developer shall conduct the relevant activities in accordance with the plan. The
developers management shall review the software development process at intervals specified
in the software development plan to assure that tl-re process complies with the contract and
adheres to the plans. With the exception of developer-internal scheduling and related staffing
information, updates to plans shall be subject to acquirer approval.
5.2
The developer shall establish a
-tab Iishirm a software development environmen~.
software development environment in accordance with the following requirements.
Note:
If a system or CSCI is developed in multiple builds, establishing the software
development environment in each build should be interpreted to mean establishing the
environment needed to complete that build.
5.2.1
so ftware encrineerina environmen~. The developer shall establish, control, and maintain
a software engineering environment to perform the software engineering effort,
The
developer shall ensure that each element of the environment performs its intended functions,
The developer shall establish, control, and maintain a
5.2.2
so ftware test environment.
software test environment to perform qualification, and possibly other, testing of software.
The developer shall ensure that each element of the environment performs its intended
functions.
5.2.3
so ftware deveioDment library. The developer shall establish, control, and maintain a
software development library (SOL) to facilitate the orderly development and subsequent
The SOL may be an integral part of the software engineering and test
support of software.
environments.
The developer shall maintain the SOL for the duration of the contract.
5.2.4
software develoDment files. The developer shall establish, control, and maintain a
software development file (SDF) for each software unit or logically related group of software
units, for each CSCI, and, as applicable, for logical groups of CSCIS, for subsystems, and for
The developer shall record information about the development of the
the overall system.
software in appropriate SDFS and shall maintain the SDFS for the duration of the contract.
The developer may use non-deliverable software in the
5.2.5
Non-deliverable software.
development of deliverable software as long as the operation and support of the deliverable
software after delivery to the acquirer do not depend on the non-deliverable software or
provision is made to ensure that the acquirer has or can obtain the same software.
The
developer shall ensure that all non-deliverable software used on the project performs its
intended functions.
5.3
$vSte m reau irements analvsi~. The developer shall participate in system requirements
analysis in accordance with the following requirements.
Note: [f a system is developed in multiple builds, its requirements may not be fully defined
until the final build. The developers planning should identify the subset of system
requirements to be defined in each build and the subset to be implemented in each build.
System requirements analysis for a given build should be interpreted to mean defining the
system requirements so identified for that build.

13

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5,3.1
Analvsis of use r inc)ut. The developer shall participate in analyzing user input provided
bytheacquirer
togainan understanding ofuser needs. This input maytake the form of need
statements, surveys, problem/change reports, feedback on prototypes, interviews, or other
user input or feedback.
5.3.2
erational conceD~. The developer shall participate in defining and recording the
The result shall include all applicable items in the
operational concept for the system.
Operational Concept Description (OCD) DID (see 6.2).
5.3.3
The developer shall participate in defining and recording the
ste m reauiremen&.
requirements to be met by the system and the methods to be used to ensure that each
requirement has been met.
The result shall include all applicable items in the System/
Subsystem Specification (SSS) DID (see 6.2). Depending on CDRL provisions, requirements
concerning system interfaces may be included in the SSS or in interface requirements
specifications (IRSS).
Note:
If a system consists of subsystems, the activity in 5.3.3 is intended to be
performed iteratively with the activities in 5.4 (System design) to define system
requirements, design the system and identify its subsystems, define the requirements for
those subsystems, design the subsystems and identify their components, and so on.
5.4
following

em des ian. The developer shall participate in system design in accordance with the
requirements.

Note: If a system is developed in multiple builds, its design may not be fully defined until
the final build. The developers planning should identify the portion of the system design
to be defined in each build. System design for a given build should be interpreted to mean
defining the portion of the system design identified for that build.
The deve)oper shall participate in defining and
5.4.1
Svste m-wide des ian dec isionS.
recording system-wide design decisions (that is, decisions about the systems behavioral
design and other decisions affecting the selection and design of system components).
The
result shall include all applicable items in the system-wide
design section of the
System/Subsystem
Design Description (SSDD) DID (see 6.2). Depending on CDRL provisions,
design pertaining to interfaces maybe included in the SSDD or in interface design descriptions
(IDDs) and design pertaining to databases maybe included in the SSDD or in database design
descriptions (DBDDs).
Note: Design decisions remain at the discretion of the developer unless formally converted
to requirements through contractual processes. The developer is responsible for fulfilling
all requirements and demonstrating this fulfillment through qualification testing (see 5.9,
5.11 ). Design decisions act as developer-internal
requirements, to be implemented,
imposed on subcontractors, if applicable, and confirmed by developer-internal testing, but
their fulfillment need not be demonstrated to the acquirer.
5.4.2
Svste m architect ural des ian. The developer shall participate in defining and recording
the architectural design of the system (identifying the components of the system, their
interfaces, and a concept of execution among them) and the traceability between the system
The result shall include all applicable items in the
components and system requirements.
architectural design and traceability sections of the System/Subsystem
Design Description
(SSDD) DID (see 6.2).
Depending on CDRL provisions, design pertaining to interfaces may
be included in the SSDD or in interface design descriptions (IDDs).
14

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.5
so ftware reau irements a nalwii~. The developer shall define and record the software
requirements to be met by each CSCI, the methods to be used to ensure that each
requirement has been met, and the traceability between the CSCI reqwrements and system
Requirements
requirements.
The result shall include all applicable items in the Software
Specification (SRS) DID {see 6.2). Depending on CDRL provisions, requirements concerning
CSCI interfaces may be included in SRSS or in interface requirements specifications (IRSS).
Note: If a CSCI is developed in multiple builds, its requirements may not be fully defined
until the final build. The developers planning should identify the subset of each CSCIs
requirements to be defined in each build and the subset to be implemented in each build.
Software requirements analysis for a given build should be interpreted to mean defining
the CSCI requirements so identified for that build.
5.6
software des ian, The developer shall perform software
following requirements.

design in accordance

with the

Note: If a CSCI is developed in multiple builds, its design may not be fully defined until the
final build.
Software design in each build should be interpreted to mean the design
necessary to meet the CSCI requirements to be implemented in that build.
5.6.1
Gsc l-wide des ian dec ision~. The developer shall define and record CSC1-wide design
decisions (that is, decisions about the CSCIs behavioral design and other decisions affecting
the selection and design of the software units comprising the CSCI). The result shall include
ail applicable items in the CSC1-wide design section of the Software Design Description (SDD)
DID (see 6.2). Depending on CDRL provisions, design pertaining to interfaces maybe included
in SDDS or in interface design descriptions (IDDs) and design pertaining to databases may be
included in SDDS or in database design descriptions (DBDDs).
Csc I architect rat des i~.
The developer shall define and record the architectural
5.6.2
design of each CSCI (identifying the software units comprising the CSCI, their interfaces, and
a concept of execution among them) and the traceability between the software units and the
CSCI requirements. The result shall include all applicable items in the architectural design and
traceability sections of the Software Design Description (SDD) DID (see 6.2). Depending on
CDRL provisions, design pertaining to interfaces may be included in SDDS or in interface
design descriptions (IDDs).
Note: Software units may be made up of other software units and may be organized into
as many levels as are needed to represent the CSCI architecture.
For example, a CSCI
may be divided into three software units, each of which is divided into additional software
units, and so on.
5.6.3 ~SCl deta iled des ian. The developer shall develop and record a description of each
software unit. The result shall include all applicable items in the detailed design section of the
Software Design Description (SDD) DID {see 6.2).
Depending on CDRL provisions, design
pertaining to interfaces maybe included in SDDS or in interface design descriptions (IDDs) and
design of software units that are databases or that access or manipulate databases may be
included in SDDS or in database design descriptions (DBDDs).

15

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.7
so ftware
implementation

imtdementation and unit test in~. The developer shall perform


and unit testing in accordance with the following requirements.

software

Note: The term software includes both computer programs and computer databases.
The term implementation means converting software design into computer programs and
computer databases. If a CSCI is developed in multiple builds, software implementation
and unit testing of that CSCI will not be completed until the final build. Software
implementation and unit testing in each build should be interpreted to include those units,
or parts of units, needed to meet the CSCI requirements to be implemented in that build.
5.7.1
so ftware imdementat ion. The developer shall develop and record software corresponding to each software unit in the CSCI design. This activity shall include, as applicable,
coding computer instructions and data definitions, building databases, populating databases
and other data files with data values, and other activities needed to implement the design.
For deliverable software, the developer shall obtain acquirer approval to use any programming
language not specified in the contract,
Note: 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.
5.7.2
Preoa ring for unit test ing. The developer shall establish test cases (in terms of inputs,
expected results, and evaluation criteria), test procedures, and test data for testing the
software corresponding to each software unit. The test cases shall cover all aspects of the
units detailed design. The developer shall record this information in the appropriate software
development files (SDFS).
5.7.3
Performing unit te sting. The developer shall test the software corresponding to each
software unit. The testing shall be in accordance with the unit test cases and procedures.
5.7.4
Revision and retest in q , The developer shall make all necessary revisions to the
software, perform all necessary retesting, and update the software development files (SDFS)
and other software products as needed, based on the results of unit testing.
5.7.5
Analvzina and rec ordina unit test resu h$. The developer shall analyze the results of
unit testing and shall record the test and analysis results in appropriate software development
files (SDFS).
Unit intea ration and t esting. The developer shall perform unit integration and testing
5.8
in accordance with the following requirements.
Note 1: Unit integration and testing means integrating the software corresponding to two
or more software units, testing the resulting software to ensure that it works together as
intended, and continuing this process until all software in each CSCI is integrated and
tested. The last stage of this testing is developer-internal CSCI testing. Since units may
consist of other units, some unit integration and testing may take place during unit testing.
The requirements in this section are not meant to duplicate those activities.
Note 2: If a CSCI is developed in multiple builds, unit integration and testing of that CSCI
will not be completed until the final build. Unit integration and testing in each build should
be interpreted to mean integrating software developed in the current build with other
software developed in that and previous builds, and testing the results.
16

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.8.1
Pre~a rinu for unit intea ration and test inq. The developer shall establish test cases (in
terms of inputs, expected results, and evaluation criteria), test procedures, and test data for
conducting unit integration and testing. The test cases shall cover all aspects of the CSClThe developer shall record this information in the
wide and CSCI architectural design.
appropriate software development files (SDFS).
5.8.2
Fe rformina unit intea ration and test inq. The developer shall perform unit integration
test cases
and
and testing.
The testing shall be in accordance with the unit integration
procedures.

5.8.3
Revision and retest inq. The developer shall make all necessary revisions to the
software, perform all necessary retesting, and update the software development files (SDFS)
and other software products as needed, based on the results of unit integration and testing.
5.8.4
Analvzina and reco rdina unit intea ration and test resul~. The developer shall analyze
the results of unit integration and testing and shall record the test and analysis results in
appropriate software development files (SDFS).
5.9
CSC I aua Iification test inq. The developer shall perform CSCI qualification
accordance with the following requirements.

testing in

Note 1: CSCI qualification testing is performed to demonstrate to the acquirer that CSCI
requirements have been met. It covers the CSCI requirements in software requirements
specifications (SRSS) and in associated interface requirements specifications (IRSS). This
testing contrasts with developer-internal CSCI testing, performed as the final stage of unit
integration and testing.
Note 2: If a CSCI is developed in multiple builds, its CSCI qualification testing will not be
completed until the final build for that CSCI, or possibly until later builds involving items
with which the CSCI is required to interface.
CSCJ qualification testing in each build
should be interpreted to mean planning and performing tests of the current build of each
CSCI to ensure that the CSCI requirements to be implemented in that build have been met.
5.9.1
lndeDendence in CSCI aualific ation test ing. The person(s) responsible for qualification
testing of a given CSCI shall not be the persons who performed detailed design or
implementation of that CSCI. This does not preclude persons who performed detailed design
or implementation of the CSCI from contributing to the process, for example, by contributing
test cases that rely on knowledge of the CSCIS internal implementation.
Testina on the taraet co m Dute r svst em. CSCI qualification testing shall include testing
5.9.2
on the target computer system or an alternative system approved by the acquirer.
PreDarina for CSC la ualificat ion te sting. The developer shall define and record the test
5.9,3
preparations, test cases, and test procedures to be used for CSCI qualification testing and the
traceability between the test cases and the CSCI requirements.
The result shall include all
applicable items in the Software Test Description (STD) DID (see 6.2). The developer shall
prepare the test data needed to carry out the test cases and provide the acquirer advance
notice of the time and location of CSCI qualification testing,

17
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
pry run of CSC I aua Iificat ion test ing. If CSCI qualification testing is to be witnessed
5.9.4
by the acquirer, the developer shall dry run the CSCI test cases and procedures to ensure that
they are complete and accurate and that the software is ready for witnessed testing. The
developer shall record the results of this activity in appropriate software development files
(SDFS) and shall update the CSCI test cases and procedures as appropriate.
5.9.5
Performin~ CS Cl aua Iificat ion test ing. The developer shall perform CSCI qualification
testing of each CSCI. The testing shall be in accordance with the CSCI test cases and
procedures.
5.9.6
Revision and retest inq. The developer shall make necessary revisions to the software,
provide the acquirer advance notice of retesting, conduct all necessary retesting, and update
the software development files (SDFS) and other software products as neededt based on the
results of CSCI qualification testing.
5.9.7
Analvzina and reco rdina CSC I aua Iificat ion test re suIts. The developer shall analyze
and record the results of CSCI qualification testing. The results shall include all applicable
items in the Software Test Report (STR) DID (see 6.2).
5.10
Csc l/HWCl intea ration and test inq, The developer shall participate in CSC1/HWCl
integration and testing activities in accordance with the following requirements.
Note 1: CSCi/HWCl integration and testing means integrating CSCIS with interfacing
HWCIS and CSCIS, testing the resulting groupings to determine whether they work
together as intended, and continuing this process until all CSCIS and HWCIS in the system
The last stage of this testing is developer-internal
system
are integrated and tested.
testing.
Note 2: If a system or CSCI is developed in multiple builds, CSC1/HWCl integration and
testing may not be complete until the final build. CSC1/HWCl integration and testing in
each build should be interpreted to mean integrating the current build of each CSCI with
the current build of other CSCIS and HWCIS and testing the results to ensure that the
system requirements to be implemented in that build have been met.
5.10.1
Pref)a rinrz for CSC l/HWCl integration and test inq. The developer shall participate in
developing and recording test cases (in terms of inputs, expected results, and evaluation
criteria), test procedures, and test data for conducting CSC1/HWCl integration and testing.
The test cases shall cover all aspects of the system-wide and system architectural design.
The developer shall record software-related
information in appropriate software development
files (SDFS).
5.10.2
Fe rformina Csc l/HWCl intea ration and test in~, The developer shall participate in
CSC1/HWCl integration and testing, The testing shall be in accordance with the CSC1/HWCl
integration test cases and procedures.
The developer shall make necessary revisions to the
5.10.3
Revision and retest ing.
software,
participate in all necessary retesting, and update the appropriate software
development files (SDFS) and other software products as needed, based on the results of
CSC1/HWCi integration and testing.

18

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.10,4
AnalvzinQandreco rdirm CS C1/FfWCl intea ration and tea resu 1~. The developer shall
participate in analyzing the results of CSC1/HWCl integration and testing. Software-related
analysis and test results shall be recorded in appropriate software development files (SDFS).
5.11
WSte m aua Iificat ion te sting. The developer shall participate
testing in accordance with the following requirements.

in system qualification

Note 1: System qualification testing is performed to demonstrate to the acquirer that


It covers the system requirements
in the
system requirements
have been met.
system/subsystem
specifications
(SSSs) and in associated interface requirements
system testing,
specifications
(I RSS). This testing contrasts with developer-internal
performed as the final stage of CSC1/HWCl integration and testing.
Note 2: If a system is developed in multiple builds, qualification testing of the completed
system will not occur until the final build, System qualification testing in each build should
be interpreted to mean planning and performing tests of the current build of the system
to ensure that the system requirements to be implemented in that build have been met.
5.11.1
jnderrendence in svstem aualific ation tes tinq. The person(s) responsible for fulfilling
the requirements in this section shall not be the persons who performed detailed design or
implementation of software in the system, This does not preclude persons who performed
detailed design or implementation of software in the system from contributing to the process,
for example, by contributing test cases that rely on knowledge of the systems internal
implementation.
5.11.2
Testina on the target co mtmter svst em. The developers system qualification testing
shall include testing on the target computer system or an alternative system approved by the
acquirer.
5.11.3
PreDa rin~ for svst em aua Iificat ion test inq. The developer shall participate in developing and recording the test preparations, test cases, and test procedures to be used for
system qualification testing and the traceability between the test cases and the system
requirements.
For software systems, the results shall include all applicable items in the
Software Test Description (STD) DID (see 6.2). The developer shall participate in preparing
the test data needed to carry out the test cases and in providing the acquirer advance notice
of the time and location of system qualification testing.
Prv run of svste m aua Iific ation test ing. If system qualification testing is to be
5.11.4
witnessed by the acquirer, the developer shall participate in dry running the system test cases
and procedures to ensure that they are complete and accurate and that the system is ready
for witnessed testing. The developer shall record the software-related results of this activity
in appropriate software development files (SDFS) and shall participate in updating the system
test cases and procedures as appropriate.
5.11.5
Performing svst em aua Iific ation test inq. The developer shall participate in system
qualification testing. This participation shall be in accordance with the system test cases and
procedures.
5.11.6
Revision and retest inq.
The developer shall make necessary revisions to the
software, provide the acquirer advance notice of retesting, participate in all necessary
retesting, and update the software development files (SDFS) and other software products as
needed, based on the results of system qualification testing.
19
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
5.11.7
Analvzina and reco rdin~ syste m aua Iificat ion test resu Its. The developer shall participate in analyzing and recording the results of system qualification testing. For software
systems, the result shall include all applicable items in the Software Test Report (STf?) DID
(see 6.2).
5.12
PreDarina for software use. The developer
dance with the following requirements.

shall prepare for software

use in accor-

Note: If software is developed in multiple builds, the developers planning should identify
what software, if any, is to be fielded to users in each build and the extent of fielding (for
example, full fielding or fielding to selected evaluators only). Preparing for software use
in each build should be interpreted to include those activities necessary to carry out the
fielding plans for that build.
5.12.1
Pre Darina the executa ble so ftware. The developer shall prepare the executable software for each user site, including any batch files, command files, data files, or other software
files needed to install and operate the software on its target computer(s).
The result shall
include all applicable items in the executable software section of the Software Product
Specification (SPS) DID (see 6.2).
Note: To order only the executable software (delaying delivery of source files and
associated support information to a later build), the acquirer can use the SPS DID, tailoring
out all but the executable software section of that DID.
5.12.2
PreDa rin~ version desc riDtions for user siteq. The developer shall identify and record
the exact version of software prepared for each user site. The information shall include all
applicable items in the Software Version Description (SVD) DID (see 6.2).
5.12.3
PreDarirm use r manua Is.
with the following requirements.

The developer shall prepare user manuals in accordance

Note: Few, if any, systems will need all of the manuals in this section. The intent is for
the acquirer, with input from the developer, to determine which manuals are appropriate
for a given system and to require the development of only those manuals. All 010s permit
substitution of commercial or other manuals that contain the required information.
The
manuals in this section are normally developed in parallel with software development,
ready for use in CSCI testing.
Software use r manual$. The developer shall identify and record information needed
5,12.3.1
by hands-on users of the software (persons who will both operate the software and make use
of its results). The information shall include all applicable items in the Software User Manual
(SUM) DID (see 6.2).
5.12.3.2
so ftware inc)ut/outt)ut manuals. The developer shall identify and record information
needed by persons who will submit inputs to, and receive outputs from, the software, relying
on others to operate the software in a computer center or other centralized or networked
software installation.
The information shall include all applicable items in the Software
input/Output Manual (SIOM) DID (see 6.2).

20

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.12.3.3
SQftware center ooerato r manuals. The developer shall identify and record information needed by persons who will operate the software in a computer center or other
The
centralized or networked software installation, so that it can be used by others.
information shall include all applicable items in the Software Center Operator Manual (SCOM)
DID (see 6.2).
5.12.3.4
ComDuter ODeration manua 1s. The developer shall identify and record information
needed to operate the computers on which the software will run. The information shall
include all applicable items in the Computer Operation Manual (COM) DID (see 6.2).
5.12.4

Insta IIation at use r sites.

The developer shall:

a.

Install and check


contract.

out the executable

b.

Provide training to users as specified in the contract.

c.

Provide other assistance

to user

sites

software

as specified

at the user sites specified

in the

in the

contract.

5.13
PreDarincr for so ftware transition. The developer shall prepare for software
in accordance with the following requirements.

transition

Note: If software is developed in multiple builds, the developers planning should identify
what software, if any, is to be transitioned to the support agency in each build. Preparing
for software transition in each build should be interpreted to include those activities
necessary to carry out the transition plans for that build.
5.13.1
PreDarina the executable software. The developer shall prepare the executable software to be transitioned to the support site, including any batch files, command files, data
files, or other software files needed to install and operate the software on its target
computer(s). The result shall include all applicable items in the executable software section
of the Software Product Specification (SPS) DID (see 6.2).
5.13.2
Preo arinas ource files. The developer shall prepare the source files to be transitioned
to the support site, including any batch files, command files, data files, or other files needed
The result shall include all applicable items in the
to regenerate the executable software.
source file section of the Software Product Specification (SPS) DID (see 6.2).
5.13.3
Prer)arina version desc ricMions for the SUDDOt
r s it~. The developer shall identify and
record the exact version of software prepared for the support site. The information shall
include all applicable items in the Software Version Description (SVD) DID (see 6.2).
5.13.4
PreDarina the as builtW CSC I des ian and related information.
The developer shall
update the design description of each CSCI to match the as built software and shall define
and record: the methods to be used to verify copies of the software, the measured computer
hardware resource utilization for the CSCI, other information needed to support the software,
and traceability between the CSCIS source files and software units and between the
computer hardware resource utilization measurements and the CSCI requirements concerning
them. The result shall include all applicable items in the qualification, software support, and
traceability sections of the Software Product Specification (95)
DID (see 6.2).

21
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
Note:
In hardware development, the final product is an approved design from which
hardware items can be manufactured.
This design is presented in the product
specification. In software development, by contrast, the final product IS the software, not
its design, and manufacturing consists of electronically duplicating the software, not
recreating it from the design. The as built design is included in the software product
specification not as the product but as information that may help the support agency
understand the software in order to modify, enhance, and otherwise support it.
5.13.5
Qvdat ina the svste m des ian desc ri~tion. The developer shall participate in updating
the system design description to match the as built system. The result shall include all
applicable items in the System/Subsystem
Design Description (SS00) DID (see 6.2).
5.13.6
j%eDa rina suDDort manua 1$ The developer shall prepare support manuals in accordance with the following requirements.
Note: Not all systems will need the manuals in this section. The intent is for the acquirer,
with input from the developer, to determine which manuals are appropriate for a given
system and to require the development of only those manuals. All DIDs permit substitution
of commercial or other manuals that contain the required information. The manuals in this
section supplement the system/subsystem
design description (SSDD) and the software
product specifications (SPSS), which serve as the primary sources of information for
software support. The user manuals cited in 5.12.3 are also useful to support personnel.
5.13.6.1
Commter moarammina manuals. The developer shall identify and record information needed to program the computers on which the software was developed or on which
it will run. The information shall include all applicable items in the Computer Programming
Manual (CPM) DID (see 6.2).
5.13.6.2
Firmware SUDDort manua IS. The developer shall identify and record information
needad to program and reprogram any firmware devices in which the software will be
installed. The information shall include all applicable items in the Firmware Support Manual
(FSM) DID (see 6.2).
5.13.7

r sit~. The developer shall:


Transition to the des ianated SUDDOt

a.

Install and check out the deliverable software


in the contract.

in the support environment

b.

Demonstrate
to the acquirer that the deliverable software
can be regenerated
(compiled/linked/loaded
into an executable product) and maintained using commercially
available, acquirer-owned,
or contractually
deliverable software
and hardware
designated in the contract or approved by the acquirer.

c.

Provide training to the support agency as specified in the contract.

d.

Provide other assistance to the support agency as specified in the contract.

22

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

designated

MIL-STD-498
The developer shall perform software
5414
so ftware configuration management.
uration management in accordance with the following requirements.

config-

Note: If a system or CSCI is developed in multiple builds, the software products of each
build may be refinements of, or additions to, software products of previous builds.
Software configuration management in each build should be understood to take place in
the context of the software products and controls in place at the start of the build.
5.14.1
so nfiau ration ide ntific ation. The developer shall participate in selecting CSCIS, as
performed under system architectural design in 5.4.2, shall identify the entities to be placed
under configuration control, and shall assign a project-unique identifier to each CSCI and each
additional entity to be placed under configuration control. These entities shall include the
software products to be developed or used under the contract and the elements of the
software development environment. The identification scheme shall be at the level at which
entities will actually be controlled, for example, computer files, electronic media, documents,
software units, configuration items. The identification scheme shall include the version/
revision/release status of each entity.
The developer shall establish and implement procedures
5.14.2
so nfiau ration co ntrol.
designating the levels of control each identified entity must pass through (for example, author
control, project-level control, acquirer control); the persons or groups with authority to
authorize changes and to make changes at each level (for example, the programmer/analyst,
the software lead, the project manager, the acquirer): and the steps to be followed to request
authorization for changes, process change requests, track changes, distribute changes, and
maintain past versions. Changes that affect an entity already under acquirer control shall be
proposed to the acquirer in accordance with contractually established forms and procedures,
if any.
Note:
A number of requirements in this standard refer to project-level
or higher
If
project-level
is
not
a
level
of
control
selected
for
the
project,
configuration control.
the software development plan should state how these requirements map to the selected
levels.
5,14.3
0 nfiauration status acc ountinq. The developer shall prepare and maintain records
of the configuration status of all entities that have been placed under project-level or higher
They
configuration control. These records shall be maintained for the life of the contract.
shall include, as applicable, the current version/revision/release
of each entity, a record of
changes to the entity since being placed under project-level or higher configuration control,
and the status of problem/change reports affecting the entity.
5.14.4
configuration audi~. The developer shall support acquirer-conducted
audits as specified in the contract.
Note:
These configuration audits may be called Functional
Physical Configuration Audits.

Configuration

configuration

Audits

and

5.14.5
Packaaina. storaoe, handlina. and delivery.
The developer shall establish and
implement procedures for the packaging, storage, handling, and delivery of deliverable
software products. The developer shall maintain master copies of delivered software products
for the duration of the contract.

23

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
~oftware m-t
evaluat ion. The developer shall perform software product evaluation
5.15
in accordance with the following requirements.
Note: If a system or CSCI is developed in multiple builds, the software products of each
build should be evaluated in the context of the objectives established for that build. A
software product that meets those objectives can be considered satisfactory even though
it is missing information designated for development in later builds.
5.15.1
In-orocess a nd final software Droduct evaluat ions. The developer shall perform inprocess evaluations of the software products generated in carrying out the requirements of
this standard. In addition, the developer shall perform a final evaluation of each deliverable
software product before its delivery. The software products to be evaluated, criteria to be
used, and definitions for those criteria are given in Appendix D.
software
moduct evaluat ion record~. The developer shall prepare and maintain
5.15.2
records of each software product evaluation. These records shall be maintained for the life
of the contract.
Problems in software products under project-level or higher configuration
control shall be handled as described in 5.17 (Corrective action).
5.15.3
lndeDendence in software Droduct evaluat ion. The persons responsible for evaluating
a software product shall not be the persons who developed the product.
This does not
preclude the persons who developed the software product from taking part in the evaluation
(for example, as participants in a walk-through of the product).
5.16
so ftware oualitv assu ranc~. The developer shall perform software
in accordance with the following requirements.

quality assurance

Note: If a system or CSCI is developed in multiple builds, the activities and software
products of each build should be evaluated in the context of the objectives established for
that build. An activity or software product that meets those objectives can be considered
satisfactory even though it is missing aspects designated for later builds. Planning for
software quality assurance is included in software development planning (see 5.1.1).
software
oualitv assu rance evaluat ion~. The developer shall conduct on-going
5.16.1
evaluations of software development activities and the resulting software products to:
a.

Assure that each activity required by the contract or described in the software
development plan is being performed in accordance with the contract and with the
software development plan.

b.

Assure that each software product required by this standard or by other contract
provisions exists and has undergone software product evaluations, testing, and
corrective action as required by this standard and by other contract provisions.

software
a ualitv assu rance records.
5.16.2
The developer shall prepare and maintain
records of each software quality assurance activity. These records shall be maintained for the
life of the contract. Problems in software products under project-level or higher configuration
control and problems in activities required by the contract or described in the software
development plan shall be handled as described in 5.17 (Corrective action].

24

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.16.3
@endence
insoftware aualitvassu rancQ. The persons responsible for conducting
software quality assurance evaluations shall not be the persons who developed the software
product, performed the activity, or are responsible for the software product or activity. This
does not preclude such persons from taking part in these evaluations.
The persons
responsible for assuring compliance with the contract shall have the resources, responsibility,
authority, and organizational
freedom to permit objective software
quality assurance
evaluations and to initiate and verify corrective actions.
5.17
Corrective action. The developer shall perform corrective action in accordance
the following requirements.

with

The developer shall prepare a problem/change report to


5.17.1
Problem/chanae reDor~.
describe each problem detected
in software
products under project-level
or higher
configuration control and each problem in activities required by the contract or described in
the software development plan. The problem/change report shall describe the problem, the
corrective action needed, and the actions taken to date. These reports shall serve as input
to the corrective action system.
5.17.2
Correct ive action svs~ m, The developer shall implement a corrective action system
for handling each problem detected in software products under project-level or higher
configuration control and each problem in activities required by the contract or described in
the software development plan. The system shall meet the following requirements:
a.

Inputs to the system shall consist of problem/change

reports.

b.

The system shall be closed-loop, ensuring that all detected problems are promptly
reported and entered into the system, action is initiated on them, resolution is
achieved, status is tracked, and records of the problems are maintained for the life of
the contract.

c.

Each problem shall be classified by category and priority, using


priorities in Appendix C or approved alternatives.

d.

Analysis shall be performed to detect trends in the problems reported.

e.

Corrective actions shall be evaluated to determine whether problems have been


resolved, adverse trends have been reversed, and changes have been correctly
implemented without introducing additional problems.

the categories

and

5,18
JO int tec hnical and manaae ment reviewS. The developer shall plan and take part in
joint (acquirer/developer) technical and management reviews in accordance with the following
requirements.
Note: If a system or CSCI is developed in multiple builds, the types of joint reviews held
and the criteria applied will depend on the objectives of each build. Software products that
meet those objectives can be considered satisfactory even though they are missing
information designated for development in later builds,

25

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
The developer shall plan and take part in joint
5.18.1
do int tec hnical review~.
reviews at locations and dates proposed by the developer and approved by the
These reviews shall be attended by persons with technical knowledge of the
products to be reviewed. The reviews shall focus on in-process and final software
rather than materials generated especially for the review.
The reviews shall
following objectives:

technical
acquirer.
software
products,
have the

a.

Review evolving software products, using as criteria the software product evaluation
criteria in Appendix D; review and demonstrate proposed technical solutions; provide
insight and obtain feedback on the technical effort; surface and resolve technical
issues.

b.

Review project status; surface near- and long-term risks regarding technical, cost, and
schedule issues.

c.

Arrive at agreed-upon
those present.

d.

Identify risks and issues to be raised at joint management

e.

Ensure on-going communication

mitigation strategies for identified risks, within the authority of

reviews.

between acquirer and developer technical personnel.

The developer shall plan and take part in joint


5.18.2
Jo int manaae ment reviews.
management reviews at locations and dates proposed by the developer and approved by the
acquirer.
These reviews shall be attended by persons with authority to make cost and
schedule decisions and shall have the following objectives.
Examples of such reviews are
identified in Appendix E.
a.

Keep management informed about project status, directions being taken,


agreements reached, and overall status of evolving software products.

b.

Resolve issues that could not be resolved at joint technical reviews.

c.

Arrive at agreed-upon mitigation strategies for near- and long-term risks that could not
be resolved at joint technical reviews.

d.

identify and resolve management-level


reviews.

e.

Obtain commitments
project.

5.19

Qther act ivities.

technical

issues and risks not raised at joint technical

and acquirer approvals needed for timely accomplishment

of the

The developer shall perform the following activities.

5.19.1
Risk management.
The developer shall perform risk management throughout the
software development process. The developer shall identify, analyze, and prioritize the areas
of the software development project that involve potential technical, cost, or schedule risks;
develop strategies for managing those risks; record the risks and strategies in the software
development plan; and implement the strategies in accordance with the plan.

26

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
5.19.2
so ftware manaae ment indicators. The developer shall use software management
indicators to aid in managing the software development process and communicating its status
The developer shall identify and define a set of software management
to the acquirer.
indicators, including the data to be collected, the methods to be used to interpret and apply
the data, and the planned reporting mechanism. The developer shall record this information
in the software development plan and shall collect, interpret, apply, and report on those
indicators as described in the plan. Candidate indicators are given in Appendix F.
5.19.3
Secu ritv and mivacy. The developer shall meet the security and privacy requirements
specified in the contract. These requirements may affect the software development effort,
the resulting software products, or both.
5.19.4
Subco ntracto r mtmaa ement. If subcontractors are used, the developer shall include
in subcontracts all contractual requirements necessary to ensure that software products are
developed in accordance with prime contract requirements.
5.19.5
Interface with so ftware lV&V aaents.
The developer shall interface with the
software Independent Verification and Validation (lV&V) agent(s) as specified in the contract.
5.19.6
The developer shall coordinate with
coo rdination with assoc iate develot)er~.
associate developers, working groups, and interface groups as specified in the contract.
5.19.7
Immovement
of moiect mocesses.
The developer shall periodically assess the
processes used on the project to determine their suitability and effectiveness,
Based on these
assessments, the developer shall identify any necessary and beneficial improvements to the
process, shall identify these improvements to the acquirer in the form of proposed updates
to the software development plan and, if approved, shall implement the improvements on the
project.

27
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
6.
(This section contains information
helpful, but is not mandatory. )

NOTES

of a general

or explanatory

Intended use.
This standard contains requirements
6.1
documentation of software.
Its application is described in 1.2.
6.2
The following Data
~ata reau iremen~,
applicable, on the Contract Data Requirements
applied on a contract, in order to obtain the
227.405-70
exempts the requirement for a DD
Reference

Par?

nature that may be

for

the

development

Item Descriptions (DIDs) must be listed, as


List (DD Form 1423) when this standard is
data, except where DOD FAR Supplement
Form 1423.
DID Title

DID Number
DI-IPSC-81427

Software

Development

DI-IPSC-81438

Software

Test

5.1.4

DI-IPSC-81428

Software Installation Plan (SIP)

5,1.5

DI-IPSC-81429

Software Transition Plan (STrP)

5.3.2

DHPSC-81

Operational Concept Description (OCD)

5.3.3

DI-IPSC-81431

System/Subsystem Specification (SSS)

DI-IPSC-81

Interface Requirements Specification (IRS)

5.1.1
5.1.2,

5.1.3

430

434

Plan (SDP)

Plan ISTP)

5.3.3,

5.5

5.4.1,

5.4.2,

5.13.5

DI-IPSC-81432

System/Subsystem Design Description (SSDD)

5,4.1,

5.4.2,

5.6,1,

DI-IPSC-81436

Interface

Design

5,6.2,

5.6.3
DI-IPSC-81

Software

Requirements

5.5

433

Description

IIDD)

Specification

5.6.1,

5.6.2,

5.6.3

DI-IPSC-81435

Software

Design

Description

(SDD)

5.4.1,

5.6.1,

5.6,3

DI-IPSC-81437

Database

Design

Description

(DBDD)

5.9.3,

5.11.3

DI-IPSC-81

Software

Test

Description

5.9.7,

5.11.7

DI-IPSC-81440

Software

Test

Report

5.12.1,5.13.1,5.13.2,
5.13.4

DI-IPSC-81441

Software

Product

Specification

5.12.2,

DI-IPSC-81

442

Software

Version

Description

5.12.3.1

DI-IPSC-81

443

Software

User Manual

(SUM)

5.12.3.2

DI-IPSC-81445

Software

Input/Output

Manual

5.12.3.3

DI-IPSC-81

444

Software

Center

5.12.3.4

DI-IPSC-81

446

Computer

Operation

5.13.6.1

DI-IPSC-81447

Computer

Programming

5.13.6.2

DI-IPSC-81448

Firmware

5.13.3

439

and

Suppofl

{STD)

(STR)

Operator

(SPS)

(SVD)

(SCOM)

(COM)

Manual

Manual

(SIOM)

Manual

Manual

The above DIDs were those cleared as of the date of this standard.

(SRS)

(CPM)

(FSM)

The current issue of DOD

5010.12,
Acquisition Management Systems and Data Requirements Control List (AMSDL),
must be researched to ensure that only current, cleared DIDs are cited on the Form 1423.

28

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
6.3
Relationship) between standard and CDRL. [f the CDRL calls for a DID different from
the one named in corresponding paragraph(s) of this standard, all references to the DID in the
standard should be interpreted to mean the one in the CDRL.
Jleliverv of tool content~.
6.4
Depending on contract provisions, the developer may be
permitted to satisfy CDRL requirements by delivering: 1) a repository or database containing
the information specified in the cited DID; 2) a means of accessing that repository or
database, such as a CASE tool, if not already available to the recipients designated on the
CDRL; and 3) a hard-copy or electronically stored table of contents, specifying how and where
to access the information required in each paragraph of the DID.
6.5
Tailorirw auidance. This standard and its Data Item Descriptions (DIDs) are applied at
the discretion of the acquirer. In each application, the standard and DIDs should be tailored
to the specific
Care

should

requirements
be taken

of a particular

to eliminate

tasks

program,
that

add

program

unnecessary

phase,
costs

or contractual
and

data

that

structure.
do not add

deletion of
activities, alteration of activities to more explicitly reflect the application to a particular effort,
or addition of activities to satisfy program requirements.
This tailoring is specified in the
Statement of Work. Tailoring for the DIDs consists of deleting requirements for unneeded
information and making other changes, such as combining two documents under one cover,
that do not increase the required workload. DID tailoring for deliverables is specified in Block
16 of the CDRL.
value

to the

process

or the

product.

Tailoring

for the

standard

takes

the

form

of

6.6
Costls chedule reoo rting. Developer cost/schedule reports should be prepared at the
CSCI level. The cost reports should indicate budgeted versus actual expenditures and should
conform to the Work Breakdown Structure (WBS) applicable to the development effort. These
reports should also indicate to the acquirer planned, actual, and predicted progress.
6.7
Related sta n da rdization docu ment~.
Figure 2 identifies a set of standardization
documents related to software development. These and other standardization documents may
be imposed or quoted in the Statement of Work to supplement the requirements in MIL-STD498.
MI L-STD-498 does not invoke these documents.
The acquirer should use caution to
ensure that supplemental standards are appropriate to the project and that any conflicts
among these standards or with MIL-STD-498
are identified and resolved.
6.8
~ublect

term (key word) listing. The following list of key words may be used to catalog
or characterize key topics in this standard.
Software
Software
Software
Software
Software
Software
Software
Software
Software
Software
Tailoring

Builds/incremental development
Computer software configuration item .
Database
Joint technical/management reviews
Operational concept
Reusable software
Risk management
Securitylprivacy
Software

Software configuration management


Software development

documentation
implementation
management indicators
product evaluation
quality assurance
requirements analysis
safety
support
testing
unit

29
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MI L-STD-498

Related Standardization Documents


(Determine latest version before use}

Topic and
MIL-STD-498
Paragraph

MlL-STD-l 801, User ComputerInterlace


MIL-HDEK-761, Human Engineering Guldelmes for Management

Sehavloral design

[5.4.1, 5.6.1)

Iniormatlon

Systems
lmputer
.2.4.2)

DOD-5200.28

securW

mfiguration
.14)

management

STD, DoD Trusted Computer System Evaluation Crlterla

ANS1/lEEE Std 828, Standard for Software


Management Plans

Conflguratlon

ANSMEEE Std 1042, Guide to Software Configuration Management


MIL-STD-973,
Configuration Management
MIL-HDBK-61
Guidelines for Configuration Management
ontinuous acquisition and
e-cycle support (CAM)

MlL-STD-l 840, Automated Interchange of Technical Information


MIL-STD- 1556, Government-lndustfY
Data Exchange Program
MIL-HDBK-59, Continuous Acquisition and Life-Cycle Support Program
Implementation Guide
MIL-HDBK-800,
Documentation Streamlining
MIL-D-28000,
Digital Representation for Communication of Product Data:
IGES Application Subset and IGES Application Protocols
MIL-M-28001,
Markup Requirements and Generic Style Specification for
Electronic Printed Output and Exchange of Text
MIL-R-28002,
Requirements for Raster Graphics Representation in Binary
Format
MIL-D-2 8003, Digital Representation
CGM Application Profile

for Communication

of Illustration Data:

Ioint technical and


management rewews
5.18, APP. E)

ANSMEEE Std 1028, Standard for Sottware Reviews and Audits


MIL-STD-499,
Engineering Management
MlL-STD-l 521, Technical Reviews and Audits for Systems, Equipments,
(audit porlion superseded by MIL-STD-973)
and Computer Software

%ogramming languages
5.7.1)

FIPS-PUB-1 19, Ada (Also issued as ANS1/lSO/lEC 8652;


formerly ANWMIL-STD-18
15, Ada Programming LanguafJe)

3oftware

ANSMEEE Std 1016,


Descriptions

5.4,

design

5.6)

Recommended

Practice for Software

Design

IEEE Std 1016,1, Guide for Software Design Descriptions


lEEE/ANSl Std 990, Recommended Practice for Ada as a Program
Design Language
Software development
environment
(5.2)

IEEE Std 1209, Recommended Practice for the Evaluation and


Selection of CASE Tools
DOD-STD-1 467 (AR), Software Support Environment
MIL-HDBK-782
(AR), Software Support Environment Acquisition

Software development
planning (5.1 .1)

AN S1/lEEE Std 1058.1,


Plans

Standard for Software

Software development
process
(4.1, APP. G)

lSO/lEC 12207 (when issued), Software Life-Cycle Processes


ANS1/lEEE Std 1074, Standard for Developing Software Life
Cycle Processes
MIL-STD- 1803 (USAF), Software Development
Guidebook on MIL-STD-498
(when issued)
MIL.HDBK-498
(when issued)

Note:

MIL-STD-498

Project Management

Integrity Program

does not revoke any of these documents

FIGURE 2. Related standardization

documents.

30
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
4

Related Standardization Documents


(Determme latest version before use)

TopIc and
MIL-STD-498
Paragraph
Software management
indicators
(5,19.2,
APP. F)

tSO/lEC 9126, (luahty Characteristics and Guldehnes for Their Use


At+JS1/lEEEStd 982.2, Guide: Use of Standard Measures to Produce
Reliable Software
IEEE Std 1045, Standard for Software Productnrity Metrics
IEEE Std 1061, Standard for Software C)uahty Metrics Methodolotry

Software problem
categories/priorities
(Append!x C)

IEEE Std 1044,

Software product
evaluation (5. 15)

ANS1/lEEE Std 1012, Standard for Software Verification


and Validation Plans
IEEE Std 1059, Guide for Verification and Validation Pfans

Software quality
assurance
[5. 16)

ISO 9001, Cluality System - Model for Quality Assurance in


Design/Development,
Production, Installation, and Servicing
ISO 9000-3, Guidelines for the Application of ISO 9001 to the Development,
Supply, and Maintenance of Software
ANS1/lEEE Std 730, Standard for Software Quality Assurance Plans
IEEE Std 1298/A3563.
1, Software Quality Management System
DOD-STD-2 168, Defense System Software Quality Program
MIL-HDBK-286,
A Guide for DOD-STD-2 168

Software requirements
[5.3.3, 5.51

ANS1/fEEE Std 830, Recommended Practice for Software


Requirements Specifications
MIL-STD-490,
Specification Practices

Software

MIL-STD-882,
System Safety Program Requirements
MIL-HD6K-272,
Safety Design and Evaluation Criteria for Nuclear Weapons
Systems
IEEE Std 1228, Standard for Software Safety Plans

safety (4.2.4. 1 )

Standard Classification

for Software

Anomalies

Software support
all paragraphs)

IEEE Std 1219,


MIL-HDBK-347,

Standard for Software Maintenance


Mission-Critical Computer Resources Software

software testing
5.1.2,
5.1.3,
5.7-5.11)

ANSMEEE Std 829, Standard for Software Test Documentation


ANSMEEE Std 1008, Standard for Software Unit Testing
AN SUIEEE Std 1012, Standard for Software Verification
and Validation Plans
IEEE Std 1059, Guide for Verification and Validation Plans

Software user
~ocumentation

AN SMEEE Std 1063,

Standard for Software

MIL-STD-499,
Engineering Management
MIL-HDBK-805,
Microcomputer Software

railoring
1.2.3, 6.5,
4PP. G, H

DOD-HDBK-248,
Guide for Application
Defense Materiel Acquisitions
MIL-HDBK-498
{when issued)

Training (5,12.4,

5.13.71

MIL-STD- 1379,

#Vork breakdown
!6.6)

structure

MIL-STD-881,

MIL-STD-498

User Documentation

(5.12.3)

systems engineering
5.1.3, 5.3, 5.4, 5.10,
5.11)

Note:

Suppofl

and Hardware

Guidelines

and Tailoring of Requwements

Military Training Programs


Work Breakdown

Structures for Defense Materiel

does not invoke any of these documents.

FIGURE 2.

Related sta nda rdization documents

- continued.

31
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

hems

for

MIL-STD-49B
APPENDIX A
LIST OF ACRONYMS
A. 1
-.
This appendix provides a list of acronyms used in this standard, with their
associated meanings. This appendix is not a mandatory part of the standard. The information
provided is intended for guidance only.
doc uments.

A.2

Amlicable

A.3

Acronvm~.
CASE
CDRL
COM
CPM
Cscl
DBDD
DID
DoD
FSM

I-fwcl
IDD
IRS
Iv&v
OCD
SCOM
SDD
SDF
SD!SDP
SIOM
SIP
sow
SPS
SRS
SSDD
Sss
STD
STP
STR
STrP
SUM
SVD
Sw
WBS

This section is not applicable to this appendix.

Computer-Aided Software Engineering


Contract Data Requirements List
Computer Operation Manual
Computer Programming Manual
Computer Software Configuration Item
Database Design Description
Data Item Description
Department of Defense
Firmware Support Manual
Hardware Configuration Item
Interface Design Description
Interface Requirements Specification
Independent Verification and Validation
Operational Concept Description
Software Center Operator Manual
Software Design Description
Software Development File
Software Development Library
Software Development Plan
Software input/Output Manual
Software Installation Plan
Statement of Work
Software Product Specification
Software Requirements Specification
System/Subsystem
Design Description
System/Subsystem
Specification
Software Test Description
Software Test Plan
Software Test Report
Software Transition Plan
Software User Manual
Software Version Description
Software
Work Breakdown Structure

32
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
APPENDIX B
INTERPRETING MIL-STD-498

FOR INCORPORATION

OF REUSABLE SOFTWARE

PRODUCTS

B.1
of
5CODQ. This appendix interprets MIL-STD-498
when applied to the incorporation
reusable software products. This appendix is a mandatory part of this standard, subject to
tailoring by the acquirer.
B.2

Armiicabie docu ment~.

This section is not applicable to this appendix.

B.3
~valuat ina reusab Ie so ftware moduct$.
The developer shall specify in the software
development plan the criteria to be used for evaluating reusable software products for use in
fulfilling the requirements of the contract.
General criteria shall be the software products
ability to meet specified requirements and to be cost-effective over the life of the system.
Non-mandatory examples of specific criteria include, but are not limited to:
a.
b.
c.
d.
e.
f.

9.

h,
i.

Ability to provide required capabilities and meet required constraints


to provide
required
safety,
security,
and privacy
Reliability/maturity,
as evidenced by established track record
Testability
Interoperability with other system and system-external elements
Fielding issues, including:
1) Restrictions on copying/distributing
the software or documentation
2) License or other fees applicable to each copy
Maintainability, including:
1) Likelihood the software product will need to be changed
2) Feasibility of accomplishing that change
3) Availability and quality of documentation and source files
4) Likelihood that the current version will continue to be supported by the supplier
5) Impact on the system if the current version is not supported
6) The acquirers data rights to the software product
7) Warranties available
Short- and long-term cost impacts of using the software product
Technical, cost, and schedule risks and tradeoffs in using the software product
Ability

B.4
Inte rmetina MIL-STD-498
act ivitie s for reusable
rules apply in interpreting this standard:

so ftware

Droduct$.

The

following

a.

Any requirement that calls for development of a software product may be met by a
reusable software
product that fulfills the requirement and meets the criteria
established in the software development plan. The reusable software product may be
used as-is or modified and may be used to satisfy part or all of the requirement.
For
example, a requirement may be met by using an existing plan, specification, or design.

b.

When the reusable software product to be incorporated is the software itself, some
of the requirements in this standard require special interpretation.
Figure 3 provides
this interpretation.
Key issues are whether the software will be modified, whether
unmodified software constitutes an entire CSCI or only one or more software units,
and whether unmodified software has a positive performance record (no firm criteria
exist for making this determination).
The figure is presented in a conditional manner:
If an activity in the left column is required for a given type of software, the figure tells
how to interpret the activity for reusable software of that type.
33
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
APPENDIX

Interpret the actnmy as follows for each type of existing, reusable software:
If this
MIL.STD-498
activity is
required:

For software umts to be used


unmodified

For CSCIS to be used unmodified

Posmve
performance
record
5.1 Project
planning and
oversight

No or poor
performance
record

Positive
performance
record

No or poor
performance
record

For software
units being
modified for/
during project

Include the activities in this figure in project plans

5.2 Establishing
software devel
enwronment

Establish and apply a software test environment, software development


libra~, and software development files as appropriate to perform the
activities in this figure

5.3 System
requirements
analysis

Consider softwares
Use test/
performance
records to
confirm ability to
meet needs

capabilities

Apply full
requirements

in defining the operational concept & system requirements

Test to confirm
abillty to meet
needs

Use testl
performance
records to
confirm ability
to meet needs

Test to
confirm ability
to meet
needs

Use tests or
records to
determine
potential to
meet needs

5.4.1 Systemwide design

Consider the softwares capabilities and characteristics


makmg other system-wide design decisions

5.4.2 System
architectural
design

Include the CSCI in the system


architecture; allocate system
requirements to it

Consider the units capabilities and characteristics


in designating CSCIS and allocating system
requirements to them

5.5 Software
requirements
analysis

Specify the project-specific


requirements the CSCI must meet;
verify via records or retest that the
CSCI can meet them

Consider the units capabilities and characteristics


in specifying the requirements for the CSCI of
which It is a part

5.6.1 CSClwide design

No requirement:
the CSC1-wide
design decisions have already been
made (recording the as built design
is under 5.13)

Consider the units capabilities and characteristics

No requirement:
the CSCIS
architecture is already defined
(recording the as built design is

Include the unit in the CSCI architecture


allocate CSCI requirements to it

5.6.2 CSCI
architectural
design

in designing system behavior and m

in designing CSCI behavior and making other


CSC1-wide design decisions

and

under 5.13)
;.6.3 CSCI
jetailed design

5.7.1 Software
mplementation

No requirement:
the CSCIS detailed
design is already defined (recording
the as built design is under 5.13)

No requirement: the unit IS


already designed {recording the

Modify the
units design

as built design is under5.131

as needed

No requirement: the software for the


CSCISunits is alreadyimplemented

No requirement: the software


for the unit is already

Modify the

implemented
5.7.2 -5.7.5
Jnit testing

No requirement:
the CSCIS unrts

Perform
selectively

are already

question and units

tested

are accessible

for

Perform this testing

No requirement:
the unit is

If In

software
the unit

alreadytested

FIGURE

3.

Interrrretina

MIL-STD-498

for

incorcroration

of reusable

34

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

so ftware.

MIL-STD-498
APPENDIX

Interpret the activity as follows for each type of existing, reusable software:
If this
MIL-STD-498
activity is
required:

For CSCIS to be used unmodlf~ed

For software units to be used


unmodified

Positive
performance
record

No or poor
performance
record

Positive
performance
record

5.8 Umt
integration and
testing

No requirement:
the CSCIS units
are already
integrated

Perform
selectively if in
question and units
are accessible

Perform except
where integration is already
testedlproven

5.9 Cscl
qualification
testing

No requirement:
CSC1 is already
tested & proven

Perform this
testing

5.10
CSC1/HWCl
integration and
testing

Perform, except
where integration is already
testedlproven

Include the CSCI


in CSC1/HWCl
integration and
testing

5.11 System
qualification
testing

No or poor
performance
record

For software
units being
modified for/
during project

Perform this testing

Include the unit in CSCI qualification testing

Include the CSCI in


system qualification testing

Include the unit in


CSC1/HWCl integration and testing

Include the unit in system qualification

testing

5.12 Preparing
for software
use

Include the software for the CSCI or unit in the executable software; include in version
descriptions; handle any license issues; cover use of the CSCI or unit, as appropriate, via
existing, new, or revised user/operator manuals; install the CSCI or unit as part of the
overall system; include its use, as appropriate, in the training offered

5.13 Preparing
for software
transition

Include the software for the CSCI or unit in the executable software; prepare source files
for the CSCI or unit, if available; include in version descriptions; handle any license issues;
prepare or provide as built design descriptions for software whose design is known;
install the CSCI or unit at the support site; demonstrate regenerability if source is available;
include in the training offered

5.14 Software
configuration
management

Apply to all software

5.15 Software
product
evaluation

Apply to all software products prepared or modified in incorporating this software; for
software products used unchanged, apply unless a positive performance record or evidence
of past evaluations indicates that such an evaluation would be duplicative

5.16 Software
quality
assurance

Apply to all activities performed and all software


incorporating this software

products prepared, modified, or used in

5.17 Corrective
action

Apply to all activities performed and all software


incorporating this software

products prepared or modified in

5.18 Joint

Cover the software

products prepared, modified, or used in incorporating this software

products prepared or modified in incorporating

this software

eviews
5.19 Other
]ctivities

FIGURE 3.

Apply the lull requirements

Intermetina

MIL-STD-498

of this section

for incorr)oration of reus able so ftware

35
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

- continue~.

MIL-STD-498
APPENDIX

CATEGORY AND PRIORITY CLASSIFICATIONS


FOR PROBLEM REPORTING
C.1
scheme

m.

This appendix

to

be

applied

to

contains requirements

each

problem

for a category

submitted

to

the

and

corrective

priority
action

classification
system.

This

to the following conditions: 1) these


requirements may be tailored by the acquirer, and 2) the developer may use alternate category
and priority schemes if approved by the acquirer.

appendix

is a mandatory

part

of the

C.2

AllDlicable docu menu.

C.3

Glass ifica tion bv cateao ry.

standard,

subject

This section is not applicable to this appendix.


The developer

shall:

a.

Assign each
Figure 4.

problem

in software

products

b.

Assign

problem

in activities

to one or more

each

to one or more

of the

of the

categories

categories

in

in Figure

(shown at the start of Section 5).


C.4

Glass ificat ion

bv

Driority.

The

developer

shall

assign

each

products or activities to one of the priorities in Figure 5.

36

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

problem

in software

MIL-STD-498
APPENDIX

Applies to problems in:

Category
a.

One of the plans developed for the project

Plans
I

b.

The operational

Concept

concept

1
c.

The system or sofiware

Requirements

requirements

d.

The design

Design

of the system

or software

e.

Code

f.

Database/data

g,

Test

I The software code


I
A database or data file

file

Test

information

plans,

test descriptions,

or test rePOftS

h.

Manuals

i.

Other

FIGURE

The user, operator,


Other

4.

software

products

ories to be used for class ifyinQ

in software

Droblems

woducts.

Applies if a problem could:

Priority
1

or support manuals

a.

Prevent the accomplishment

b.

Jeopardize

a.

Adversely affect the accomplishment of an operational


capability and no work-around solution is known

safety, security,

of an operational

or mission essential capability

or other requirement

designated

critical

or mission essential

b. Adversely affect technical, cost, or schedule risks to the project or to life


cycle support of the system, and no work-around solution is known
3

a. Adversely affect the accomplishment of an operational or mission essential


capability but a work-around
b.

Adversely affect technical, cost, or schedule risks to the project or to life


cycle suPport of the system, but a work-around solution is known

a. Result in userloperator
required operational
b.

solution is known

inconvenience or annoyance
or mission essential capability

but does not affect a

Result in inconvenience or annoyance for development or suPport personnel,


but does not prevent the accomplishment of those responsibilities

Any other effect

FIGURE 5.

<

Priorities to be used for class ifvina ~roblem$.


37

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498

SOFTWARE
D.1

-.

ThlsaPpendiX
evaluations,
identifies

APPENDIX

PRODUCT

EVALUATIONS

identifies
thesoftWare
the criteria
to be

products

that

areto

undergo

software

used for each evaluation, and contains a


default set of definitions for the evaluation criteria. This appendix is a mandatory part of the
standard, subject to the following conditions: 1) these requirements may be tailored by the
by the acquirer,
acquirer, 2) the developer may use alternate criteria or definitions if approved
of a given software product has been tailored out of the standard,
and 3) if the development
the requirement to evaluate that product does not apply.
product

D.2

Atmlicable doc umen~.

This section is not applicable to this appendix.

0.3
Reauired evaluat ions. Figure 6 identifies the software products that are to undergo
software product evaluations and states the criteria to be applied to each one. Each software
product and criterion is Iabelled for purposes of identification and tailoring. For convenience,
they may be treated as subparagraphs of this paragraph (referring to the first criterion, for
example, as D.3. 1a). The software products are expressed in lower case letters to convey
generic products, not necessarily in the form of hard-copy documents. Evaluations of systemIevel products are to be interpreted as participation in these evaluations, Some of the criteria
are subjective. Because of this, there is no requirement to prove that the criteria have been
met; the requirement
problems

is to perform

for discussion

and

the evaluations

using

these

criteria

and to identify

possible

resolution.

criteria de finitions.
D.4
The following paragraphs provide definitions for the criteria in
Figure 6 that may not be self-explanatory.
The criteria are listed in alphabetical order,
matching as closely as possible the wording used in Figure 6.
D.4. 1 Accurately desc ribes (an itemj. This criterion, applied to user/operator/programmer
instructions and to the as built design and version descriptions, means that the instructions
or descriptions are correct depictions of the software or other item described.
Test cases are adequate if they cover
D.4.2
ate test cases, D rocedu res. data, rem.
all applicable requirements or design decisions and specify the inputs to be used, the expected
results, and the criteria to be used for evaluating those results. Test procedures are adequate
if they specify the steps to be followed in carrying out each test case. Test data are adequate
if they enable the execution of the planned test cases and test procedures. Test or dry run
results are adequate if they describe the results of all test cases and show that all criteria have
been met, possibly after revision and retesting.
D.4.3 ~~ n i
roduc
. This criterion means that: (1) no statement or
representation in one software product contradicts a statement or representation in the other
software products, (2) a given term, acronym, or abbreviation means the same thing in all of
the software products, and (3) a given item or concept is referred to by the same name or
description in all of the software products.
D.4.4 0 ntains all aRplica ble information in (a s~e cified DIDI. This criterion uses the DIDs
to specify the required content of software products, regardless of whether a deliverable
document has been ordered. Allowances are to be made for the applicability of each DID
topic. The formatting specified in the DID (required paragraphing and numbering) are not
relevant to this evaluation.
38
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Evaluation Criteria
Software
Product

1,

Software
development plan

Contains

Meets

all applic.
info in:

SOW, if
applic.

a. SDP
DID

Meets
CDRL, if

Understand-

Intern.
consis-

Follows
SW dev

applic.

able

tent

plan

c.

b.

d.

e.

f.

(up-

(5.1.1)

dates]

Additional Criteria

g. Covers all activities/deliverables in SOW and CDRL


h. Consistent with other project plans
i. Presents a sound approach to the development

2.

Software test plan


(5.1.2, 5.1.3)

a. STP
DID

b.

c.

d.

e.

f.

g. Covers all software-related qualification activities


the SOW
h. Covers all requirements for the items under test
i. Consistent with other project plans
j. Presents a sound approach to the testing

3.

Software
installation
(5.1.4)

a. SIP
DID

b.

c.

d.

e.

f.

g. Covers al} user site installation activities in the SOW


h. Consistent with other project plans
i. Presents a sound approach to the installation

a. STrP
DID

b.

c.

d.

e.

f.

g. Covers all transition-related activities in the SOW


h. Consistent with other project r)lans
i. Presents a sound approach to the transition

a. OCD
DID

b.

c.

d.

e.

f.

g. Feasible

a. SSS,
IRS
DlOs

b.

c.

d.

e.

f.

g. Covers the operational concept


h. Feasible
i. Testable

a. SS00,
IDD,
DBDD
010s

b.

c.

d.

e.

f.

g. Consistent with system requirements


h. Feasible

a. SSDD,
IDD
DIDs

b.

c.

d.

e.

f.

g. Covers the system requirements


h. Consistent with the system-wide
i. Feasible

a. SRS,
IRS
010s

b,

4.

Software
plan

plan

transition

(5.1.5)
5.

Operational
(5.3.2)

6.

System
requirements
(5.3.3)

7.

System-wide
decisions
(5.4.1)

8.

System
architectural
[5.4.2)

9.

concept

design

design

CSCI requirements
(5!5)

FIGURE

c.

6.

Software

d.

tmducts

e.

f.

g. Covers system requirements


h. Feasible
i. Testable

and assoc iated e valuation criteria.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

in

design decisions

allocated to the CSCI

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Evaluation Criteria
Software
Product

Meets

Contains
all applic.
info in:

SOW. if
applic.

Meets
CDRL, if
applic.

Understandable

Intern.
consistent

Follows
SW dev
plan

Additional Criteria

19.

Software version
descriptions
(5.12.2,
5.13.3)

a. SVD
DID

t).

c.

d.

e.

f.

g. Accurately identifies the version of each software


component (file, unit, CSCI, etc. ) delivered
h. Accurately identifies the changes incorporated

20.

Software
manuals
(5.12.3.1)

a. SUM
DID

b.

c.

d.

e.

f.

g. Accurately describes software installation and use to


the intended audience of this manual

21.

Software input/
output manuals

a. SIOM
DID

b.

c.

d.

e.

f.

g. Accurately describes software input/output


intended audience of this manual

a. SCOM
DiD

b.

c.

d.

e.

f.

g. Accurately describes software installation and


operation to the intended audience of this manual

a. C(3M
010

b.

c.

d.

e.

f.

g. Accurately describes the operational characteristics


the computer

user

to the

(5.12.3.2)
22.

Software center
operator manuals
(5.12.3.3)

23.

Computer
manuals
(5.12.3.4)

operation

24.

Source files
(5.13.2)

a. SPS
DID

b.

c.

d.

e.

f.

g,
h.
i.
1.

Meets delive~ requirements


All required software is present
Version exactly matches version that passed testing
Deliverable media accurately Iabelled

25.

As built- CSCI
design and related
information

a. SPS
DID

b.

c.

d.

e.

f.

g.
h.
i.
j.
k,

Accurately describes the as built design of the CSCI


Accurately describes compilation/build procedures
Accurately describes modification procedures
Source files cover all units in the CSCI design
Measured resource utilization meets CSCI
requirements

a. SS00
DID

b.

c.

d.

e.

f.

g. Accurately describes the as built system design

of

(5.13.4)

26.

As built- system

design
(5.13.51

FIGURE

6.

Software

moducts and assoc iated evaluation criteria - c ontinued.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

MIL-STD-498
APPENDIX

D.4.5
co vers (a Qiven set of items). A software product covers a given set of items if
every item in the set has been dealt with in the software product.
For example, a plan covers
the SOW if every provision in the SOW is dealt with in the plan; a design covers a set of
requirements
if every requirement has been dealt with in the design; a test plan covers a set
of requirements
if every requirement
is the subject of one or more tests.
Covers
corresponds to the downward
traceability
(for example, from requirements
to design) in the
requirement,
design, and test planning/description
DIDs.
D.4.6
Feasible.
This criterion
means that, in the knowledge
and experience
of the
evaluator, a given concept, set of requirements,
design, test, etc. violates no known principles
or lessons learned that would render it impossible to carry out.
c)Ian. This criterion means that the software product
FOtlOWS SO ftware development
D.4.7
shows evidence of having been developed in accordance with the approach described in the
Examples include following
design and coding standards
software
development
plan.
For the software
development
plan itself, this criterion applies to
described in the plan.
updates to the initial plan.
D.4.8
Internally
consistent.
This criterion
means that:
(1) no two statements
or
representations
in a software product contradict one another, (2) a given term, acronym, or
abbreviation
means the same thing throughout
the software product, and (3) a given item or
concept is referred to by the same name or description throughout
the software product.
D.4.9
Meets CD RL,
evaluated is specified
evaluation.
It focuses
rather than on content,

if aml[icab le. This criterion applies if the software


product being
in the CDRL and has been formatted
for delivery at the time of
on the format, markings, and other provisions specified in the CDRL,
covered by other criteria.

D.4.1O
M eets SOW, if QJ?DhCable. This criterion means that the software product fulfills any
Statement of Work provisions regarding it. For example, the Statement of Work may place
constraints
on the operational concept or the design.
0.4.11
Presents a so und aDD r o sch. This criterion means that, based on the knowledge and
experience
of the evaluator,
a given plan represents
a reasonable way to carry out the
required activities.
D,4. 12 shows evidence that (an item under test) meets its reau irement~,
This criterion
means that recorded test results show that the item under test either passed all tests the first
time or was revised and retested until the tests were passed.
D,4. 13 ~table.
A requirement
or set of requirements
is considered to be testable if an
objective and feasible test can be designed to determine whether each requirement
has been
met.
D.4.14
Understandable.
This criterion means understandable
by the intended audience.
For example, software products intended for programmer-to-programmer
communication
need
not be understandable
by non-programmers.
A product that correctly identifies its audience
(based on information
in Block 3 of the corresponding
to that audience meets this criterion.

DID) and is considered

43
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

understandable

MIL-STD-498
APPENDIX
CANDIDATE

JOINT

MANAGEMENT

REVIEWS

E.1
-.
This appendix describes a candidate set of joint management
reviews
might be held during a software development
project. This appendix is not a mandatory
of this standard.
The information
provided is intended for guidance only.
E.2

ADtdicable

docu ment~.

E.3

Assu mc)tion~.

This section

This appendix

is not applicable

makes the following

that
part

to this appendix.

assumptions:

a.

The acquirer has reviewed the subject products in advance,


technical
reviews have been held to resolve issues, leaving
review as a forum to resolve open issues and reach agreement
of each product.

and one or more joint


the joint management
as to the acceptability

b.

Any of the reviews may be conducted


incrementally,
dealing at each review with
subset of the listed items or a subset of the system or CSCI(S) being reviewed.

E.4
Ca ndid ate reviewS, Given below is a set of candidate joint management
reviews that
might be held during a software development
project.
There is no intent to require these
reviews
or to preclude alternatives
or combinations
of these reviews.
The objectives
supplement
those given in 5.18.2.
E.4.1 so ftware Dkm reviews.
or more of the following:
a.
b.
c.
d.

The
The
The
The

software
software
software
software

These reviews

are held to resolve

one

development
plan
test plan
installation
plan
transition plan

erational conceM reviews. These reviews


E.4.2
the operational concept for a software system.

are held to resolve open issues regarding

E.4.3 Svste mlsubsvste m reau irements reviews.


These reviews
issues regarding the specified requirements
for a software system
E.4.4 Svste mlsubsvste m des ian reviews.
regarding one or more of the following<
a.
b.

open issues regarding

These reviews

are held to resolve


or subsystem.

are held to resolve

open

open issues

The system- or subsystem-wide


design decisions
The architectural
design of a software system or subsystem

E.4.5 so ftware requirements


reviews.
These
regarding the specified requirements
for a CSCI.

reviews

are held to resolve

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

open

issues

MIL-STD-498
APPENDIX
E.4.6 so ftware des i~n reviews.
or more of the following:
a.
b.
c.

The CSC1-wide design decisions


The architectural
design of a CSCI
The detailed design of a CSCI or portion

E.4.7 Test read iness reviews.


or more of the following:
a.
b.
c.

These reviews

These reviews

are held to resolve open issues regarding

thereof

(such as a database)

are held to resolve open issues regarding

The status of the software test environment


The test cases and test procedures to be used for CSCI qualification
qualification
testing
The status of the software to be tested

testing

These reviews are held to resolve open issues


E.4.8 Test res ults review$.
results of CSCI qualification
testing or system qualification
testing.
usab ilitv reviews.
E.4.9 software
one or more of the following:
a.
b.
c.
d.

The
The
The
The

E.4.1O
regarding
a.
b.
c.
d.
e.

readiness
user and
software
status of

are held to resolve

one

or system

regarding

the

open issues regarding

of the software for installation


at user sites
operator manuals
version descriptions
installation
preparations and activities

so ftware SUDDOtlab ilitv reviews.


one or more of the following:

The readiness
The software
The software
The software
The status of
development

E.4.11
regarding

These reviews

one

These reviews

are held to resolve

of the software for transition to the support agency


product specifications
support manuals
version descriptions
transition preparations and activities, including transition
environment,
if applicable

of the software

Critical reau irement reviews.


These reviews
are held to resolve
the handling of critical requirements,
such as those for safety, security,

45
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

open issues

open issues
and privacy.

MIL-STD-498
APPENDIX
CANDIDATE

MANAGEMENT

INDICATORS

F.1
-.
This appendix identifies a set of management
indicators that might be used
on a software development
project. This appendix is not a mandatory part of this standard.
The information
provided is intended for guidance only.
F.2

This section

ADL)!icable doc umen@.

is not applicable

to this appendix.

F.3
r.
Given below is a set of candidate management
indicators that
Ca ndidate indic~
There is no intent to impose these
might be used on a software
development
project.
indicators or to preclude others.
a.

Requirements
time.

volatility:

total number

b.

planned
Software
size:
measurement
over time,

c.

Software

staffing:

d.

Software

complexity:

e.

planned
and actual number
Software
progress:
implemented,
unit tested, and integrated over time.

of

f.

Problem/change
report status:
total number,
current reporting period, age, priority.

closed,

9.

Build release content:


build.

h.

Computer hardware resource utilization:


planned and actual use of computer hardware
resources
(such as processor
capacity,
memory capacity,
input/output
device
capacity, auxiliary storage device capacity, and communications/network
equipment
capacity) over time.

i.

Milestone

j.

Scrap/rework:
amount of resources expended to replace or revise software
after they are placed under project-level
or higher configuration
control.

k.

Effect of reuse: a breakout


software products.

and actual

planned

performance:

of requirements

number

and actual staffing

complexity

planned

planned

of units,

lines of code,

changes

over

or other

size

levels over time.

of each software

and actual

and requirement

unit.

number

number

software

of software

number

designed,

opened

in the

units released in each

and actual dates of key project

of each of the indicators

units

milestones.
products

above for reused versus

46
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

new

MIL-STD-498
APPENDIX
GUIDANCE

ON PROGRAM

STRATEGIES,

TAILORING,

AND BUILD PLANNING

three
of the program strategies used by DOD and
G. 1
w.
This appendix identifies
shows how MIL-STD-498
can be applied under each of these strategies and on a project
involving
reengineering.
This appendix is not a mandatory
part of the standard.
The
information
provided is intended for guidance only.

G.2

AL)r)licabie doc ument~.

Documents

cited in this appendix

a.

DODI 5000,2,

Acquisition

Management

b.

DODI 8120.2,
Automated
Information
Review, and Milestone Approval

Defense

are as follows:

Policies and Procedures

System

Life-Cycle

Management

Process,

G.3
Candidate Rr o aram strate aie~. DODI 8120.2 describes three basic program strategies
plus a generic strategy called other,* encompassing variations, combinations,
and alternatives
to the three.
DODI 5000.2 identifies similar strategies, called acquisition
strategies.
The
three basic strategies are summarized below and in Figure 7.
a.

Grand d esian. The grand design strategy (not named in DODI 5000.2 but treated
as one strategy)
is essentially
a once-through,
do-each-step-once
strategy.
Simplistically:
determine
user needs, define requirements,
design the system,
implement the system, test, fix, and deliver,

b.

incremental.
The incremental
strategy (called Preplanned Product Improvement
in DODI 5000.2) determines user needs and defines the system requirements,
then
performs
the rest of the development
in a sequence of builds.
The first build
incorporates
part of the planned capabilities, the next build adds more capabilities, and
so on, until the system is complete.

c.

Evolutionary.
The evolutionary
strategy
(called evolutionary
in both DOD
Instructions)
also develops a system in builds, but differs from the incremental strategy
in acknowledging
that the user need is not fully understood
and all requirements
cannot be defined up front. In this strategy, user needs and system requirements
are
partially defined up front, then are refined in each succeeding build.

Define All
Requirements First?

Multiple
Development
Cycles?

Field Interim
Software?

Grand Design

Yes

No

No

Incremental (Preplanned
Product Improvement]

Yes

Yes

Maybe

Evolutionary

No

Yes

Yes

Program Strategy

FIGURE 7. Key features

o f three DOD woaram

strateaie~.

47
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
APPENDIX
G.4
acquirer,

select ina an aD DrclD riate


but

may

strateqy.

The

program

strategy

is selected

by the

8 illustrates a
selecting an appropriate strategy.
The approach consists of listing
opportunity
items (positives) for each strategy; assigning each item
of High, Medium, or Low; and making a decision on which strategy
among the risks and opportunities.
The fill-ins shown are sample
The DECISION
entry
on the
actual analysis may use others.
strategy was selected.

be proposed

risk analysis approach for


risk items (negatives) and
level
a risk or opportunity
to use based on a trade-off
considerations
only.
An
which
bottom
line shows

D r oa ram

by prospective

or selected

developers.

Figure

G.5
Relationship) of MIL -STD-498 to o r oa ram strat *.
The program strategy usually
applies to the overall system.
The software within the system may be acquired under the
same strategy or under a different one, such as requiring that all software be finalized in the
first build of the system.
Figures 9, 10, and 11 show how MIL-STD-498
might be applied
under each of the program strategies identified in G.3. Figure 12 shows how MIL-STD-498
might be applied on a reengineering
project. All four figures are, by necessity, simplified.
For
example, they show MI L-STD-498 activities in sequence when they might actually be ongoin9,
overlapping,
or iterative;
they show each software
product as a single entity, without
depicting early drafts or updates; and they represent each software product by the name of
DID, when the actual software product is the information
called for by the
the corresponding
in the form of a hard-copy document.
DID, not necessarily
Pianning the software builds on
G.6
Plannina s oftware bu ilds and ta ilorina MI L-STD-498.
a project and tailoring MIL-STD-498
for each build maybe accomplished in several ways. The
acquirer might, for example, select an overall program strategy and tailor the standard for the
overall contract,
leaving it to the developer to lay out the software builds and propose the
tailoring for each build.
Alternatively,
the acquirer might lay out the software
builds and
specify the tailoring for each as part of the contract.
The approach selected will be projectdependent.
The paragraphs below provide guidelines for planning the builds and tailoring the
standard without attempting
to divide these activities between the acquirer and developer.
G.6. 1 Identifvirw
b uilds and their obiec tives, The first step in software build planning is to
lay out a series of one or more builds end to identify the objectives of each build. The top
In the example, the system/subsystem
part of Figure 13 illustrates
such planning.
specification
(SSS) already exists and fulfillment
of its requirements is divided into four builds,
two of which
will be prototypes
delivered to a selected set of users, and two of which will
actually be fielded.
A further objective
of Build 4 is transitioning
the software
to the
designated support agency.
An actual project would expand on these objectives.
act ivities to be De rformed in eac h build. The next step
t he MIL-STD-498
which
MI L-STD-498
activities
apply
in each
build
and
is identifying
the start of
determining
the extent
to which
they apply.
The lower part of Figure 13 shows
such planning. Listed on the left are the paragraphs of MI L-STD-498.
The worksheet entries
indicate in which builds each activity is to be performed and include any notes regarding the
For example, the figure shows that each build will
nature of each activity in each build.
include software development
planning (5. 1.1), but that the nature of that planning changes
in each build,
Some activities
will not apply at all in a given build, some will apply identically
in all builds, and some will apply differently
in different builds. Since some aspects of the
project, such as number and type of CSCIS, may not have been identified at the time the
worksheet
is being filled out, completion
of the worksheet may itself be incremental.
The
following
guidelines apply:
G.6.2 Identifvina
in build planning

48
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Grand

Design

Incremental

Risk Item
(Reasons

Risk

Risk Item

Level

against this strategy)

Evolutionary

(Reasons

against

this

strategy)

Risk

Risk hem

Risk

Level

(Reasons against this strategy)

Level

Requirements are not well


understood

Requirements are not well


understood

System too large to do all at


once

User prefers all capabilities at


first delivery

Rapid changes

Rapid changes in mission


technology are expected--may
change the requirements

l-l

in mission

technology anticipated--may
change the requirements
-

User prefers all capabilities at


first delivery

Limited staff or budget


available now
Opportunity Item
(Reasons to use this strategy)

Opp.
Level

Opportunity Item
(Reasons to use this strategy)

Opp.
Level

Opportunity Item
(Reasons to use this strategy)

Opp.
Level

User prefers all capabilities at


first delivery

Early capability is needed

Early capability is needed

User prefers to phase out old


system all at once

System breaks naturally into


increments

System breaks naturally into


increments

Funding/staffing
incremental

Funding/staffing
incremental

User feedback and monitoring


of technology changes is
needed to understand full
requirements

will be

will be

DECISION: USE THIS STRATEGY

FIGURE

8.

Samole

risk

ana Ivsis for dete rminirm

the EIDDr OD riate

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

moa ram

strateay.

Project

SOP

planning

STP

SIP/STrP

1,
CSCI 1:

Software
IIl@emew
Unit Test

Software
Design

Software
Req
Analysis

and oversight

CscI
mat
Test

Unit
I meg/
Test

Prepare
for SW
Use

STR
STD

Executable

SDD/IDD/DBOO
SRS/IRS
r,

Cscl 2:
system
m Rea
Amlysis
DCD

system
Oesign

I
ssoo/IoD

--@E 7

User/op

Cscl

Unit
Integ/
Test

Qua[
Test

Prepare

I
SDD/ 100/0S00

Transiticm

Executable
sw
Source fi(es
SVDs
SPSS
U@ated SS00s
Support msnua(s

SRS/IRS

HUCI(S)

(Not

covered

marM(

for NJ

STR
STD

SSS/IRS

Software
ln@emen/
Unit Test

Software
Design

Softuare
I Reo
Am(ysis

SW

SVK)s

by M[L-sTD-498)
I

SW devel
software

Note:

A((

nvironment,

W configuration
sumagement, W product vacuation,
SU quality
management indicators,
security/privacy,
interface
with IV6V, coordination

activities

overlapping,

and iterative

Doss ible wav

of aoo lying

may be more ongoing,

FIGURE9.

One

than the

figure

MIL-STD-498

assurance,
corrective
action,
joint
reviews,
risk mnagement,
improvement of project
processes
with associate
developers,

is able

to the

to shou.

G rand

Desian

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

rxoa ram

strateay.

W.LO

1:

Establ

ish

system md softwuw

rwirements

and insta([

software

Project

ispiementing

p[anning

a stiet

of

those

requirements

at user sites

.srx+ oversight
J

SDP (focus

on Buitd

1)

STP for

CSCI 1:

Bui{d

[1

Software
Design

Software

,1

Unit

Sof tmare
lll@efnen/
Unit Test

Test

Req

Analysis

Pertia[
SRS/lRS*

m
lntmded
conplete

nvir OImOnt, SU configuration

I W deve(

BUILD 2:

Instalt

the

conp(eted

(Not

management,

software

at user sites

Build

c1

---Eia

Cscl

Unit

Qua [
Test

lnteg/
Test

STR for

Bui(d

for

Build

Executable
SU
SVDS
User/op manua(s
Build 1

for

IJExx21

SDD/tDD/DBDD
(All activities
may be more
ongoing, overlapping,
and iterative
than the figure
is able to show)
covered

by MI L-STD-698)

valuation,

W prc&ct

ad

transition

W quaiity

the software

planning

assurance,

to the softuare

corrective

s~rt

action,

joint

t-eviws,

other

activities

agsncy

and oversight
1

for

Build

STP qdated

for

Build

r
1,

Software
Des i gn

Software
Req
Ana[ysis

Co@ete
SRS/IRS*

DCD*

1 SSDD/l DD*
SSS/IRS*

SW

ckvel

mvirormen

t,

Software
Design

I
W configuratim

FIGURE

10.

One

HuCI(S)

Doss ible

STrP

Unit
Integ/
Test

Ilui[d

-L-l

Executable
SU
SVDS
User/~
Manuals
Build 2

CSCI
Qua{
Test

STR for
STD for
Build 2

Bui(d

--EK!for

Build

SW prochxt

bYMIL-STD-698)

va[uetion,

2
+3

Executable
SW
Source files
SVDS
SPSS, qxiated
SSDDS
Sqf30rt
rnsnus[s

W ~ality

wav of aDD Ivirm MIL-STD-498to

for

Prepare
for W
Transition

SDD/lDD/DBDD

(Mot covered

msnagemant,

2; cmpleted

Prepare
for SW
Use

STR for
Build 2

Conpleta
SRS/l RS*

Updatecl only if
necessary;
not interrled
to ch.mge

Software
lllqJlemen/
Unit Test

Build

+
1

I
I

r
I

Software
Req
Ane(ysis

Software
In@emen/
Unit Test

SIP for

Unit
I ntegl 1!!!
TestI
STD for

SDD/lDD/DBDD

CSCI 2:

Analysis

Cscl 1:

I
I

Project

SDP Lpdated

STrP

t-----

STD for
Build 1

HUCI(S)

Bui Ld 1; Pret iminary

Prepare
for W
Use

I
I
STR for
STD for Build 1

Software
Inq31emen/
Unit Test

Software
Des i gn

Partial
SRS/l RS*

to be
and stable

Sof tuare
Req
Analysis

SSS/l RS*

O(X)

lnteg/ 1%

SDD/lDD/DBDD
1.

CSCI 2:.

SIP for

assurance,

corrective

t he incremental

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

action,

joint

rlroaram

reviews,

strateay.

other

activities

BUILD

1:

Estab(ish

preliminary

system/softuare

requirements

and insta(l

Project

a prototype

p(aming

implementing

a subset

of

those r~irements

at

setected

user

sites

and oversight

I
SOP (focus

Build

1)

(No STP for Build


no W(
testing)
r

CSCI 1:

SIP

1
1-

Ana(ysis
Partiai
sRS/lRS

Partial
r

system

system
Req
Analysis
DCD

CSCI

.(No

Bui(d

1)
1
cscl/HTJCl
I ntegl
Test

S10 for
Build 1)

MI(S)

(Not

Executable
W
SVDS
User/op manuals
Eui(d 1

(No Sys
Oual
Test)

(No STR for


Build 1)

for

(No STD/STR
for Buiid 1)

(No
Software
Transition)

(A~l activities
may be more
ongoing, overlapping,
and iterative
than the figure
is ab(e to shou)

Preliminary/
partial

STrP

sDD/lbD/DBDD

Partial
SRS/IRS

Partial

1; Preliminary

(No
Qua(
Test)

Unit
lnteg/
Test

Sof tnare
ln@emen/
Unit Test

Softuare
Design

Software
Req
Analysis

SSDD/IDD*
SSS/IRS*

2: .

Design

SDO/lDD/DBDD

Build

Prepare
for SW
Use

(No STR for


Build 1)

(No STD for

Req

for

(No
Olbsl
Test)

Unit
lnteg/
Test

Software
xu$Jlaslan/
Unit Test

Softuare
Design

Software

1:

coverad

by MI L-STD-@W

I
SW deve(

envirofsnent,

SW ccrtfiguration

management,

W product

evacuation,

W quatity

assurance,

corrective

acticm,

joint

reviews,

other

activities

w
m

BUILD 2:

Refine

and carp(ete

the

install

requirements;

the conpleted

Project
SOP @at&
for Build

STP for

Buitd

plaming

2
I
f

1:

Software
Design

Software
Req
Analysis

STD for

OCD*

Cscl

Systm
Design

system
Req
Analysis

2:

environnrnt,

Software
Design

transition

the

softnare

to the software

Software
l~lemenl
Unit Test

Bui(d

2; com(eted

STrP

I
w

configuration

FIGURE 11.

Mucl(s)

STR for
Build 2

Build

El

2
1

Cscl

Unit
I ntegl
Test

Qua[
Test
I
STD for
Buitd 2

(Not

management,

C)netms sible

covered

SW product

wavofam

STR for
Build 2

Executable
W
SVVS
User/oo mnuats
Build 2

--@E!
for

Build

vacuation,

for

Prepare
for SW
Transition

n
Executable
SW
Source fi(es
SVDS
SPSS, updated SSDDS
Sqport
manuals

bYMIL-STD-498)

lvina

agency

Prepare
for SW
Use

SRS/l RS*

s~rt

SODIIODIQBDO*

SS00/ lDf)*
SSS/l RS*

sw deve(

[.
Software
Rq
Ana(ysis

Refined
from Build
and conpleted

1
I

sites;

SIP for

SDD/ 1DD/DBQD
SRS/IRS*

user

Csc I
alla I
Test

Lfni t
Integ/
Test

Software
Ill@emen/
Unit Test

at

and oversight

I
1

2
Cscl

software

W ~tity

MIL-STD-498

assur~e,

to the

corrective

Evolutionary

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

actionc

joint

revi~c

rxoaramstrateav.

other

activities

~EENGINEERIHG
4

Project

[
SOP

FORWARD
ENGINEER
I NG
planning end oversight

STP

SIP/STrP
4EDDCWENTAT f-

+-TRANSLAT IW-.

CSCI 1: Trans(ate

I
SU Reqts
lAna(ysis:
redocunsnt
derived
rql ts
1
SRS/f

1,

to Ada

I
Software

Software
Inpl emen/

Waign:

Unit Test:

Csc I
Oual
Test

Unit
lnteg/
Test

1
t

STR

revise and trans[ate


software
redocment
derived des

STD

StTD/lDLI/DBDD
RS

<RED(XMTENTATIDNO 4ESTRUCTURIN%

CSC1z:

<REVERSE ENGINEERi N&


*

system
Req
Ana(ysis

I -w

Sof tuare
Des i gn

Restructure
to object-oriented

t
I
[

, Software

r,
Unit
I 1nt e9/

CSCI

Ouat
I Test t

systesi

Raq
Analysis

Design

v
Determine
req ts
for
reengnd
System

Derived
reqf ts
of (egacy
software

SSDDIIDI

~
SRS/

I RS

4EDDCWENTATIOW

v
xisting
Collect
softuare
pr~ts;
analyze
them; derive
SU dssign/reqts:
derive
systmn
design/raqts
for
a softuare
system

Dlsign
reeng$d
system
based on
findings

CSCI 3: Retarget
new conputer

Software
IwleInen/
Unit Test:
retarget
software

Sof tnare
Design:
revise
and
redocusent
derived des

W Reqts
Am(ysis:
revise and
redownent

IfJerived req~
J

I
i.
r

4ETARGETING-+

to

W deve[ environment,

W configuration

nmnagamsnt indicators

FIGURE

12.

Qnenos

interface

sibleway

Mi th

ofa

smwals

Prepare
for W
Transition

STR
STD

(A[l

activities
may be more
ongoing, over(a~ing,
ad
iterative
than the figure
is able to show)

S001lDD/DBDD

management, St/ prochct valuation,

, security/privacy,

User/op

CSCI
Qua\
Test

Unit
Integ/
Test

SRS/l RS

software

Executable W
SVDs

L
1
Executable
w
Source files
SVDS
SPSS
updated SSODS
Sq3port manua(s

t
SSSIIRS ~
Derived
design
of (egacy
software

Prepare
for SW
Use

IVW,

SWquality

coordinat

assurance, corrective

ion wi th associate

txdvinaMIL-5TD-498

toa

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

action,

developers,

reenaineerin~

joint revieus,
risk mnagensnt,
improvement of project
process

woiect.

*W.:: .

, : .,:;:,.,
.. .

~~
~~: *
I.

fdi?ntify *t *M

*@bj@%k!td,

MM

... . ..:.

& ~,:

. .,..

tiarif~ing

of .~it

w.

to selected

prototype

are.
~~~

that

meets

the following systemlevel requirements:


Sss-1 , SSS-5, . ..

noteti~$j .*iiJd&:.;.,. ,.:.::. I,..: ,<


.,........ .... ... :..........:.. ,. .,..,...:
:.:+:...:SSS-1 250
:;. . :&&@j
,,; ;:;$
.. ., ..........:,..... .... . :..:-:.:
:.:.:...
.:,.::..::

to all users a

Deliver

tested
meets

system that
the requirements

tested

system

meets

all system-level

the requirements of
Build 1 plus: SSS-2,
SSS-3, SSS-15, ....
SSS-1249

of Builds 1 and 2 plus:


SSS-4, SSS-7,
SSS-10, .... SSS-1248

to selected

i;::, :. : :....>::: ... .: :::, j.;;::.::

,, ::

to all users

requirements;
to designated
agency

that

transition
suPPort

~~
,::,

:. ~,

5.1

6.1.1

Deliver

users an operational
prototype
that meets

Deliver

users an operational
::,

2, tndiiate betti
w?ikih W?iW&
!0 be accompfisfwd &rk?@th&.
~velOfsment

Oeliver

::
.

~~*@&&.:;

. ,,,

deveM@m@it&~:

~~~

Yes: Plan Build 1 in


detail; Builds 2-4 in

Yes: Ptan Build 2 in


detail; Builds 3-4 in
general

Yes: Plan Build 3 in


detail; Budd 4 in ~eneral

Yes: Ptan Build 4 in


detail

No: NO CSCI qual


testing h this build

No: No CSCI qual


testing in this build

Yes: Plan for CSCI qual


testing in this build

Yes: Update for CSCI


qual testing in this build

No: No system qual


te$ting in this ~ui,d

No: No system qual


testing in this build

Yes: Plan for system


qual testing in this build

Yes: Update for system


qual testing in this build

No: Let users install on


their own

No: Let users install on


their own

Yes: plan to install at


user sites

Yes: Update as needed


for installation of Bld 4

,.:....::..: ,.. ... .


6.12

Ran fwcm%aiitifi;.:;
@$tl*:
:: *
.+::.,
. .. .... .
.. .. .... ,.

5.1.3

Plaq fw,.s~ii*,fi@ti~AtiW
~ati~:j:::;;,>:.~:,,
,,:
..
: -.:.
., ..:.
,.,..:,,:.:,:.,,, .::,
.

5,1.4

Pfan ftl? *MW


user sites, ~~;

;:

k~ftkk
,,,:

;,,.
#t
)

9.1,5

Pfart for weilWtkMnlJ Softwara


m the $t#PK@ ti~mj!

Yes: Very preliminary


planning only

Yes: Update preliminary


plans

Yes: Update preliminary


plans

Yes: Finalize transition


planning

5,1,6

Folfw4 @&ti&;f&@titi
~
manafpme~
C@vidw,, ~.:{ ,:

Yes: For those plans


that are in effect

Yes: For those plans


that are in effect

Yes: For those plans


that are in effect

Yes: For those plans


that are in effect

Yes: Update as needed


for Build 2

Yes: Update as needed

Yes: Update as needed

for Build 3

for Build 4

yes: AS needed for

Yes: As needed for

Build

Build 2 testing

Yes: Set up fully for


Build 3 qualification
testing

Yes: Update as needed


for Build 4 quahfication
testing

5.2
6.2.1
5.2.2

, ::::.,;,,::, .;
,, ,,,: ::,,;,..:::, ,,,
Estebliift $@&&:;:.:
~&:,,
EWWti
*-,

;,:. Yes: As needed for


;..>.,; Build 1

d:.w&&tis$A:;::
i
::.::..::.,
::, ~~,,,
..... :::.:.......
, .... .... ,..:..
......... : .,,. :.::..
.,:.....:.,,,

FIGURE

13.

1 testing

Examt)le

o f build

,,: :,,

DIannina

.,:
,,

for a MIL-STD-498

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

woject.

MIL-STD-498
APPENDIX

a.

Different
decisions will apply to different types of software
differences
can be shown within the entries of one worksheet
worksheets
for different types of software on a project.

on a project,
These
or by using different

b.

If early builds are devoted to experimentation,


developing throw-away
software to
concept
or system
requirements,
it may be appropriate
to forgo
arrive at a system
such as coding standards, that will be imposed later on the real
certain
formalities,
software,
If the early software will be used later, such formalities may be appropriate
from the start. These decisions are project-dependent.

G.6.3 Rec ordina ta ilorina dec ision~. Tailoring decisions made by the acquirer before the
of Work. Tailoring proposed by the developer
project begins are specified in the Statement
may be communicated
via feedback on draft solicitations,
proposals written in response to
solicitations,
the software
development
plan, joint reviews during the project, or by other
means of communication.
Refinements
to the tailoring decisions may be ongoing as the
Those
involving
contractual
changes
should
be handled
accordingly.
project proceeds.
G.6.4 schedu Iina the selected act ivities in eac h build.
Another important
step in build
planning is scheduling the activities in each build. As with tailoring, the acquirer may set forth
general milestones
and have the developer
provide specifics
or may provide specific
schedules,
The following guidelines apply:
a.

A common mistake is to treat all CSCIS as though they must be developed in lockstep, reaching key milestones at the same time. Allowing CSCIS to be on different
schedules can result in more optimum development.

b.

A similar mistake is to treat software units as though they must be developed in lockstep, all designed by a certain date, implemented
by a certain date, etc. Flexibility
in the scheduling of software units can also be effective.

c.

The activities in MIL-STD-498


need not be performed sequentially.
Several may be
taking place at one time, and an activity maybe performed continually or intermittently
throughout
a build or over multiple builds. The activities in each build should be laid
out in the manner that best suits the work to be done.

55
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STO-498
APPENDIX
GUIDANCE

ON ORDERING DELIVERABLES

H.1
%QLH2. This appendix provides guidance to the acquirer on the deliverables to be
required on a software development
project.
This appendix is riot a mandatory part of this
standard.
The information
provided is intended for guidance only.
H.2

Alxiicab!e

docu ment~.

This section

is not applicable

to this appendix.

H.3
Qrderina de liverable~.
MIL-STD-498
has been worded to differentiate
between the
pIanning/engineering
activities
that make up a software
development
project and the
generation of deliverables.
A key objective of this wording is to eliminate the notion that the
acquirer must order a given deliverable in order to have planning or engineering work take
place.
Under MIL-STD-498,
the planning and engineering work takes place regardless of
which deliverables
are ordered, unless a given activity is tailored out of the standard.
In
addition, joint technical reviews have been included to review the results of that work in its
Deliverables should be ordered only
natural form, without the generation
of deliverables.
when there is a genuine need to have planning or engineering information
transformed
into
a deliverable,
recognizing
that this transformation
requires time and effort that would
otherwise
be spent on the engineering
effort.
B\ock 3 of each DID provides information
helpful in deciding whether the corresponding
deliverable should be ordered.
MIL-STD-498
has been structured
to support a variety of
H.4
Schedu Iina de liverable~.
program
strategies
and to provide the developer
flexibility
in laying out a software
development
process that will best suit the work to be done. All of this flexibility
can be
canceled by rigid scheduling
of deliverables
on the CDRL. If the CDRL lays out a strict
waterfall
sequence of deliverables,
little room is left to propose innovative development
processes.
If the CDRL forces all CSCIS into lock-step with each other, little room is (eft to
develop the CSCIS in an optimum order. To the maximum extent possible, the CDRL should
avoid such pre-determination,
leaving the door open for incremental
delivery of software
products, staggered development
of CSCIS, and other variations to optimize the software
The developers
software
development
plan will lay out a proposed
development
effort.
schedule that meets the constraints
in the CDRL. Final agreement on scheduling can take
place at that time.
Traditional
deliverables take the form of paper documents
H.5
Format of de liverable~.
While this form works well for some deliverables, it is not the
exactly following DID formats.
only form, and alternatives
should be considered.
One variation from paper documents
is
word processing files containing those documents.
This format saves paper, but still requires
the developer to format the information
as required by the DID.
Another
variation is
specifying that a paper or word processor document is to include all DID contents but may
be in the developers format. Yet another variation is allowing deliverables to take forms that
are not traditional
documents
at all, such as data in computer-aided
software engineering
(CASE) tools. These variations in required format can be specified on the CDRL, minimizing
the time spent transforming
actual work products into deliverables.
H.6
Tailorina the DID$. Tailoring the DIDs consists of deleting requirements
for unneeded
information
and making other changes that do not increase the required workload, such as
combining two documents
16 of the CDRL,

under one cover.

DID tailoring

for deliverables

56

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

is specified

in Block

MIL-STD-498
APPENDIX

CONVERSION GUIDE FROM


DOD-STO-21 67A AND DOD-STD-7935A
~coDQ. This appendix provides a conversion guide from DOD-STD-21 67A and DOD1.1
STD-7935A,
the two standards that were merged to form MIL-STD-498.
It maps key terms
from each of these standards to their counterparts
in MI L-STD-498 and shows the relationship
of the DIDs required by these standards to their counterparts
in MI L-STD-498.
This appendix
is not a mandatory
part of the standard.
The information
provided is intended for guidance
only.
1.2
which

This appendix
by this standard:

ADD Ii cab Ie docume

are superseded

a.

DOD-STD-2

167A,

b.

DOD-STD-7935A,
31 October 1988

n~.

Defense

System

DoD Automated

references

Software

the following

Development,

Information

System

standards,

29 February

Documentation

Term

DOD-STD-2

167A

Counterpart

DOD-STD-7935A

1988
Standards,

Matm ina of kev terms. Figure 14 identifies selected terms in MIL-STD-498


1.3
their counterparts
in DOD-STD-21 67A and DOD-STD-7935A.

MIL-STD-498

both of

and states

Counterman
4

>
Acquirer

Contracting

agency

User Group (no distinction made


between acquirer and user roles)

Developer

Contractor (covers Government


agency or contractor)

Development Group (covers


Government agency or contractor)

Implementation

Coding

Development, production,
database generation

Installation

Deployment

Deployment,
installation

Computer software component


and computer software unit

Software

Computer Software
Configuration Item ICSCI)

Computer Software
Item (CSCII

Program, computer program

Software

Software

Software

(at user sites)

unit

support

Configuration

support

Software

coding,

implementation,

unit

maintenance

Software system (consisting of


software and possibly
computers)

System [No specific term used to


distinguish this type of system]

Automated
system

Hardware-software

System (No specific term used to


d!stlnguish this type of system]

(This type of system not covered


by DOD-STD-7935A)

system

(where the hardware may be


other than computers)

Information

System,

FIGURE 14.

Matm irm of kev te rm~.

57
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
APPENDIX

Figure 15 identifies the DOD- STD-7935A


DIDs and tells which
1.4
Mam irw of DIDs.
their contents.
Figure
16 provides a similar mapping from the
MI L-STD-498
DIDs contain
DOD-STD-21 67A DIDs to the MIL-STD-498
DIDs. Figure 17 provides the reverse mapping,
identifying the MIL-STD-498
DIDsandtelling
which DOD-STD-2 167Aand/or
DOD-STD-7935A
DIDs formed the basis for each.

DC)D-STD-7935A

DID

Incorporated

into These MIL-STD-498

DIDs

Functional Description (FD)

System concepts into Operational Concept Description (OCD)


System requirements into System/Subsystem
Specification (SSS)
Development planning into Software Development Ptan (SDPI

System/Subsystem
[ss)

System requirements into System/Subsystem


Specification (SSS)
System design into System/Subsystem
Design Description (SSDD)

Specification

Software

Unit Specification

Database

Specification

W]

(DSJ

Requirement information into Software Requirements Specification


MS)
and Interface Rerwirernents %reclficatim (IRS}
Design information into Software Design Description (SDD) and
h-rterface Design Description (IDD)
Database Design Description IDBDD)

Test Plan (PTI

High-level planning into Software Test Plan (STP]


Detailed planning into Software Test Description (STD)

Test Analysis Report (RT)

Software

Test Report (STR)

Users Manual (UM)

Software

input/Output

End User Manual (EM)

Software

User Manual (SUMI

Computer Operation Manual (OMI

Software

Center Operator Manual (SCOM)

Maintenance

Planning information into Software Transition Plan (STrP)


Software description into Software Design Description (SDD)
Maintenance procedures into Software Product
Specification (SPS)

Manual (MM)

Implementation
w

Procedures (1P)

FIGURE

15.

MaDD

Software

Manual (SIOMI

Installation Pfan (SIPI

ina of DOD-STD-793

5A DIDs to MIL-STD-498

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DIDs.

MIL-STD-498
APPENDIX

DOD-STD-2
Software

Development

167A DID

System/Segment

Specification

System/Segment

Design Document

Incorporated

Plan (SDPj

Software

(SSS)

Development

System/Subsystem

(SSDD)

into These MIL-STD-498

DIDs

Plan (SDP}

Specification

(SSS1

Operational concept mto Operational Concept Description


(OCD)
System design into System/Subsystem
Design Description
(SSDD)

Software

Requirements

Specification

(SRSJ

I Software

Imefface

Requirements

Specification

(IRS)

! Interface Recwirernems Sxcificalion

Software

Design Document

(SDD)

I Software

Interface

Design Document

(IDD)

I Interface Desirer Descricrtion (IDD)

Software

Test Plan fSTP)

I Software

Test Ptan {STP)

Software

Test Description (STD)

I Software

Test Description

Software

Test Report (STR}

I Software

Test Report (STR)

Computer
Software

System Operators

Manual (CSOM)

Software
Support

Software

Woduct Specification

(SPS)

Software

Programmers

Firmware

Support Manual (FSM)

Speclilcatm

[SRS)

(IRS}

II

Deskm Descrimion (SDD)

II

(STD)

n
I

Computer Operation Manual {COM}

Users Manual (SUM)

Computer Resources Integrated


Document lCRiSD)

Rrwuimmems

User Manual (SUM)

Planning information into Software Transition Plan (STrP)


Modification procedures into Software Product Specification
(SPS)
z

Version Description

Manual (SPM)

Document

FIGURE 16.

(VDD)

Software

Product Specification

(SPS)

! Computer ProwamrninQ Nlanual (Cpfvl)


! Firmware SutIDort Manual (FSM)

I Software

II

M aoD in a of DOD-STD-21

Version Description

(SVD)

67A D)Ds to MIL-STD-498

59
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

DIDs,

MIL-STD-498
APPENDIX

MIL-STD-498

DOD-STD-21

DID

67A and DOD-STD7935A

Source DIDs

2 167A Software Development Plan (SDP)


7935A Functional Description (FD), section 7

Software

Development

Software

Installation Plan (SIP)

7935A

Implementation

Software

Transition Plan (STrP)

2167A
7935A

Comp Res Inteo SUP Doc (CRKD) - planning info


Maintenance Manual (MM) - planning infO

Operational

Plan (SDP)

Concept Description

Procedures (1P)

(OCDI

2 167A System/Segment
Design Doc (SSDD), section 3
7935A Functional Description (FD), section 2

(SSS)

2167A
7935A
7935A

System/Segment
Specification (SSS)
Functional Description (FD) - system reqt mfo
Spec (SS) - system reqt info
System/Subsystem

2167A
7935A

System/Segment
Design Document (SSDD)
System/Subsystem
Spec - system design info

System/Subsystem

Specification

System/Subsystem

Design Description

(SSDD)

Software

Requirements

Specification

(SRSI

2167A
7935A

Software
Software

Requirements Specification fSRS)


Unit Specification (US) - reqt info

interface

Requirements

Specification

(IRS)

2167A
7935A

Interface Requirements Specification (IRS)


SW Unit Specification (US) - interface reqt info

Software

Design Description

C5DD)

2167A
7935A
7935A

Software Design Document (SDD)


Software Unit Specification (USI - design info
Maintenance Manual IMM) - as built design info

Interface

Design Description

(IDDI

2167A
7935A

Interface Design Document ODD)


SW Unit Specification (US) - intetiace

Database

Design Description (DBDDI

7935A

Database

Software

Test Plan (STP)

2167A
7935A

Software Test Ptan (STPI


Test Plan (PT) - high-level information

Software

Test Description

2167A
7935A

Software Test Description (STD)


Test Plan (PT) - detailed information

Software

Test Report (STR)

Software

Product Specification

Software

Version Description

Software

(STDI

Specification

design info

[DS)

2 167A Software Test Report (STR)


7935A Test Analysis Report (RT)
2167A
2167A
7935A

Software Product Specification W%]


CRISD - modification procedures
MM - maintenance procedures

2167A

Version Description Document

User Manual (SUMI

2167A
7935A

Software Users Manual (SUM)


End User Manual (EMI

Software

Center Operator Manual (SCOM)

7935A

Computer Operation Manual (OM)

Software

Input/Output

7935A

Users Manual (UM)

Computer Operation Manual (COM)

2167A

Computer System Operators Manual (CSOM)

Computer Programming

2 167A Software

(SVD)

Manual (SIOM)

Manual {CPM)

sirmware SUPPOR Manual

FIGURE 17.

(SPS)

(FSMI

MacIcrirm of MIL-STD-498

Programmers

(VDDJ

Manual (SPMI

2 167A Ftrmware Support Manual (FSM)


DIDs to DOD-STD-21

67A and DOD-STD-7935A

60
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

DIDs.

MIL-STD-498
INDEX
This index covers
followed

in the standard
Block 10,
number
indicate

both MIL-STD-498

by paragraph
have

section

numbers;

no preceding

10.1

and its DIDs.

an overall

of the DID

acronym,
(General

Paragraphs

DID is indicated
DID

references

Instructions).

in the DIDs are indicated

by the DID acronym


that

All other

begin

with

alone;
10.1

DID references

by the DID acronym

paragraphs

refer to paragraphs
that

appears

too frequently

in

do not cite a Block

refer to paragraphs
in Block 10, section
10.2 of the DID (Content
Requirements).
primary sources of information
about a topic.
The entry et al indicates
that

software)

and figures

Entries in bold
a topic (such as

to cite all references.

acceptance
3.1, 3.30, E,3; IRS 3; SRS 3; SSS 3
access
access for acquirer review
4.2.7;
SDP 4.2.7
access to information in a repository
6.4
acquirer (use of term acquirer in MIL-STD-498)
Foreword-4, 1.2.1, 3.2, FIg 14
acquisition strategies
(see program strategies)
acronyms
Appandix A
allocation
allocation of computer hardware resources
4.2.5;
SDP 4.2.5;
SDD 4.1; SSDD 4.1
allocation of requirements
Fig 3, Fig 6; SDD 4.1, 6;
SRS 5; SSDD 4.1, 5; SSS 5
AN S1/lEEE/EIA 1498
Foreword-1
1.2
application of MIL-STD-498
approval (by the acquirer)
3.3, 5.1.6, 5.7.1, 5.9.2,
5.13.7, 5.18.1, 5.18.2, 5.19.7, Cl, D.1
architecture
3.4
[also see CSCI architectural design,
system architectural design)
as built design descriptions
5.13.4, 5.13.5, Fig 2,
Fig 3, Fig 6, D.4.1, Fig 17; SDP 5.13.4, 5.13.5;
SPS 3, 6.1
associate developer
3.5, 5.19.6, Fig 9-1 2; SDP 5.19.6
assurance
4.2.4;
SDP 4.2.4
(also see software
quality assurance)
privacy assurance
4.2.4.3;
SDP 4.2.4.3
safety assurance
4.2.4.1;
SDP 4.2.4.1
security assurance
4.2.4.2;
SDP 4.2.4.2
audits (configuration audits)
5,14.4;
SDP 5,14.4

computer-aided software engmeermg (CASEI


Foreword-3, 1.2.4.4,
3.38, 5.1.1, 6.4, Fig 2, H.5;
all DIDs: Block 7; STrP 3.3
5.12.3.2,
5.12.3.3;
computer center, software center
OCD 7.1; SCOM; SDP 5.12.3;
SIOM; SIP 4;
SUM
computer hardware characteristics
CPM 3, 4; FSM
3.x.1, 3.x.4, 4.1; SRS 3.10.1;
SSDD 4.1; SSS
3.10.1;
STrP 3.2
computer hardware resource utilization
4.2.5, 5.13.4,
F.3; OCD 8.2; SDD 4.1; SDP 4.2.5;
SPS 5.4,
6; SRS 3.10.2;
SSDD 4.1; SSS 3.10.2
Computer Operation Manual (COM)
5.12.3.4,
6.2,
Fig 4, Fig 6, E.4.9, Fig 9-12, Fig 16, Fig 17;
COM; SDP 5.12.3
computer program
3.10
Computer Programming Manual (CPM)
5.13.6.1,
6.2,
Fig 6, Fig 9-12, Fig 16, Fig 17; CPM; SDP
5.13.6
Computer Software Configuration Item (CSCI)
1.2.2,
3.12, 3.24, Fig 14, et al
CSCI architectural design
3.4, 5.6.2, Fig 3,
Fig 6, E.4.6; SDD 4; SDP 5.6.2;
SPS 5.1
CSCI detailed design
3.45, 5.6.3, 5.13.4, Fig 3,
Fig 6, E.4.6; SDD 5; SDP 5.6.3, 5.1 3.4; SPS
5.1
(also see Database Design Description,
Interface Design Description)
CSC1/HWCl integration and testing
4.1, Fig 1, 5.10,
Fig 3, Fig 6, Fig 9-12;
SDP 5.10
CSCI qualification testing
3.28, 3.43, 4.1, Fig 1,
5,1.2, 5.2.2, 5.9, 5.9.5, Fig 3, Fig 6, E.4.7,
E.4.8, Fig 9-13; IRS 4; SDP 5.1.2, 5.9;
SRS 4; STD; STP; STR
CSCI requirements
5.5, 5.6.2, 5.7, 5.9, 5.9.3,
Fig 2-4, Fig 6, Fig 9-12; DBDD 3, 4, 6; IDD
4; SDD 4.1, 5, 6; SDP 5.5; SPS 5.4, 6; SRS
3; STD 4.x.Y. 1, 5; STP 6 (also see software
requirements analysis, Software Requirements

behavioral design
3.6, 5.4.1, 5.6.1, Fig 2, Fig 3;
DBDD 3; OCD 3.3, 5.3; SDD 3; SSDD 3
builds 3.7, 5, Fi~ 1, G.3, G.5, Fig 10, Fig 11
build planning guidance
G.6, Fig 13
notes on interpreting activities for multiple builds
5.1-5.16,
5.18
category classifications for problem reporting 5.17.2,
Fig 2, C.1, C.3, Fig 4; SDP 5.17.2
(also see
corrective action)
code standards
4.2.2, D.4.7, G.6.2;
SDP 4.2.2;
SPS 5.3
coding
(see software implementation and unit testing)
commercial off-the-shelf (COTS)
(see reuse, reusable
software products)
compilers, compilatiodbuild
procedures
3.38, 5.13.7,
Fig 6; CPM 3; SPS 5.2, 5,3; STP 3.x.1; STrP 3.3
~;ompliance with the contract
5.1.6, 5.16,3

Specification, Interface Requirements


Specification)
CSC1-wide desiQn decisions
3.6, 5.6.1, Fig 3,
Fig 6, E.4.6; SDD 3, 4.1; SDP 5.6.1, 5.13.4;
SPS 5.1
configuration management
(see software configuration
management)
Continuous acquisition and life-cycle SUPPOrt (CALS)
Fig 2; all DIDs: Block 7

61
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
INDEX
definitions of sottware product evaluation crnerla D.4
defimtlons of terms
3
dehverables, deliverable software products
1.2.1, 1.2.2,
3.16, 5.1.1 Notes 1-2, 5.2.5, 5.13.7, 5.14.5,
5.15.1;
all DIDs: Block 7
guidance on ordering deliverables
6.5, Appandix H
design
3.17
{also see as built- design descriptions,
behavioral design, CSCI architectural design, CSCI
detailed design, CSC1-wide design decisions,
Database Design Description, Interface Design
Description, software design, Software Design
Description, system architectural design,
System/Subsystem
Design Description, systemwide design decisions)
design standards
4.2.2, D.4.7;
DBDD 3, 4, 5; 100 3;
SDD 3, 4, 5; SDP 4.2.2;
SPS 5.3; SSDD 3, 4
detailed requirements of MIL-STD-498
5
develop (interpretation of develop= m MIL-STD-498)
1.2.4.3
developer (use of term developer- in MIL-STD-498)
Foreword-4, 1.2.1, 3.18, Fig 14
documentation
Foreword-3, 3.19, 5.1. 1; all DIDs:
Block 7, 10,1.a, 10.1.i
(also see Data Item
Description)
DOD-STD- 1703
Fweword-3
DOD- STD-2 167A
Foreword-3
mapping between MIL-STD-498
DIDs and
DOD-STD-21 67A 010S
1.4, Fig 16, Fig 17
mapping of key MIL-STD-498
terms to
MIL-STD-2167A
1.3, Fig 14
DOD-STD-7935A
Foceword-3
mapping between MIL-STD-498
DIDs and
DOD-5TD-7935A
DIDs
1.4, Fig 15, Fig 17
mapping of key MIL-STD-498
terms to
MIL-STD-7935A
1.3, Fig 14

1.2.2
contract, contract specific application
use of term contract in MIL-STD-498
Foreword-4, 1.2.1
references to the contract
Foreword-4, Foreword-5,
1.2.1, 1.2.2, 1.2.4.1,
3.1, 3.3, 3.16, 3.18,
3.26, 3.30, 3.39, 4.1, 4.2.3.1,
4.2.3.2,
4.2.4.4,
4.2.5, 4.2,7, 5.1, 5.1.1, 5.1.4-5.1.6,
5.2.3, 5.2.4, 5.4.1, 5.7.1, 5.12.4, 5.13.7,
5.14.1-5.14.5,
5.15.2, 5.16.1-5,16.3,
5.17.1,
5.17.2, 5.19.3 -S.19.6, 6.2, 6.4, 6.5, B.3,
G.6, G.6.3; all 010s: Block 7 (7.11, 10.1.c,
10.1.h;
SDP 4.1, 4,2,1, 4.2.2, 4.2.3.1,
4.2.3.2,
4.2.4-4.2.7,
5.1-5.19;
SRS 3.1 1;
SSS 3.16; STrP 7
Contract Data Requirements List (CDRL)
1.2.1, 5.1.1,
6.3, 6.4, 6.5, Fig 6, D.4.9, H.4, H.5, H.6;
all DIDs: Block 7, 10. ?.c
contracting agency
(see acquirer)
contractor
(see developer)
conversion guide from DOD-STD-2 167A and
DOD-STD-7935A
Appa@x
I
corrective action, corrective action system
4.1,
Fig 1, 5.17, Fig 3, Appendix C, Fig 9-12;
SOP 5.17
(also see problem reporting]
Cosf
cost benefit, cost-effectiveness
Foreword-9,
4.2.3.2,
6.5, B.3
costlschedule reporting, costlschedule risks
5.18.1, 5.18.2, 5.19.1,
6.6, B.3, Fig 5
critical requirements
4.2.4,
Fig 5; DBDD 3; IRS 3.y;
SDD 3; SDP 4.2.4; SRS 3.18; SSDD 3; SSS 3.18
critical requirements reviews
E.4.1 1
privacy assurance
4.2.4.3,
5,19.3, B.3, E.4.11
safety assurance
4.2.4.1,
Fig 2, B.3, Fig 5, E.4.1 1
security assurance
4.2.4.2,
5.19.3, Fig 2, B.3,
Fig 5, E,4.11

dry run of qualification tests


5.9.4,
D.4.2;
SDP 5.9.4, 5.11.4

data elements/data element assemblies


all DIDs: 10. 1.h;
DBDD 3, 4.x, 5.x; IDD 3.x; IRS 3.x; SDD 3,
4.3.x, 5.X; SIOM 5.1; SRS 3.2.x, 3.3.x, 3.4,
3.5; SSDD 3, 4.3.x;
SSS 3.2.x, 3.3.x, 3.4, 3.5
data rights 4.2.3.1,
B.3; STP 3.x,4;
STrP 3.2, 3.3,
3.4
(also see licenses, licensing)
data standardization, standard data descriptions
all DIDs: 10.1 .h
Data Item Description (DIDI
Foreword-9, 1.2.3, 511.1,
5.13.6,
6.2, 6.3, 6.4, 6.5, 0,4.4, G.5, Appandix
H, 1.4, FiQ 15-17
database
3.14, 3.15, 3.32, 3.45, 5.7,1, 5.12.1,
5.13,1,
5.13.2, 6.4, Fig 4; SCOM 3.2, 3.3,
5.5.x.3;
SIOM 3.2, 3.4, 5.1; SIP 4.x.5;
SPS
3.1, 3.2; SRS 3.5, 3.10.3,
3.12; SSS 3.5,
3.10.3;
STD 4.x.Y.6;
STP 3.x.1;
SUM 3.2, 3.3
database design, Database Design Descrlptlon (DBDD)
5.4.1, 5.6.1, 5.6.3, 6.2, Flg 9-12, Fig 15, Fig 17;
DBDD; SOD 3, 4,1, 5, 5.x, 6; SPS 5.1, 5.3;
SSDD 3, 4.1
define (interpretation of define in MIL-STD-4981
1.2.4.3

5.11.4,

Fig 6,

error reporting
(see problem reporting]
evaluation
3.20
(also see Independent Verification and
Validation, reusable software products, software
product evaluations, software quality assurance,
test case evaluation criteria)
Evolutionary program strategy
Foreword-3, G.3, Fig 7,
Fig 8, Fig 11
executable software
Fig 6
compilation/build procedures
Fig 6; SPS 5.2, 5.3
delivery of executable software
SPS 3.1
incorporating reusable software into the executable
software
Fig 3
5.12.4
installing executable software
preparing the executable software for software
transition
5.13.1;
SOP 5.13.1
preparing the executable software for software use
5.12.1;
SDP 5.12.1
5.13.2, 5.13.7;
regenerating executable software
SPS 3.2
version descriptions
(see Software Version
Description)

62
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
INDEX
firmware
1.2.2,
3.21,
3.38,
3.43;
SPS 5.2; STP 3.X.2
Firmware Support Manual (FSM)
5.13.6.2,
6.2, F196,
FIg 9-12, FIg 16, FIQ 17; FSM; SDP 5.13.6
forward engineenng
3.29, FIIJ 12

general requirements of MIL-STD-49B


4
Government in-house agencies [as developers)
Foreword-4, 1.2.1
Grand Design program strategy
G.3, Fig 7, FIg 8, Fig 9
Hardware Configuration Item (HWCI)
3.22, 3.24, 5, 10;
SDP 5.10;
SRS 3.10.1;
SSDD 4, 4.1; SSS
3.10.1
hardware-software
systems
1.2.4.1,
1.2.4.2, Fig 14;
SSDD 3; SSS 3.9, 3.10, 3.12
implementation
(see software implementation and unit
testing)
Incremental program strategy
Foreword-3, G.3, Fig 7,
Fig 8, Fig 10
in-process
in-process and final software product evaluations
S.15.1;
SDP 5.15.1
joint reviews of in-process and final software
products
5.18.1
independence
independence in software product evaluation
5.15.3;
SDP 5.15.3
independence in software quality assurance
5.1 6.3;
SDP 5.16.3
independence in qualification testing
5.9.1, 5.11.1;
SDP 5.9.1,5.11.1
Independent Verification and Validation (lV&V)
3.23,
5.19.5, Fig 9-12; SDP 5.19.5
installation
installation at the SUppOrt site 5.13.7;
STrP 7
installation at user sites 5.12.4, Fig 6, E.4.9, Fig 14;
SCOM 4; SDP 5.1 2.4; SIP; SSS 3.16; SUM
4.1.3;
SVD 3.6
software installation planning
5.1.4, 6.2, Fig 6,
E.4.1, Fig 9-13, Fig 15, Fig 17; SDP 5.1.4;
SIP
intefJral software development processes
4.1
int.?gralion
(see CSC1/HWCl integration and testing, unit
integration and testing)
interface
3.24
interface design, Interface Design Description (IDDJ
5.4.1, 5.4.2, 5.6,1, 5.6.2, 5.6.3, 6.2, Fig 6,
Fig 9-12, Fig 15-17;
DBDD 3, 5.x; IDD; SDD
3, 4.3, 5, 5.x, 6; SPS 5.1; SSDD 3, 4.3, 5
interface requirements, Interface Requirements
Specification (IRS) 5.3.3, 5.5, 5.9, 5.11, 6,2,
Fig 6, Fig 9-12, Fig 15-17;
IRS; SRS 3.3, 3,4;
SSS 3.3, 3.4; STD 5; STP 6
lSO/lEC DIS 12207
Foreword-6
tomt technical and management reviews 3.25, 4.1, Fig 1
5.18, Flg 2-3, Flg 9-12, G.6.3, H.3; SDP 5.18
candidate }oint management rewews
Appendix E

key decisions (recording rationale for key decmons)


3.34, 4.2.6, 5.2.4;
all DIDs: Notes section;
SDP4t2.6
key word listing m MIL-STD-498
6.8
key terms [mapping of key MIL-STD-498
terms to
DOD-STD-2167A,
DOD-STD-7935A)
1.3,
Flg 14
licenses, licensing
B.3, Fig 3; STP 3.x.4;
STrP 3.2,
3.3, 3.4
(also see data rights)
life cycle
Foreword-4, FIg 2, Flg 5, G.2; SDP 3
logistics SRS 3. 15; SSS 3.15
(also see Continuous
acquisition and life-cycle support [CALS))
maintenance
FIg 14

Foreword-4, 1.2.1,
(also see software

1.2.4.3,
suppo~)

3.33,

3,41,

management indicators
(see software management
indicators)
management review
5.1.6;
SDP 5.1.6
metrics
(see software management indicators)
non-deliverable software products
SDP 5.2.5
Notes
6; all DIDs: Notes section

1.2.2,

3.26,

5.2.5;

operational concept, Operational Concept Description


(OCDI
5.3.2, 6.2, Fig 3, Fig 4, Fig 6, E.4.2,
Fig 9-12, Fig 15-17;
OCD; SDP 5.3.2
operational concept reviews
E,4.2
packaging, packaging requirements
5. 14.5; SDP
5.14.5;
SPS 3.3; SRS 3.17;
SSS 3.17; STrP 7
participate [interpretation of participate- in
MIL-STD-498)
1.2.4.2
participation in system-level activities
5.1.3, 5.3,
5.4, 5.10, 5.11, 5.13.5, D.3; SDP 5.3, 5.4,
5.10, 5.11
planning
(see build planning, project planning, software
development planning, software installation
planning, software transition planning, test
planning)
pnorit y classifications for problem reporting
5.17.2,
C. 1, C.4, Fig 5, F.3
{also see corrective action)
privacy
4.2.4.3,
5.19.3, B.3, E.4.11, Fig 9-12;
ail DIDs 1.3; COM 3.2,4;
DBDD 3, 4.x, 5.x;
FSM 3.x.5;
IDD 3.x; IRS 3.x, 3.y; OCD 3.3, 5.3;
SCOM 3.2, 3.4, 3.6, 5.5.x;
SDD 3, 4.3.x;
SDP
3, 4.2.4.3,
5.19.3;
SIOM 3.2, 3.4, 3.6, 4.2.1,
4.3.1, 4.3.2;
SIP 3.7, SRS 3.3.x, 3.8, 3.18;
SSDD 3, 4.3.x;
SSS 3.3.x, 3.8, 3.18; STD 3, 4;
STP 3.x.1, 3.x.2, 3.x.3, 4.2.x.Y;
STrP 3.1-3.4;
SUM 3.2, 3.4, 3.6, 4.1.2;
SVD 3.1, 3.2, 3.6

(also see assurance)


problem reporting, problem/change reports 5.3.1,
5.14.3, 5.15.2, 5.16.2, 5.17.1, 5.17.2, F~g2,
Appendix C, Fig 4, Fig 5, F.3; SDP 5.1 7.1; STR
3.1, 4.x.2.y;
SVD 3.3, 37
process improvement
5.19.7, FIg 9-12;
program (computer program)
3.10

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

SDP 5.19.7

MIL-STD-498
INDEX
program

strategies
Fig 9-11,

Appandix
H.4;

risk mana~ement
5.18.1, 5.18.2, 5.19.1,
G.4, Flg 8-12; SDP 4, 5, 5.19.1

G, Flg 7, Fig 8,

SDP3

FIg 2;
languages
3.29,
4.2.2,
5.7.1,
SRS 3.12;
DBCXI 5.X; SDD 5.x; SOP 4.2.2;
SSS 3.12
[also see Computer Programming
Manual)
project planning 4.1, FIg 1, 5.1, Fig 3, Fig 6,
Fi~ 9-13; SOP 1.4, 5.1; SIP 1.4; STP 1.4;
STrP 1.4
(also see software development
plannin~)
project-unique identifiers
5. 14.1; DBDD 3, 4,
4.x, 5, 5.x; IDD 3, 3.1, 3.x; IRS 3, 3,1,
3.x; SDD 3, 4, 4.1, 4.3.1, 4.3.x, 5, 5.x;
SRS 3, 3.3.1, 3.3.x;
SSDD 3, 4, 4.1, 4.3.1,
4.3.x;
SSS 3, 3.3.1, 3.3.x;
STD 3.x, 4.x,
4.x,y; STP 4.2.x, 4.2.x.y;
STR 4.x, 4.x.2.y,
4.x.3.y
prototypes
5.3.1, G.6.1, F~g 11, FIg 13

B.3, Fig 5,

programming

qualification

methods

IRS 3. 4;

SPS 4;

5.3;

4.2.4.1,
FIg 2, B.3, FIg 5, E.4.ll;
COM 3;
DBDD 3, 5.x; FSM 3.x.6; iDD 3.x; IRS 3.x, 3.y;
OCD 3.3, 5.3; SCOM 4, 5; SDD 3, 4.3.x;
SOP
4.2.4,1;
SIOM 4, 6; SIP 4.X.5, 5.x.2; SRS
3.3.x, 3.7, 3.18; SSDD 3, 4.3.x;
SSS 3.3.x, 3.7,
3.18;
STD 3, 4; STP4.2.X.Y;
STrP 3.1; SUM 4,
5; SVD 3.6
(also see assurance)
schedules
3.34;
SDP 3, 6, 7.2; SIP 3.1, 4.x.1, 5.x.1:
STP 5; STrP 5, 7
costlschedule repofimg, costlschedule risks
5.1 B.1, 5.18.2, 5.19.1, 6.6, 8.3, Fig 5
~uidance on scheduling activities
G.6.4
guidance on scheduling delwerables
H.4
scope of MIL-STD-498
1
security
4.2.4.2,
5.19.3, FIQ 2, B.3, Fig 5, E.4.1 1,
Fig 9-12; all DIDs 10.1.c, 1.3; COM 3.2.4;
DBDD 3, 4.x, 5.x; FSM 3.x.5; iDD 3.x; iRS 3.x,
3.y; OCD 3.3, 5.3; SCOM 3.3, 3.4.1, 3.4.2,
3.7, 5.5.x;
SDD 3, 4.3.x;
SDP 3, 4.2.4.2,
5.19.3, 7.2; SIOM 3.2, 3.4, 3.6, 4.2.?, 4.3.1,
4.3.2;
SIP 3.7, 4.x.2;
SRS 3.3.x, 3.8, 3.18;
SSDD 3, 4.3.x;
SSS 3.3.x, 3.8, 3.18; STD 3, 4;
STP 3.x.1, 3.x.2, 3.x.3, 4.2.x.Y;
STrP 3.1-3.5;
SUM 3.2, 3.4, 3.6, 4.1.2;
SVD 3.1, 3.2, 3.6
(also see assurance)
software
3.32, et al
Software Center Operator Manual [SCOM)
5.12.3.3,
6.2, Fig 6, Fig 9-12, Fig 15, Fig 17; SCOM
{also
see Software Input/Output Manuai, Software User
Manuai)
software configuration management
3.12,4.1,
Fi~ 1,
5.14, Fig 2, Fig 3, Fig 9-12; SDP 5.14
configuration audits 5.14.4;
SOP 5.14.4
configuration control, author control, project-level
control, acquirer control
5.14.1, 5.14.2,
5.14.3, 5.15.2, 5.16.2, 5.17.1, 5.17.2, F.3;
SDP 5.14.2
configuration identification
5.14. 1; SDP 5.74.1
5.14.3;
SDP 5.14.3
configuration status accounting
packaging, storage, handiing, and delivery [of
software products)
5.14.5;
SDP 5.14.5
software design, Software Design Description [SDD)
3.17, 3.39, 3.45, 4.1, 4.2.6, Fig 1, 5.2.4, 5.6,
5.7, 5.9.1, 5.11.1, 6.2, Fig 2, Fig 4, Fig 6, F.3,
Fig 9-12, Fig 15-17; DBDD 5; SDD: SDP 5.6;
SPS 5.1
(also see as built design descriptions,
behavioral design, CSCI architectural design, CSCI
detailed design, CSC1-wide design decisions,
Database Design Description, Interface Design
Description, system architectural design,
System/Subsystem
Deslffn Description, systemwide design decmons)
software design rewews
E.4.6
software design standards
4.2.2, D.4.7;
DBDD 3,
4, 5; IDD 3; SDD 3, 4, 5; SDP 4.2.2;
SPS
5.3; SSDD 3, 4

SRS 3, 4;

SSS 3, 4; STP 4.2.x.y


qualification testing
3.28, 3.43, 5.2.2, 5.4.1, 5.9,
[also see CSCI qualification testing, system
qualification testing)
qualNy assurance
(see software quality assurance)
quality factors (reliability, maintainability, etc. )
B.3; DBDD 3; OCD 3.3,
SSDD 3; SSS 3.11

safety

5.11

SOD 3; SRS 3.1 1;

rationale (recordin~ rationale)


3.34, 4.2.6, 5.2.4;
all DIDs: Notes section; SDP 4.2.6
record (interpretation of record in MIL-STD-498)
1.2.4.4
redocumentation
3.29, Fig 12
reengineering
Foreword-4, 1.2.1, 1.2.4.3, 3.29, 3.33,
G.5, Fig 12; SDD 4.1; SSDD 4.1
requirement (definition of requirement)
3.30
requirements analysis
(see software requirements
analysis, system requirements analysis,
traceability)
resource utilization
(see computer hardware resource
utilization)
restructuring
3.29, Fig 12
retargeting
3.29, Fig 12
reuse, reusable software products Foreword.4, ?.2.1,
1.2.4.3, 3.31, 3.33, 4.2.3;
SDP 4.2.3
developing reusable software products
4.2.3.2;
SDP 4.2.3.2;
SDD 4.1; SSDD 4.1
evaluating reusabie software products
4.2.3.1,
B.3; SDP 4.2.3.1
incorporating reusable software products
Foreword-3, 3.12, 4.2.3.1,
Appendix B, Fig 3;
all DIDs: 10.1. i; SDP 4.2.3.1;
SOD 4.1;
SSDD 4.1
3.29, FIg 12
reverse engineering
reviews
(see joint technical and management reviews)
revision and retesting
5.7.4, 5.8.3, 5.9.6, 5.10.3,
5.11.6;
SOP 5.7.4, 5.8.3, 5.9.6, 5.10.3, 5.1 1,6;
STD 4.x. ~, 4.x. y.3, 5; STP 4.1.3, 5

64
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
INDEX
software

development

development=

(meaning

of term

in MIL-STD-4981

independence in software quality assurance


5.16.3;
SDP 5.16,3
software quality assurance evaluations
5.16.1;
SDP 5.16.1
software quahty assurance records
5.16.2;
SDP 5.16,2
software requirements, Software Requirements
Specification (SRS) 5.5, 5.9, 6.2, Fig 2-4, FIQ 6,
FIg 9-12, Fig 15-17; SRS; STP 6 (also see CSCI
requirements)
4.1, Fig 1, 5.5,
software requwements analysis
FIg 3, Fig 9-12; SDP 5,5
software requirements review
E.4.5
software support
Foreword-3, 3.35, 3.41, 3.44, 4.2.6,
5.2.3, 5.2.5, 5.13.4, Fig 2, Fig 3, Fig 6, Fig 14;
SPS 5; SRS 3.15; SSS 3.15; STrP
(also see
maintenance)
support agency
3.44, 4.2.6
5.1.5, 5.13, 5.13.4,
5.13.7, E.4.1O, G.6.1, Fig 13; OCD 3.6, 5.5,
7.1, 7.2, 7.3
support concept
3.12, 5.1.5;
OCD 3.5, 5.5
support manuals
5.13.6, Fig 4, Fig 6, E.4. 10;
SDP 5.13.6;
STrP 3.2, 3.3, 3.4
support site 5.13.1-5.13.3,
5.13.7;
SDP 5.13.3,
5.13.7
supportability reviews
E.4.1 O
software systems
1.2.4.1,
1.2.4.2, 3.42, Fig 14;
Sss 3.9, 3.10
software testing
(see testing)
software transition
3.44
software transition piannino, Software Transition Plan

software
Foreword-4,

3.33
1.2.1,
software development environment
1.2.2, 4.1, FIg 1,
5.2, 5.14.1, Fig 2, Fig 3, E,4,1O, Fig 9-13;
SDP 5.2
(also see software engineerin~
environment, testing - software test environment)
software development files [SDF) 3.34, 5.2.4, 5.7.2,
5.7.4, 5.7.5, 5.8.1, 5.8.3, 5.8.4, 5.9.4, 5.9,6,
5.10.1,
5.10.3, 5.10.4, 5,11.4, 5.11.6, FIg 3,
Fi~ 6; SDP 5.2.4
software development library (SDL) 3.35, 5.2.3, FiQ 3;
SDP 5.2.3
software development methods
Foreword-5, 4,2.1;
SDP 4,2.1
software development planning, Software Development
Ptan (SDP}
1.2.4.2, 4.1, 5.1.1, 5.14.2, 5.16.1,
5.16.2,
5.17.1, 5.17.2, 5.19.1, 5.19,2, 5.19.7,
6.2, Fi9 2, B.3, Fig 4, Fig 6, D.4.7, E.4.1,
Fig 9-13, G.6.3, H.4, Fig 15-17; SDP
software development process
3.36, 4.1, Fig 1, 5.19.1,
5.19.2,
5.19.7, 6.5, Fig 2, Appandix G, H.4
software engineering environment
1.2.2, 3.37, 3.38,
4.2,7, 5.2.1, 5.2.3, Fig 13; SDP 5.2.1;
CPM 3
software implementation and unit testing
4.1, Fig 1,
5.7, 5.9.1, 5.11.1, Fig 3, Fig 6, Fig 9-12, FIg 14;
SDP 5.7
Software input/Output Manual (SIOM]
5.12.3.2,
6.2,
Fig 6, Fig 9-12, Fig 15, Fig 17; SIOM
(also see
Software Center Operator Manual, Software User
Manual)
software installation planning, Software krstallation Plan

(STrPl Fig 1, 5.1.5, 6.2, Fig 4, Fig 6, E.4.1,


FiO 9-12, Fig 15-17;
SDP 5.1.5;
STrP
software transition (preparing for) 4.1, Fig 1, 5.13,
Fig 3, Fig 9-12; SDP 5.13
software unit 3.24, 3.45, 5.2.4, 5.6, 5.7, 5.8, 5.13.4,
5.14.1, B.4, Fig 3, Fig 6, F.3, G.6.4, Fig 14,
Fig 15, Fig 17; DBDD 5, 5.x, 6; SDD 3, 4.1, 4.2,
4.3, 4.3.1, 5, 5.x, 6; SPS 5.4, 6; SRS 3.12
(also see testing)
software use (preparing for) 4.1, Fig 1, 5.12, Fig 3,
Fig 9-12
software usability reviews
E.4.9
Software User Manual (SUM)
5,12.3, 5.12.3.1,
6.2,
Fig 2, Fig 3, Fig 4, Fig 6, E.4.9, Fig 9-12, Fig 1517; SDP 5.12.3;
SIP 3.5, 4.x.6, 5.x.2, 5.x.3;
STrP 3.2-3.4;
SUM
(also see Software Center
Operator Manual, Software Input/Output Manuat)
Software Version Description U3VD) 5.12.2,
5.13.3,
6.2, Fig 3, Fig 6, D.4.1, E.4.9, E.4.1O, Fig 9-12,
Fig 16, Fig 17; SDF 5,12.2, 5.13.3;
SVD
{also
see version/revision/release)
source code, source files 3.29, 5.7.1, 5.12.1, 5.13.2,

(SIP) 5.1.4, 6.2, Fig 4, Fig 6, E.4.1, Fig 9-13,


Fig 15, Fig 17; SDP 5.1.4;
SIP
software maintenance
(see software support)
software management indicators
Foreword-3, 5.19.2,
Fig 2, Appandix F, Fig 9-12; SDP 5.19.2
software plan reviews
E.4. 1
software products
1.2.1, 3.16, 3.26, 3.31, 3.39, et al

{also see standards for software products)


software product evaluation 4.1, Fig 1, 5,15, 5.16.1,
Fig 2, Fig 3, Appandix D, Fig 6, Fig 9-12;
SDP 5.15
independence

in software

product evaluation

5.15.3;
SDP 5.15.3
in-process and final software product evaluations
5.15.1;
SDP 5.15.1
software product evaluation criteria
5,15.1, 5.18.1,
Fig 6, 0.4; SDP 5.15.1
software product evaluation records
5,15.2;
SDP 5.15.2
software products subject to evaluation
D.3, Fig 6
Software Product Specification {SPS) 5.12.1, 5.13.1,
5.13.2,
5.13.4, 5.13.6, 6.2, Fig 6, E.4.1O, Fig 912, Fig 15-17;
SPS
software quality
3.40
software quality assurance
4.1, Fig 1, 5.16, Flg 2,
Flg 3, Fig 9-12; SDP 5,16

5.13.4,
5.13.2;
dehvery of
staffing
F,3,
SIP 3.5,
standardization

B.3, Fig 3, Fig 4, Fig 6, F.3; SDP 5.7.1,


SPS 3.2, 3.3, 5.1; SVD 3.2
source files SPS 3.2
Fig 8; OCD 3.4, 5.4, 7.2; SDP 7;
3.6, 4.x.4;
STP 3.x.6, 3.x.7;
STrP 3.5
documents related to MIL-STD-498
Fig 2

65
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

MIL-STD-498
INDEX
standards Ior software products
4.2.2, SDP 4.2.2;
SPS 5.3
{also see code standards, software
design standards)
states and modes of operatton
COM 3.2; DBDD 3, 4,
5; IDD 3; IRS 3; OCD 3.3, 5,3, 6, 7.1, 7.2;
SCOM 3.5; SDD 3, 4, 5; SIOM 3.5; SRS 3.1;
SSDD 3, 4; SSS 3.1; SUM 3.5
Statement of Work (SOW)
1.2.1, 6.5, 6.7, Fi9 6,
D.4.5, D.4.1O, G.6,3
subcontractor, subcontractor management
Foreword-4,
1.2.?, 3.5, 4.2.7, 5.4.1, 5.19.4;
SDP 4.2.7,
5.19.4
subsystem
1.2,4.1,
5.2.4, 6.3.3, E.4.3, E.4.4; SSDD;
SSS (also see system/subs@ em)
support (of software)
(see software support, softvvare
transition planning)
system
(also see operational concept)
interpretation of system in MIL-STD-498
1.2.4,1,
Fig 14
system architectural design
3.4, 5.4.2, Fig 3, Fig 4,
Fig 6, E.4.4; SDP 5.4.2, 5.13.5;
SSDD 4
system design
3.17, 4.1, Fig 1, 5.4, 5.13.5, Fig 3,
Fig 4, E.4.4, Fig 9-12; SDP 5.4, 5.13.5
system Qualification testing
3.28, 3.43, 4.1, Fig 1,
5.1.3, 5.2.2, 5.11, 5.11.5,
Fig 3, Fig 6, E.4.7,
E.4.8, Fig 9-13; IRS 4; SDP 5.11; SSS 4;
8TD; STP; STR
system requirements 5.3.3, 5.4.2, 5.5, 5.11.3, Fig 3,
Fig 4, Fig 6; DBDD 3, 4, 6; IDD 4; SDP 5.3.3;
SSDD 3, 4, 4.1, 5; STD 4.x.Y.1, 5; STP 6
(also see Interface Requirements Specification,
System/Subsystem
Specification)
system requirements analysis
4.1, Fig 1, 5.3, Fig 3,
Fig 9-12; SDP 5.3
system test planning
5.1.3;
STP
system-wide design decisions 3.6, 5.4.1, 5.10.1,
Fig 3, Fig 6, E.4.4; SDP 5.4.1;
SSDD 3, 4.1
System/Subsystem
Design Description ISSDD)
5.4.1, 5.4.2, 5.13.5, 5.13.6, 6.2, Fig 6,
Fig 9-12, Fig 15-17;
SSDD
system/subsystem
design reviews
E.4.4
systemlsubsystem
requirements reviews
E.4.3
System/Subsystem
Specification {SSS) 5.3.3, 5.11,
6.2, Fig 6, Fig 9.12, Fig 15-17;
SSS

developer-internal testing
3.34, 5.4.1, 5.8, 5.9,
5.10, 5.11; SDP 5.9.4, 5.11.4
dry run of quallflcatlon testing 5.9.4, 5.11.4, Fig 6,
D.4.2
revision and retesting
5.7.4, 5.8.3, 5.9.6, 5.10.3,
5.11.6;
SDP 5.7.4, 5.8.3, 5.9.6, 5.10.3
5.1 1.6; STD 4.x.y.3, 4.x.y.5;
STP4.1 .3, 5
Software Test Description (STD} 5.9.3, 5.11.3, 6.2,
Fig 2, FIg 4, Flg 6, D.4.2, E,4.7, Fig 9-12,
Ftg 15-17; STD
software test environment
1.2.2, 3.37, 3.43, 4.2.7,
5.2.2, Flg 3, E.4.7, Fig 13; SDP 5.2.2;
STP
3; STR 3.2
software test planning, Software Test Plan (STP)
5.1.2, 5.1.3, 6.2, FIg 4, Fig 6, E,4.1, Fig 9-12,
Fig 15-17;
SDP 5.1.2, 5.1.3;
STP
Software Test Reporl (STR} 5.9.7, 5.11.7, 6.2,
Fig 4, Fig 6, D.4.2, E.4.8, Fig 9-12, Fig 15-17;
SOP 5.9.7, 5.1 1.7; STR
system qualification testing
3.28, 3.43, 4.1, Fig 1,
5.1.3, 5,2.2, 5.11, 5.11,5, Fig 3, Fig 6, E.4.7,
E.4.8, Fig 9-13; IRS 4; SOP 5.11; SSS 4;
STD; STP; STR
target computer system (testing on) 5.9.2, 5.1 1.2;
SOP 5.9.2, 5.11.2
test classes (timing, erroneous input, maximum
capacity)
STP 4.1.2, 4.2.x.Y
test information for developer-internal testing (test
cases, test descriptions, test procedures,
test results) 3.34, 3.39, 5.2.4, 5.7.2, 5.8.1,
5.10.1, Fig 2-4, Fig 6, 0.4.2
test readiness reviews
E.4.7
test results reviews
E.4.8
unit testing
5.7, Fig 3, F,3, Fig 9-12; SDP 5,7
unit integration and testing
4.1, Fig 1, 5.8, Fig 3,
F,3, Fig 9-12; SDP 5.8
witnessed testing
5.9.4, 5.1 1.4; STFf 5
traceability
5.4.2, 5.5, 5.6.2, 5.9.3, 5.11.3, 5.13.4;
DBDD 6; IDD 4; IRS 3, 5; SDD 6; SPS 5.4, 6;
SRS 3, 5; SSDD 5; SSS 3, 5; STD 4.x.Y.1, 5;
STP 4.2.x.y, 6
training
5.1.4, Fig 2, Fig 3; OCD 7.1, 7.2;
SIP 3.4, 3,5; SRS 3.14; SSS 3.14; STrP 5, 7
support agency training
5.13.7;
STrP 5, 7
user training
5.12.4;
SIP 3.4, 3.5; STP 3.x,8
transition (of software)
(see software transition)
translation
3.29, Fig 12

tailoring MIL-STD-498
and its DIDs Foreword-9, 1.2.2,
1.2.3, 5.12.1, 6.5, Fig 2, G.6, G.6.3, H.3, H.6;
all DIDs: 10.1.f
target computer system {testing on) 5.9.2, 5.1 1.2;
SDP 5.9.2, 5.11.2
testing
Fig 2, D.4. 13; STD; STP; STR
advance notice of qualification testing
5.9.3, 5.9.6,

unit, unit testing, unit integration and testing


software unit, testing)
user manuals
(see software user manuals)

version/revisionlre) ease
3.7, 5.14.1-5.14.3,
B.3;
all DIDs: 10.1 .c; DBDD 3, 5.x; FSM 3.x.4;
4.1, 4,3.1;
SDP 4.2.2, 5.17.1;
SIP 4.x.2;

5.11.3, 5.11.6
CSCUHWCI integration and testing
4.1, Fig 1, 5.10,
fig 3, Fig 6, Fig 9-12; SDP 5.10

CSCI qualification testing 3.28, 3.43, 4.1, Flg 1,


5.1.2, 5.2.2, 5.9, 5.9.5, Fig 3, Fig 6, E.4.7,
E.4.8, Fig 9-13; IRS 4; SDP 5.1.2,
SRS 4; STD; STP; STR

(see

SDD
SPS

5.2; SRS 3.3.1, 3.10.3; SSDD 4.1, 4.3.1; SSS


3.3.1, 3.10.3; STR 5; STrP 3.2-3.4; SVD

5.9;
Work Breakdown

Structure (WBS)

66
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

6.6, Fig 2

MIL-STD-498

Custodians:
Army - SC
Navy - EC
Air Force -10
DISA - DC
DLA - DH

Preparing
Navy
(Project

Activity:
- EC

IPSC-0230)

Review Activities:
OSD - SO, IR, NT
Army - AR, CR, Ml, AV
Navy - AS, SH, SA, TD, OM, MC
Air Force-02,06,
11, 13, 17, 19
DMA - MP
DNA - DS
NSA - NS

Civil Agency coordinating


NASA - NA
DOT - FAA, USCG
COM - NIST
CIA

activities:

Other DoD activities:


DSMC
SEI
Agencies other than US Government:
DND Canada
MoD Germany
MoD UK
US Industry - CODSIA

67
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

STANDARDIZATIC)N

DOCUMENT

IMPROVEMENT

PROPOSAL

INSTRUCTIONS
1. The preparing activity must complete blocks 1, 2, 3, and 8. In block 1, both the document number and revision
letter should be ghran.
2. The submitter of this form must complete blocks 4, 5, 6, and 7.
3.

The preparing activity must provide a reply within 30 days from receipt of the form.

NOTE: This form may not be used to request copies of documents, nor to request waivers, or clarification of
requirements on current contracts.
Commants submitted on this form do not constitute or imply authorization
wahre any portion of the referenced document(s) or to amend cent ractual requirements.

! RECOMMEND A CHANGE:

11~

2.~t

to

( W~DD)
W 1205

MIL-STD498

. DOCUMENT TITLE

Software
dentrfy

peregreph

number

Development

end tnclude

proposed

and Documentation
rewrmr,

If possible.

Attech

exrra sheets

os needed.

::y.:x,
:::::::
! ::::
;::::::.,:::

..... .....

. . .. .. .. .
:,:,,,.,..,,,,.,,: .
.. .
.
.
,,:,., ,. : ,, : ,.,

;.,::
,.,.,::,:,
,,,,

PfiEPARINGACTIVITY

NAME
1

lb. TELEPHONE //nc/ude

Space & Naval Warfare Systems Command

Area

] (1) Commercial

Code)

(2) AUTOVON

(703}602-4491
f
1

\60RESS (Include Zrp Code)


SPAWAR 10-12
2451

I
i

Crystal Drivo ICPK-5)

Adington. VA 22245 -52oo

OCT 89

3324491

IF YOU DO NOT RECEIVEA REPLY WITHIN 45 DAYS, CONTACT:


Defense

5203

Quahty and Standardization

Leesburg Pike, Suite 1403,

Telephone (703)756-2340
Previous odtiorn
e obsolete 2016-03-31T14:47Z
Source: https://assist.dla.mil
-- Downloaded:
Check the source to verify that this is the current version before use.

Office

Falls Church, VA 22041-3466

AUTOVON

289.2340

10SDSO

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Data Item

Descriptions

(DIDs)

for
MIL-STD-498

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Form Approved

DATA ITEM DESCRIPTION


PubI,c ,.pw,,rq

bwtin

SOWCD8, OWVrIIW

ot mm cotlutIon
HIohwtv,

.Swo

to,

cokc,,nn

of wdomIMw-I.
1204,

momtmmq

,tm.

tntwm.t,m

WV d.t.

madad

Itwl~Iq

.g~imm

la

ArlIIwIon, VA 22202-4302,

COMPUTER

I,rn.td

v.rq

to

and cornvk9tItxI d

!ductrq

110 how,

WVNW8W

ww bu-

tO !Fu OffI- et Mrnq-onl

OPERATION

W, ,ow,

tlw colkctm.

to WmhIW

md

MANUAL

O&fB NO. 0704-0188


,nclul,rIo

of mlmmwlon

ton I+esdquutefo
P@wwofk

Bdoot,

ltw !,nn Iw ,.v~w,w

%nd

,mt, ucl,mu.

Conwrmnts rq!b?d,q

!Arvtcw,

DIIcctotmQ

Raducl,on

Propel

O( OMI W$WU ud

(0704.01

WCIUW

VW bweon a.ttmm.
fwPo$is,

88), WmhIrgtnn

(COM)

12

.,m,rg

d.,.

o+ my otrm

-cl

\ & hfhmm

Dw18

, DC 20603

DI-IPSC-81446

3. DESCRlP710N/P
URPOSE
3.1 The Computer Operation Manual (COM) provides information needed to operate a given computer and
its peripheral equipment, This manual focuses on the computer itself, not on particular software that will
I
run
on the computer.

3.2 The COM is intended for newly developed computers, special-purpose


for which commercial or other operation manuals are not readily available.

APPROVAL
DATE
941205
~
APPUC~ON/lN~

d
4.
-

7,1

generated

or other computers

6a. DTIC APPLICABLE

EC

Bb. GIDEP APPLICABLE

This Data Item Description

product
I
7.2

OFFICE OF PRIMARY RESPONSIBILITY

computers,

by specific

(DID) contains
and discrete

This DID is used when the developer

(
computer(s)
on which software

the format

and content

task requirements

preparation

as delineated

instructions

for the data

in the contract,

is tasked to identify and record information

needed to operate the

will run.

List {CDRL) (DD 1423) should specify whether deliverable data are to
1
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
7,3

The Contract Data Requirements

(
(CASEI
or other automated tool rather than in the form of a traditional document.
i
7.4
This DID supersedes DI-MCCR-80018A

and DI-MCCR-80316.

?
8.

APPROVAL
UMITATION
Litited ApprovaJirom 1215/94through12/5/96
i O. PREPARATION
INSTRUCTION
s

98. APPLICABLE
FORMS

9b. AMSCNUMBER
N7089

1
10.1
Genera! instru ctions.

a. Automated tec hniaue~,

Use of automated techniques is encouraged.

The term document

in this

DID means a collection of data regardless of its medium,


b.

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

(Continued on Page 2)
iii. DISTRIBUTION sTATEMENT
r?l~TRIBUTION

STATEMENT

1,
.-.
---.-.Dtl Form 1664, APR 89

A.

Approved

for public release;


Previous

editions

are

distribution

is unlimited.

obsolete

1)5/123

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page J_ of ~

Pages

Computer

10.

PREPARATION

INSTRUCTIONS

Operation Manual
DI-IPSC-8 1446

(COM)

-- 10.1 General Instructions

(continued)

c.

Title
The document
shall include a title page containing,
as
e or ide ntifier.
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
For data in a database or other alternative
organization;
and distribution
statement.
form, this information
shall be included on external and internal labels or by equivalent
identification
methods.

d.

Table of contents 8nd index. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing an alphabetic listing of key terms and concepts covered in the
document and the pages or paragraphs in which the terms or concepts are covered.
For data in a database or other alternative
form, this information
shall 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.

Paae numbe rina/lab


document number,
database or other
names or numbers

f.

cling. Each page shall contain a unique page number and display the
including version, volume, and date, as applicable.
For data in a
alternative
form, files, screens, or other entities shall be assigned
in such a way that desired data can be indexed and accessed.

onse to ta ilorina
resulting

document

instruct ions.

shall contain

If a paragraph

the corresponding

is tailored

paragraph

out of this

number

DID, the

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

MultiDie DWMIrFiDhS and subDa raciraDh~,


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

h.

If a data description
required by this DID has been
Zta ndard data desc ri Dt ions.
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,

stitut ion of existina docu men~.


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

may be

iremen
. Content requirements
10.2
begin on the following
page.
The
c~ ntent r
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Computer

10.

1.

PREPARATION
SCODQ.

INSTRUCTIONS

This section

Operation Manual
DI-IPSC-81446
-- 10.2

shall be divided

Content

(COM)

Requirements

into the following

(continued)

paragraphs,

name, model number, and


1.1 ~
ificat ion. This paragraph shall contain the manufacturers
any other identifying
information
for the computer system to which this COM applies.
1.2 ~omtwter
svste m Ove rview,
This paragraph
computer system to which this COM applies.
1.3 Docu ment overview.
manual and shall describe

shall

briefly

state

the

purpose

of the

This paragraph shall summarize the purpose and contents of thk


any security or privacy considerations
associated with its use.

2. Referenced docu ment$. This section shall list the number, title, revision, and date of all
This section shall also identify the source for all
documents
referenced
in this manual.
documents not available through normal Government
stocking activities.
paragraphs.
3. SomDute
svste m OD eration. This section shall be divided into the following
Safety preca~tions,
marked by WARNING or CAUTION, shall be included where applicable.
3.1 Qmcmter
system meD aration
following subparagraphs.

and shutd own.

Power on and off.


This paragraph
3.1.1
power-on and power-off the computer system.

shall

This paragraph

contain

the

shall be divided

procedures

into the

necessary

to

3.1.2
Initiation. This paragraph shall contain the procedures necessary to initiate operation
as applicable,
equipment
setup,
pre-operation,
of the computer
system,
including,
bootstrapping,
and commands typically used during computer system initiation.
3.1.3
shutdown.
This paragraph
computer system operation,

shall contain

the procedures

necessary

to terminate

3.2 QDeratina Drocedur~,


This paragraph shall be divided into the following subparagraphs.
If more than one mode of operation is available, instructions
for each mode shall be provided,
3.2.1
Irmut and outcmt mote dure~. This paragraph shall describe the input and output
media (e.g., magnetic disk, tape) relevant to the computer system, state the procedures to
read and write on these media, briefly describe the operating system control language, and
list procedures for interactive messages and replies (e,g, terminals to use, passwords,
keys).
This paragraph shall contain the procedures to be followed
3.2.2
Monitoring
mocedure~.
for monitoring
the computer
system in operation.
It shall describe available indicators,
interpretation
of those indicators,
and routine and special monitoring
procedures
to be
followed.
l) ff-[ine moced ure$. This paragraph shall contain the procedures
3.2.3
all relevant off-line equipment of the computer system.

necessary

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

to operate

Computer

10.

INSTRUCTIONS

PREPARATION

Operation Manual
DI-IPSC-81446
-- 10.2

Content

(COM)

Requirements

(continued)

This paragraph shall contain any additional


procedures to be
Qther mocedur~.
3.2.4
followed by the operator (e. g., computer system alarms, computer system security or privacy
considerations,
switch over to a redundant computer system, or other measures to ensure
continuity
of operations in the event of emergencies).
3.3 Problem-handlina
procedures.
This paragraph shall identify problems that may occur in
any step of operation described in the preceding paragraphs in Section 3. It shall state the
error messages or other indications
accompanying
those problems and shall describe the
automatic and manual procedures to be followed for each occurrence, including, as applicable,
evaluation techniques, conditions requiring computer system shutdown, procedures for on-line
intervention
or abort, steps to be taken to restart computer system operation after an abort
or interruption
of operation,
and procedures
for recording
information
concerning
a
malfunction.
4. ~iaanost ic features.
This section shall be divided into the following
paragraphs to
describe diagnostics that may be performed to identify and troubleshoot
malfunctions
in the
computer system.
4.1 J?iaanostic features su mmarv.
This paragraph shall summarize the diagnostic features
of the computer system, including error message syntax and hierarchy for fault isolation. This
paragraph shall describe the purpose of each diagnostic feature.
4.2 Diagnostic mocedures.
This paragraph shall be divided into subparagraphs
as needed to
describe the diagnostic procedures to be followed for the computer system, including:
a.

Identification
procedure

of hardware,

b.

Step-by-step

c.

Diagnostic

instructions
messages

software,

for executing

or firmware

necessary

for executing

each

each procedure

and the corresponding

required

action

This paragraph shall be divided into subparagraphs


as needed to
4.3 piacmostic
tools.
system.
These tools may be
describe the diagnostics
tools available for the computer
hardware, software, or firmware.
This paragraph shall identify each tool by name and number
and shall describe the tool and its application.
5. -.
This section shall contain any general information that aids in understanding
this
document (e.g., background information,
glossary, rationale].
This section shall include an
alphabetical
listing of all acronyms, abbreviations,
and their meanings as used in this document and a list of terms and definitions
needed to understand this document.
Appendixes
may be used to provide information
published separately for
endixe~.
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.).
A.

ADD

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Form Approved

DATA ITEM DESCRIPTION


PubI,c r.p.rt,~
sowcu,
of thn

gmtvn~
cdbctmo

Htghtv.y,

S@.

bwd.n
d

te

cekaton

mwnmm~

of Wntmarmn.

!204,

ef ttu. ,nlem.t,cm
ttv

data nndd

Inchd!m

Arl#w1en,

- mttm.1.d

~Iiam

h!

VA 22202-4302,

ti

to wuw

compbt~

Md

ruruc~

ttw

to l+w Ofhc,

OMB

110 howo WI r~,

r*vmw4rql
budon

tlu

cohcmn

to W&n~Ion

at Muiqcwmm

mcludww tlu vmm fot tavIOwIW

of mbrmmmn

t+eadqumoro

ond Buleol

6mul Camlnam*

6.WICN

Pm.rwM4

%ducuo.

DItocIormo

Iwvdlw

lb

Prowct f0704~l@81,

NO. 0704-0188
-chq

&*

of Opmowtu

TITLE

1.

emtmct,om,

.xmtn-g

ammm

Pwpats.

Wtiwtm

0, Uly

1216

dtia
Mtm

Jdt.r.m

OCt

Dsbw

. OC 20603

2. IDENOTIFICATIONN~

COMPUTER

PROGRAMMING

MANUAL

(CPM)

DI-IPSC-81447

I
3.

DESCRIPTIOIWWRPOBE

3.1 The Computer Programming Manual {CPM) provides information needed by a programmer to
understand how to program a given computer. This manual focuses on the computer itself, not on
particular software that will run on the computer.
3.2 The CPM is intended for newly developed computers, special-purpose computers,
for which commercial or other programming manuals are not readily available.

OFFICE OF PRIMARY RESPONSIBILITY

or other computers

6-. DTIC APPLICABLE

EC

Sb. GIDEP APPLICABLE


I

SHIP

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

for the data

7.2 This DID is used when the developer is tasked to identify and record information needed to program the
computer(s) on which software was developed or on which it will run,
7.3 The Contract Data Requirements List (CDRL) (DD 1423) should specify whether deliverable data are to
be delivered on pBper or electronic media; are to be in a given electronic form (such as ASCII, CALS, or
compatible with a specified word processor or other suppon software); may be delivered in developer

format rather than in the format specified herein; and may reside in a computer-aided
(CASE) or other automated tool rather than in the form of a traditional document.
7,4

This DID supersedes DI-MCCR-80021

A.

UM ITATION
8. APPROVAL

Sat APPLICABLEFORMS

Limited Approvel from 12/S/S4

software engineering

through 12/5/96

9b. AMSC NUMBER

N7090

10.1 Ge neral instruct ion$.


a. Automated tec hniaue$. Use of automated techniques is encouraged.
DID means a collection of data regardless of its medium.
b. Alternate mesentation
acceptable

stvles.

substitutes

The term document

Diagrams, tables, matrices, and other presentation

in this

styles are

for text when data required by this DID can be made more readable

using

these styles.
(Continued on page 2)
11.DISTRIBUTION STATEMENT
{ CNSTRIBUTION STATEMENT
WI Form 1664, APR 89

A.

Approved

for public release; distribution


Previous

editions

are

is unlimited.

obsolete

135/123

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page J_ 01 ~

Pages

Computer

10.
c.

PREPARATION

INSTRUCTIONS

Programming
Manual
DI-IPSC-81447

-- 10.1 General Instructions

or identf~.
I
Title D~
The document
shall
applicable:
document
number; volume number;
markings or other restrictions
on the handling of
name, abbreviation,
and any other identifier for
which the document applies; contract
number;

which

the

organization;

document

has

and distribution

(CPM)

been

prepared;

statement.

form, this information


shall be included
identification
methods.

(continued)

include a title page containing,


as
version/revision
indicator;
security
the document; date; document title;
the system, subsystem,
or item to
CDRL

name

For data

on external

item

and

number;

address

organization
of

the

for

preparing

in a database or other alternative


and internal labels or by equivalent

d.

Table of contents and index. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing an alphabetic listing of key terms and concepts covered in the
document
and the pages or paragraphs in which the terms or concepts are covered.
For data in a database or other alternative
form, this information
shall 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.

me
numbe rina/labelin~.
Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Rest)onse to ta ilorina instruct ions.


If a paragraph is tailored out of this DID, the
resultrng document shall contain the corresponding
paragraph num ber and title, f ollowed
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.

9.

Any section, paragraph, or subparagraph in


Multide
Daraara~hs and SU brlaraarar)hs.
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description
required by this DID has been
Sta ndard dat a desc riMionS.
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.

Commercial or other existing documents


Subst itut ion of existina doc ument~.
substituted
for all or part of the document if they contain the required data.

maybe

10.2
Conte nt reau iremen~.
Content requirements
begin on the following
page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Computer

PREPARATION

10.

1.

a.

INSTRUCTIONS

This section

Programming
Manual
DI-IPSC-81447
-- 10.2

shall be divided

Content

(CPM)

Requirements

into the following

(continued)

paragraphs,

1.1 Identific ation. This paragraph shall contain the manufacturers


name, model number, and
applies.
any other identifying
information
for the computer system to which this document
1.2 ~omr)uter
svstern overview.
This paragraph
computer system to which this document applies.
1.3 Pocument overview.
manual and shall describe
2.

Referenced

referenced

documents

not available

This section

in this

shall list the number,

manual.

through

This

normal

The components

b.

Operating
1)
2)
3)
4)
5)
6)
7)
8)
9)
1O)

c.

and configuration

characteristics,

shall

state

the purpose

of the computer
and limitations,

Machine cycle time


Word length
Memory capacity and characteristics
Instruction
set characteristics
Interrupt capabilities
Modes of operation (e.g., batch, interactive,
Operational registers
Error indicators
input/output
characteristics
Special features

title, revision,

also

stocking

shall be divided

capabilities,

of the

identify

the

and date of all


source

for all

activities.

into paragraphs

as appropriate

system
including,

privileged,

as applicable:

non-privileged)

Description
of the equipment
(e.g., tapes, disks, other peripheral
equipment)
necessary to perform compilations
and assemblies on the computer system. Identify
(as applicable) by name and version number the editor, linker, link-editor,
compiler,
assembler, cross-compilers,
cross-assemblers,
and other utilities used, and reference
appropriate manuals describing their use, Highlight any special flags or instructions
necessary for loading, executing, or recording the results.

4. =mmina
information,
This section
provide the following
information.
a.

section

Government

environment.
This section
3. ~arammina
to provide the following
information.
a.

briefly

This paragraph shall summarize the purpose and contents of this


any security or privacy considerations
associated with its use.

docu men~.

documents

shall

Description
of the programming
ture, including, as applicable:
1)
2)

3)
4)

shall be divided into paragraphs

features

of the computers

as appropriate

instruction

to

set architec-

Data representation
(e.g., byte, word, integer, fioating-point,
double precision)
Instruction
formats and addressing modes
Special registers and words (e.g., stack pointer, program counter)
Control instructions
(e.g,, branch, jump, subroutine and procedure call instructions,

privileged

instructions,

and the modes

they operate

in)

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Computer

10.

PREPARATION

b.

-- 10.2

Content

(CPM)

Requirements

(continued)

5)

Subroutines and procedures {e.g., non-reentrant,


argument lists, parameter passing conventions)

6)
7)
8)
9)

Interrupt processing
Timers and clocks
Memory protection
features (e.g., read-only memory)
Additional features, such as instruction
or data cache architecture

Description
1)
2)
3)
4)
5)
6)
7)

c.

INSTRUCTIONS

Programming
Manual
DI-IPSC-81447

including,

macrocode

routinesl

as applicable:

Use
Syntax
Condition codes set
Execution time
Machine-code
format
Mnemonic conventions
Other characteristics

Description
1)
2)
3)
4)
5)

of each instruction,

reentrant,

of input and output

control

programming,

including,

Initial loading and verification


of computer memory
Serial and parallel data channels
Discrete inputs and outputs
Interface components
Device numbers,
operational
codes, and memory
equipment

as applicable:

locations

for

peripheral

d.

with the
Additional,
restricted,
or special programming
techniques
associated
computer system (e.g., a concise description
of the microprogram
control section)

e.

Examples
examples

f.

Error detection
and diagnostic
features associated
with the computer
system,
including condition codes, overflow and addressing exception interrupts,
and input
and output error status indicators

that demonstrate
the programming
features described above, including
of the proper use of all categories of instructions
on the computer system

5. Notes. This section shall contain any general information


that aids in understanding
this
document (e.g., background
information,
glossary, rationale).
This section shall include an
alphabetical
listing of all acronyms,
abbreviations,
and their meanings as used in this
document and a list of terms and definitions
needed to understand this document.
A. ~ndixe$,
Appendixes
may be used to provide information
published separately for
convenience
in document maintenance
(e.g., charts, classified data).
As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided.
Appendixes may be bound as separate documents for ease in handling.
Appendixes
shall be lettered alphabetically
(A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Ap#vo
fbrrrl

DATA ITEM DESCRIPTION


Ptili,c ,apm,~
sowca.

budm-1 IO( Celkwct,on d

oathrrIq

ud

of !lno cdkctmn

Wghway,

Sut.

maWmmr@

of Mo?mstkm.

1204,

Adw@m,

!Fm Inhwnowan

th8 dma
WIClulhg

m.dad

uxl

~Iem

VA 22202

* al,mal,d
comrIIcIIrw
tot ?odwtmj

<302,

IO wu OffIa

10 vml~
d
tht

110

rWIWWWW
budm

houo pa rwOln4,

tlm COWCIW!

to WD!WQIWI

of M~ornmt

vod

(2MB NO.0704-0188
d

lncldfl-q

Wmmmmn

Meuul.m

md Lhdgcl,

tiv
SW@

SOWICN,

Pqrwork

%4ctmn

tmlg fm ,.wmw,rq

Wut,ucttom

chq

..w~

dbt.

curwunw

fqudl~

Dmctaac

of OPWMWB uw RqJorts, 1216 Jottarson D8VN

I+qm!

ww budm

!O7O4-O1OBI,

aummb

WnFUWfm

en my

ohu

DP@t

, DC 20603

2. I-CATION

DATABASE

DESIGN

DESCRIPTION

(DBDD]

DI-IPSC-81437

3.1 The Database Design Description (DBDD] describes the design of a database, that is, a collection of
related data stored in one or more computerized files in a manner that can be accessed by users or
computer programs via a database management system (DBMS), It can also describe the software units
used to access or manipulate the data.
3.2 The DBDD is used as the basis for implementing
the acquirer

visibility

into the design

and provides

the database and related

information

needed

4. APPROVAL DATE
6. OFFICE OF PRIMARY RESPONSIBILITY
~
941205
EC
I
APPLICATION/lNTERRIZATIONSHIP

software

for software

units,

It provides

support.

6a. DTIC APPLICABLE

6b . GiDEP APPUCABLE
I

7.1 This Data Item Description (DID) contains the format and content preparation instructions for the data
product generated by specific and discrete task re~uirements as delineated in the contract,
7.2 This DID is used when the developer is tasked to define and record the design of one or more
databases.
7,3 Software units that access or manipulate the database may be described here or in Software Design
Descriptions (SDDS) (D14PSC-8 1435).
Interfaces may be described here or in Interface Design Descriptions

[IDDs) (DI-IPSC-81 4361.


7.4 The Contract Data Requirements List (CDRL) (DD 1423) 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
:ompatible 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
ICASE) or other automated tool rather than in the form of a traditional document.
7.5

This DID supersedes DI-IPSC-80692

and DI-MCCR-80305.

~ APPROVALLIMITATION
Limited Approval from 1215194 through 12151B6

n.

PR~oNs

lo,:i

%.

APPLICABLE FORMS

Bb. AMSC NUMBER

N7080

Ge neral instru ction$.

a.

Automated techniaue~.
Use of automated techniques is encouraged.
DID means a collection of data regardless of its medium.

b.

Alternate twes entation stvles, Diagrams, tables, matrices, and other presentation styles are
acceptable substitutes for text when data required by this DID can be made more readable using

The term document

in this

these styles.
.
11.

(Continued on Page 2)
131STR(BUTKINSTATEMENT

71SYFl181JT10N

sT#lTEhrlENT

/4.

Approved

for public release;

distribution

is unlimited.

l=...

DD Fwm 1664, APR 89

Previous

editions

are

obsolete

135/123

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page .1 of &

Pages

Database

10.

PREPARATION

INSTRUCTIONS

Design Description
D1-IPSC-81437
-- 10.1

(DBDD)

General Instructions

(continued)

c.

The document
shall include a title page containing,
as
Title
e or id entifier.
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
name and address of the preparing
which
the document
has been prepared;
For data in a database or other alternative
organization;
and distribution
statement.
form, this information
shall be included on external and internal labels or by equivalent
identification
methods.

d.

The document
shall contain a table of contents
providing the
Tab Ie of conten~.
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative
form, this information
shall 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.

&ge numbe rina/la beling. Each page shall contain a


document number, including version, volume, and
database or other alternative
form, files, screens,
names or numbers in such a way that desired data

f.

~onse
to t ailorirm instru ction~.
If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

and subDa raar aD h~.


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

h.

required by this DID has been


[f a data description
Sta ndard data desc riotion~,
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.

Subst itut ion of existirw doc ument~. Commercial or other existing documents
substituted
for all or part of the document if they contain the required data.

unique page number and display the


date, as applicable.
For data in a
or other entities shall be assigned
can be indexed and accessed.

may be

10.2
Content requirements
begin on the following
page.
The
co ntent rem irement~.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Database

10.
1.

PREPARATION
-.

INSTRUCTIONS

This section

Design Description
DI-IPSC-81 437
-- 10.2

shall be divided

Required

(DBDD)

Content

into the following

(continued)

paragraphs.

of the database
1.1 Mentificat ion. This paragraph shall contain a full identification
this
document
applies,
including,
as applicable,
identification
number(s),
abbreviation(s),
version number(s), and release number(s).

to which
title(s),

1.2 Database o verview.


This paragraph shall briefly state the purpose of the database to
which this document applies. It shall describe the general nature of the database; summarize
the history of its development,
use, and maintenance;
identify the project sponsor, acquirer,
user, developer, and support agencies; identify current and planned operating sites; and list
other relevant documents.
1.3 DOCUment o verview.
This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations
associated with its use.
2. Referenced do cumenw.
This section shall list the number, title, revision, and date of ail
This section shall also identify the source for all
documents
referenced
in this manual.
documents not available through normal Government
stocking activities.
ign
isions. This section shall be divided into paragraphs as needed
3. ~
to present database-wide
design decisions, that is, decisions about the databases behavioral
design (how it will behave, from a users point of view, in meeting its requirements,
ignoring
internal implementation)
and other decisions affecting further design of the database.
If all
such decisions are explicit in the system or CSCI requirements,
this section shall so state.
Design decisions that respond to requirements
designated critical, such as those for safety,
security, or privacy, shall be placed in separate subparagraphs.
If a design decision depends
upon system states or modes, this dependency shall be indicated.
If some or all of the design
decisions
are described
in the documentation
of a custom
or commercial
database
management system (DBMS), they may be referenced from this section.
Design conventions
needed to understand the design shall be presented or referenced.
Examples of database-wide
design decisions are the following:
a.

Design decisions regarding queries or other inputs the database will accept and
outputs
(displays, reports, messages, responses,
etc. ) it will produce, including
interfaces with other systems, HWCIS, CSCIS, and users (5.x.d 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 database behavior in response to each input or query, including


response
actions,
times
and
other
performance
characteristics,
selected
equations/algorithms/rules,
disposition,
and handling of unallowed inputs

c.

files will appear


Design decisions on how databases/data
identifies topics to be considered in this description)

d.

Design decisions on the database management


system to be used (including name,
version/release)
and the type of flexibility to be built into the database for adapting
to changing

to

the user (4.x of this DID

requirements

Page &

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

of &

Database

10.

PREPARATION

Design Description
DI-IPSC-81437
10.2

INSTRUCTIONS--

Required

(DBDD)

Content

(continued)

e,

Design decisions
on the levels and types of availability,
continuity
of operations to be offered by the database

f.

Design decisions on database distribution (such as client/server),


master database file
including
maintaining
consistency,
establishing/
reupdates
and maintenance,
establishing and maintaining
synchronization,
enforcing integrity and business rules

9.

Design decisions
strategies,

considerations
h.

Design

on backup

permissible

and restoration

actions

for new

including

during

or non-standard

backup

technologies

security,

privacy,

data and process

and

restoration,

and

distribution
and

special

such as video and sound

on repacking,
sorting, indexing, synchronization,
and consistency
automated
disk management
and space reclamation
considerations,
storage and size considerations,
and
strategies
and considerations,
of the database and capture of legacy data

decisions

including
optimizing
population

This section shall be divided into paragraphs as needed


4. Pets il ed des ion of the dat-.
The number of levels of design and the
to describe the detailed design of the database.
names of those levels shall be based on the design methodology
used. Examples of database
design levels include conceptual,
internal, logical, and physical.
If part or all of the design
Design
depends upon system states or modes, this dependency
shall be indicated.
conventions
needed to understand the design shall be presented or referenced.
Note:
This DID uses the term data element assembly to mean any entity, relation,
schema, field, table, array, etc., that has structure
(number/order/grouping
of data
elements) at a given design level (e,g., conceptual, internal, logical, physical) and the term
data element to mean any relation, attribute, field, cell, data element, etc. that does
not have structure at that level.
4.x jhlame of data base des ian level~, This paragraph shall identify a database design level
and shall describe the data elements and data element assemblies of the database in the
terminology
of the selected design method.
The information
shall include the following,
as
applicable, presented in any order suited to the information
to be provided:
a.

Characteristics
1)

Page ~

of individual

in the database

design,

such as:

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural-language)

c)

DoD standard

data element

d)

Technical

e)

Abbreviation

or synonymous

Data type (alphanumeric,

3)

Size and format

4)

Units

name

5)

Range or enumeration

6)

Accuracy

integer,

names
etc. )

(such as length and punctuation

of measurement

(how

name

name (e.g., field name in the database]

2)

of

data elements

correct)

(such

as meters,

dollars,

of a character

string)

nanoseconds)

of possible values (such as O-99)


and

precision

(number

of significant

AL
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

digits)

Database

10.

PREPARATION

b.

Design Description
DI-IPSC-81 437
10.2

INSTRUCTIONS--

7)

Priority,
whether

timing, frequency,
the data element

8)

Security

and privacy

9)

Sources

(setting/sending

(D8DD)

Required Content

volume, sequencing, and other constraints,


such as
may be updated and whether business rules apply

constraints
entities)

and recipients

Characteristics
of data element assemblies {records,
design,
such as:
reports, etc. ) in the database
1)

(continued)

(using/receiving
messages,

entities)

files, arrays, displays,

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural

c)

Technical

d)

Abbreviations

language)

name

name (e.g., record or data structure


or synonymous

in the assembly

name in code or database)

names

2)

Data elements

and their structure

3)

Medium

4)

Visual and auditory characteristics


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

5)

Relationships

6)

Priority,
whether

7)

Security

and privacy

8)

Sources

(setting/sending

(such as disk) and structure

among assemblies,

(number,

order, grouping)

of data elements/assemblies

such as sorting/access

on the medium

characteristics

timing, frequency, volume, sequencing, and other constraints,


such as
the assembly may be updated and whether business rules apply
constraints
entities)

and recipients

(using/receiving

entities)

il ed~es
ian of software units use d for database acce ss or manitw Iation. This section
5. Pe~a
shall be divided into the following
paragraphs to describe each software
unit used for
database access or manipulation.
If part or all of this information
is provided elsewhere, such
as in a Software
Design Description
(SDD), the SDD for a customized
DBMS, or the user
manual of a commercial DBMS, that information may be referenced rather than repeated here.
If part or all of the design depends upon system states or modes, this dependency shall 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 shall be presented or referenced,
5.x ~Proiect -uniaue id entifier of a software unit, or des ianator for a tvouD of software units~.
This paragraph shall identify a software unit by project-unique
identifier and shall describe the
unit. The description shall 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

b.

Any constraints,

c.

The programming
language
specified CSCI language

limitations,

or unusual

features

to be used, if not previously

selected

in the design of the software

to be used and rationale

unit

for its use if other than the

Page &
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

of&

Database

10.

PREPARATION
d.

Page &

-- 10,2

Required

(DBDD)

Content

(continued)

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 a reference to user
manuals

e.

INSTRUCTIONS

Design Description
DI-IPSC-81 437

or other

documents

that

explain

them

software unit contains, receives, or outputs data, a description of its inputs,


outputs, and other data elements and data element assemblies, as applicable.
Data
local to the software unit shall be described separately from data input to or output
from the software
unit.
Interface
characteristics
may be provided here or by
If a given interfacing
entity is not
referencing
Interface
Design Description(s).
an
external
system)
but
its interface
covered
by this DBDD (for example,
characteristics
need to be mentioned
to describe software
units that are, these
characteristics
shall be stated as assumptions
or as When [the entity not covered]
does this, [the software unit] will .... This paragraph may reference other documents
(such as data dictionaries,
standards for protocols, and standards for user interfaces)
shall include the
in place of stating the information
here. The design description
following,
as applicable,
presented in any order suited to the information
to be
provided, and shall note any differences
in these characteristics
from the point of
view of the interfacing
entities (such as different
expectations
about the size,
frequency,
or other characteristics
of data elements):
If the

1)

Project-unique

identifier

2)

Identification
of the interfacing
users, etc. ) by name, number,
applicable

entities (software
units, configuration
items,
references,
as
version, and documentation

3)

Priority

by the interfacing

4)

Type of interface (such as real-time


etc. ) to be implemented

5)

Characteristics
of individual data elements that the interfacing
entity (ies) will
provide, store, send, access, receive, etc. Paragraph 4.x.a of this DID identifies
topics to be covered in this description.

6)

Characteristics
of data element assemblies (records, messages, files, arrays,
displays, reports, etc. ) that the interfacing entity (ies) will provide, store, send,
access, receive, etc. Paragraph 4.x. b of this DID identifies topics to be covered
in this description.

7)

Characteristics
of communication
for the interface, such as:

assigned

a)

Project-unique

b)

Communication

for the interface

to the interface

data transfer,

entity (ies)
storage-and-retrieval

methods that the interfacing

of data,

entity (ies) will use

identifier(s)
links/bands/f

requencies/media

and their characteristics

of &

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Database

10.

PREPARATION

8)

9)

f.

Required

Content

(continued)

c)

Message

d)

Flow control

(such as sequence

e)

Data transfer
fers

rate, whether

f)

Routing,

g)

Transmission

h)

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

formatting

addressing,
services,

a)

Project-unique

b)

Priority/layer

c)

Packeting,

d)

Legality

e)

Synchronization,
tion

f)

Status,

numbering

and buffer

periodic/aperiodic,

and naming
including

Characteristics
of protocols
interface, such as:

that

allocation)

and interval

between

priority

and grade

the interfacing

user authenti-

entity (ies) will

use for

the

identifier(s)
of the protocol

including

checks,

fragmentation

error control,

and reassembly,

and recovery

including connection

identification,

routing,

and addressing

procedures

establishment,

and any other reporting

logic,

1)

Conditions

in effect

the software

2)

Conditions

under which

3)

Response and response time to each input, including


and data transfer operations

4)

Sequence
of operations
software units operation,

maintenance,

within

control

the logic

for sequence

to be used

is passed to other software

units

sequencing

The method

b)

The logic and input conditions


priority assignments

c)

Data transfer

d)

The sensing of discrete input signals, and timing


interrupt operations within the software unit

unit,

is initiated

data conversion,

controlled

entity (ies)

by the software

unit when its execution

and dynamically
including:

termina-

features

a)

Exception

trans-

conventions

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

Reau irements
a.

-- 10.2

(DBDD)

If the software
unit contains
including, as applicable:

5)
6.

INSTRUCTIONS

Design Description
DI-IPSC-81 437

renaming,
during

the

control
of that method,

such as timing

variations,

in and out of memory


relationships

between

and error handling

tracea bility.

This section

shall contain:

Traceability
from each database or other software
system or CSCI requirements
it addresses.

unit covered

by this DBDD to the

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Database

10.

PREPARATION

b.

10.2

INSTRUCTIONS--

Traceability

database
software

Design Description
DI-IPSC-81437

from

each

system

or other software
units that address

Required

or CSCI

unit covered
it.

(DBDD)

Content

(continued)

that has been allocated to a


DBDD to the database or other

requirement

in this

7. -.
This section shall contain any general information
that aids in understanding
this
document (e.g., background
information,
glossary, rationale).
This section shall 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. ADD endixes.
Appendixes
may be used to provide information
published separately for
convenience
in document
maintenance
(e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided.
Appendixes

Appendixes

shall be lettered

may be bound as separate

alphabetically

documents

(A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

for ease in handling.

Approved
Form

DATA ITEM DESCRIPTION


Pt&IIc rWWIaW
SOUNO

budm

VUIVWW

O?ttw

e-cum

(OI colioct,m
mmmmruq

e! hMwm8hon,

SW.

H@hwW,

1204,

MIIWIIOn.

of ttwa mtmmmton
tho dab

includIrw

~Ian

VA 22202

cumptmmE

to? ?ut~

-4302.-

FIRMWARE

to va~

m at,mmd

&

110 hc+us -I

and rewmvq

lb

to ttm Ofha

budm

mapomo,

UKIUJIW

ttu cEMoc81m O! mtormmton

to

of Muu@ma

SUPPORT

OkfB NO.0704-0188
t!w tmm ta WWNWIW wwlruct,~,

SUM

cannnamw

mgad~

m_ctww

tlw budm

W_hIIVtonHoadwmuoS8tVIrn,Owcctwm.
OfOp.rmH md~,
w -

S*I,

MANUAL

PuI.rwoIk

Muctmn

Pmpcf

(0704-01

d.!.

w my @ttm gpoct

1216 Joftoma!

WI}, Wafnwlm

(FSM)

xiot~

Utlmme

Oova

, OC 20603

DI-IPSC-81448

3. DESCRIPTION/PLIRPOSE
3,1 The Firmware Support Manual (FSM) provides the information needed to program and reprogram the
firmware
Erasable

devices of a system.
PROMS

(EPROMs),

It applies to read only memories (ROMs),

and other firmware

Programmable

ROMs

(PROMSI,

devices.

3.2 The FSM describes the firmware devices and the equipment, software, and procedures needed to erase
firmware devices, load software into the firmware devices, verify the load process, and mark the loaded
firmware devices.

4. APPROVAL DATE

5, OFFICE OF PRtMARY RESPONSIBILITY


EC
SHIP

~m
941205
APPLICATION/lN~TDN
7.1

This Data Item

product

generated

Description
by specific

(DID)

contains

and discrete

the format

task

6a. DTIC APPUCABLE

Sb. GIDEPAPPLICABLt
I

and content

requirements

preparation

as delineated

instructions

for the data

in the contract.

7.2 This DID is used when the developer is tasked to identify and record information
and reprogram firmware devices in which software will be installed,

needed to program

7.3 The Contract Data Requirements List {CDRL] (DD 1423) 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 suppon 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.
7.4 This DID supersedes DI-MCCR-80022A

and DI-MCCR-80318.

0. A

9-.
Limited Approval

from 12/5/S4

Bb. AMSC NUMSER

APPLICABLEFORMS

through 12%/66

N7091

CTIONs
I 0.1
a.

b.

genera I instruction,
Auto mated
DID means
Alternate
acceptable

t echniaue~.
a collection

rwesentation
substitutes

Use of automated
of data regardless
stvle~.

Diagrams,

for text

when

techniques
is encouraged,
of its medium.
tables,

matrices,

data required

and other

The term

presentation

document

styles

in this

are

by this DID can be made more readable using

these styles.

(Continued on Page 2)
11.

DISTRIBUTION STATEMENT

I!$TRIBLJTION

STATEMENT

A.

Approved

for public
Previous

release;

editions

are

distribution

is unlimited.

obsolete

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page

of

Firmware

Support

Manual

(FSM)

D14PSC-81448
10.

PREPARATION

INSTRUCTIONS

-- 10.1

General

Instructions

(continued)

c.

Title Dw
or ide ntifier.
The document
shall 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
name and address of the preparing
which
the document
has been prepared;
For data in a database or other alternative
organization;
and distribution
statement.
form, this information
shall be included on external and internal labels or by equivalent
identification
methods.

d.

Table of contents and index. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing an alphabetic listing of key terms and concepts covered in the
document and the pages or paragraphs in which the terms or concepts are covered.
For data in a database or other alternative
form, this information
shall 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.

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

f.

If a paragraph is tailored out of this DID, the


nse to ta ilorina instruct i~.
resulting document shall 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.

9.

~
~li(
this DID may be written

h.

If a data description
required by this DID has been
Sta ndard data desc rit)ti ons.
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.

tut ion of existirm docu ment~. Commercial or other existing documents


substituted
for all or part of the document if they contain the required data.

raar Dhs. Any section, paragraph, or subparagraph


in
as multiple paragraphs or subparagraphs
to enhance readability.

maybe

10.2
Content requirements
begin on the following
page.
The
m ntent reau irement~.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Firmware

10.
1.

PREPARATION

-.

INSTRUCTIONS

This section

Support Manual
DI-IPSC-81448

-- 10.2

shall be divided

Content

(FSM)

Requirements

into the following

(continued)

paragraphs.

of the system, software,


1.1 Me ntificat ion. This paragraph shall contain a full identification
and firmware devices to which this document applies, including, as applicable, identification
number(s), title(s), abbreviation(s),
version nurnbeds), and release number(s) of the system
and software and manufacturers
name and model number for each firmware device.
1.2

svs~~ m overview.

This paragraph

shall briefly

state the purpose

of the system

and the

software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Docu ment overview.
manual and shall describe

This paragraph shall summarize the purpose and contents of this


any security or privacy considerations
associated with its use.

2. Referenced c@u men~,


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

3.

Firmware
paragraphs.

instru ctions.

woarammina

This section

shall be divided

into the following

3.x ~ldentifier of monrammed firmware devicel. This paragraph shall state the project-unique
identifier of a programmed firmware device to be used in the system and shall be divided into
the following subparagraphs.
3. X.1
a.

b.

Q-crintion

rammed

Identify
by manufacturers
programmed
Provide

a complete

following,

c.

of Dre-Droa

de vice.

name

physical

This

paragraph

and model

description

of

number

the

shall:

the firmware

firmware

device

device,

to be

including

the

as applicable:

1)

Memory

size, type, speed, and configuration

2)

Operating

3)

Pin functional

4)

Logical interfaces

5)

internal

6)

Timing

characteristics

(such as 64Kx1,

8Kx8)

(such as access time, power requirements,logic

levels)

descriptions
(such as addressing

and external

identification

scheme,

chip selection)

scheme used

diagrams

Describe the operational and environmental


be subjected and still maintain satisfactory

limits to which
operation

the firmware

3.x.2
so ftWare to be D r Oa ramme d into the device. This paragraph shall identify
unique identifier(s)
the software to be programmed
into the firmware device.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

device may

by project-

Firmware

10.

PREPARATION

INSTRUCTIONS

Support Manual
DI-IPSC-81448

-- 10.2

Content

(FSM)

Requirements

(continued)

3.x.3
Proarammina eau iDment. This paragraph shall describe the equipment to be used for
programming
and reprogramming
the firmware device. It shall include computer equipment,
general purpose equipment,
and special equipment to be used for device erasure, loading,
verification,
and marking, as applicable.
Each piece of equipment
shall be identified by
manufacturers
name, model number, and any other information that is necessary to uniquely
identify that piece of equipment.
A description of each piece of equipment shall be provided,
including its purpose, usage, and major capabilities.
3.x.4
Promammina
software.
This paragraph shall describe the software to be used for
programming
and reprogramming
the firmware device. It shall include software to be used
and marking, as applicable.
Each software item shall
for device erasure, loading, verification,
be identified
by vendors name, software
name, number, version/release,
and any other
information
necessary to uniquely identify the software item. A description of each software
item shall be provided, including its purpose, usage, and major capabilities.
3.x.5
profiramminQ
wocedu reS. This paragraph shall describe the procedures to be used
for programming
and reprogramming
the firmware device. It shall include procedures to be
used for device erasure, loading, verification,
and marking, as applicable,
All equipment and
software
necessary for each procedure shall be identified, together with any security and
privacy measures to be applied.

3.x.6

lnsta Ilation

and

rena ir Drocedure~.

This

paragraph

shall

contain

the

This paragraph shall


remove-and-replace
procedures, device addressing scheme and implementation,
of the host board layout, and any procedures for ensuring continuity
of operations
of emergencies.
Safety precautions,
marked by WARNING or CAUTION, shall
where applicable.
replacement,

and repair

procedures

for the firmware

3.x.7
Vendor information.
This section
supplied by the vendor(s) of the firmware
software.

device.

installation,

also include
description
in the event
be included

shall include or reference any relevant information


device, programming
equipment, or programming

This section shall contain any general information that aids in understanding this
4. w.
document
(e.g., background
information,
glossary, rationale),
This section shall include an
alphabetical
listing of all acronyms,
abbreviations,
and their meanings as used in this
document and a list of terms and definitions
needed to understand this document.
A.
D endixeS.
Appendixes
may be used to provide information
published separately for
convenience
in document maintenance
(e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided.
Appendixes may be bound as separate documents for ease in handling.
Appendixes
shall be lettered alphabetically
(A, B, etc.).

Page 4

of ~

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

I%rm

Approved
OMB NO. 0704-0188

DATA ITEM DESCRIPTION


co4bctInn I lb

FI@hc MPWIIIW budm

cwra.

mmmmnifw

OMhUIrKI

of flus calktlw!
t4@twsv,

md

of Mofmmwm,

SUM 1204, AAtvtot).

mlormaion W,mmd

tho dmc nnd.d

hdtdq

WW.MIW

VA 22202-4302,

to w-

uid C-PMW
lW r.dumw

110 houo PSI tou+nrn,

ud FOVIOWIIWb
ttn

to du OftI-

kud.n

of M~

to Wmhfwton

t40adquM-

and Bidoa

lIITU fw Iovmwma wotruct!om, NucrurqI IIOIIW dm.

lndudma !*

colhctlm e! mfwmottm
Pa.rwork

S.nd cotnm.nto fogafdq

S.rvwu,
R-L@on

PIc+ocf 1070401

OBW-IWOw MT Dthu -c!


1216 JdW.on

0w18

SBI. WdWUWWI . DC 20603

ICATIONNUMBER
I 2 lDENT~F

TITLE

1.

WM budm

Dwatorata of OPWmIam uui R+uto,

INTERFACE

DESIGN

DESCRIPTION

ODD)

DI-IPSC-81436

DESCRIPTION/PURPOSE

3.

3.1 The Interface Design Description [lDO) describes the interface characteristics of one or more systems,
subsystems, Hardware Configuration Items (HWCISI, Computer Software Configuration Items (CSCIS),
manual operations, or other system components.
An IDD may describe any number of interfaces.

Design Description (SSDD)


The IDD can be used to supplement the System/Subsystem
(DI-IPSC-81 432), Software Design Description (SDD) (D14PSC-81 435), and Database Design Description

3.2

(DBDD) (DI-IPSC-81 437). The IDD and its companion Interface Requirements Specification
(D14PSC-81 434) serve to communicate and control interface design decisions.
5. OFFICEOF PRIMARYRESPONSIBILITY
4. APPROVALDATE
EC
~m
941205
REIATIONSttlP
7. APPLICATION/lNTER

(IRS)

Sb, GIDEPAPPLICABLE

ea. DTIC APPLICABLE


I

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
systems, subsystems, HWCIS, CSCIS, manual operations, or other system components.
7.3 The IRS specifies interface requirements; the IDD describes interface characteristics selected to meet
those requirements. The IDD may reference the IRS to avoid repeating information. The IDD can be used to
supplement the SSDD, SDD, or DBDD,
7,4 The Contract Data Requirements List (CDRL} (DD 1423) should specify whether deliverable data are to be
delivered on pspw or electronic media; are to be in a given electronic form (such as ASCII, CALS, or
~ delivered in developer format
compatible with a specified word processor or other SUPPOfI software); fw
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.
7,5

This DID supersedes DI-MCCR-80027A.

& APPROVALLIMITATION
LirnitadApprovalfrom 12/5/94 through32/5/66
10. PREPARATIONINSTRUCTIONS

9a. APPLICABLE
FORMS

S4. AMSC NUMBER


N7079

10.1 Qgneral instruct ions.


a.

Auto mated tec hniaueS. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

b. Alternate Presentation
acceptable substitutes
these styles.

The term document in this

stv Ies. Diagrams, tables, matrices, and other presentation styles are
for text when data required by this DID can be made more readable using

(Continued on Page 2)
-r

i i \. DISTRIBUTIONSTATEMENT

I n\sTRIB(JTloN

STATEMENT

A.

Approved

for public release; distribution is unlimited.

6-D Form 1664, APR 89

Previous editions are obsolete

115123

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page J_ of ~

1
Pages

Interface Design Description {IDD)


DI-IPSC-81436
10.
co

PREPARATION

INSTRUCTIONS

-- 10.1 General Instructions

(continued)

Title r)agg or ide ntifier vuith signature blocks. The document shall 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,
to which the document

and any other identifier for the systems, subsystems,


or items
applies; contract number; CDRL item number; organization
for

which the document has been prepared; name and address of the preparing organization; distribution statement; and signature blocks for the developer representative
authorized to release the document, the acquirer representative authorized to approve
For data in a database or other
the document, and the dates of release/approval.
alternative form, this information shall be included on external and internal iabels or by
equivalent identification methods.
d.

Table of contents.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Pa9e numbe rinafla beling. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

se to tailo rirm instruct ionS. If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Mu[tii)le Daraarac)hs and subtla r aa rarlh$. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description required by this DID has been


W ndard data desc riDtion~.
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.

bst itut ion of existina docu mentS. Commercial or other existing documents
substituted for all or part of the document if they contain the required data.

may be

10.2
Content requirements begin on the following page.
The
m ntent reau irementS.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Interface Design Description


DI-IPSC-81436
10.
1.

PREPARATION
-.

INSTRUCTIONS

-- 10.2

(lDO)

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 Identificat ion. This paragraph shall contain a full identification of the system(s), the
interfacing entities, and interfaces to which this document applies, including, as applicable,
identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2
This paragraph shall briefly state the purpose of the system(s) and
st em overview.
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
verview. This paragraph shall summarize the purpose and contents of this
1.3 Pocumeto
n
document and shall describe any security or privacy considerations associated with its use.
2. Referenced docu e ts. This section shall list the number, title, revision, and date of all
documents reference% i: this document.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Jnterface des ian. This section shall be divided into the following paragraphs to describe
the interface characteristics of one or more systems, subsystems, configuration items, manual
If part or all of the design depends upon system
operations, or other system components.
states or modes, this dependency shall be indicated. If design information falls into more than
one paragraph, it may be presented once and referenced from the other paragraphs. If part
or all of this information is documented elsewhere, it may be referenced. Design conventions
needed to understand the design shall be presented or referenced.
3.1 Interface identifica tion and diaarams. For each interface identified in 1.1, this paragraph
shall state the project-unique identifier assigned to the interface and shall identify the
interfacing entities (systems, configuration items, users, etc. ) by name, number, version, and
documentation references, as applicable. The identification shall 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 shall be provided, as appropriate, to
depict the interfaces.
3.x Jproiect-uniau e identifier of interface.
This paragraph (beginning with 3.2) shall identify
an interface by project-unique identifier: shall briefly identify the interfacing entities, and shall
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 shall be stated as assumptions or
as When [the entity not covered} does this, Ithe 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 shall include the following, as applicable, presented in any order suited to the
information to be provided, and shall note any differences h 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):

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Interface

10.

PREPARATION
a.

Priority

b.

Type

INSTRUCTIONS

assigned

Design Description (IDD)


DI-IPSC-81436
-- 10.2

by the interfacing

to the interface

of interface

Content Requirements

{such as real-time

(continued)

entity (ies)

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)

d.

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural-language)

c)

DoD standard data element name

d)

Technical

e)

Abbreviation

name

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


or synonymous

names

2)

Data type (alphanumeric,

integer, etc. )

3)

Size and format (such as length and punctuation

4)

Units of measurement

(such as meters, dollars, nanoseconds)

5)

Range or enumeration

of possible values (such as O-99)

6)

Accuracy

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

9)

Sources

(setting/sending

of a character string)

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

constraints
entities)

and recipients

(using/receiving

entities)

Characteristics of data element assemblies (records, messages, files, arrays, displays,


reports, etc. ) that the interfacing entity (ies) will provide, storer send t access~ receive~
etc., such as:
1)

Names/identifiers
a)

Project-unique

b)

Non-technical

c)

Technical

d)

Abbreviations

identifier
(natural

name

(e.g.,

language)
record

or synonymous

name

or data structure

name

in code or database)

names

2)

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

3)

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

4)

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

5)

Relationships among assemblies,

6)

Priority, timing, frequency, volume, sequencing, and other constraints, such as


whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources (setting/sending

such as sorting/access

on the medium

characteristics

entities) and recipients (using/receiving

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

entities)

Interface Design Description


DI-IPSC-8 1436
10.

PREPARATION
e.

f.

INSTRUCTIONS

-- 10.2

Characteristics of communication
the interface, such as:

(IDD)

Content Requirements

(continued)

methods that the interfacing entity (ies) will use for

1)

Project-unique

identifier(s)

2)

Communication

3)

Message

4)

Flow

5)

Data transfer rate, whether periodic/aperiodic,

6)

Routing, addressing, and naming conventions

7)

Transmission

8)

Safety/security/privacy
compartmentalization,

links/bands/f

requencies/media

and their characteristics

formatting

control

Characteristics

(such as sequence numbering and buffer allocation)


and interval between

transfers

services, including priority and grade


considerations,
and auditing

such as encryption,

user authentication,

of protocols the interfacing entity (ies) will use for the interface,

such

as:

9.

4.

1)

Project-unique

identifier(s)

2)

Priority/layer

3)

Packeting,

4)

Legality checks, error control, and recovery procedures

5)

Synchronization,

6)

Status, identification,

of the protocol

including fragmentation

and reassembly,

including connection establishment,

routing, and addressing

maintenance,

and any other reporting features

Other characteristics, such as physical compatibility of the interfacing


(dimensions, tolerances, loads, voltages, plug compatibility, etc.)

Reau irements tracea bility.

termination

entity (ies)

This paragraph shall contain:

a.

Traceability from each interfacing entity covered by this IDD to the system or CSCI
requirements addressed by the entitys interface design,

b.

Traceability from each system or CSCI requirement that affects an interface covered
in this IDD to the interfacing entities that address it.

5, Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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. me ndix~.
Appendixes may be used to provide information published separately for
convenience in document maintenance (e. g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Page &
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

of&

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DATA ITEM DESCRIPTION


Pdthc

rDDOmIW
buck

WXXCU,

of tti

gmturIrQ

ti

f-

vu Wna bl ,.*W,W
mmmfcwmawm
9atmm9d
10 www
110 how m -otzemo, ,Iwhdqj
ttmdmoMUM d comAIIrs d rcwmwtg tho cokcttm of Infermwon%mJ Cmtmmta I.owdmgthe

cdll.cttm d

mumwwm

1204, Mwqtan.

VA 22202 ~302,

INTERFACE

4m.hlrq

lmlrw.t,0t9,

coliocwonof u-dermmten, irx4dm4 UWNtIOm

H@hway, S@.

i%rm Approved
OMB NO. 0704-0188

for mducww w
10 ti

bwd.n 10 WmfwWtm

OHIce d M~

REQUIREMENTS

HodouuIom

-v!cot,

bud.n

Dtractofste of OPWMIOIU d

RoP@Is,

md Bbe@a. Pacatwofk Raducoon Prc+oa 10704-O IO@) Wmtwxxun

SPECIFICATION

(IRS)

Wutitq

nt!mal.

dms

MIW me!

o! my

1216 Jotf-

Dbwa

OC 20603

DI-IPSC-81434
1

3, OESCRIPTKWWJRPOSE

3.1 The Interface Requirements Specification (IRS) specifies the requirements imposed on one or more
systems, subsystems, Hardware Configuration hems (HWCIS), Computer Software Conf;ouration Items
(CSCIS), manual operations, or other system components to achieve one or more interfaces among these
entities. An IRS can cover any number of interfaces.
3.2 The IRS can be used to supplement the System/Subsystem
Software Requirements
of systems and CSCis.

Specification

Specification (SSS) (DPIPSC-81 431 ) and


(SRS) (DI-IPSC-81 433) as the basis for design and qualification testing

5. OFFICEOF PRIMARYRESPONSIBIL~Y
4. APPROVALDATE
*BJ
951205
EC
APPUCATIOWNTERRE
IATIDNSHIP

6b, t310EPAPPUCABLE

69. DTIC APPLICABLE


I

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

for the data

for one

7.2 This DID is used when the developer is tasked to define and record the interface requirements
or more systems, subsystem, HWCIS, CSCIS, manual operations, or other system components.
7.3

The IRS can be used to supplement

the SSS and the SRS.

7,4 The Contract Data Requirements List (CDRL) {00 14231 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.
7.5

This DID supersedes DI-MCCR-80026A

mi$MovAL

mmA7

and DI-MCCR-80303.

9s. APPUCABI.EFORMS

10N

LimitedApprovalfrom 12/5/S4 through12/S/S6


)0. PREPARATIONlNS~CT)

9b. AMSC NUMBER


N7077

ONs

10.1 Ge neral instruction~.


a. Auto mated tec hniau~.
Use of automated techniques is encouraged.
DID means a collection of data regardless of its medium.

The term document* in this

b. Alternate mes entation stvle$. 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,
(Continued

..
11, DfSTRIWTIDN STATEMENT
)! STRIBUTIC)N

STATEMENT

(&J Form 1664, APR 89

A.

Approved

for public release; distribution

on Page 2)

is unlimited.

FYeviixls editions are obsolete


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page ~

of &

Pages

Interface

10.

PREPARATION

Requirements Specification
DI-IPSC-81 434

INSTRUCTIONS

(IRS)

-- 10.1 General Instructions (continued)

c.

Jitle me
or ide ntifier with signature blocks. The document shall 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 systems, subsystems, or items
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; distribution statement; and signature blocks for the developer representative
authorized to release the document, the acquirer representative authorized to approve
the document, and the dates of release/approval.
For data in a database or other
alternative form, this information shall be included on external and internal labels or by
equivalent identification methods.

d.

Table of conten~.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

me numbe rinaflabe Iing. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Resc)onse to ta ilorin~ instructions.


If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Multide mwaaraDhs and subo araar al)h$. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description required by this DID has been


Zta ndard data desc rirrtions.
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.

~
on of existina doc ument~. Commercial or other existing documents may be
substituted for all or part of the document if they contain the required data.

10.2
ntent reau irement~.
Content requirements begin on the following page.
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.

Page ~

of&
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Interface Requirements Specification


DI-IPSC-81434
10.

1,

PREPARATION

-.

INSTRUCTIONS

-- 10.2

Content

(IRS)

Requirements

(continued)

This section shall be divided into the following paragraphs.

1.1 Merit ificat ion. This paragraph shall contain a full identification of the systems, the
interfacing entities, and the interfaces to which this document applies, including, as
applicable, identification number(s), title(s), abbreviation(s), version number(s), and release
number(s).

1.2
ste m ove rview. This paragraph shall briefly state the purpose of the system(s) and
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Rocu ment overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Referenced docu mentgi. This section shall list the number, title, revision, and date of all
documents referenced in this specification.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Reau irement~. This section shall be divided into the following paragraphs to specify the
requirements imposed on one or more systems, subsystems, configuration items, manual
operations, or other system components to achieve one or more interfaces among these
entities. Each requirement shall be assigned a project-unique identifier to support testing and
traceability and shall be stated in such a way that an objective test can be defined for it. Each
requirement shall be annotated with associated qualification method(s) (see section 4) and
traceability
to system
(or subsystem,
if applicable)
requirements
(see section
5a) if not
in those sections.
The degree of detail to be provided shall be guided by the
provided

following rule: Include those characteristics of the interfacing entities that are conditions for
their acceptance; defer to design descriptions those characteristics that the acquirer is willing
to leave up to the developer. If a given requirement fits into more than one paragraph, it may
be stated once and referenced from the other paragraphs. If an interfacing entity included in
this specification will operate in states and/or modes having interface requirements different
from other states and modes, each requirement or group of requirements for that entity shall
be correlated to the states and modes. The correlation may be indicated by a table or other
in an appendix referenced from this paragraph, or by annotation of
method in this paragraph,
the requirements in the paragraphs where they appear.
3.1 Interfac e identificat ion and dia~ramS. For each interface identified in 1.1, this paragraph
shall include a project-unique identifier and shall designate the interfacing entities (systems,
configuration items, users, etc. ) by name, number, version, and documentation references,
as applicable. The identification shall 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 shall be provided to depict the interfaces.
3.x jProie ct-uniaue identifier of interface). This paragraph (beginning with 3.2) shall identify
an interface by project-unique identifier, shall briefly identify the interfacing entities, and shall
be. divided into subparagraphs as needed to state the requirements imposed on one or more
Page Jl_ of&
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Interface Requirements Specification


D14PSC-81434
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(IRS)

Content Requirements

(continued)

of the interfacing entities to achieve the interface. If the interface characteristics of an entity
are not covered by this IRS but need to be mentioned to specify the requirements for entities
that are, those characteristics shall be stated as assumptions or as When [the entity not
covered] does this, the [entity being specified] shall.. ., rather than as requirements on the
entities not covered by this IRS. This paragraph may reference other documents (such as data
dictionaries, standards for communication protocols, and standards for user interfaces) in
place of stating the information here.
The requirements shall include the following, as
applicable, presented in any order suited to the requirements, and shall note any differences
in these characteristics from the point of view of the interfacing entities (such as different
expectations about the size, frequency, or other characteristics of data elements):
a.

Priority

b.

(such as real-time data transfer, storage-andRequirements


on the type of interface
retrieval of data, etc. ) to be implemented

c.

Required characteristics of individual data elements that the interfacing


must provide, store, send, access, receive, etc., such as:
1)

d.

the interfacing

entity (ies) must

assign

the interface

entity (ies)

Names/identifiers
a)

Project-unique

b]

Non-technical

(natural-language)

c)

DoD standard

data

d)

Technical

e)

Abbreviation

identifier

name

element

(e.g.,

name

name

variable

or synonymous

or field name

in code or database)

names

2)

Data type (alphanumeric,

3)

Size and format (such as length and punctuation

4)

Units of measurement

(such as meters, dollars, nanoseconds)

5)

Range or enumeration

of possible values (such as O-99)

6)

Accuracy

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

integer, etc.)
of a character string)

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

entities) and recipients (using/receiving

entities)

Required characteristics of data element assemblies (records, messages, files, arrays,


displays, reports, etc.) that the interfacing entity (ies) must provide, store, send,
access, receive, etc., such as:
1)

Page ~

that

Names/identifiers
a)

Project-unique

b)

Non-technical

c)

Technical

d)

Abbreviations

identifier
(natural language) name

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


or synonymous

names

2)

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

3)

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

of

A
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

on the medium

Interface Requirements Specification


DI-IPSC-81 434
10.

PREPARATION
4)

INSTRUCTIONS

of displays and other outputs (such as colors,


icons and other display elements,
beeps, lights)

fonts,

Relationships

6)

volume, sequencing, and other constraints, such as


Priority, timing, frequency,
whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources (setting/sending

among

assemblies,

such as sorting/access

Project-unique

characteristics

entities) and recipients (using/receiving

,Required characteristics of communication


must use for the interface, such as:

entities)

methods that the interfacing

entity (ies)

identifier(s)

2)

Communication

3)

Message formatting

4)

Flow control (such as sequence numbering and buffer allocation)

5)

Data transfer rate, whether

6)

Routing, addressing,

7)

Transmission

8)

Safety/security/privacy
compartmentalization,

[inks/bands/frequencies/media

periodic/aperiodic,

and their characteristics

and interval between

transfers

and naming conventions

services, including priority and grade

Required characteristics
interface,

9.

(continued)

5)

1)

f.

Content Requirements

Visual and auditory characteristics


layouts,

e.

-- 10,2

(IRS)

considerations,
and auditing
of protocols

such as encryption, user authentication,

the interfacing

entity(ies)

must use for the

such as:

1)

Project-unique

identifier(s)

2)

Priority/layer

3)

Packeting,

of the protocol

4)

Legality checks, error control, and recovery procedures

5)

Synchronization,

6)

Status, identification,

including fragmentation

and reassembly,

including connection establishment,

routing, and addressing


maintenance,

termination

and any other reporting features

Other required characteristics,


such as physical compatibility of the interfacing
entities (dimensions, tolerances, loads, plug compatibility, etc.), voltages, etc.

3.y Precedence and criticalitv of reau irements. This paragraph shall be numbered as the last
paragraph in Section 3 and shall specify, if applicable, the order of precedence, criticality, or
assigned weights indicating the relative importance of the requirements in this specification.
Examples include identifying those requirements deemed critical to safety, to security, or to
privacy for purposes of singling them out for special treatment. If all requirements have equal
weight, this paragraph shall so state.
4. Qua Iific ation movision~. This section shall define a set of qualification methods and shall
specify, for each requirement in Section 3, the qualification method(s) to be used to ensure
that the requirement has been met. A table may be used to present this information, or each
requirement in Section 3 may be annotated with the method(s) to be used. Chalification
methods may include:

Page -& of&


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Interface Requirements Specification


D14PSC-81434
10.

PREPARATION
a.

INSTRUCTIONS

Demonstration:
functional

The

operation

or subsequent

-- 10.2

operation

not requiring

of

Content

(IRS)

Requirements

interfacing

entities

the use of instrumentation,

(continued)

that

relies
special

on

observable

test equipment,

analysis.

b.

Test:
The operation of interfacing entities
equipment to collect data for later analysis.

using instrumentation

c.

Analysis:
methods,

d.

Inspection:

e.

Special qualification methods: Any special qualification methods for the interfacing
entities, such as special tools, techniques, procedures, facilities, and acceptance
limits.

The processing
of accumulated
data
Examples are reduction,
interpretation,
The visual

examination

of interfacing

or special test

obtained
from other qualification
or extrapolation
of test results.
entities,

documentation,

etc.

5, Beau ireme nts traceab ility. For system-level interfacing entities, this paragraph does not
apply.
For each subsystem- or lower-level interfacing entity covered by this IRS, this
paragraph shall contain:
a.

Traceability from each requirement imposed on the entity in this specification to the
system (or subsystem, if applicable) requirements it addresses. (Alternatively, this
traceability may be provided by annotating each requirement in Section 3.)
Note:
Each level of system refinement may result in requirements not directly
For example, a system architectural design
traceable to higher-level requirements.
that creates multiple CSCIS may result in requirements about how the CSCIS will
interface, even though these interfaces are not covered in system requirements.
Such requirements may be traced to a general requirement such as system
implementation or to the system design decisions that resulted in their generation.

b.

Traceability from each system (or subsystem, if applicable) requirement that has been
allocated to the interfacing entity and that affects an interface covered in this
specification to the requirements in this specification that address it.

6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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.
endixeS. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

form Appro vod


OhlB NO. 0704-0188

DATA ITEM DESCRIPTION


%bhc ras.arnqtbwti
ouca,

h aoliwttm ef

ostlunrq a!d muntwvw

rhm tn+ormumn 98-Iammd

dma !uuI.d

of tln co+krmn of in?wwwtton.ir!chdwq NSOatIam


H~hwsy,

S@!.

1?04, tirqton,

VA 222024302,

10 vww

and c0mc48wmM

110 hcnu* pa raprw.

!awwwww Iho cdlac!!on

tw mdUXVJ NW budon 10 Wmluw!m

to lb

Otl!m of M~tnam

mchdma rho Mu

of Ontwmstwm

Hods-ero

BudLPt, %#S?WWk

*M

lot 19. IWWI.J wwtfucwru, wwehtq

cOnW?-M.

wowdtnn

lb

bwdon atnnaw

SorvICn, DIIoctorato of OPW ION P$c+ect(0?04418S1,

kduCtlWl

%patta,

W-hIrqtcm

.mmtt~ dwa
w anv otti

121 b JoN-

-CI
ODVU

, DC 20603.

2. lDE~

1. TtTLE

OPERATIONAL

CONCEPT

DESCRIPTION

(OCD)

DI-IPSC-81430

DESCRIPTIOWPURPOSE

3.

3.1 The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it
will fulfill, its relationship to existing systems or procedures,

and the ways it will be used.

3.2 The OCD is used to obtain consensus among the acquirer, developer, support, and user agencies on
the operational concept of a proposed system. Depending on its use, an OCD may focus on communicating
the users needs to the developer or the developers ideas to the user and other interested parties. The
term system may be interpreted to apply to a portion of a system.

4.

Mm

OVAL bATE

5.

~~i
941205
>. APPIJCATION~TiONSHIP

OFFICEOF PRIMARYRESPONSIBILITY
EC

6a. DTIC APPUCABLE

Sb. GIDEPAPPUCABIE

7,1 This Data Item Description (DID) contains the format and content preparation instructions
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 operational
system.

for the data

concept for a

7.3 The Contract Data Requirements List (CDRL) (DD 1423) 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
7.4

tool rather than in the form of a traditional

document.

This DID supersedes DI-IPSC-80689.

%. APPR OVAL IMITATION


LimitedApprovalfrom 12/5/94 through12/S/96
s
)0. ~ont

9a. APPLICABLE
FORMS

9b. AMSC NUMBER


N7073
I

10.1 !3eneral instruction~.


tec hnictue~. Use of automated techniques is encouraged. The term document in this

a.

DID means a collection of data regardless of its medium.


b.

Alternate oresentat ion stvles. 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.
(Continued

on Page 21

11. DISTRIBUTIONSTATEMENT

DISTRIBUTION
--

STATEMENT
-.

1664, APR 89

A,

Approved for public release; distribution is unlimited.


Previous editions are obsolete

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

page ~

of ~

Pages

Operational

10.
c.

PREPARATION
Title

INSTRUCTIONS

DQJJ.9 or id entifier.

applicable:
markings
name,

document
or other

-- 10.1 General Instructions

The

document

number;

restrictions

abbreviation,

Concept Description (OCD)


DI-IPSC-81 430

volume

shall
number;

on the handling

and any

other

include

Icontinued)

a title

page

version/revision

of the document;

containing,

indicator;
date;

as

security

document

title;

for the system, subsystem, or item to


for
number; CDRL item number; organization

identifier

which the document applies; contract


which the document has been prepared;

name

and

address

of

the

preparing

For data in a database


or other alternative
organization;
and distribution
statement.
form, this information
shall be included on external and internal labels or by equivalent
identification

d.

methods.

of conten@.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.

Table

For data

in a database

internal

or

accessing,

external
each

or other
table

paragraph,

of

alternative
contents

figure,

table,

form,

this information

containing

pointers

and appendix

to,

shall consist
or

instructions

of an
for

or their equivalents.

e.

Paa e numbe rindlabe Iing. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Res~nse
to ta ilorina instruct ions.
If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Mu[tirl!e Daraclrarlhs and sub~a raaraoh~. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description required by this DID has been


Sta ndard data desc rirltion$.
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.

Commercial or other existing documents may be


5ubst itut ion of ex istino docu men~.
substituted for all or part of the document if they contain the required data.

10.2
numbers

content
shown

reau iremen~.
designate

Content

the paragraph

requirements
numbers

begin on the following

to be used in the document.

number is understood
to have the prefix 10.2
within
numbered
1.1 is understood
to be paragraph
10.2.1.1

this DID. For example,


within this DID.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

page.

The

Each such
the paragraph

Operational

10.
1.

PREPARATION
SCODQ.

INSTRUCTIONS

Concept Description
DI-IPSC-81 430
-- 10.2

(OCD)

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 Jdentificat ion. This paragraph shall contain a full identification of the system to which
this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2
ste m overview. This paragraph shall briefly state the purpose of the system to which
this document applies. It shall 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 agencies; identify current and planned operating sites;
and list other relevant documents.
1.3 ~ment
overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2, Referenced doc ument~. This section shall list the number, title, revision, and date of all
documents referenced in this document.
This section shall also identify the source for all
stocking activities.
documents not available through normal Government
3. Gu rrent svst em or situat ion. This section shall be divided
to describe the system or situation as it currently exists.
-round,

3.1

tit

mission or objectives,

into the following

ives, and SCODQ. This paragraph shall describe the background,


and scope of the current system or situation.

3.2 Operational Dolicies and co nstrain L~. This paragraph shall describe
policies and constraints that apply to the current system or situation.

P=

3,3

riDtion of cu rrent svste m or situ ation.

the current system


modes of operation

paragraphs

or situation,

identifying

This paragraph

differences

shall provide

associated

with

any operational

a description

different

states

of
or

(for example, regular, maintenance,


training, degraded, emergency,
alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary.
A system may be described in terms of states only, modes only, states within modes, modes
within states, or any other scheme that is useful. If the system operates without states or
modes, this paragraph shall so state, without the need to create artificial distinctions.
The
description shall include, as applicable:
a.

The operational environment

and its characteristics

b.

Major system components

c.

interfaces

d.

Capabilities/functions

e.

Charts and accompanying descriptions depicting inputs, outputs, data flow, and
manual and automated processes sufficient to understand the current system or
situation from the users point of view

f.

Performance

and the interconnections

among these components

to external systems or procedures


of the current system

characteristics,

such as speed, throughput,

volume, frequency

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Operational

10.

PREPARATION

INSTRUCTIONS

Concept Description
DI-IPSC-81 430
-- 1 Q.2

Content

(OCD)

Requirements

Chmlity attributes, such as reliability, maintainability,


usability, efficiency

h.

Provisions for safety, security,

(continued)

availability, flexibility, portability,

privacy, and continuity of operations in emergencies

3.4 ~ers
or involve$f Derso nnel. This paragraph shall describe the types of users of the
system, or personnel involved in the current situation, including, as applicable, organizational
structures, training/skills, responsibilities, activities, and interactions with one another.
3.5

~ort

the current

conce~.
system,

This paragraph shall provide an overview of the support concept for

including,

as applicable

to this document,

equipment;
support software;
repair/replacement
storage, distribution,
and supply methods.

4.

Just ificat ion for and nature

of chanae~.

criteria;

This section

support

agency (ies); facilities;

maintenance

levels and cycles;

shall be divided

and

into the following

paragraphs.

4,1

Just ificat ion for chanae.

This paragraph shall:

a.

Describe new or modified aspects of user needs, threats, missions, objectives, environments, interfaces, personnel or other factors that require a new or modified
system

b.

Summarize deficiencies or limitations in the current system or situation that make it


unable to respond to these factors

4.2 Qesc riDtion of needed chanae~.


This paragraph shall summarize new or modified
capabilities/functions,
processes, interfaces, or other changes needed to respond to the
factors identified in 4.1.
4.3 Priorities amorra the cha naes. This paragraph shall identify priorities among the needed
changes. It shall, for example, identify each change as essential, desirable, or optional, and
prioritize the desirable and optional changes.
4.4
This paragraph shall identify changes considered
co nsidered but not mcl~.
but not included in 4.2, and rationale for not including them.
4.5
This paragraph shall identify
Sumotions and co nstraintq.
constraints applicable to the changes identified in this section.

any assumptions

and

5. ~
m. This section shall be divided into the following
paragraphs to describe a new or modified system.
5.1 Bac karound, obiect ives, and SCOD?. This paragraph shall describe the background,
mission or objectives, and scope of the new or modified system.
5.2

Qt)erational

policies

DOIicies and co nstraint~.

and constraints

This

that appJy to the new

paragraph

or modified

shall

describe

system.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

any

operational

Operational

10.

PREPARATION

INSTRUCTIONS

Concept Description (OCD)


D14PSC-81 430
-- 10.2

Content Requirements

(continued)

5.3 Rest riDtion of the new or mo dified svste m. This paragraph shall provide a description
of the new or modified system, identifying differences associated with different states or
modes of operation (for example, regular, maintenance, training, degraded, emergency,
alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary.
A system may be described in terms of states only, modes only, states within modes, modes
within states, or any other scheme that is useful, If the system operates without states or
modes, this paragraph shall so state, without the need to create artificial distinctions. The
description shall include, as applicable:
a.

The operational

environment

and its characteristics

b.

Major system components

c.

Interfaces

d.

Capabilities/functions

e.

Charts and accompanying descriptions depicting inputs, outputs, data flow, and
manual and automated processes sufficient to understand the new or modified
system or situation from the users point of view

f.

Performance

9.

Quality attributes, such as reliability, maintainability,


usability, efficiency

h.

Provisions for safety, security,

and the interconnections

among these components

to external systems or procedures


of the new or modified system

characteristics,

such as speed, throughput,

volume, frequency

availability, flexibility, portability,

privacy, and continuity of operations in emergencies

5.4 Users/affected Dersonnel. This paragraph shall describe the types of users of the new
or modified system, including, as applicable, organizational structures, training/skills, responsibilities, and interactions with one another.
5.5 ~uDDo rt conceD~. This paragraph shall provide an overview of the support concept for
the new or modified system, including, as applicable, support agency (ies); facilities;
equipment; support software; repair/replacement criteria; maintenance levels and cycles; and
storage, distribution, and supply methods.
6. oDe rational sce nario~. This section shall describe one or more operational scenarios that
illustrate the role of the new or modified system, its interaction with users, its interface to
other systems, and all states or modes identified for the system. The scenarios shall include
events, actions, stimuli, information, interactions, etc., as applicable. Reference maybe made
to other media, such as videos, to provide part or all of this information.
7.

Su mmarv of immcts.

This section shall be divided into the following

paragraphs.

7.1 9Derational immc~.


This paragraph shall describe anticipated operational impacts on
the user, acquirer, developer, and support agency (ies). These impacts may include changes
in interfaces with computer operating centers; change in procedures; use of new data
sources; changes in quantity, type, and timing of data to be input to the system; changes in
data retention requirements; and new modes of operation based on peacetime, alert, wartime,
or emergency conditions.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Operational

10.

PREPARATION

INSTRUCTIONS

Concept Description (OCD)


DI-IPSC-81 430
-- 10.2

Content

Requirements

(continued)

7.2 Qmanizat ional imDa@. This paragraph shall describe anticipated organizational impacts
on the user, acquirer, developer, and support agency (ies).
These impacts may include
modification of responsibilities; addition or elimination of responsibilities or positions; need for
training or retraining; and changes in number, skill levels, position identifiers, or location of
personnel in various modes of operation.
7.3 Imoacts du rina develoDment. This paragraph shall describe anticipated impacts on the
user, acquirer, developer, and support agency (ies) during the development effort.
These
impacts may include meetings/discussions
regarding the new system; development or
modification of databases; training; parallel operation of the new and existing systems;
impacts during testing of the new system; and other activities needed to aid or monitor
development.
8.

Analvsis of the DrODOSed SWte m.

This paragraph
shall provide a qualitative
and quantitative
Su mmarv o f ad vantaa~.
summary of the advantages
to be obtained from the new or modified system.
This summary
8.1

shall include new capabilities,


enhanced capabilities,
and improved
and their relationship
to deficiencies
identified
in 4.1.

performance,

as applicable,

8.2 Summary of disadvanttmesfl imitat ions. This paragraph shall provide a qualitative and
quantitative summary of disadvantages or limitations of the new or modified system. These
disadvantages and limitations shall include, as applicable, degraded or missing capabilities,
degraded or less-than-desired performance, greater-than-desired
use of computer hardware
resources, undesirable operational impacts, conflicts with user assumptions, and other
constraints.
This paragraph shall identify and describe major
8.3 Alternatives and trade -offs con sider~.
alternatives considered to the system or its characteristics, the trade-offs among them, and
rationale for the decisions reached.
9. -.
This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shail 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.

Aooe ndixe~.

Appendixes

may

be used

to provide

information

published

separately

for

convenience
in document
maintenance
(e.g., charts, classified
data).
As applicable,
each
in the main body of the document where the data would normally
appendix shall be referenced

have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Fbrm Approved
OMB NO. 0704-0188

DATA ITEM DESCRIPTION


Ptitc

FWWIIW budm

oucoo,
of ti

Lwt-rim
cohctton

H@wev,

f-

Goliocmgnd lb.

md mdm-mw
01 Informctmn,

mtofmamn * al,mbtti

ttu data ~
mc4ulI*

Sute 1204, &l)@on,

md cetn~tww

.-IWU

10I rtiua~

VA 22202.4302,

SOFTWARE

ud

CENTER

110 how, w

40 .et~

ard I.VUWW
ttn

budm

ti

r+aw9,

to W*nOtm

~c

to tlw OtrIa of MaMWIWRW md 8udPt,

OPERATOR

mcluin~ lho Imm b

cdtocl!on of Intatmti$on

S.mi corn-

fiorwoa,
PvNwork

MANUAL

t..mw8w

,mtrwst,mm, -arctn~

?Ward!w

.mm,~

tin budcn -ornate

CMwaaroto of OPU SI*-

ud tbparn,

Raducmm Prowm 10704-01@81, WVhKQton

(SCOM)

dti.

of MY

ah

12 }6 Jottawn

MPDCt

Dsvu

, OC 20603.

DhlPsc-81444

3. DESCRIPTOIWU
RPOSE
3.1 The Software Center Operator Manual (SCOMJ provides personnel in a computer center or other
centralized

or networked

software

installation information

on how to install and operate a software

system,

3.2 The SCOM is developed for software systems that will be installed in a computer center or other
centralized or networked software installation, with users accessing the system via terminals or personal
computers or submitting and receiving inputs and outputs in batch or interactive mode,

4. APPROVALDATE
~)
941205
mNnN~
APPLJCAT

5.
I

ICE OF PRIMARYRESPONSIBILWY
EC

6a. DTIC APPLICABLE ab. GIDEPAPPLICABLE


I

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 identify and record information needed by persons
who will operate software in a computer center or other centralized or networked software installation, so
that the software can be used by others.
7.3 This DID is often used with the Software Input/Output Manual (SIOM) (DI-IPSC-8 1445).
manuals is an alternative to the Software User Manual (SUM) (DI-IPSC-8 1443).
7.4

The Contract Data Requirements

List (CDRL) (C)D 1423)

should specify whether

This pair of

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
7.5

This DID supersedes

tool rather than in the form of a traditional document.


DI-IPSC-80695.

~, APPROVALUMITATION
limited Approvalfrom 12/5/94 through12/5/96
b. PREPA~
10.1

98. APPLIcABLEFORMS
I

Bb, AMSC NUMBER


hJ7087

Gene rat instruct ion$,

a.

Use of automated techniques is encouraged.


Auto mated t echniau~.
DID means a collection of data regardless of its medium,

b,

Alternate wese ntation stv le~. 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.

The term document

in this

(Continued on page 2)
fi . DISTRIBUTION
SIATEMENT
~lSTRIBUTION
1
1.
----

----

STATEMENT

--

WJ Form 1664, APR 89


, :./!73

A. Approved for public release; distribution is unlimited.


Previous editions are obsolete
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page ~

I
of J_ Pages

Software

10.

PREPARATION

INSTRUCTIONS

Center Operator Manual (SCOM)


D14PSC-8 1444
-- 10.1 General Instructions

(continued)

c.

Title traae or identifi~.


The document shall 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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

Table of contents and inde x. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing an alphabetic listing of key terms and concepts covered in the
document and the pages or paragraphs in which the terms or concepts are covered.
For data in a database or other alternative form, this information shall consist of an
for
internal or external table of contents containing pointers to, or instructions
accessing, each paragraph, figure, table, and appendix or their equivalents.

e.

Paae numb erindabe Iing. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

If a paragraph is tailored out of this DID, the


nse to ta ilorina instru ction~.
resulting document shall 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.

0 Jvlultide Dar@graDhs and subr)a raaraQ hs. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.
h.

If a data description required by this DID has been


Sta ndard data d~c riotion~.
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.

wit
ution of existina doc ument~. Commercial or other existing documents
substituted for all or part of the document if they contain the required data.

may be

10.2
co ntent reau irement$.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

1.

PREPARATION

-.

INSTRUCTIONS

Center Operator Manual (SCOM)


D14PSC-81444
-- 10.2

Content

Requirements

This section shall be divided into the following

(continued)

paragraphs.

1,1 ~entificat ion. This paragraph shall contain a full identification of the system and
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
st em overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Docu ment overview. This paragraph shall summarize the purpose and contents of this
manual and shall describe any security or privacy considerations associated with its use.
2. ~eferenced doc uments. This section shall list the number, title, revision, and date of all
This section shall also identify the source for all
documents referenced in this manual.
documents not available through normal Government stocking activities.
3.

software

summary.

This section shall be divided into the following

paragraphs.

ation. This paragraph shall provide a brief description of the intended


3.1 ~oftwa~tdic
uses of the software.
Capabilities, operating improvements, and benefits expected from its
use shall be described.
This paragraph shall identify all software files, including databases
~.
3.2 s
and data files, that must be installed for the software to operate. The identification shall
include security and privacy considerations for each file and identification of the software
necessary to continue or resume operation in case of an emergency.
This paragraph shall identify the hardware, software, manual
3.3 software environment.
operations, and other resources needed to install and operate the software.
Included, as
applicable, shall be identification of:
a.

Computer equipment that must be present, including amount of memory needed,


amount of auxiliary storage needed, and peripheral equipment such as terminals,
printers, and other input/output devices

b.

Communications

c.

Other software that must be present, such as networking software,


operating
systems, databases, data files, utilities, permanent files that are referenced, created,
or updated by the software; and databases/data files necessary to resume operation
in the event of emergencies

d.

Forms, procedures,

e.

Other facilities, equipment,

equipment that must be present

or other manual operations that must be present


or resources that must be present

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

Center Operator Manual (SCOMJ


DI-IPSC-B1444

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

This paragraph shall provide a brief


3.4 50 ftware oraaniza tion and overview of Wratio@.
description of the organization and operation of the software from the operators point of
view. The description shall include, as applicable:
a.

Logical

components

overview

of the

software,

of the purpose/operation

that

from

the

operators

point

of view,

and an

of each component

b.

Types of inputs/access
response to each type

can be made to the software

and the softwares

c.

The reports and other outputs that are produced by the software,
and privacy considerations for each

d.

Typical run times and factors that affect it

e.

Organization of software operation into runs. This description shall use a chart, if
applicable, showing how the different operations are interrelated. If sets of runs are
grouped by time periods or cycles, each set of integrated operations required on a
If runs may be grouped logically by
daily, weekly, etc., basis shall be presented.
organizational level, the groups of runs that can be performed by each organizational
processing, field activity processing, etc., shall be
level such as headquarters
presented.

f.

Any system restrictions, waivers of operational standards, information oriented


toward specific support areas (for example, library, small computer and teleprocessing support, interfaces with others ystems), or other special aspects of processing

9.

General description of the communications functions and processes of the software,


including, as applicable, a diagram of the communications
network used in the
system

including security

3.5 co ntinaencies and aIternate states and modes of oDeration. This paragraph shall explain
the differences in software operation at times of emergency and in various states and modes
of operation, if applicable.
3.6 ~ecu ritv and Drivacy. This paragraph shall contain an overview of the security and
privacy considerations associated with the software. A warning shall be included regarding
making unauthorized copies of software or documents, if applicable.
3.7 #assistance and Droblem reDo rtinQ. This paragraph shall identify points of contact and
procedures to be followed to obtain assistance and report problems encountered in operating
the software.
4.

Insta Ilation

must perform

or overwrite
precautions,

Page &

and setuD.

This

paragraph

to install the software

shall describe

on the equipment,

any procedures

to configure

that

the operator

the software,

to delete

former files or data, and to enter parameters for software operation.


marked by WARNING or CAUTION, shall be included where applicable.

of&
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Safety

Software

10.

PREPARATION

Center Operator Manual (SCOM)


D14PSC-81 444

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

5. Desc riDtion of runs. This section shall be divided into the following paragraphs to provide
Safety precautions, marked by WARNING or
a description of the runs to be performed.
CAUTION, shall be included where applicable.
5.1 Hun inventory. This paragraph shall provide a list of the runs to be performed, identifying
the software snd the jobs that make up each run. It shall include a brief summary of the
purpose of each run and shall relate the list to the run descriptions included in the remainder
of this section,
5.2 Phasiqg. This paragraph shall describe acceptable phasing of the software into a logical
A run may be phased to permit manual or semiautomatic checking of
series of operations.
intermediate results, to provide the user with intermediate results for other purposes, or to
permit a logical break if higher priority jobs are submitted.
An example of the minimum
division for most systems would be edit, file update, and report preparation.
This paragraph shall provide the setup and execution procedures
5.3 Piaanostic mocedure$
for any software diagnostics. included shall be procedures for validation and trouble shooting.
All parameters (both input and output), codes, and range values for diagnostic software shall
be explained,
This paragraph shall list all error messages output by the software,
5.4 ~ror messa~.
along. with the meaning and corresponding correction procedure for each message.
ion of eac h run.
5.5 R-c riDt
graphs.

This paragraph shall be divided into the following

subpara-

5.5.x
Run des cric)tion for (run name or ide ntifier}. This paragraph shall identify a run and
shall be divided into the following subparagraphs to describe the run.
This paragraph shall provide a listing of the run stream of job control
5.5. X.1 co ntrol i-.
statements needed to initiate the run.
5.5.x.2
Run management information. This paragraph shall provide the information
to manage the run including, as applicable:

needed

a.

Peripheral and resource requirements

b.

Security and privacy considerations

c.

Method of initiation, such as on request, after another run, or at a predetermined

d.

Estimated run time

e.

Required turnaround time

f.

Messages

9.

Procedures for taking check points

h.

Waivers from operational standards

and responses

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

time

Software Center Operator Manual (SCOM)


DI-IPSC-81444
10. PREPARATION INSTRUCTIONS -- 10.2 Content Requirements (continued)
5.5.x.3 Input-output files. This paragraph shall provide information about the files and
databases that serve as input to or that are created or updated by the run. Included for each
shall be information such as name, security and privacy, recording medium, retention
schedule, and disposition.
5.5.x.4 Output reports. This paragraph shall provide information about the reports that are
produced during the run. Included for each report shall be the following information, as
applicable: report identifier, product control number, report control symbol, title, security and
privacy, media (e.g., hard copy, magnetic tape), volume of report, number of copies, and
distribution of copies.
5.5.x.5 Reproduced output reports.
This paragraph shall provide information about
computer-generated reports that are subsequently reproduced by other means. Included for
each report shall be information such as report identification, security and privacy, reproduction
technique, paper size, binding method, number of copies, and distribution of copies.
5.5.x.6 Procedures for restart/recovery and continuity of operations. This paragraph shall
provide procedures to be followed by operator personnel concerning restart/recovery in the
event of a system failure and for continuity of operations in the event of emergencies.
6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall include an
alphabetical listing of all acronyms, abbreviations, and their meanings as used in this
document and a list of 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, 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.).

Page 6 of 6
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

hm Approved
OMB NO.0704-O 188

DATA ITEM DESCRIPTION


Ptilc r-mml

budonfol Canwtknof *

Inl-fnmlal

SOFTWARE

ntmmd

DESIGN

10 OVam

mcltxi,rm1-

110 houc #of r,

DESCRIPTION

Wnm tot rbbwwtrg

lmtructmcm.

(SDD)

aarclwm

xnwm

dmn

DI-IPSC-81435

3.

DE6cRlPTloNfPuRPosE

3.1 The Software Design Description (SDD) describes the design of a Computer Software Configuration
Item (CSCI). It describes the CSC1-wide design decisions, the CSCI architectural design, and the detailed
design needed to implement the software.
The SDD may be supplemented by Interface Design Descriptions
(IDDs) (DI-IPSC-81 436) and Database Design Descriptions (DBDDs) (DI-IPSC-81 437) as described in Block 7
below.
3.2 The SDD, with its associated IDDs and DBDDs, is used as the basis for implementing the software.
provides the acquirer visibility into the design and provides information needed for software support.

6.

6a. DTIC Applicable

APPROVAL DATE
OFFICEOF PRIMARYRESPONSIBILITY
~w
941205
EC
1
APPLICATION/lNTERREIATIONSlllP
?.
4.

It

GIDEPAPPUCABLE
Sb.

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 design of a CSCI.
Design petiaining to

7.3 Desisn pertaining to interfaces may be presented in the SDD or in IDDs.


databases may be presented in the SDD or in DBDDs.

7.4 The Contract Data Requirements List (CDRL) (DD 1423) 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.
7.5 This DID supersedes DI-MCCR-8001

2A, DI-IPSC-80691,

%. APPROVALLIMITATION
LimitedApprovalfrom 12/S/S4 through12/5/S6
.,

DI-MCCR-80304,

9a. APPLICABLEFORMS

and DI-MCCR-80306.

9b. AMSC NUMBER


N7078

10.1 Ge neral instruct ions.


a. Automated

tec hniaue$. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

b. Alternate wesentation
acceptable

substitutes

The term document

in this

stv Ies. Diagrams, tables, matrices, and other presentation styles are
for text when data required by this DID can be made more readable using

these styles.
(Continued on Page 2)

..
11.-DKTRIBUTK)NSTATEMENT
131!5TRIBUTION

STATEMENT

(.x$ ~om11664, APR 89


)5/123

A.

Approved

for public

release;

distribution

is unlimited.

Previous editions are obsolele


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page ~

of ~

1
Pages

Software

10.

PREPARATION

INSTRUCTIONS

Design Description
DI-IPSC-8 1435

(S00)

-- 10.1 General Instructions

(continued)

The document shall include a title page containing, as


Title naae or ide ntifier.
applicable:
document number; volume number; version/revision indicator; security

c.

markings
name,

or other

abbreviation,

restrictions
and

any

on the handling
other

identifier

of the document;
for the

system,

date;

document

subsystem,

title;

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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.
d.

Tab Ie of co ntent~.
number,

title,

shall contain a table of contents


of each titled paragraph,
figure, table,

The document

and page number

providing the
and appendix.

For data in a database or other alternative form, this information shall 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.

~ e numberina/labe Iinq. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

~Rn

9.

Ir e Da aarar.lhs and subD araar ao h~. Any section, paragraph, or subparagraph in


M ultm
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

~ndard
If a data description required by this DID has been
data desc riotion~.
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.

=itut

in r
in,
If a paragraph is tailored out of this DID, the
resulting document shall 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.

ion of existina doc ument~. Commercial or other existing documents may be


substituted for all or part of the document if they contain the required data.

Co n tent reau iremen~.


10.2
Content requirements begin on the following page.
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 examp(e, the paragraph
numbered 1.1 is understood to be paragraph 10.2.1.1
within this DID.

Page ~

of Jl_
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

1.

SCODQ.

INSTRUCTIONS

Design Description (SDD)


DIIPSC-81 435
-- 10.2

Content

Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 b ntificat ion. This paragraph shall 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

Svste m overview.

software

to which

and software;

This paragraph shall briefly state the purpose

this document

summarize

applies.

the history

It shall describe

of system

the general

development,

of the system
nature

operation,

and the

of the system

and maintenance;

user, developer, and support agencies; identify current


and planned operating sites; and list other relevant documents.

identify

the project

sponsor,

acquirer,

1.3 Pocu ment overview, This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2.
fe rented doc ument~. This section shall list the number, title, revision, and date of all
documents referenced in this document.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3.

Qsc l-wide d= ion de cision~.

present

CSC1-wide

design

This section

decisions,

that

shall be divided

is, decisions

about

into paragraphs
the CSCIS

as needed

behavioral

to

design

ignoring internal
implementation) and other decisions affecting the selection and design of the software units
that make up the CSCI. If all such decisions are explicit in the CSCI requirements or are
deferred to the design of the CSCIS software units, this section shall so state.
Design
decisions that respond to requirements designated critical, such as those for safety, security,
or privacy, shall be placed in separate subparagraphs.
If a design decision depends upon
system states or modes, this dependency shall be indicated. Design conventions needed to
understand the design shall be presented or referenced.
Examples of CSC1-wide design
decisions are the following:
(how

it will behave,

from a users point of view, in meeting its requirements,

a.

Design decisions regarding inputs the CSCI will accept and outputs it will produce,
including interfaces with other systems, HWCIS, CSCIS, 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 CSCI behavior in response to each input or condition, including


actions the CSCI 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 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,

and privacy

requirements.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION
e.

INSTRUCTIONS

Design Description (SDDI


DI-IPSC-81435
-- 10.2

Content Requirements

(continued)

Other CSC1-wide design decisions made in response to requirements, such as


selected approach to providing required flexibility, availability, and maintainability.

This section shall be divided into the following paragraphs to


describe the CSCI architectural design. If part or all of the design depends upon system states
or modes, this dependency shall 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 shall be presented or referenced.
4.

Csc I architectural

de si~.

Cl comDonen&.

4.1

a.

This paragraph shall:

Identify the software units that make up the CSCI.


assigned a project-unique identifier.
Note:

A software

unit is an element

in the design

Each software

of a CSCI;

unit shall be

for example,

a major

subdivision
of a CSCI, a component
of that subdivision,
a class, object, module,
function,
routine, or database.
Software
units may occur at different
levels of a
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 CSCI or as a software
unit. The SOD may refer to software units by any name(s) consistent with the design
methodology being used.
hierarchy

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 CSCI).

c.

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

d.

Identify each software units 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 shall provide identifying information,
such as name, version, documentation references, library, etc.

e.

Describe the CSCIS (and as applicable, each software units) planned utilization of
computer hardware resources (such as processor capacity, memory capacity,
input/output
equipment

device capacity,
capacity).

auxiliary

The description

storage capacity,
shall cover

and communications/network

all computer

hardware

resources

included in resource utilization requirements for the CSCI, in system-level resource


allocations affecting the CSCI, 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 SDD, this paragraph may
reference that source. Included for each computer hardware resource shall be:
Page ~

of ~
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

-- 10.2

(SDD)

Content Requirements

or system-level

(continued)

1)

The CSCI requirements

2)

The assumptions and conditions on which the utilization data are based (for
example, typical usage, worst-case usage, assumption of certain events)

3)

f.

INSTRUCTIONS

Design Description
D14PSC-81435

Any special considerations


memory,

overlays,

overhead,

library

affecting

or multiprocessors
software,

or other

resource allocations being satisfied

the utilization
or the

Isuch as use

impacts

implementation

of

of virtual

operating

system

overhead)

4)

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

5)

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

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

4.2 ~onceDt of execut ion. This paragraph shall describe the concept of execution among the
software units. It shall include diagrams and descriptions showing the dynamic relationship
of the software units, that is, how they will interact during CSCI operation, including, as
applicable, flow of execution control, data flow, 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 jnterface des inn. This paragraph shall be divided into the following subparagraphs to
describe the interface characteristics of the software units. It shall include both interfaces
among the software units and their interfaces with external entities such as systems,
is contained
in Interface
configuration items, and users. If part or all of this information
these sources may be
Design Descriptions
(IDDs), in section 5 of the SDD, or elsewhere,
referenced.
4.3,1

and diaaramS.
This paragraph
shall state the project-unique
Jnter face identification
identifier assigned to each interface and shall identify the interfacing
entities (software
units,

systems,

configuration

items,

users,

etc. ) by name,

The identification
characteristics (and therefore impose interface
are being developed or modified (thus having
or more interface diagrams shall be provided,
references,

as applicable.

number,

version,

and

documentation

shall state which entities have fixed interface


requirements on interfacing entities) and which
interface requirements imposed on them). One
as appropriate, to depict the interfaces.

4.3.x
JProiect -uniau e ide ntifier of inlerface~. This paragraph (beginning with 4.3.2) shall
identify an interface by project-unique identifier, shall briefly identify the interfacing entities,
and shall 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 shall be stated as assumptions or
as When [the entity not covered] does this, [the entity that is covered] will .... This

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page ~

of ~

Design Description (S00)


DI-IPSC-81 435

Software

10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content

Requirements

(continued)

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 shall include the following, as applicable, presented in any order suited to the
information to be provided, and shall note any differences in these characteristics from the
point of view of the interfacing entities (such as different expectations about the size,
frequency, or other characteristics of data elements):

a.
b.

Priority
Type

assigned

of interface

to the interface

by the interfacing

(such as real-time

data transfer,

entity (ies)
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)

d.

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural-language)

c)

DoD standard

data element

d)

Technical

e)

Abbreviation

name

(e.g.,

name

variable

or synonymous

name

or field name

in code

or database)

names

2)

Data type (alphanumeric,

integer, etc.)

3)

Size and format (such as length and punctuation

4)

Units

5)

Range or enumeration

6)

Accuracy

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

of a character string)

(such as meters, dollars, nanoseconds)

of measurement

of possible values (such as O-99)

(how correct) and precision (number of significant

digits)

entities) and recipients (using/receiving

entities)

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:
1)

Names/identifiers
a)

Project-unique

b)

Non-technical

c)

Technical

d)

Abbreviations

identifier
(natural language) name

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


or synonymous

names

2)

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

3)

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

4)

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

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

on the medium

Software

10.

PREPARATION

e.

INSTRUCTIONS

9.

-- 10.2

Content Requirements

(continued)

5)

Relationships among assemblies,

6)

Priority, timing, frequency, volume, sequencing, and other constraints, such as


whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources

(setting/sending

entities)

Characteristics of communication
the interface, such as:

such as sorting/access

and recipients

characteristics

(using/receiving

Project-unique

2)

Communication

3)

Message formatting

4)

Fiow control (such as sequence numbering and buffer allocation)

5)

Data

6)

Routing,

7)

Transmission

8)

Safety/security/privacy

transfer

identifier(s)
iinks/bands/frequencies/media

rate,

whether

addressing,

Characteristics
such as:

entities)

methods that the interfacing entity (ies) will use for

1)

periodic/aperiodic,

and naming

services,

compartmentalization,
f,

Design Description (SOD)


DI-IPSC-81435

including

and their characteristics

and interval

between

transfers

conventions
priority

considerations,

and grade
such as encryption,

user authentication,

and auditing

of protocols that the interfacing entity (ies) will use for the interface,

1)

Project-unique

2)

Priority/layer

3)

Packeting,

4)

Legality

5)

Synchronization,

6)

Status, identification,

identifier(s)
of the protocol

including

fragmentation

and reassembly,

routing,

and addressing

checks, error control, and recovery procedures


including connection establishment,

maintenance,

termination

and any other reporting features

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

entity (ies)

This section shall be divided into the following paragraphs to


deta iled des i~.
5. ml
describe each software unit of the CSCI. If part of all of the design depends upon system
states or modes, this dependency shall 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 shall 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).

Page J_
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

of&

Software

Design

Description

(SOD)

D14PSC-81 435
10.

PREPARATION

5.x
~aue
This paragraph

10.2

INSTRUCTIONS--

Content Requirements

(continued)

uni~.
ident ifier of a so ftware unit, or des irlnator o f a arouD of software
shall identify a software
unit by project-unique
identifier and shall describe the

The description shall include the following information, as applicable. Alternative y, 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.

unit.

a.

Unit design decisions, if any, such as algorithms to be used, if not previously selected

b.

Any constraints,

c.

The programming language to be used and rationale


specified CSCI 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-iine 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 shall 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) shall be referenced; interface characteristics
may be provided here or by referencing section 4 or the corresponding Interface
Design Description(s).

f.

[f the software unit contains


including, as applicable:

logic, the logic to be used by the software

1)

Conditions

in effect

the software

2)

Conditions

under which control is passed to other software

3)

Response and response time to each input, including data conversion, renaming,
and data transfer operations

4)

Sequence of operations and dynamically


software units operation, including:

5)

limitations,

or unusual features in the design of the software unit

within

for its use if other than the

unit when its execution

controlled

is initiated

units

sequencing

during the

a)

The method for sequence control

b)

The logic and input conditions


priority assignments

c)

Data transfer in and out of memory

d)

The sensing of discrete input signals, and timing relationships


interrupt operations within the software unit

of that method,

unit,

such as timing variations,

Exception and error handling

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

between

Software

Design Description (SDD)


DI-IPSC-81 435

10.
6.

PREPARATION
~irernents
a.

b.

INSTRUCTIONS

tracea bili~.

-- 10.2

Content Requirements

(continued)

This section shall contain:

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

from

each

CSCI

requirement

to

the

software

units

to

which

it is

allocated.

7. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale), This section shall include en
alphabetical
document

listing

of all

acronyms,

and a list of any terms

abbreviations,

and definitions

and

needed

their

meanings

to understand

as

used

in this

this document.

Dendixe~. Appendixes may be used to provide information published separately for


convenience in document maintenance (e. g., charts. classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided, Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).
A.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Form Approved
OMB NO.0704-0188

DATA ITEM DESCRIPTION


PIAJ8cmponuq
uon,

budm

10I colbctmn of ww mtmmmtm * -tlmm.o

smlurImJ uw mamutww

6! ltmocoil.ctwn ot infamaoa,
li~hway,

tit.

1204.

-tan,

110 how* pm t~oma,

to wu~

mchde~

tlu dma IIONID3 md comPIotttwawl mvwwcrg Mu COOOISIOF!


of Wntmmmn.

I@@IW

~tom

la mducw-g OW bcsdon to WmhIWlon

VA 22202-4302.

to lb

OttIm 01MUWOWMI

)+auowrg

ttw bud.n

Swwcoo, DIractomta of Op.rmom

md Budoot, P~wfxk

EmtIrw dm9

lfM tmu la r.vmwu-q Uwtru.mom, nmctvrq

S.rd commmm r~anil~

kduclmn

#d

atwnbt.

x.

w my orhu ~cl

1216 JoflomaI D-m

PIOIDCrKI704-O1OSI, WmhIfVIon

. DC 20603

CATION

SOFTWARE

DEVELOPMENT

PLAN (SDP)

N~

DI-IPSC-81427

3. DESCRIPTION/PURPDSE
3,1 The Software Development Plan (SDP) describes a developers plans for conducting a software
development effort. The term software development in this DID is meant to include new development,
modification, reuse, reengineering, maintenance, and all other activities resulting in software products.
3.2 The SDP provides the acquirer insight into, and a tool for monitoring, the processes to be followed for
software development, the methods to be used, the approach to be followed for each activity, and project
schedules, organization, and resources.

APPROVALDATE
S, OFFICE OF PRIMARYRESPONSIBILITY
~
941205
EC
APPLICATION/lNTERR~TIONSHIP

6s. DTIC APPLICABLE

4.

Sb. GIDEPAPPLKASLE
I

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 develop and record plans for conducting
development activities.
7.3 Portions of this plan may be bound separately if this approach enhances their usabiiity.
include plans for software configuration management and software quality assurance.

software

Examples

7.4 The Contract Data Requirements List {CDRL) (DD 1423) 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 mav reside in a computer-aided software engineering

(CASH or other automated tool rather than in the form of a traditional document.
7.5 This DID supersedes DI-MCCR-80030A,
DI-MCCR-80300,
and DI-MCCR-80319.

B. APPROVALLIMITATIDN
LimitedApprovalfrom 12/S/94 through1215fB6
TO. PREPARATION
~S

10.1 @neral

DI-MCCR-80297,

DI-MCCR-80298,

9a. APPLEABLEFORMS
I

DI-MCCR-80299,

%. AMSC NUMBER
N7070
I

instru ction~.

a,

Automated tec hniaues. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium,

The term document

in this

b,

Alternate wese ntation sty Ies, Diagrams, tables, matrices, and other presentation styles are
acceptable substitutes for text when data required bv this DID can be made more readable using
these styles.

(Continued on Page 2J
11. DWTRlaUTtONSTATEMENT
DISTRIBUTION
:.
Cir
rorm

STATEMENT

--------1004, bar~ us

A.

Approved

for public release;

distribution

is unlimited.

Previous editions are obsolete

135/123

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page J_ ot -Q

Pages

Software

10.
c.

PREPARATION
Title

D~e

INSTRUCTIONS

o r ide ntifier.

Development Plan (SDP)


DI-IPSC-81427
-- 10.1 General Instructions

The document

shall include

a title

(continued)
page containing,

as appli-

cable: 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 in a database or other alternative form, this information
shall be included on external and internal labels or by equivalent identification methods.
d.

The document shall contain a table of contents providing the


Table of co nten~.
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall consist of an
internal or external table of contents containing pointars to, or instructions for
accessing, each paragraph, figure, table, and appendix or their equivalents.

e.

Paae n umbe rirmllabe IinQ. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Resoonse
to ta ilorina instruct ion$.
If a paragraph
is tailored
out of this DID, the
paragraph number and title, followed
resulting document shall contain the corresponding
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.

9.

Jylultic)le DaraaraDhs and subDa ra9raD hS. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

standard data desc ricNionS. 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.

@bst itut ion of existirm doc umen~. Commercial or other existing documents, including
other project plans, may be substituted for all or part of the document if they contain
the required data.

10.2
nte nt reau iremen~.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

1.

PREPARATION

INSTRUCTIONS

Development Plan (SDP)


D14PSC-81427
-- 10.2

Content

Requirements

(continued)

&.QBQ. This section shall be divided into the following paragraphs.

1.1 Identificat ion. This paragraph shall 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 svstem overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 ~ment
overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
1.4 Relationship to other clans. This paragraph shall describe the relationship,
SDP to other project management plans.

if any, of the

This section shall list the number, title, revision, and date of all
2. Pe ferenced doc umen~.
This section shall also identify the source for all
documents referenced in this plan.
documents not available through normal Government stocking activities.
3. Qve rview of reau ired work. This section shall be divided into paragraphs as needed to
It shall include, as
for the planning described in later sections.
establish the context
applicable, an overview of:
a.

Requirements

and constraints

on the system

b.

Requirements

and constraints

on project

c.

Position

d.

The selected

e.

Requirements

f.

Other

of the project

program/acquisition
and constraints

requirements

standards,

in the system

and software

to be developed

documentation

life cycle

strategy
on project

or any requirements
schedules

or constraints

on it

and resources

such as on project security, privacy, methods,


in hardware and software development, etc.

and constraints,

interdependencies

4. Plan s for Derformina ae nerd software deve!oK)ment aCt iviti~. This section shall be divided
into the following paragraphs.
Provisions corresponding to non-required activities may be
satisfied by the words Not applicable. If different builds or different software on the project
require different planning, these differences shall be noted in the paragraphs. In addition to
the content specified below, each paragraph shall identify applicable risks/uncertainties and
plans for dealing with them.
4.1
are de veloDment rxocess. This paragraph shall describe the software development
process to be used. The planning shall cover all contractual clauses concerning this topic,
identifying planned builds, if applicable, their objectives, and the software development
activities to be performed in each build,

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page ~

of JJ)_

Software

10.

PREPARATION

NSTRUCTIONS

4.2 @nerel o18ns pr software


following subparagraphs.

Development Plan (SDP)


DI-IPSC-81427
-- 10.2

Content Requirements

develoomen~.

This paragraph

{continued)

shall be divided into the

4.2.1
This paragraph shall describe or reference the
so ftware develoofnent methods.
software development methods to be used. Included shall be descriptions of the manual and
automated tools and procedures to be used in support of these methods. The methods shall
Reference may be made to other
cover all contractual clauses concerning this topic.
paragraphs in this plan if the methods are better described in context with the activities to
which they will be applied.
4.2.2
This paragraph shall describe or reference the
Sta ndards for so ftware moducts.
standards to be followed for representing requirements, design, code, test cases, test
procedures, and test results. The standards shall cover all contractual clauses concerning this
topic. Reference may be made to other paragraphs in this plan if the standards are better
described in context with the activities to which they will be applied. Standards for code shalt
be provided for each programming language to be used. They shall include at a minimum:
a.

Standards for format


information)

b.

Standards for header comments {requiring, for example, namefidentifier of the code;
version identification;
modification
history; purpose; requirements and design
decisions implemented;
notes on the processing (such as algorithms used,
assumptions,
constraints, limitations, and side effects); and notes on the data
(inputs, outputs, variables, data structures, etc.)

c.

Standards for other comments

d.

Naming conventions

e.

Restrictions,

if any,

f.

Restrictions,

if any, on the complexity

4.2.3
Reusable so ftware
subparagraphs.

(such as indentation,

capitalization,

and order of

(such as required number and content expectations)

for variables, parameters,


on the use of programming

modu~.

spacing,

packages,
language

procedures, files, etc.


constructs

or features

of code aggregates

This paragraph

shall be divided into the following

4.2.3.1
This paragraph shall describe the
software I)rOduu.
!nco rrloratirw rzle
approach to be followed for identifying, evaluating, and incorporating reusable software
products, including the scope of the search for such products and the criteria to be used for
their evaluation.
It shall cover all contractual clauses concerning this topic. Candidate or
selected reusable software products known at the time this plan is prepared or updated shall
be identified and described, together with benefits, drawbacks, and restrictions, as applicable,
associated with their use.
4.2.3.2
Jlevelooina reusable so ftware moduct~. This paragraph shall describe the approach
to be followed for identifying, evaluating, and reporting opportunities for developing reusable
software products. It shall cover all contractual clauses concerning this topic.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Development Plan (SOP)


DI-IPSC-8 1427
-- 10.2

Content Requirements

(continued)

This paragraph shall be divided into the following


Hand Iina o f critical reau irement~.
subparagraphs
to describe the approach to be followed for handling requirements designated
4.2.4

critical. The planning in each subparagraph shall cover all contractual clauses concerning the
identified topic.
4.2.4.1

Safety

4.2.4.2

Security

4.2.4.3
4.2.4.4

Assurance

4.2.5

assurance

Privacy

assurance
assurance
of other

critical

requirements

so mwte r hardware resou rce ut ilization.

This paragraph

to be followed
for allocating
computer
hardware
resources
It shall cover all contractual
clauses concerning
this topic.

shall describe

and monitoring

the approach

their

utilization.

This paragraph shall describe the approach to be followed for


recording rationale that will be useful to the support agency for key decisions made on the
project.
It shall interpret the term key decisions for the project and state where the
rationale are to be recorded. h shall cover all contractual clauses concerning this topic.

4.2.6

Feco rdina

rationale.

4.2.7
Access for acau irer review,
This paragraph shall describe the approach to be
followed for providing the acquirer or its authorized representative access to developer and
subcontractor facilities for review of software products and activities.
It shall cover all
contractual clauses concerning this t epic.
ns for Derformina deta iled software de veloDment act ivitie$. This section shal( be
5.
divided into the following paragraphs. Provisions corresponding to non-required activities may
be satisfied by the words Not applicable. If different builds or different software on the
project require different planning, these differences shall be noted in the paragraphs.
The
discussion of each activity shall include the approach (methods/procedures/tools)
to be applied
to: 1 ) the analysis or other technical tasks involved, 2) the recording of results, and 3) the
preparation of associated deliverables, if applicable.
The discussion shall also identify
applicable risks/uncertainties
and plans for dealing with them. Reference may be made to
4.2.1 if applicable methods are described there.
This paragraph shall be divided into the following
5.1
Proiect dannina and oversiaht.
subparagraphs to describe the approach to be followed for project planning and oversight.
The planning in each subparagraph shall cover all contractual clauses regarding the identified
topic.
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6

Software development planning {covering updates to this plan)


CSCI test planning
System test planning
Software installation planning
Software transition planning
Following and updating plans, including the intervals for management

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

review

Software

10.

PREPARATION

INSTRUCTIONS

Development Plan (SOP)


DI-IPSC-81427
-- 10.2

Content

Requirements

(continued)

This paragraph shall be divided into


~lishina
a soft ware de veloDme nt environme~.
5.2
the following subparagraphs to describe the approach to be followed for establishing,
controlling, and maintaining a software development environment.
The planning in each
subparagraph shall cover all contractual clauses regarding the identified topic.
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5

Software engineering environment


Software test environment
Software development library
Software development files
Non-deliverable software

5.3
s vste mr eauirements ~ nalvsi . This paragraph shall be divided into the following
subparagraphs
to describe the approach to be followed for participating in system
shall cover all contractual
clauses
requirements analysis. The planning in each subparagraph
regarding

the identified

5.3.1
5.3.2
5.3.3

topic.

Analysis of user input


Operational concept
System requirements

5.4
ste m des ian. This paragraph shall be divided into the following subparagraphs to
describe the approach to be followed for participating in system design. The planning in each
subparagraph shall cover all contractual clauses regarding the identified topic.
5.4.1
5.4.2

System-wide design decisions


System architectural design

This paragraph shall describe the approach to be


software reau irements analv*.
5.5
followed for software requirements analysis. The approach shall cover all contractual clauses
concerning this topic.
ftware des i~.
This paragraph shall be divided into the following subparagraphs to
5.6
describe the approach to be followed for software design. The planning in each subparagraph
shall cover all contractual clauses regarding the identified topic.
5.6.1
5.6.2
5.6.3

CSC)-wide design decisions


CSCI architectural design
CSCI detailed design

~oftwwe
imc)lementation and unit test ing. This paragraph shall be divided into the
5.7
following subparagraphs to describe the approach to be followed for software implementation
The planning in each subparagraph shall cover all contractual clauses
and unit testing
regarding the identified topic.
5.7.1
5.7.2
5.7.3
5.7.4
5.7.5

Software implementation
Preparing for unit testing
Performing unit testing
Revision and retesting
Analyzing and recording unit test results

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

5.8

PREPARATION

INSTRUCTIONS

lJnit intea ration and test ing.

Development Plan (SDP)


DI-IPSC-8 1427
-- 10.2

This

Content Requirements

paragraph

shall be divided

(continued)
into the following

sub-

to be followed for unit integration and testing.


The
planning in each subparagraph shall coverall contractual clauses regarding the identified topic.

paragraphs

5.8.1
5.8.2
5.8.3
5.8.4

to describe

the approach

Preparing for unit integration and testing


Performing unit integration and testing
Revision and retesting
Analyzing and recording unit integration and test results

5,9
GSC I aua Iificat ion test ing, This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for CSCI qualification testing.
The
planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
5.9.1
5.9.2
5.9.3
5.9.4
5.9.5
5.9.6
5,9.7
5.10

Independence in CSCI qualification testing


Testing on the target computer system
Preparing for CSCI qualification testing
Dry run of CSCI qualification testing
Performing CSCI qualification testing
Revision and retesting
Analyzing and recording CSCI qualification test results

Csc l/HWCl

intea ration

and test

q.

This paragraph

subparagraphs
to describe
the appr~ch
to be followed
integration
and testing.
The planning in each subparagraph

regarding the identified


5.10.1
5.10.2
5.10.3
5.10.4

shall be divided

into the following

in CSC1/HWCl
for participating
shall cover all contractual clauses

topic.

Preparing for CSC1/HWCl integration and testing


Performing CSC1/HWCl integration and testing
Revision and retesting
Analyzing and recording CSCUHWCI integration and test results

5.11 Svste m aua Iificat ion te stinq. This paragraph shall be divided into the following subparagraphs to describe the approach to be foliowed for participating in system qualification
testing. The planning in each subparagraph shall cover all contractual clauses regarding the
jdentif ied topic.
5.11.1
5.11.2
5.11,.3
5.11.4
5.11.5
5.11.6
5.11.7

Independence in system qualification testing


Testing on the target computer system
Preparing for system qualification testing
Dry run of system qualification testing
Performing system qualification testing
Revision and retestirlg
Analyzing

and recording

system

qualification

test

results

This paragraph shall be divided into the following sub5.12 Prer)arin~ for software use.
paragraphs to describe the approach to be followed for preparing for software use. The
planning in each subparagraph shall coverall contractual clauses regarding the identified topic.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

5.12.1
5.12.2
5.12.3
5.12.4

INSTRUCTIONS

Development Plan (SDP)


DI-IPSC-81427
-- 10.2

Content

Requirements

(continued)

Preparing the executable software


Preparing version descriptions for user sites
Preparing user manuals
Installation at user sites

This paragraph shall be divided into the following


5.13 PreDarina for ~ ftware transi~.
subparagraphs to describe the approach to be followed for preparing for software transition.
The planning in each subparagraph shall cover all contractual clauses regarding the identified
topic.
5.13.1
5.13.2
5.13.3
5.13.4
5,13.5
5.13.6
5.13,7

Preparing
Preparing
Preparing
Preparing
Updating
Preparing
Transition

the executable software


source files
version descriptions for the support site
the as built CSCI design and other software
the system design description
support manuals
to the designated support site

support information

5.14 software c onfiau ration manaae men~. This paragraph shall be divided into the following
subparagraphs
to describe the approach to be followed
for software
configuration
management. The planning in each subparagraph shall cover all contractual clauses regarding
the identified topic.
5.14.1
5.14.2
5.14.3
5.14,4
5.14.5

Configuration identification
Configuration control
Configuration status accounting
Configuration audits
Packaging, storage, handling, and delivery

5.15 software modu~ eva I@tion. This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for software product evaluation.
The
planning in each subparagraph shall coverall contractual clauses regarding the identified topic.
5.15.1
5.15.2
5.15.3

In-process and final software product evaluations


Software product evaluation records, including items to be recorded
Independence in software product evaluation

5.16 software aual itv assura nc~. This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for software quality assurance.
The
planning in each subparagraph shall coverall contractual clauses regarding the identified topic.
5,16.1
5.16.2
5.16.3

Software quality assurance evaluations


Software quality assurance records, including items to be recorded
Independence in software quality assurance

Page J!_ of ~
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Development Plan (SOP)


DI-IPSC-81427
-- 10.2

Content Requirements

(continued)

5.17 ~orrective act ion. This paragraph shall be divided into the following subparagraphs to
describe the approach to be followed for corrective action. The planning in each subparagraph
shall cover all contractual clauses regarding the identified topic.
5.17.1

5.17.2

Problem/change reports, including items to be recorded (candidate items


include project name, originator, problem number, problem name, software
element or document affected,
origination date, category and priority,
description, analyst assigned to the problem, date assigned, date completed,
analysis time, recommended solution, impacts, problem status, approval of
solution,
follow-up
actions,
corrector,
correction
date,
version where
corrected,

correction

Corrective

action

time,

description

of solution

implemented)

system

This paragraph shall be divided into the


5.18 Joint tec hnical and manaae ment reviews.
following subparagraphs to describe the approach to be followed for joint technical 8nd
management reviews. The planning in each subparagraph shall cover all contractual clauses
regarding the identified topic.
5.18.1
5.18.2

Joint technical reviews, including a proposed set of reviews


Joint management reviews, including a proposed set of reviews

This paragraph shall be divided into the


5.19 $)ther software development act ivitie~.
following subparagraphs to describe the approach to be followed for other software
development activities. The planning in each subparagraph shall cover all contractual clauses
regarding the identified topic.
5.19.1
5.19.2
5.19.3
5,19.4
5.19.5
5.19.6
5.19.7
5.19.8
6.

Risk management, including known risks and corresponding strategies


Software management indicators, including indicators to be used
Security and privacy
Subcontractor management
Interface with software independent verification and validation (lV&V) agents
Coordination with associate developers
Improvement of project processes
Other activities not covered elsewhere in the plan

~chedu Ies and activitv netwo rk. This section shall present:
a.

Schedule(s) identifying the activities in each build and showing initiation of each
activity, availability of draft and final deliverables and other milestones,
and
completion of each activity

b.

An activity network, depicting sequential relationships and dependencies among


activities and identifying those activities that impose the greatest time restrictions on
the project

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10,

PREPARATION

INSTRUCTIONS

Development Plan (SDP)


D14PSC-81427
-- 10.2

Content

Requirements

(continued)

This section shall be divided into the following


7. ~ct
omanizat ion and resou rces.
paragraphs to describe the project organization and resources to be applied in each build.
structure
to be
7.1 Proiect oraanizat ion. This paragraph shall describe the organizational
used on the project, including the organizations involved, their relationships to one another,
and the authority and responsibility of each organization for carrying out required activities.

7.2 Proiect resources.


This paragraph
project. It shall include, as applicable:
a.

shall describe the resources to be applied to the

Personnel resources, including:


1)

The estimated staff-ioading

for the project (number of personnel over time)

2)

The breakdown of the staff-loading numbers by responsibility (for example,


management, software engineering, software testing, software configuration
management, software product evaluation, software quality assurance)

3)

A breakdown of the skill levels, geographic locations, and security clearances of


personnel performing each responsibility

b.

Overview of developer facilities to be used, including geographic locations in which


the work will be performed, facilities to be used, and secure areas and other features
of the facilities as applicable to the contracted effort.

c.

Acquirer-furnished equipment, software, services, documentation, data, and facilities


required for the contracted effort.
A schedule detailing when these items will be
needed shall also be included.

d.

Other required resources, including a plan for obtaining the resources, dates needed,
and availability y of each resource item.

8.
Notes.
This section shall contain any general information
that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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. Atme ndixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DATA ITEM DESCRIPTION

Form Approved
OMR NO. 0704-0188

3.1 The Software Input/Output Manual (SIOM) tells a user how to access, submit inputs to, and interpret
output from, a batch or interactive software system that is run by personnel in a computer center or other
centralized or networked software installation.

3.2 The SIOM is developed for software systems that will be installed in a computer center or other
centralized or networked software installation, with users accessing the system via terminals or personal
computers or submitting and receiving inputs and outputs in batch mode.

PROVALDATE
941205
APPLkATION/l~lsHIP

4.

~m

OFFICEOF PRIMARYRESPONSIBILITY
EC

6~. DTIC APPLICABLE

6b. GIDEP APPLKASLE

7,1 This Data Item Description (D1D) contains the format and content preparation instructions
product generated by specific and discrete task requirements as delineated in the contract,

for the data

7.2 This DID is used when the developer is tasked to identify and record information needed by persons
who will submit inputs to, and recieve outputs from, software, relying on others to operate the software in
a computer center or other centralized or networked software installation.

7.3 This DID is often used with the Software Center Operator Manual [SCOM) (D14PSC-,81 444).
Df manuals is an alternative to the Software User Manual (SUM I (DI-IPSC-81 443).

This pair

7.4 The Contract Data Requirements List (CDRL] (DD 1423) 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 suppon 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,
7.5

This DID supersedes

DI-IPSC-80693,

s. A PPROVM

UMITATION
timitod Approvalfrom 12/6/94 through12/6/B6

9~. APPUCABLEFORMS

9b. AMSC NUMBER


N7088

)0. ~lONS

10>1
a.

GQnera I instru ctions,


niaue$.

Automate-h

Use of automated

techniques

is encouraged.

The term document in this

DID means a collection of data regardless of its medium.


b.

Alternate wesentation stvle$, Diagrams, tables, matrices, and other presentation styles are
acceptable substitutes
these styles.

for text when data required by this DID can be made more readable using
(Continued

on Page 2)

11. DISTRIBUTIONSTATEMENT
!IISTRIBUTION
/ .
<..
)~ F~~

STATEMEhJT

f 664, APR 89

A.

Approved

for public release;

distribution

is unlimited.

Previous editions
are obsolete
Source: https://assist.dla.mil
-- Downloaded:
2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page ~

of &

PaOes

Software

10.

PREPARATION

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81445
-- 10.1

General

Instructions

(continued)

c.

Title ~
or identifi~.
The document shall include a title page containing, as
applicable:
document number; volume number; versionhevision 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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

Table of contents and index. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing en alphabetic listing of key terms end concepts covered in the
document and the pages or paragraphs in which the terms or concepts are covered.
or other alternative
form, this information
shalJ consist of an
For data in a database
internal
accessing,

or external
each

table

paragraph,

of

contents

figure,

table,

containing

pointers

and appendix

to,

or

instructions

for

or their equivalents.

e.

Paae numb rinallabe Iing. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

n se to ta ilorirm instruct ion~, If a paragraph is tailored out of this DID, the


resulting document shall 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.

Muhide Daraara~hs end subr)a rararaohs. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

standard data desc ricXionS. 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.

~ub~t itut ion of existina docu ment$. Commercial or other existing documents may be
substituted for all or part of the document if they contain the required data.

ReSDO

10.2
co ntent reau irerne nt~.
Content requirements begin on the following page.
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
within this DID.
numbered 1.1 is understood to be paragraph 10.2.1.1

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
&QRQ.

Input/Output Manual (SIOM)


DIIPSC-81 445

INSTRUCTIONS

-- 10.2

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 Jdentificat ion. This paragraph shall 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

~m

overview.

This paragraph

shall briefly

state the purpose

of the system

and the

software
to which this document
applies.
It shall describe the general nature of the system
and software;
summarize
the history of system development,
operation,
and maintenance;

user, developer, and support agencies; identify current


and planned operating sites; and list other relevant documents.
identify

the project

sponsor,

acquirer,

This paragraph shall summarize the purpose and contents of this


1.3 DOCUment o verview.
associated
with its use.
manual and shall describe any security or privacy considerations
20 fieferenced doc ument~. This section shall list the number, title, revision, and date of all
This section shall also identify
the source for all
documents referenced in this manual.
documents

3.

not available

so ftware

3.1

so ftware

summary.

through

Government

stocking

activities,

This section shall be divided into the following

acmlicat ion.

uses of the software.


use shall be described.

normal

This

paragraph

Capabilities,

operating

shall provide

paragraphs,

a brief description

improvements,

of the intended

and benefits

expected

from

its

This paragraph shall identify the software files, if any, including


3.2 soft ware inventorv.
databases and data files, that the user is responsible for requesting in order to access the
The identification shall include security and privacy
software described in this manual.
considerations for each file and identification of the software necessary to continue or resume
operation in case of an emergency.
3.3 software environmen~. This paragraph shall identify the hardware, software, manual
operations, and other resources needed to access and use the software. This paragraph shall
be based on the assumption that the software is installed in a computer center or other
centralized or networked environment and shall focus on the resources that a user must have
to access and use the software in that environment.
Included, as applicable, shall be
identification of:
a.

Computer equipment
input/output devices

b.

Communications

c.

Other software

d.

Forms, procedures,

e.

Other facilities,

that must be present,

equipment

such as terminals,

printers,

that must be present

that must be present, such as networking

software

or other manual operations that must be present

equipment,

or resources that must be present

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

or other

Software

10.

PREPARATION

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81445
-- 10.2

Content

Requirements

(continued)

3.4 software organization and we rview of WO ration. This paragraph shall provide a brief
description of the organization and operation of the software from the users point of view.
The description shall include, as applicable:
a.

Logical components of the software, from the users point of view, including
databases and data files the user can access, Database Management
Systems
(DBMSS), and communications paths, and an overview of the purpose/operation of
each component

b.

Performance

characteristics

that can be expected

by the user, such as:

1)

Types, volumes, rate of inputs accepted

2)

Types, volume, accuracy,

3)

Typical response time and factors that affect it

4)

Typical processing time and factors that affect it

5)

Limitations, e.g, restrictions on what data maybe queried and from what location

6)

Error rate that can be expected

7)

Reliability that can be expected

rate of outputs that the software

can produce

c.

Relationships of the functions performed by the software with interfacing systems


and with the organizations or stations that are sources of input or recipients of output

d.

Supervisory
software

controls that can be implemented

(such as passwords} to manage the

and alternate states and modes of ooe ration. This paragraph shall explain
at times of emergency
the user will be able to do with the software
and in various states and modes of operation, if applicable.
3.5

co ntinaencies

the differences

in what

3.6 ~ecu rity and Drivacy. This paragraph shall contain an overview of the security and
privacy considerations associated with the software. A warning shall be included regarding
making unauthorized copies of software or documents, if applicable.
3.7 &Qstance
and cwoblem reDortin~. This paragraph shall identify points of contact and
in using the
procedures to be followed to obtain assistance and report problems encountered
software.

4.
This section shall be divided into the following paragraphs to
Ys ina the software.
describe how to prepare inputs to, and interpret output from, the software.
If the software
has a query capability, this paragraph shall reference section 5 for a description of this
If the software can be accessed via terminal, this paragraph shall reference
capability.
Sections 6 through n to describe terminal processing procedures. Safety precautions, marked
by WARNING or CAUTION, shall be included where applicable.
4.1 Initiation mocedure~. This paragraph shall contain the procedures that must be followed
to initiate use of the software. Included maybe information such as sample job request forms
or sample control statements.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

4.2

_tion

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81445
-- 10.2

Content Requirements

(continued)

This paragraph shall be divided into the following subparagraphs.

of inDu&.

4.2.1
This paragraph shall describe the conditions to be observed in
Lnout co ndition~.
preparing each type or class of input to the software.
The conditions shall include the
following, as applicable:
a.

Reason for input, such as normal status report, need to update data

b.

Frequency of input, such as monthly,

c.

Origin of input, such as the organization

d.

Medium of input, such as magnetic tape

e.

Related inputs that are required to be entered at the same time as this input

f.

Other applicable information,

on demand
or station authorized to generate the input

such as priority; security and privacy considerations

4.2,2
jnr)ut formats. This paragraph shall illustrate the layout formats to be used in the
preparation of inputs to the software and shall explain the information that may be entered
in the various sections and lines of each format.
4.2.3
ComDos ition rules. This paragraph shall describe any rules and conventions that must
be observed to prepare inputs. The rules of syntax, usage of punctuation, etc., shall be
explained. The rules shall include the following, as applicable:
a.

Input transaction

length, such as 100 characters maximum

b.

Format conventions,

c.

Labeling, such as usage of identifiers to denote major data sets to the software

d.

Sequencing,

e.

Punctuation,
such as spacing and use of symbols (virgule, asterisk, character
combinations, etc. ) to denote start and end of input, of data groups, and of fields

f.

Restrictions,

such as all input items must be left-justified

such as order and placement

of items in the input

such as rules forbidding use of particular characters or parameter sets

4.2.4
)nout vocabu Iary. This paragraph shall explain the legal character combinations or
codes that must be used to prepare inputs. An appendix may be provided containing an
ordered listing of these codes.
-4.2.5
Sa mc)le inDu~. This paragraph shall provide examples that illustrate and explain each
Included shall be information on the
type or class of input acceptable by the software.
following types of inputs, as applicable:
a.

Headers denoting the start of input

b.

Text or body of the input

c.

Trailers denoting the end of input

d.

Portions of the input that may be omitted

e.

Portions of the input that may be repeated

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

Input/Output

Manual

(SIOM)

DI-IPSC-81445
10.

PREPARATION

4.3

De= ripJion

INSTRUCTIONS

-- 10.2

Content

Requirements

(continued)

This paragraph shall be divided into the following subparagraphs.

of ou~.

4.3.1
~e neral desc ricNion. This paragraph
applicable, for each type or class of output:

shall provide the following

information,

as

a.

Reasons why the output is generated

b.

Frequency of the output, such as monthly, on demand

c.

Any modifications

d.

Media, such as printout, display screen, tape

e.

Location where the output will appear, such as in the computer area or remotely

f.

Any additional characteristics, such as priority, security and privacy considerations,


the information
in this output
associated outputs that complement

or variations of the basic output that are available

4.3.2
Ut formats. This paragraph shall illustrate and explain the layout of each typa
or class of output from the software. The following aspects shall be explained, as applicable:
a.

Security and privacy markings

b.

Data that may appear in headers

c.

Information that may appear in the body or text of the output,


headings and subsets or sections in the output format

d.

Data that may appear in trailers

e.

Additional

characteristics,

including column

such as the meaning of special symbols

4.3.3
SamD Ie outDu&. This paragraph shall provide illustrations of each type or class of
A description of each sample shall be provided, including, as
output from the software.
applicable:
a.

Meaning and use of each column, entry, etc.

b.

Source, such as extracted

c.

Characteristics,

from database,

such as when omitted,

calculated

range of values, unit of measure

4.3,4
9utDut vocabu Iary. This paragraph shall describe any codes or abbreviations that
appear in the output that differ from those used in the input described in paragraph 4.2.4.
4.4 Use of outDu~.
This paragraph shall explain the use of the output by the operational
area or activity that receives it.
4.5

Recovery

generated

and e rror corre ction

by the software,

Drocedu re~.

give their

meanings,

This

paragraph

and describe

shall

list the

the corrective

error
actions

codes
to be

Also included shall be the procedures to be followed by the user with


taken by the user.
respect to restart, recovery, and continuity of operations in the event of emergencies.
This paragraph shall describe the diagnostic procedures
4.6 so mmunications diaanostic~.
available to the user for validating communications
and for identifying and classifying
problems.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81445
-- 10.2

Content Requirements

rwocedu re~. This section shall be prepared for software


5. ~rv
It shall be divided into the following paragraphs.

(continued)
with a query capability.

5.1
ta file format. This paragraph shall provide a users view of the format and
content of each database and data file that can be queried. Figure 1 provides an example.
Information such as the following shall be provided for each data element, as applicable:
a.

Data element name

b.

Synonymous

c.

Definition

d.

Format

e.

Range and enumeration

f.

Unit of measurement

9.

Data item names, abbreviations,

names

of values

and codes

5.2 Cluerv caoab ilities. This paragraph shall identify and describe the preprogrammed and
An example of preprogrammed queries
ad hoc query capabilities provided by the software.
is shown in Figure 2.
This paragraph shall provide instructions for preparing queries.
5.3 Querv weoa ration.
Figure 3 shows an example of the format for a preprogrammed query. Figure 4 shows an
example of a query statement.
5.4 co ntrol instruct ionq. This paragraph shall provide instructions for the sequencing of runs
and other actions necessary to extract responses to query requests. These instructions shall
include control statements that may be required by the computer system or software.
6. User te rminal mocess irm clrocedu re~. This section shall be divided into the following
paragraphs to provide the user with information on the use of terminals to accomplish
processing.
If the procedures are complicated or extensive, Sections 7 through n may be
added in the same paragraph structure as this section and with titles meaningful to the
sections selected. The organization of the document will depend on the characteristics of the
software being documented.
For example, sections might be based on the organizations in
which users work, their assigned positions, work sites, or the tasks they must perform. For
other software, it may be more appropriate to have Section 6 be a guide to menus, Section
7 be a guide to the command language, and Section 8 be a guide to functions.
Detailed
procedures are intended to be presented in paragraphs 6.2 through 6.5. Depending on the
design of the software, the subparagraphs might be organized on a function-by-function,
menu-by-menu, transaction-by -transaction, or other basis. Safety precautions, marked by
WARNING or CAUTION, shall be included where applicable.
6.1 Available ca~a bilitie~. This paragraph shall describe in general terms the capabilities for
retrieval, display, and update of data through terminal operations.
6,2 Access II r ocedu re~. This paragraph shall present the sequence
applicable rules pertaining to accessing the software to initiate software

of steps and any


operations.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81445
-- 10.2

Content Requirements

(continued)

This paragraph shall be divided into


6.3 Qiscdav, uDdates. and ret rieval I)rocedu r=.
subparagraphs to provide the step-by-step procedures necessary to produce the displays,
updates, and retrievals that are available through the use of a terminal. Each procedure shall
include the name of the operation, input formats, and sample responses, as applicable.
6.4 Reco verv and e rror correction mocedu res. This paragraph shall identify error messages
that may be displayed and shall indicate their meanings and any corrective actions that should
be taken. Also included shalt be any procedures to be followed by the user with respect to
restart, recovery, and continuity of operations in the event of emergencies.
6.5 Termination rlrocedure~.
to terminate the processing.

This paragraph shall present the sequence of steps necessary

7. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall include an
and their meanings as used in this
alphabetical listing of all acronyms, abbreviations,
document and a list of terms and definitions needed to understand this document. If section
6 has been expanded into section(s) 7,..., this section shall be numbered as the next section
following section n.
ndix~.
Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided, Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).
~.

ADDO

Page _& of JQ_


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Input/Output Manual (SIOM)


DI-IPSC-81 445
-- 10.2

Format

of

ITEM NAME

FORMAT .

ORG-NAME
ORG-ID
SOC-SEC-NO
NAME
PAY-GRADE
GROSS-PAY
GROSS-PAY-YTD
FED-TAX
FED-TAX-YTD
FICA
FICA-YTD
STATE-TAX
STATE-TAX-YTD
STATE-TAX-CODE
ALLOTMENTS
NET-PAY

30
6AN
9N
20
4AN
6
8
6
8
6
8
6
8
2
6
6

Content Requirements

Data

(continued)

Record
RANGE OF
VALUES

AN

UNIT OF
MEASUREMENT

I-9,A-Z
l-9,A-Z
o-9
---

AN

---

0-9
0-9
0-9
0-9
0-9
0-9
0-9
0-9
B3-F6
0-9
0-9

SN
SN
SN
SN
SN
SN
SN
SN
AN
SN
SN

Dollars
Dollars
Dollars
Dollars
Dollars
Dollars
Dollars
Dollars
Dollars
Dollars

AN = Alphanumeric
SN = Signed Numeric

Figure

1. Example of data record format.

Preprogrammed

Query Capabilities

DESCRIPTION

QUERY CODE

Number of employees within an organization


Number of employees in a specific pay grade
Total gross pay for employees within an
organization
State tax year-to-date for specific state
FICA tax year-to-date for a specific employee
Total deductions for a specific employee
Net pay for a specific employee

Figure

2.

Example of preprogrammed

query capability.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

A
B
c
D
E
F
G

Software

10

PREPARATION

Input/Output Manual (SIOMl


DI-IPSC-81445

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

Format of Query A

NUMBER OF EMPLOYEES WITHIN AN ORGANIZATION


CONTENT/
COMMENT

CHARACTER

QUERY ITEM

POSITIoN
Query Designator
File Number
Query Number
Security Classification
Query Card Format Code
Organization

Figure3.

1
2-3
4-5
10
12
14-19

Q
01

Constant
Constant
Insert 01-99
Unclassified

A
Insert ORG-ID
as requested by
query. Refer to
data format for
applicable code.

Example of query format.

I
Query Statement
Request - No. of employees within an organization
(Office of Secretary
of Defense)
Query Statement - IF ORG-ID EQ OSD LIST NO OF EMPLOYEES

Figure4.

Page JQ.

of lJ)_

Example of query statement.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

form Approved
OMB NO. O 704-0188

DATA ITEM DESCRIPTION


P@tc

rqortIrxI

8Mca,

bwdm

oattuarq

d th

cdlactmn

HIohww,

Sdta

10! cdkctwn
ntdr4uoru

of !dummmn,
120d,

Muwrm,

of t-

tndidIIw

a!!mslu!

tnto?mmm!

rfn dsu ru.dbd

ud

~tmm

VA 222024302.

~lIfw
fof m6ucIIw

-d

to f-

to svu~

110 how

unl r.vmwrq
Off I-

tb

bXOM

ttn

to Wnlwwmn

of MDUOWII

mclcdIrQ Vu Itima to, tevrnwma

FNI r~,

colhctmn
d Idamatmn.
Hoalquwtom

md 0~1,

Pwwort

%r.ma,
R.ducom

tqwIcwQ

Owoetorata

01 0prM,w9

P?W.CI !0704.01

ud

MmtIra dote

-uchrq

trw budcn

-I,mao

%ports,

881, Wtitwtm

w my
1216

SOFTWARE

INSTALLATION

PLAN (SIP)

oh

htt-

mc+-t
OWtt

OC 20603

2. l~E~ON

1.TITLE

3.

lfwtructmm

cnmmmts

DI-IPSC-81428

DESCRIPTM3WPURPOSE

3.1 The Software Installation Plan (SIPI is a plan for installing software at user sites, including
preparations, user training, and conversion from existing systems.
3.2 The SIP is developed when the developer will be involved in the installation of software at user sites
and when the installation process will be sufficiently complex to require a documented plan. For software
embedded in a hardware-software system, a fielding or deployment plan for the hardware-software system
may make a separate SIP unnecessary.

4.

AFPR OVAL DATE

OFFICE OF PRIMARY RESPONSIBILITY

Sb. GIDEP APPLICABLE

EC. DTIC APPLICABLE

EC

941205

>. APPUCAT
ION/lN~RUTIONSHIP
~m

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 develop and record plans for performing software
installation and training at user sites.
7,3 The Contract Data Requirements List (CDRL) (DD 1423) should specify whether deliverable data areto
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 sotiware engineering
{CASE) or other automated tool rather than in the form of a traditional document.
7.4 This DID supersedes DI-IPSC-80699.

s. APPROVAL
UMITATION
Limited Approval from

~f).

PREPARATION

10.1

98.

12iW94 through 12/6/96

9b.

APPLICABLE FORMS

AMSC NUMBER

N7071

lN~NS

General instructions.

a. Auto mated tec hniaue$. Use of automated techniques is encouraged. The term document in this
DID means a collection of data regardless of its medium.
b. Alternate mesentation stvles 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.
(Continued on Page 2)
11. DISTRIBUTION

STATEMENT

DISTRIBUTION STATEMENT
D Form 1664, APR89
135/123

A.

Approved for public release; distribution is unlimited.

Previous editions
are obsolete
Source: https://assist.dla.mil
-- Downloaded:
2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page ~

.
of A Pages

Software

10.

PREPARATION

INSTRUCTIONS

Installation Plan (SIP)


DI-IPSC-81428

-- 10.1 General Instructions

(continued)

c.

or ide ntifier.
The document shall include a title page containing, as
Title DW
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 in a database or other alternative form, this information
shall be included on external and internal labels or by equivalent identification methods.

d.

Table of co nten~.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Paae numberinaflabe Iinq. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

ResDonse to ta ilorirm instruct ionS. If a paragraph is tailored out of this DID, the
resulting document shall 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.

Mukicde D aracrraDhs and subr)a raara Dh$. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

~andard
data descriDt ions.
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.

Commercial or other existing documents


Su bstitution of existina documents.
substituted for all or part of the document if they contain the required data.

may be

10.2
content reau irement~.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
Si.Q.

INSTRUCTIONS

Installation Plan (SIP)


DI-IPSC-8 1428

-- 10.2

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 Identificat ion. This paragraph shall 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
m overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3
rview. This paragraph shall summarize the purpose and contents of this
plan and shall describe any security or privacy considerations associated with its use.
1.4 j3elatio nshiD to ot her dan~, This paragraph shall describe the relationship, if any, of the
SIP to other project management plans.
This section shall list the number, title, revision, and date of all
2. Referenced docu mens.
This section shall also identify the source for all
documents referenced in this plan.
documents not available through normal Government stocking activities.
3. Installation overview.
This section shall be divided into the following
provide an overview of the installation process.

paragraphs

to

3.1 D- riDtion. This paragraph shall provide a general description of the installation process
to provide a frame of reference for the remainder of the document. A list of sites for software
installation, the schedule dates, and the method of installation shall be included.
3.2 Contact DOint. This paragraph shall provide the organizational name, office symbol/code,
and telephone number of a point of contact for questions relating to this installation.
This paragraph shall list the type, source, and quantity of support
3.3
materials needed for the installation.
Included shall be items such as magnetic tapes, disk
packs, computer printer paper, and special forms.
3.4 Training. This paragraph shall describe the developers plans for training personnel who
will operate and/or use the software installed at user sites. Included shall be the delineation
between general orientation, classroom training, and hands-on training.
3.5 Tasks. This paragraph shall list and describe in general terms each task involved in the
software installation. Each task description shall identify the organization that will accomplish
the task, usually either the user, computer operations, or the developer. The task list shall
include such items as:
a.

Providing overall planning, coordination,

b.

Providing personnel for the installation

and preparation

for installation

team

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

I o.

PREPARATION

INSTRUCTIONS

Installation Plan (SIP)


DI-IPSC-8 1428

-- 10.2

Content Requirements

(continued)

c.

Arranging lodging, transportation,

and office facilities for the installation

d.

Ensuring that all manuals applicable to the installation

e.

Ensuring that all other prerequisites

f.

Planning and conducting

9.

Providing students for the training

h.

Providing computer support and technical assistance for the installation

i.

Providing for conversion from the current system

team

are available when needed

have been fulfilled prior to the installation

training activities

This paragraph shall describe the number, type, and skill level of the
3.6 Personnel.
personnel needed during the installation period, including the need for multishift operation,
clerical support, etc.
3.7 Secu ritv ~ n d Drivacy. This paragraph shall contain
privacy considerations associated with the system.

an overview

of the security and

4. ~ite-sDec ific information for software center ODerations staff. This section applies if the
software will be installed in computer center(s) or other centralized or networked software
installations for users to access via terminals or using batch inputs/outputs.
If this type of
installation does not apply, this section shall contain the words Not applicable.
4.x jSite name). This paragraph shall identify a site or set of sites and shall be divided into
the following subparagraphs to discuss those sites. Multiple sites may be discussed together
when the information for those sites is generally the same.
4.x. 1
schedule. This paragraph shall present a schedule of tasks to be accomplished during
installation.
It shall depict the tasks in chronological order with beginning and ending dates
of each task and supporting narrative as necessary.
~oftware inventory. This paragraph shall provide an inventory of the software needed
4.x.2
to support the installation. The software shall be identified by name, identification number,
version number, release number, configuration, and security classification, as applicable. This
paragraph shall indicate whether the software is expected to be on site or will be delivered
for the installation and shall identify any software to be used only to facilitate the installation
process.
4.x.3
Facilities. This paragraph shall detail the physical facilities and accommodations
This description shall include the following, as
needed during the installation period.
applicable:
a.

Classroom, work space, and training aids needed, specifying hours per day, number
of days, and shifts

b.

Hardware

c.

Transportation

Page *

of &

that must be operational and available


and lodging for the installation team

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

4.x.4
team.

INSTRUCTIONS

Installation Plan (SIP)


DI-IPSC-81428

-- 10.2

Content Requirements

(continued)

Jnstal~m
tea m. This paragraph shall describe the composition
Each team members tasks shall be defined.

of the installation

4.x.5
Insta nation tvocedure$,
This paragraph shall provide step-by-step procedures for
References may be made to other documents, such as
accomplishing the installation.
operator manuals. Safety precautions, marked by WARNING or CAUTION, shall be included
where applicable. The procedures shall include the following, as applicable:
a.

Installing the software

b.

Checking out the software

c.

Initializing databases and other software

d.

Conversion from the current system, possibly involving running in parallel

e.

Dry run of the procedures in operator and user manuals

once installed
with site-spec]flc

data

4.x.6
Data uDdate Dr oced ures. This paragraph shall present the data update procedures to
be followed during the installation period. When the data update procedures are the same as
normal updating or processing procedures, reference may be made to other documents, such
as operator manuals.
This section shall provide installation
5. ~ite-sDec ific information for software us ers.
planning pertinent to users of the software. When more than one type of user is involved, for
example,
users at different positions, performing different functions,
or in different
organizations, a separate section (Sections 5 through n) may be written for each type of user
and the section titles modified to reflect each user.
5.x jSite namel. This paragraph shall identify a site or set of sites and shall be divided into
the following subparagraphs to discuss those sites. Multiple sites may be discussed together
when the information for those sites is generally the same.
5.x. 1
~Q.
This paragraph shall present a schedule of tasks to be accomplished by
the user during installation, It shall depict the tasks in chronological order including beginning
and ending dates for each task and supporting narrative as necessary.
installation mocedu re~. This paragraph shall provide step-by-step procedures for
5.x.2
accomplishing the installation.
Reference may be made to other documents, such as user
manuals. Safety precautions, marked by WARNING or CAUTION, shall be included where
applicable. The procedures shall include the following, as applicable:
a.

Performing the tasks under 4.x.5

if not performed

by operations staff

b.

Initializing user-specific data

c.

Setting up queries and other user inputs

d.

Performing sample processing

e.

Generating

f.

Conversion from the current system, possibly involving running in parallel

9,

Dry run of procedures in user manuals

sample reports

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Installation Plan {SIP)


DI-IPSC-81428

-- 10.2

Content Requirements

(continued)

5.x.3
Data @ate
Dr ocedu re~. This paragraph shall be divided mto subparagraphs to
present the users data update procedures to be followed during the installation period. When
update procedures are the same as normal processing, reference may be made to other
documents, such as user manuals, and to Section 4 of this document
6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall Include an
alphabetical
listing of all acronyms, abbreviations,
and their meanings as used in this
document and a list of terms and definitions needed to understand this document. If section
5 has been expanded into section(s) 6 ,... n, this section shall be numbered as the next section
following section n.
A. AL)Dendixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Page &

of Ji_
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Form Approved
0M8 NO. 0704-0188

DATA ITEM DESCRIPTION


P*1Ic mwtwg budonfof cotiactmn
owca

odvww

ot WY- colktwn
H~hway,
1.

mamnmw

d tiwmmmn,

Suto

1204,

&lw@m,

of 1*

dcwm.tmm

tkm dma rwdcd


WAJIIIIW

s~mtu

vA222024302.

n -tam*led

md cawd.tmo

to SV*ICW

to! MCIWIIW *
d

~ 10 ruwm

ud rovtewme
bu4m

r-

fnomn.

tho colloctIm

to W-WIOII

to On OifIca d M UtaOUWM!

ud

mctdfw

of U#wmmmn
~uutwt

Ewdoct, PumfwOrk

thi
**

%rwcu,
RahCtmn

tmw fm IW.mwmb-

nt,uclmfm

CIWIU..MO

I.ODMIW

DWSCIWU*

of OPGtatIOIU ad

%OPCI (0704-01881,

2.

TITLE

SOFTWARE

PRODUCT

SPECIFICATION

WWcbw

ttw budui

aomma

~ono.

WMIUIWIOII

xmn-w

ama

a my ot?w -c!
1216

.lotbmon

Dswa

, DC 20603

lDENTIFICA TK)N NUMBER

(SPS)

DI-IPSC-81441

3. DE6CRlPT10N/PURPOBE
3.1 The Sohware Product Specification (SPS) contains or references the executable software, source files,
and software suppofi information, including as built design information and compilation, build, and
modification procedures, for a Computer Sottware Configuration Item (CSCI).
3.2 The SPS can be used to order the executable sotiware and/or source files for a CSCI and is the primaw
software suppcr~ document for the CSCI. Note: Different organizations have different policies for ordering
delivery of software. These policies should be determined before applying this DID.

4.

APPROVAL

DATE

6a.

S. OFFICE OF PRIMARY RESPONSIBILITY

941205

~w

EC

DTIC APPLICABLE

Sb . QIDEP APPUCASLE

7. APPUCATION/lNTERRELATONSHIP

7,1 This Data hem 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 prepare executable software, source files, as built
CSCI design, and/or related support information for delivery.
7.3 The Contract Data Requirements List (CDRLI (DD 1423) 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.
7,4 This DID supersedes DI-MCCR-80029A,

D14PSC-80696, and DI-MCCR-8031 7.

B. APPROVAL
UMITATION
Limited Approval from 12/S/94

)0. ~ARAtlON
10.1

Ge

9~. APPLICABLE
FORMS
through 12/5/96

9b. AMSCNUMBER
N7084

INSTRUCTIONS

neral instruction$.

a. Automated tec hniaues. Use of automated techniques is encouraged. The term document in this
DID means a collection of data regardless of its medium.
b. Alternate wesentation stvle$. 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.
{Continued on Page

i?.
OISTRIBUTDN

STATEMENT

IISTRIBUTIC)N STATEMENT
,. .-- .?.. --- -.
135/1

23

A. Approved for public release; distribution is unlimited.


-.
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

.,-

2)

Software

10.

PREPARATION

INSTRUCTIONS

Product Specification
DI-IPSC-81 441

(SpS)

-- 10.1 General Instructions

(continued)

c.

Title D~
or ide ntifier w ith sirmature blocks. The document shall 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; distribution statement; and signature blocks for the developer representative
authorized to release the document, the acquirer representative authorized to approve
the document, and the dates of release/approval.
For data in a database or other
alternative form, this information shall be included on external and internal labels or by
equivalent identification methods.

d.

Table of conten~.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Paae numbe rinallab cling. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

ResDo n se to ta iIor ina instruct ions.


If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Multide Daraaraohs and subDaraaraDhs.


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

h.

[f a data description required by this DID has been


Sta ndard data desc riotion~.
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.

-tit
ution of existina docu ment~. Commercial or other existing documents
substituted for all or part of the document if they contain the required data.

may be

10.2
Content requirements begin on the following page.
The
m ntent reau irement~.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
&?RQ.

INSTRUCTIONS

Product Specification
DI-IPSC-81441
-- 10.2

(SPS)

Content Requirements

This section shall be divided into the following

(continued)

paragraphs,

1.1 Identificat ion. This paragraph shall 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 Mte m overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Docu ment overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Referenced docu ment~. This section shall list the number, title, revision, and date of all
documents referenced in this specification.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
This section shall be divided into the following paragraphs to achieve
3. Reau irement~.
delivery of the software and to establish the requirements that another body of software must
meet to be considered a valid copy of the CSCI.
Note: In past versions of this DID, Section 3 required a presentation of the software
That approach was modeled on hardware
design describing the as built software.
development,
in which the product specification presents the final design as the
requirement to which hardware items must be manufactured. For software, however, this
approach does not apply. Software manufacturing consists of electronic duplication of
the software itself, not recreation from design, and the validity of a manufactured copy
is determined by comparison to the software itself, not to a design description.
This
section therefore establishes the software itself as the criterion that must be matched for
a body of software to be considered a valid copy of the CSCI. The updated software
design has been placed in Section 5 below, not as a requirement, but as information to
be used to modify, enhance, or otherwise support the software.
If any portion of this
specification is placed under acquirer configuration control, it should be limited to Section
3. It is the software itself that establishes the product baseline, not a description of the
softwares design.
ecutab Ie softwa r~. This paragraph shall provide, by reference to enclosed or otherwise
3.1
provided electronic media, the executable software for the CSCI, including any batch files,
command files, data files, or other software files needed to install and operate the software
on its target computer(s).
In order for a body of software to be considered a valid copy of the
CSCIS executable software, it must be shown to match these files exactly.
file . This paragraph shall provide, by reference to enclosed or otherwise
3.2 s~
provided electronic media, the source files for the CSCI, including any batch files, command
files, data files, or other files needed to regenerate the executable software for the CSCI. In
order for a body of software to be considered a valid copy of the CSCIS source files, it must
be shown to match these files exactly.
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS--

Product Specification
DI-IPSC-81441
10.2

(SpS)

Content Requirements

This paragraph
3.3 Packaaina reau irement~.
packaging and marking copies of the CSCI.

shall state

(continued)

the requirements,

if any,

for

4. Qua Iificat ion movision~.

This paragraph shall state the method(s) to be used to


demonstrate that a given body of software is a valid copy of the CSCI. For example, the
method for executable files might be to establish that each executable file referenced in 3.1
has an identically-named
counterpart in the software in question and that each such
counterpart can be shown, via bit-for-bit comparison, check sum, or other method, to be
identical to the corresponding executable file.
The method for source files might be
comparable, using the source files referenced in 3.2.
5. so ftware suDI)o rt information. This section shall be divided into the following paragraphs
to provide information needed to support the CSCI.
5.1 t4s built so ftware des ian. This paragraph shall contain, or reference an appendix or
other deliverable document that contains, information describing the design of the as built
CSCI. The information shall be the same as that required in a Software Design Description
(SDD), Interface Design Description (IDD), and Database Design Description (DBDD), as
applicable. If these documents or their equivalents are to be delivered for the as built CSCI,
If not, the information shall be provided in this
this paragraph shall reference them.
document.
Information provided in the headers, comments, and code of the source code
listings may be referenced and need not be repeated in this section. If the SDD, IDD, or DBDD
is included in an appendix, the paragraph numbers and page numbers need not be changed.
5.2 so mDilation/bu ild mocedu re~. This paragraph shall describe, or reference an appendix
that describes, the compilation/build process to be used to create the executable files from
the source files and to prepare the executable files to be loaded into firmware or other
distribution media. It shall specify the compiler(s) /assembler(s) to be used, including version
numbers; other hardware and software needed, including version numbers; any settings,
options, or conventions to be used; and procedures for compiling/assemblingt
linkingc and
building the CSCI and the software system/subsystem
containing the CSCI, including
variations for different sites, configurations, versions, etc. Build procedures above the CSCI
level may be presented in one SPS and referenced from the others.
5.3 Mod ificat ion rlrocedu re~. This paragraph shall describe procedures that must be followed
to modify the CSCI. It shall include or reference information on the following, as applicable:
a.

Support facilities,

equipment,

and software,

b.

Databases/data

c.

Design, coding, and other conventions

d.

Compilation/build

e.

Integration

and procedures for their use

files used by the CSCI and procedures for using and modifying them
to be followed

procedures if different from those above

and testing procedures to be followed

5.4 Comtwte r hardware resource utilization.


This paragraph shall describe the as built
CSCIS measured utilization of computer hardware resources (such as processor capacity,
memory
capacity,
input/output
device
capacity,
auxiliary
storage
capacity,
and
communications/network
equipment capacity). It shall coverall computer hardware resources

Page &

of J_

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Product Specification
DI-IPSC-81441
-- 10.2

(SPS)

Content Requirements

(continued)

included in utilization requirements for the CSCI, in system-level resource allocations affecting
the CSCI, or in the software development plan. If all utilization data for a given computer
hardware resource is presented in a single location, such as in one SPS, this paragraph may
reference that source. Included for each computer hardware resource shall be:

6.

a.

The CSCI requirements


or system-level
resource allocations
being satisfied.
(Alternatively, the traceability to CSCI requirements may be provided in 6.c. )

b.

The assumptions and conditions on which the utilization data are based (for example,
typical usage, worst-case usage, assumption of certain events)

c.

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)

d.

The units of measure used (such as percentage


second, bytes of memory, kilobytes per second)

e.

The level(s) at which the estimates or measures have been made (such as software
unit, CSCI, or executable program)

Requirements

trac eabilitv.

of processor capacity,

cycles per

This section shall provide:

a. Traceability

from each CSCI source file to the software

b. Traceability

from each software

unit(s) that it implements.

unit to the source files that implement it.

c. Traceability from each computer hardware resource utilization measurement


5.4 to the CSCI requirements it addresses. (Alternatively, this traceability
provided in 5.4. )
d. Traceability from each CSCI requirement regarding computer
utilization to the utilization measurements given in 5.4.

hardware

given in
may be

resource

7. ~ot~,
This section shall contain any general information that aids in understanding this
specification (e. g., background information, glossary, rationale), This section shall 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.
endixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

hrm Approved
OMB NO. 0704-0188

DATA ITEM DESCRIPTION


Pdm

r.FI.artIw

-c-,

bma.n

eathwrw

d tt-m caoocrwn
!+Iahwmy. Suto

tw cdkclton

ua+ mm.latmm
of ttiorm~tlm,
1204,

Arlqwm,

of !hn mlwmwmn
lb

dala rmd.d

mcIudItw LQOOWICWWtw IUAXIIXI


VA 22202-4302.

to VUQW

w .8t8m@9d

and compkt,m
md to t-

OW@

1 !0 Iwws

PW ruvonm

and I.. NWIFW ttm colbdton


ttm budm

to w-h-son

d Manwrwnon!

4ncluLtIw tho IIme to, IOWI.

of tnlormmwn
He@

S.nd

UUIWO .5-w-.

nd SudOaI. P-rwwk

R9dIJcIIm

Dt,ectaal*

SOFTWARE

REQUIREMENTS

SPECIFICATION

lIW bwdon

Of OPW 11-

pfOPCT 10704.01881.

2.

T ITLE

T.

WIIW11UIIUCIION. NWCIWW

Cc.nmunta mowdtw

MIlmaa

-is.

WafVWWUI

8xI011w data
w any ottm

1216

DC 20603

KIEN71FICATION

EM)

MSMC1

J* ff*r*o@ D~WIS

NUMBER

DI-IPSC-81433

3. DESCRIPTION/PURPOSE
3.1 The Software Requirements Specification (SRS) specifies the requirements for a Computer Software
Configuration kern (CSCI) and the methods to be used to ensure that each requirement has been met.
Requirements pertaining to the CSCIS external interfaces may be presented in the SRS or in one or more
Interface Requirements Specifications (IRSS) (DI-IPSC-81 434) referenced from the SRS.
3.2 The SRS, possibly supplemented by IRSS, is used as the basis for design and qualification testing of a

Csclo
4.

APPROVAL

~m

DATE

5.

OFFICE OF PRIMARY RESPONSIBILITY

6s.

6b . GIDEP APPLICABLE

DTIC APPLICAeLE

EC

941205

A PPLICATION/lNTER RELATIONSHIP
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 software requirements to be
met by a CSCI.
7.3

Requirements pertaining to CSCI interfaces may be presented in the SRS or in IRSS.

7.4 The Contract Data Requirements List (CDRL) (DD 1423) 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.
7.5 This DID supersedes DI-MCCR-80025A

6.

APPROVAL LIMITATION
Limited Approval from 12/5/94

and DI-MCCR-80301.

9a,
through 12/5/96

APPLICABLE FORMS

9b.

AMSC

NUMBER

N7076

?0. PREPARAT I ON tNSTRUCT IONS

10.1 Ge neral instructions.


a, Automated techniaues. Use of automated techniques is encouraged. The term document in this
DID means a collection of data regardless of its medium.
b, Alternate wesentation styIe$. 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.
(Continued on page 2)
~1. blsTRIBUTION STATEMENT
)15fR161JT10N

STATEMENT

--------I Form 1654, APR 89


3/123

A. Approved for public release; distribution is unlimited.


Previous editions are obsolete
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

..-
PageJ_ or J)_ Pages

Software

10.

PREPARATION

Requirements Specification
DI-IPSC-81433

INSTRUCTIONS

(SRS)

-- 10.1 General Instructions (continued)

c.

Title oaae or ide ntifier with signature blocks. The document shall 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; distribution statement; and signature blocks for the developer representative
authorized to release the document, the acquirer representative authorized to approve
the document, and the dates of release/approval.
For data in a database or other
alternative form, this information shall be included on external and internal labels or by
equivalent identification methods.

d.

Table of contents.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, tabie, and appendix.
For data in a database or other alternative form, this information shall 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.

Paae num berina/labe IinQ. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f,

If a paragraph is tailored out of this DID, the


J3esoon se to ta ilorina instruct ions.
resulting document shall 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.

9.

and subDa raaraD h~. Any section, paragraph, or subparagraph in


Multide DWaQraDhS
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

Sta ndard data desc riK)tions. 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.

Commercial or other existing documents may be


Subst itut ion of existina docu men&
substituted for all or part of the document if they contain the required data.

10.2
Content requirements begin on the following page.
The
co ntent rea uiremenM.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
~coDQ.

Requirements Specification
D14PSC-81 433

INSTRUCTIONS

-- 10.2

(SRS)

Content Requirements

(continued)

This section shall be divided into the following paragraphs.

1.1 Identificat ion. This paragraph shall 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 Mte m overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Pocu ment overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Referenced do cuments. This section shall list the number, title, revision, and date of all
documents referenced in this specification.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Reau irementS. This section shall be divided into the following paragraphs to specify the
CSCI requirements, that is, those characteristics of the CSCI that are conditions for its
acceptance.
CSCI requirements are software requirements generated to satisfy the system
requirements allocated to this CSCI. Each requirement shall be assigned a project-unique
identifier to support testing and traceability and shall be stated in such a way that an objective
test can be defined for it. Each requirement shall be annotated with associated qualification
method(s) (see section 4) and traceability to system (or subsystem, if applicable) requirements
[see section 5a) if not provided in those sections. The degree of detail to be provided shall
be guided by the following rule: Include those characteristics of the CSCI that are conditions
for CSCI acceptance; defer to design descriptions those characteristics that the acquirer is
willing to leave up to the developer. If there are no requirements in a given paragraph, the
paragraph shall so state. If a given requirement fits into more than one paragraph, it may be
stated once and referenced from the other paragraphs.
3.1 Reau ired states a nd modes. If the CSCI is required to operate in more than one state or
mode having requirements distinct from other states or modes, this paragraph shall identify
and define each state and mode. Examples of states and modes include: idle, ready, active,
post-use analysis, training, degraded, emergency,
backup, wartime,
peacetime.
The
A
CSCI
may
be
described
in
terms
of
distinction between states and modes is arbitrary.
states only, modes only, states within modes, modes within states, or any other scheme that
is useful. If no states or modes are required, this paragraph shall so state, without the need
to create artificial distinctions. If states and/or modes are required, each requirement or group
of requirements in this specification shall be correlated to the states and modes.
The
correlation may be indicated by a table or other method in this paragraph, in an appendix
referenced from this paragraph, or by annotation of the requirements in the paragraphs where
they appear.

Page ~
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

of JJ)_

Software

10.

PREPARATION

Requirements Specification
DI-IPSC-81 433

INSTRUCTIONS

-- 10.2

(SRS)

Content Requirements

(continued)

This paragraph shall be divided into subparagraphs to


3.2 Csc I ca~ab ilitv reau irement~.
itemize the requirements associated with each capability of the CSCI.
A capability is
The word capability may be replaced with
defined as a group of related requirements.
function, subject, object, or other term useful fw presenting the requirements.
3.2.x
JCSC I caDa bilitvl. This paragraph shall identify a required CSCI capability and shall
itemize the requirements associated with the capability. If the capability can be more clearly
specified by dividing it into constituent capabilities, the constituent capabilities shall be
specified in subparagraphs. The requirements shall specify required behavior of the CSCI and
shall include applicable parameters, such as response times, throughput times, other timing
constraints, sequencing, accuracy, capacities (how much/how many), priorities, continuous
The
operation requirements, and allowable deviations based on operating conditions.
requirements shall include, as applicable, required behavior under unexpected, unallowed, or
out of bounds conditions, requirements for error handling, and any provisions to be
incorporated into the CSCI to provide continuity of operations in the event of emergencies.
Paragraph 3.3.x of this DID provides a list of topics to be considered when specifying
requirements regarding inputs the CSCI must accept and outputs it must produce.
3.3 J2SCI exe rnal interface rea uirement$. This paragraph shall be divided into subparagraphs
to specify the requirements, if any, for the CSCIS external interfaces. This paragraph may
reference one or more Interface Requirements Specifications (IRSS) or other documents
containing these requirements.
3.3.1
Interface ident ification and diaarams.
This paragraph shall identify the required
external interfaces of the CSCI (that is, relationships with other entities that involve sharing,
providing or exchanging data). The identification of each interface shall include a projectunique identifier and shall designate the interfacing entities (systems, configuration items,
users, etc. ) by name, number, version, and documentation references, as applicable. The
identification shall 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 shall be provided to depict the interfaces.
JProiect-uniaue ide ntifier of interface].
3.3.x
This paragraph (beginning with 3.3.2) shall
identify a CSCI external interface by project-unique
identifier, shall briefly identify the
interfacing entities, and shall be divided into subparagraphs
as needed to state the
requirements imposed on the CSCI to achieve the interface. Interface characteristics of the
other entities involved in the interface shall be stated as assumptions or as When [the entity
not covered] does this, the CSCI shall ..., not as requirements on the other entities. This
paragraph may reference other documents
(such as data dictionaries, standards for
Cornryiunicatic)n
protocols, and standards for user interfaces) in place of stating the information
here. The requirements shall include the following, as applicable, presented in any order
suited to the requirements, and shall note any differences in these characteristics from the
point of view of the interfacing entities (such as different expectations about the size,
requency, or other characteristics of data elements):
a.

Priority that the CSCI must assign the interface

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

Requirements Specifictition
DI-IPSC-81433
-- 10.2

INSTRUCTIONS

(SRS)

Content Requirements

(continued)

b.

Requirements on the type of interface (such as real-time data transfer, storage-andretrieval of data, etc. ) to be implemented

c.

Required characteristics of individual data elements


store, send, access, receive, etc., such as:
1)

d.

that the CSCI must provide,

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural-language)

c)

DoD standard data element name

d)

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

e)

Abbreviation

or synonymous

name

names

2)

Data type (alphanumeric,

integer, etc.)

3)

Size and format (such as length and punctuation

4)

Units of measurement

(such as meters, dollars, nanoseconds)

5)

Range or enumeration

of possible values (such as O-99)

6)

Accuracy

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

of a character string)

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

entities) and recipients (using/receiving

entities)

Required characteristics of data element assemblies (records, messages, files, arrays,


displays, reports, etc.) that the CSCI must provide, store, send, access, receive, etc.,
such as:
1)

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

2)

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

3)

Medium (such as disk) and, structure of data elements/assemblies

4)

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

5)

Relationships

6)

Priority, timing, frequency, volume, sequencing, and other constraints, such as


whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources {setting/sending

among assemblies,

such as sorting/access

on the medium

characteristics

entities) and recipients (using/receiving

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

entities)

Software

10.

PREPARATION
e.

f.

9.

Requirements Specification
DI-IPSC-81433

INSTRUCTIONS

Required characteristics
interface, such as:

-- 10.2

(SRS)

Content Requirements

of communication

(continued)

methods that the CSCI must use for the

1)

Project-unique

identifier(s)

2)

Communication

3)

Message formatting

4)

Flow control (such as sequence numbering and buffer allocation)

5)

Data transfer rate, whether

6)

Routing, addressing, and naming conventions

7)

Transmission

8)

Safety/security/privacy
compartmentalization,

links/bands/f requencies/media

periodic/aperiodic,

and their characteristics

and interval between

transfers

services, including priority and grade

Required characteristics

considerations,
and auditing

such as encryption,

user authentication,

of protocols the CSCI must use for the interface,

1)

Project-unique

2)

Priority/layer

3)

Packeting,

4)

Legality checks, error control, and recovery procedures

5)

Synchronization,

6)

Status, identification,

such as:

identifier(s)
of the protocol

including fragmentation

and reassembly,

including connection establishment,

routing, and addressing

maintenance,

termination

and any other reporting features

Other required characteristics,


such as physical compatibility of the interfacing
entities (dimensions, tolerances, loads, plug compatibility, etc.), voltages, etc.

3.4 cs~ I internal interface reau irements. This paragraph shall specify the requirements, if
any, imposed on interfaces internal to the CSCI. If all internal interfaces are left to the design,
this fact shall be so stated. If such requirements are to be imposed, paragraph 3.3of this DID
provides a list of topics to be considered.
This paragraph shall specify the requirements, if any,
3.5 CscIinternal data reau iremen~.
imposed on data internal to the CSCI. Included shall be requirements, if any, on databases
and data files to be included in the CSCI. If all decisions about internal data are left to the
If such requirements are to be imposed, paragraphs
design, this fact shall be so stated.
3.3.x.c and 3.3.x.d of this DID provide a list of topics to be considered.
This paragraph shall specify the requirements,
if any,
3.6
tat ion reau iremen~,
concerning installation-dependent
data to be provided by the CSC( (such as site-dependent
latitude and longitude or site-dependent state tax codes) and operational parameters that the
CSCI is required to use that may vary according to operational needs (such as parameters
indicating operation-dependent
targeting constants or data recording).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

Requirements Specification
D14PSC-81433

INSTRUCTIONS

-- 10.2

(SRS)

Content Requirements

(continued)

This paragraph shall specify the CSCI requirements, if any,


3.7 ~afetv Teauiremen~.
concerned with preventing or minimizing unintended hazards to personnel, property, and the
physical environment.
Examples include safeguards the CSCI must provide to prevent
inadvertent actions (such as accidentally issuing an auto pilot off command) and non-actions
(such as failure to issue an intended auto pilot off command). This paragraph shall include
the CSCI requirements, if any, regarding nuclear components of the system, including, as
applicable, prevention of inadvertent detonation and compliance with nuclear safety rules.
3.8
Curitv and Drivacv reau irement~. This paragraph shall specify the CSCI requirements,
if any, concerned with maintaining security and privacy. These requirements shall include,
as applicable, the security/privacy environment in which the CSCI must operate, the type and
degree of security or privacy to be provided, the security/privacy
risks the CSCI must
withstand, required safeguards to reduce those risks, the security/privacy policy that must be
met, the security/privacy accountability the CSCI must provide, and the criteria that must be
met for security/privacy certification/accreditation.
3.9 !Xc I environment reau irement~. This paragraph shall specify the requirements, if any,
regarding the environment in which the CSCI must operate. Examples include the computer
hardware and operating system on which the CSCI must run. (Additional requirements
concerning computer resources are given in the next paragraph. )
3.10
Commte r resou rce re auirements.
subparagraphs.

This paragraph shall be divided into the following

3.10.1
Comf)ute r hardware reau irement$. This paragraph shall specify the requirements, if
any, regarding computer hardware that must be used by the CSCI. The requirements shall
include, as applicable, number of each type of equipment, type, size, capacity, and other
required characteristics of processors, memory, input/output
devices, auxiliary storage,
communications/network
equipment, and other required equipment.
3.10.2
Comt)ute r hardware resou r ce ut ilization rea uirements. This paragraph shall specify
the requirements, if any, on the CSCIS computer hardware resource utilization, such as
maximum allowable use of processor capacity, memory capacity, input/output
device
capacity, auxiliary storage device capacity, and communications/network
equipment capacity.
The requirements (stated, for example, as percentages of the capacity of each computer
hardware resource) shall include the conditions, if any, under which the resource utilization
is to be measured.
3.10.3
Comtwter software reauiremen~.
This paragraph shall specify the requirements, if
any, regarding computer software that must be used by, or incorporated into, the CSC}.
Examples include operating systems, database management systems, communications/
network software, utility software, input and equipment simulators, test software, and
manufacturing software. The correct nomenclature, version, and documeritation references
of each such software Item shall be provided.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page ~

of lJ

Software

10,

PREPARATION

Requirements Specification
DI-IPSC-81433

INSTRUCTIONS

-- 10.2

(SRS)

Content Requirements

(continued)

3.10.4
~omDuter co mmunications requirements. This paragraph shall specify the additional
requirements, if any, concerning the computer communications that must be used by the
CSCI.
Examples include geographic locations to be linked; configuration and network
topology; transmission techniques; data transfer rates; gateways; required system use times;
type and volume of data to be transmitted/received;
time boundaries for transmission/
reception/response;
peak volumes of data; and diagnostic features.
3.11
50 ftware a ualitv factors. This paragraph shall specify the CSCI requirements, if any,
concerned with software quality factors identified in the contract or derived from a higher
level specification.
Examples include quantitative requirements regarding CSCI functionality
(the ability to perform all required functions), reliabilityy (the ability to perform with correct,
consistent results), maintainability (the ability to be easily corrected), availability (the ability
to be accessed and operated when needed), flexibility (the ability to be easily adapted to
changing requirements), portability (the ability to be easily modified for a new environment),
reusability (the ability to be used in multiple applications), testability (the ability to be easily
and thoroughly tested), usability (the ability to be easily learned and used), and other
attributes.
3.12
Pes ian and imcrlementation co nstraintS. This paragraph shall specify the requirements, if any, that constrain the design and implementation of the CSCI. These requirements
may be specified by reference to appropriate commercial or military standards and
specifications.
Examples include requirements concerning:
a.

Use of a particular CSCI architecture or requirements on the architecture, such as


required databases or other software units; use of standard, military, or existing
or use of Government/acquirer-f urnished property
(equipment,
components;
information, or software)

b.

Use of particular design or implementation


standards;
standards; use of a particular programming language

c.

Flexibility and expandability that must be provided to support anticipated


growth or changes in technology, threat, or mission

use of particular

data

areas of

3.13
Personnel-related reau iremen~. This paragraph shall specify the CSCI requirements,
if any, included to accommodate the number, skill levels, duty cycles, training needs, or other
Examples include
information about the personnel who will use or support the CSCI.
requirements for number of simultaneous users and for built-in help or training features. Also
included shall be the human factors engineering requirements, if any, imposed on the CSCI.
These requirements shall include, as applicable, considerations for the capabilities and
limitations of humans; foreseeable human errors under both normal and extreme conditions;
and specific areas where the effects of human error would be particularly serious. Examples
include requirements for color and duration of error messages, physical placement of critical
indicators or keys, and use of auditory signals.
Trainina-related reau irements. This paragraph shall specify the CSCI requirements,
3.14
if any, pertaining to training. Examples include training software to be included in the CSCI.

Page &

of lJ)_
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

Requirements Specification
D14PSC-81433

INSTRUCTIONS

-- 10.2

(SRS)

Content Requirements

(continued)

Qistics
-related reau iremen~.
This paragraph shall specify the CSCI requirements,
3.15
These considerations may include: system
if any, concerned with logistics considerations.
maintenance, software support, system transportation modes, supply-system requirements,
impact on existing facilities, and impact on existing equipment.
irement , This paragraph shall specify additional CSCI requirements,
3.16
~
any, not covered in the previous paragraphs.

if

3.17
This section shall specify the requirements, if any, for
Pac kaairm reau iremen~.
packaging, labeling, and handling the CSCI for delivery (for example, delivery on 8 track
magnetic tape Iabelled and packaged in a certain way). Applicable military specifications and
standards may be referenced if appropriate.
~r
irmn.
This paragraph shall specify, if applicable,
3.18
n
the order of precedence, criticality, or assigned weights indicating the relative importance of
the requirements in this specification.
Examples include identifying those requirements
deemed critical to safety, to security, or to privacy for purposes of singling them o~t for
special treatment.
If all requirements have equal weight, this paragraph shall so state.
4. Qua Iifica tion movision~. This section shall define a set of qualification methods and shall
specify for each requirement in Section 3 the method(s) to be used to ensure that the
requirement has been met.
A table may be used to present this information, or each
requirement in Section 3 may be annotated with the method(s) to be used. Qualification
methods may include:

5.

a.

Demonstration:
The operation of the CSCI, or a part of the CSCI, that relies on
observable functional operation not requiring the use of instrumentation, special test
equipment, or subsequent analysis.

b.

Test: The operation of the CSCI, or a part of the CSCI, using instrumentation
other special test equipment to collect data for later analysis.

c.

Analysis:
methods.

d.

Inspection:

e.

Special qualification methods: Any special qualification methods for the CSCI, such
as special tools, techniques, procedures, facilities, and acceptance limits.

The processing of accumulated data obtained from other qualification


Examples are reduction, interpretation, or extrapolation of test results.
The visual examination

Reau irements traceab ility.


a.

or

of CSCI code, documentation,

etc.

This paragraph shall contain:

Traceability from each CSCI requirement in this specification to the system (or
subsystem, if applicable) requirements it addresses. (Alternatively, this traceability
may be provided by annotating each requirement in Section 3.)

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

Requirements Specification
DI-IPSC-81433

INSTRUCTIONS

-- 10.2

(SRS)

COntOnt Requirements

(continued)

Note:
Each level of system refinement may result in requirements not directly
For example, a system architectural design
traceable to higher-level requirements.
that creates multiple CSCls may result in requirements about how the CSCIS will
interface, even though these interfaces are not covered in system requirements.
Such requirements may be traced to a general requirement such as system
implementation or to the system design decisions that resulted in their generation.
b.

Traceability from each system (or subsystem, if applicable) requirement allocated to


All system (subsystem)
this CSCI to the CSCI requirements that address it.
requirements allocated to this CSCI shall be accounted for. Those that trace to CSCI
requirements contained in IRSS shall reference those IRSS.

6. NOW. This section shall contain any general information that aids in understanding this
specification (e. g., background information, glossary, rationale). This section shall 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. ADD endixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DATA ITEM DESCRIPTION

form Approved
OMB NO. 0704-0188

P&ttc

r.porttw

ourwo,

bwd.n

OMIWIIW

of thw cdhcmn
HIOhwsy,

ICU cdlectm.

and mumanww
of iniorwwm.

SUIO 1204,

ArlIrwton,

d 11U8mtommtton
ttm data ~

bKlu41rw cq!entmrm
VA 22202+302,

to w.taoe

rn mt,mmcd
eOmPMme
fw mductrg

110 haw8 PO, FNPLWU,

mclama

and r0v19wnQ tho cOllaCtK.n of ldwM*ll~


lFUObutlsrt to Wmtwqton

UWI to Ott OffIm

of Manawnont

Haadquartors

Sudom,

thr mm I@ m.oewm
$-MI

SoIwcm

DIfecwa!a

PCPWWLWk Rulucl!on

Prwct

of OmI#IION
(0704-01

SYSTEMKUBSYSTEM

DESIGN DESCRIPTION

al!mme

md RW.OIIS

081. WadwWton

2.

TITLE

~.

WV CIWIO mtiatanadam

mtwcuom

Comnmnlo ts.acro!ng rho bwd.n

or my mm
1216 Jdtsrwn

DWIS

, OC 20603

IDENTIFICATION

(SSDD)

wet

DI-IPSC-8

NUMBER

1432

3.

DESCRIPTION iPURPOSE

3.1 The System/Subsystem Design Description (SSDD) describes the system- or subsystem-wide design
and the architectural design of a system or subsystem. The SSDD may be supplemented by Interface
Design Descriptions (IDDs) (DI-IPSC-81 436) and Database Design Descriptions (DBDDs) (DI-IPSC-8143?1
as described in Block 7 below.
3.2 The SSDD, with its associated IDDs and DBDDs, is used as the basis for further system development.
Throughout this DID, the term system may be interpreted to mean subsystem as applicable. The
resulting document should be titled System Design Description or Subsystem Design Description (SSDD).
4.

APPROVAL

5.

OFFICE OF PRIMARY RESPONSIBILITY

68.

DTIC APPLICABLE

6b . GIDEP APPUCABLE

EC

941205

-m

7.

DATE

APPUCAT I ON/lNTERRWTIO

NSHIP

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 define and record the design of a system or subsystem.

7.3
Design pertaining to interfaces may be presented in the SSDD or in IDDs. Design pertaining to
databases may be presented in the SSDD or in DBDDs.

7.4 The Contract Data Requirements List (CDRL) (DD 1423) 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.
7.5 This DID supersedes DI-CMAN-80534

B. APPROVAL UMITATION
Limited ApprovaIl from 12/5/94

)0.

PREPARATION

IN6TW

and DI-MCCR-80302.

9a.
through 12/5/96

%,

APPLICABLE FORMS

AMSC NUMBER

N7075

CTK3NS

10.1 fh neral instruction$.

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

b. Alternate wesentation stvies. 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,
(Continued on Page 2)
i 11. DISTRIBUTION

I.)/STRIBUTION

STATEMENT

STATEMENT

A. Approved for public release; distribution is unlimited.

/
0

Fwm

1664, APR 89

Previous editions are obsolete


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

Page~

of ~

Pages

System/Subsystem
Design Description (SSDD)
DI-IPSC-8 1432
10.

PREPARATION

INSTRUCTIONS

-- 10.1 General Instructions

(continued)

c.

Title Daae or ide ntifler.


The document shall 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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

The document shall contain a table of contents providing the


Table of contents.
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Paae numberina/labe Iin q. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

If a paragraph is tailored out of this DID, the


Resoonse to ta ilorina instruct ions.
resulting document shall 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.

9.

MuItide rlaraarat)hs and suboa raaraD hs. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

Sta ndard data desc ritMionS. 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.

Wbst itut ion of existina doc uments. 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 begin on the following page.
The
co ntent reau iremen~.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Design Description (SSDD)
DI-IPSC-81432
10.
1,

PREPARATION
-.

INSTRUCTIONS--

10.2

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1,1 Identificat ion. This paragraph shall contain a full identification of the system to which
this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 Svste m overview. This paragraph shall briefly state the purpose of the system to which
this document applies. h shall 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 agencies; identify current and planned operating sites;
and list other relevant documents.
1.3 Qocu ment overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Referenced doc uments. This section shall list the number, title, revision, and date of all
documents referenced in this document,
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Svste m-wide des ian decision~, This section shall be divided into paragraphs as needed
to present system-wide design decisions, that is, decisions about the systems behavioral
design (how itwill behave, from a users point of view, in meeting its requirements, ignoring
internal implementation)
and other decisions affecting the selection and design of system
components.
If all such decisions are explicit in the requirements or are deferred to the design
of the system components, this section shall so state.Design decisions that respond to
requirements designated critical, such as those for safety, security, or privacy, shall be placed
in separate subparagraphs.
If a design decision depends upon system states or modes, this
dependency shall be indicated. Design conventions needed to understand the design shall be
presented or referenced.
Examples of system-wide design decisions are the following:
a.

Design decisions regarding inputs the system will accept and outputs it will produce,
including interfaces with other systems, configuration items, 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, and privacy requirements.

Page J!_ of &


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

System/Subsystem
Design Description (SSDD)
DI-IPSC-81432
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

e.

Design and construction choices for hardware or hardware-software


as physical size, color, shape, weight, materials, and markings.

systems, such

f.

Other system-wide design decisions made in response to requirements, such as


selected approach to providing required flexibility, availability, and maintainability.

4. SVste m architect ral des ican, This section shall 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 shall be indicated. if design information fails into more than
one paragraph, it may be presented once and referenced from the other paragraphs. Design
conventions needed to understand the design shall 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

Syste m comDo nents.

This paragraph shall:

a.

Identify the components of the system (HWCIS,


Each component shall be assigned a project-unique
be treated as a CSCI or as part of a CSCI,

CSCIS, and manual operations).


identifier. Note: a database may

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 5a. )

d.

Identify each components


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
shall 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 shall, 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, 20A of the resources capacity
allocated to CSCI 1, 30A to CSCI 2), describe the conditions under which utilization
will be measured, and describe the characteristics of the resource:

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Design Description (SSDD)
D14PSC-81432
10.

PREPARATION

f.

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

1)

Descriptions of computer processors shall include, as applicable,


name and model number, processor speed/capacity, identification
set architecture, applicable compiler(s), word size (number of
computer word), character set standard (such as ASCII, EBCDIC),
capabilities.

manufacturer
of instruction
bits in each
and interrupt

2)

Descriptions of memory shall include, as applicable, manufacturer name and


model number and memory size, type, speed, and configuration (such as 256K
cache memory, 16MB RAM (4MB x 4)).

3)

Descriptions of input/output devices shall include, as applicable, manufacturer


name and model number, type of device, and device speed/capacity.

4)

Descriptions of auxiliary storage shall 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, shall include, as applicable, manufacturer name
and model number, data transfer rates/capacities,
network
topologies,
transmission techniques, and protocols used.

6)

Each description shall also include, as applicable, growth capabilities, diagnostic


capabilities, and any additional hardware capabilities relevant to the description.

Present a specification tree for the system, that is, a diagram that identifies and
shows the relationships
among the planned specifications
for the system
components.

4.2 ~oncerX of execution. This paragraph shall describe the concept of execution among the
It shall include diagrams and descriptions showing the dynamic
system components.
relationship of the components, that is, how they will interact during system operation,
including, as applicable, flow of execution control, data flow, dynamically controlled
sequencing, statetransition diagrams, timing diagrams, priorities among components, 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 Jnterface des ian. This paragraph shall be divided into the following subparagraphs to
describe the interface characteristics of the system components.
It shall include both
interfaces among the components and their interfaces with external entities such as other
systems, configuration items, and users. Note: There is no requirement for these interfaces
to be completely designed at this level; this paragraph is provided to allow the recording of
interface design decisions made as part of system architectural design. If part or all of this
information is contained in Interface Design Descriptions (IDDs) or elsewhere, these sources
may be referenced.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page JI_ of ~

System/Subsystem
Design Description (SSDD)
DI-IPSC-81432
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

4.3.1
Interface identific ation and diaararns. This paragraph shall state the project-unique
identifier assigned to each interface and shall identify the interfacing entities (systems,
configuration items, users, etc. ) by name, number, versiont and documentation references~
as applicable. The identification shall 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 shall be provided, as appropriate, to depict the interfaces.
jProiect -uniaue ide ntifier of interface.
This paragraph (beginning with 4.3.2) shall
identify an interface by project-unique identifier, shall briefly identify the interfacing entities,
and shall 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 shall 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 statin9 the information here. The desi9n
description shall include the following, as applicable, presented in any order suited to the
information to be provided, and shall note any differences in these characteristics from the
point of view of the interfacing entities (such as different expectations about the size,
frequency, or other characteristics of data elements):
4.3.x

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


b.

Type of interface (such as real-time data transfer, storage-and-retrieval


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)

c)

DoD standard data element name

d)

Technical

e)

Abbreviation

name

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


or synonymous

names

2)

Data type (alphanumeric,

3)

Size and format (such as length and punctuation

4)

Units of measurement

(such as meters, dollars, nanoseconds)

5)

Range or enumeration

of possible values (such as O-99)

6)

Accuracy

7)

integer, etc.)
of a character string)

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

prloritY, timing, frequency,

volume, sequencing,

and other constraints,

whether the data element may be updated and whether

Page &

of data, etc.)

8)

Security and privacy constraints

9)

Sources (setting/sending

of Jl_

entities) and recipients (using/receiving

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

such as

business rules apply

entities)

System/Subsystem
Design Description {SS00)
DI-IPSC-81432
10.

PREPARATION
d.

f.

9.

-- 10.2

Content Requirements

(continued)

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:
1)

e.

INSTRUCTIONS

Names/identifiers
a)

Project-unique

identifier to be used for traceability

b)

Non-technical

(natural language) name

c)

Technical

d)

Abbreviations

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


or synonymous

names

2)

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

3)

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

4)

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

5)

Relationships

6)

Priority, timing, frequency, volume, sequencing, and other constraints, such as


whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources (setting/sending

among assemblies,

such as sorting/access

characteristics

entities) and recipients (using/receiving

Characteristics of communication
the interface, such as:

entities)

methods that the interfacing entity (ies) will use for

1)

Project-unique

2)

Communication

3)

Message formatting

4)

Fiow control (such as sequence numbering and buffer allocation)

5)

Data transfer rate, whether

6)

Routing, addressing,

7)

Transmission

8)

Safety/security/privacy
compartmentalization,

Characteristics
such as:

on the medium

identifier(s)
links/bands/f requencies/media

periodic/aperiodic,

and their characteristics

and interval between

transfers

and naming conventions

services, including priority and grade


considerations,
and auditing

such as encryption,

user authentication,

of protocols that the interfacing entity (ies) will use for theinterface,

1)

Project-unique

identifier(s)

2)

Priority/layer

3)

Packeting,

4)

Legality checks, error control, and recovery procedures

5)

Synchronization,

6)

Status, identification,

of the protocol

including fragmentation

and reassembly,

including connection establishment,

routing, and addressing

maintenance,

termination

and any other reporting features

Other characteristics,
such as physical compatibility of the interfacing
(dimensions, tolerances, loads, voltages, plug compatibility, etc. )
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

entity (ies)

System/Subsystem
Design Description
D14PSC-81432
10.
5.

PREPARATION

INSTRUCTIONS--

Reau irements traceab ility.

10.2

(SSDD)

Content Requirements

(continued)

This paragraph shall contain:

a.

Traceability from each system component identified in this SSDD to the system
requirements allocated to it. (Alternatively, this traceability may be provided in 4. 1.)

b.

Traceability
allocated.

from each system requirement

to the system components

to which it is

6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale), This section shall contain 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. ~UD endixes. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided, Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DATA ITEM DESCRIPTION


P&IIc

r.poftq

.DUCU,

of tlw colktim
Viahwa,
1.

butin

oatwnrq

SUM

fet cdlulmn

MUI

muntvm~

of m!ammmn.
1204,

&hIvlan,

O? IIUO wdotmmmn
ths

dbtb noodkl

mchdtfw

qwutmtu

VA 22202-4302,

k
-

raduarq

110 IWW8 eta raP0m9,

mvmwttm

trw budm

!-

cdktmn

!0 W-rvton
ud

to ltm 0ft8c9 of M~

BITCIUOIW lVU time

of mfwmmmn.
+toadwutom

!3~t,

Pmorwofk

6.nd

SuvIcem
RuWctlm

TITLE

WVWWIW

uwtmctmm,

comm.ma

rqud,m

Duoctwatc

d O~rot!um

SPECIFICATION

ttn

PWIOC1 t070441S81,

I 2

SYSTEM/SUBSYSTEM
3.

IO vww

to ammm.d

aml compktwg

firm Approved
OMB NO. O 7W-0188

WmlwWton

DESCRIPTIONIPURPOSE

mt8ww

mttma!c

and RaPefm,

date

or UIV ottu,

1216

Art-

MP.CI
Dow.

, DC 20603

IDENTIFICATI

(SSS)

nwclnru

bwdm

oN

N~

DI-IPSC-81431

3.1 The System/Subsystem Specification (SSS) specifies the requirements for a system or subsystem and
the methods to be used to ensure that each requirement has been met. Requirements pertaining to the
system or subsystems external interfaces may be presented in the SSS or in one or more Interface
Requirements Specifications IIRSS) (DI-IPSC-81 434) referenced from the SSS.
3.2 The SSS, possibly supplemented by IRSS, is used as the basis for design and qualification testing of a
system or subsystem, Throughout this DID, the term system= may be interpreted to mean subsystem as
applicable. The resulting document should be titled System Specification or Subsystem Specification (SSS).
4.

APPROVAL

~w

DATE

S. OFFICE OF PRIMARY RESPONSIBILITY

941205

6a.

DTIC APPLICABLE

6b . GIDEP APPLICABLE

EC

APPLKAT 10NrlNTERREIAT

IONSHIP

7.1 This Data hem 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 requirements to be met by a
system or subsystem.
7.3 Requirements pertaining to system or subsystem interfaces may be presented in the SSS or in IRSS.
7.4 The Contract Data Requirements List (CDRL] (DD 1423) 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
[CASEI or other automated tool rather than in the form of a traditional document.
7.5 This DID supersedes DI-CMAN-80008A

8. APPROVAL LIMITATION
Limited Approwl from 12i5/94
10.

PREPARA~l

and DI-IPSC-80690.

9a.
through 12/S/96

APPLICABLE FORMS

9b.

AMSC NUMBER
N7074

ONS

10.1 @ neral instruct ion$,


a. Automated technictu~. Use of automated techniques is encouraged. The term document in this
DID means a collection of data regardless of its medium.
b, Alternate Presentation stvle~. 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.
(Continued on Paoe
-. 2)
~11. DISTRIBUTION
I I DISTRIBUTION

STATEMENT

STATEMENT

A.

Approved for public release; distribution is unlimited.

,..
;() F~rm 1 ~~4, ApR 89
135/1

23

Previous editions are obsolete

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page _l_

of JQ Pages

System/Subsystem
Specification
DI-IPSC-81431

10. PREPARATION

INSTRUCTIONS

(SSS)

-- 10.1 General Instructions

(continued)

c.

Title ~
or ide ntifier with sianature b locks. The document shall 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; distribution statement; and signature blocks for the developer representative
authorized to release the document, the acquirer representative authorized to approve
the document, and the dates of reIease/approval.
For data in a database or other
alternative form, this information shall be included on external and internal labels or by
equivalent identification methods.

d.

Table of contents.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Paa e numbe rina/labe Iing. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f,

Res~onse to ta ilorina instruct ions.


If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Multide tmraaraDhs and subDa raaraD h~. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description required by this DID has been


Sta ndard data desc rif)tion$.
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.

stitut ion of existina docu ment~. Commercial or other existing documents


substituted for all or part of the document if they contain the required data.

may be

10.2
Content requirements begin on the following page.
The
Co ntent reau iremen@.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
DI-IPSC-81431
10.
1.

PREPARATION
a.

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 Jdent ific ation. This paragraph shall contain a full identification of the system to which
this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 Svste m overview. This paragraph shall briefly state the purpose of the system to which
this document applies. It shall 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 agencies; identify current and planned operating sites;
and list other relevant documents.
1.3 Pocume nt o verview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Referenced do cument~, This section shall list the number, title, revision, and date of all
documents referenced in this specification.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Beau iremen~. This section shall be divided into the following paragraphs to specify the
system requirements, that is, those characteristics of the system that are conditions for its
acceptance.
Each requirement shall be assigned a project-unique identifier to support testing
and traceability and shall be stated in such a way that an objective test can be defined for it.
Each requirement shall be annotated with associated qualification method(s) (see section 4)
and, for subsystems, traceability to system requirements (see section 5a), if not provided in
those sections. The degree of detail to be provided shall be guided by the following rule:
Include those characteristics of the system that are conditions for system acceptance; defer
to design descriptions those characteristics that the acquirer is willing to leave up to the
developer.
If there are no requirements in a given paragraph, the paragraph shall so state.
If a given requirement fits into more than one paragraph, it maybe stated once and referenced
from the other paragraphs.
3.1 Reau ired states and modes. If the system is required to operate in more than one state
or mode having requirements distinct from other states or modes, this paragraph shall identify
and define each state and mode. Examples of states and modes include: idle, ready, active,
backup, wartime,
peacetime.
The
post-use analysis, training, degraded, emergency,
distinction between states and modes is arbitrary. A system may be described in terms of
states only, modes only, states within modes, modes within states, or any other scheme that
is useful. If no states or modes are required, this paragraph shall so state, without the need
to create artificial distinctions, If states and/or modes are required, each requirement or group
of requirements in this specification shall be correlated to the states and modes.
The
correlation may be indicated by a table or other method in this paragraph, in an appendix
referenced from this paragraph, or by annotation of the requirements in the paragraphs where
they appear.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
DI-IPSC-81431
PREPARATION

10.

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

(continued)

This paragraph shall be divided into subparagraphs to


3.2
itemize the requirements associated with each capability of the system.
A capability is
The word *capability may be replaced with
defined as a group of related requirements,
function, subject, object, or other term useful for presenting the requirements.
3.2.x
JSvste m ca Dabilitvl. This paragraph shall identify a required system capability and
shall itemize the requirements associated with the capability.
If the capability can be more
clearly specified by dividing it into constituent capabilities, the constituent capabilities shall
be specified in subparagraphs. The requirements shall specify required behavior of the system
and shall include applicable parameters, such as response times, throughput times, other
timing constraints, sequencing, accuracy, capacities (how much/how
many), priorities,
continuous operation requirements, and allowable deviations based on operating conditions.
The requirements shall include, as applicable, required behavior under unexpected, unallowed,
or out of bounds conditions, requirements for error handling, and any provisions to be
incorporated into the system to provide continuity of operations in the event of emergencies.
Paragraph 3.3.x of this DID provides a list of topics to be considered when specifying
requirements regarding inputs the system must accept and outputs it must produce.
3.3 Svste m external interface rea uirement$. This paragraph shall be divided into subparagraphs to specify the requirements,
if any, for the systems external interfaces.
This
paragraph may reference one or more Interface Requirements Specifications (IRSS) or other
documents containing these requirements.
This paragraph shall identify the required
3.3.1
interface identificat ion and diaaram~,
external interfaces of the system. The identification of each interface shall include a projectunique identifier and shall designate the interfacing entities (systems, configuration items,
users, etc. ) by name, number, version, and documentation references, as applicable. The
identification shall 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 shall be provided to depict the interfaces.
This paragraph (beginning with 3.3.2) shall
3.3.x
~Proiect-uniaue identifier of interfac~.
identify a system external interface by project-unique identifier, shall briefly identify the
interfacing entities, and shall be divided into subparagraphs as needed to state the
requirements imposed on the system to achieve the interface. Interface characteristics of the
other entities involved in the interface shall be stated as assumptions or as When [the entity
not covered) does this, the system shall..,, not as requirements on the other entities. This
paragraph may reference other documents (such as data dictionaries,
standards for
communication protocols, and standards for user interfaces) in place of stating the information
here. The requirements shall include the following, as applicable, presented in any order
suited to the requirements, and shall note any differences in these characteristics from the
point of view of the interfacing entities (such as different expectations about the size,
frequency, or other characteristics of data elements):
a.

Priority that the system must assign the interface

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
DI-IPSC81 431
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

(continued)

b.

Requirements on the type of interface (such as real-time data transfer, storage-andretrieval of data, etc. ) to be implemented

c.

Required characteristics of individual data elements that the system must provide,
store, send, access, receive, etc., such as:
1)

d.

Names/identifiers
a)

Project-unique

identifier

b)

Non-technical

(natural-language)

c)

DoD standard data element name

d)

Technical

e)

Abbreviation

name

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


or synonymous

names

2)

Data type (alphanumeric,

integer, etc.)

3)

Size and format (such as length and punctuation

4)

Units of measurement

(such as meters, dollars, nanoseconds)

5)

Range or enumeration

of possible values (such as O-99)

6)

Accuracy

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

of a character string)

(how correct) and precision (number of significant

digits)

entities) and recipients (using/receiving

entities)

Required characteristics of data element assemblies (records, messages, files, arrays,


displays, reports, etc.) that the system must provide, store, send, access, receive,
etc., such as:
1)

Namesfidentifiers
a)

Project-unique

identifier

b)

Non-technical

(natural language) name

c)

Technical

d)

Abbreviations

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


or synonymous

names

2)

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

3)

Medium (such as disk) and. structure of data elements/assemblies

4)

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

5)

Relationships among assemblies, such as sorting/access

6)

Priority, timing, frequency, volume, sequencing, and other constraints, such as


whether the assembly may be updated and whether business rules apply

7)

Security and privacy constraints

8)

Sources (setting/sending

on the medium

characteristics

entities) and recipients (using/receiving

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

entities)

System/Subsystem
Specification
DI-IPSC-81431
10.

PREPARATION
e.

f.

9.

INSTRUCTIONS

Required characteristics
interface, such as:

-- 10.2

(SSS)

Content Requirements

of communication

(continued)

methods that the system must use for the

1)

Project-unique

identifier(s)

2)

Communication

3)

Message formatting

4)

Flow control (such as sequence numbering and buffer allocation)

5)

Data transfer rate, whether

6)

Routing, addressing,

7)

Transmission

8)

Safety/security/privacy
compartmentalization,

links/bands/f requencies/media

periodic/aperiodic,

and their characteristics

and interval between transfers

and naming conventions

services, including priority and grade

Required characteristics

considerations,
and auditing

such as encryption, user authentication,

of protocols the system must use for the interface, such as:

1)

Project-unique

identifier(s)

2)

Priority/layer

3)

Packeting,

4)

Legality checks, error control, and recovery procedures

5)

Synchronization,

6)

Status, identification,

of the protocol

including fragmentation

and reassembly, routing, and addressing

including connection establishment,

maintenance,

termination

and any other reporting features

Other required characteristics,


such as physical compatibility of the interfacing
entities (dimensions, tolerances, loads, plug compatibility, etc.), voltages, etc.

3.4
te m internal interface reau irement~. This paragraph shall specify the requirements,
if any, imposed on interfaces internal to the system. If all internal interfaces are left to the
design or to requirement specifications for system components, this fact shall be so stated.
If such requirements are to be imposed, paragraph 3.3 of this DID provides a list of topics to
be considered.
internal dat a reau irement$. This paragraph shall specify the requirements, if any,
imposed on data internal to the system. Included shai( be requirements, if any, on databases
and data files to be included in the system. If all decisions about internal data are left to the
design or to requirements specifications for system components, this fact shall be so stated.
If such requirements are to be imposed, paragraphs 3.3.x.c and 3.3.x.d of this LX() provide
a list of topics to be considered.

3.5 ~m

This paragraph shall specify the requirements, if any,


3.6 AdarXat ion reau irements.
concerning installation-dependent
data that the system is required to provide (such as sitedependent
latitude and longitude or site-dependent
state tax codes) and operational
parameters that the system is required to use that may vary according to operational needs
(such as parameters indicating operation-dependent
targeting constants or data recording).

Page &l_ of lJ)_

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
D14PSC-81431
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

(continued)

This paragraph shall specify the system requirements, if any,


3.7 ~afetv rm irement~.
concerned with preventing or minimizing unintended hazards to personnel, property, and the
physical environment. Examples include restricting the use of dangerous materials; classifying
explosives for purposes of shipping, handling, and storing; abort/escape provisions from
enclosures; gas detection and warning devices; grounding of electrical systems; decontamination; and explosion proofing. This paragraph shall include the system requirements, if any,
for nuclear components,
including, as applicable, requirements for component design,
prevention of inadvertent detonation, and compliance with nuclear safety rules.
3.8 Secu ritv and orivacv reau irement~. This paragraph shall specify the system requirements, if any, concerned with maintaining security and privacy. The requirements shall
include, as applicable, the security/privacy environment in which the system must operate,
the type and degree of security or privacy to be provided, the security/privacy
risks the
system must withstand, required safeguards to reduce those risks, the security/privacy policy
that must be met, the security/privacy accountability the system must provide, and the criteria
that must be met for security/privacy certification/accreditation.
3.9 Svste m environment rea uirements. This paragraph shall specify the requirements, if any,
regarding the environment in which the system must operate.
Examples for a software
system are the computer hardware and operating system on which the software must run.
(Additional requirements concerning computer resources are given in the next paragraph).
Examples for a hardware-software
system include the environmental conditions that the
system must withstand during transportation, storage, and operation, such as conditions in
the natural environment
(wind, rain, temperature,
geographic location), the induced
environment (motion, shock, noise, electromagnetic
radiation), and environments due to
enemy action (explosions, radiation).
3.10
Comrmter resource rea uirement~. This paragraph shall be divided into the following
subparagraphs.
Depending upon the nature of the system, the computer resources covered
in these subparagraphs may constitute the environment of the system (as for a software
system) or components of the system (as for a hardware-software
system).
3.10.1
GomDute r hardwa re reau iremen@. This paragraph shall specify the requirements, if
any, regarding computer hardware that must be used by, or incorporated into, the system.
The requirements shall include, as applicable, number of each type of equipment, type, size,
capacity, and other required characteristics of processors, memory, input/output devices,
auxiliary storage, communications/network
equipment, and other required equipment.
3.10.2
GomDute r hardware resou rce ut ilization reau irements. This paragraph shall specify
the requirements, if any, on the systems computer hardware resource utilization, such as
maximum allowable use of processor capacity, memory capacity, input/output
device
capacity, auxiliary storage device capacity, and communications/network
equipment capacity.
The requirements (stated, for example, as percentages of the capacity of each computer
hardware resource) shall include the conditions, if any, under which the resource utilization
is to be measured,

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
DI-IPSC-81431
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

(continued)

3.10.3
ComDuter software reau irement~. This paragraph shall specify the requirements, if
any, regarding computer software that must be used by, or incorporated into, the system.
Examples include operating systems, database management systems, communications/
network software, utility software, input and equipment simulators, test software, and
manufacturing software. The correct nomenclature, version, and documentation references
of each such software item shall be provided.
3.10.4
Comty@r communimtions
rea uirements. This paragraph shall specify the additional
requirements, if any, concerning the computer communications that must be used by, or
incorporated
into, the system.
Examples include geographic locations to be linked;
configuration and network topology; transmission techniques; data transfer rates; gateways;
required system use times; type and volume of data to be transmitted/received;
time
boundaries for transmission/reception/response;
peak volumes of data; and diagnostic
features.
This paragraph shall specify the requirements, if any,
3.11
Svste m aua lit v factors.
pertaining to system quality factors. Examples include quantitative requirements concerning
system functionality (the ability to perform all required functions), reliability (the ability to
perform with correct, consistent results -- such as mean time between failure for equipment),
maintainability (the ability to be easily serviced, repaired, or corrected), availability (the ability
to be accessed and operated when needed), flexibility (the ability to be easily adapted to
changing requirements), portability of software (the ability to be easily
modified for a new
environment), reusability (the ability to be used in multiple applications), testability (the ability
to be easily and thoroughly tested), usability (the ability to be easily learned and used), and
other attributes.
3.12
~es ian and co nstru ction co nstraints. This paragraph shall specify the requirements,
if any, that constrain the design and construction of the system.
For hardware-software
systems, this paragraph shall include the physical requirements imposed on the system.
These requirements may be specified by reference to appropriate commercial or military
standards and specifications,
Examples include requirements concerning:
a.

Use of a particular system architecture or requirements on the architecture, such as


required subsystems; use of standard, military, or existing components; or use of
Government/acquirer-furnished
property (equipment, information, or software)

b.

Use of particular design or construction standards; use of particular data standards;


use of a particular programming language; workmanship requirements and production
techniques

c.

Physical characteristics of the system (such as weight limits, dimensional limits,


color, protective coatings); interchangeability of parts; ability to be transported from
one location to another; ability to be carried or set up by one, or a given number of,
persons

d.

Materials that can and cannot be used; requirements on the handling of toxic
materials: limits on the electromagnetic
radiation that the system is permitted to
generate

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

System/Subsystem
Specification
DI-IPSC-81431
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(sss)

Content Requirements

(continued)

e.

Use of nameplates,
markings

part marking, serial and lot number marking, and other identifying

f.

Flexibility and expandability that must be provided to support anticipated


growth or changes in technology, threat, or mission

areas of

Personnei-related reau iremen~.


This paragraph shall specify the system require3.13
ments, if any, included to accommodate the number, skiil levels, duty cycies, training needs,
or other information about the personnel who will use or support the system.
Examples
include requirements for the number of work stations to be provided and for buiit-in help and
training features. Also included shall be the human factors engineering requirements, if any,
imposed on the system. These requirements shall include, as applicable, considerations for
the capabilities and limitations of humans, foreseeable human errors under both normal and
extreme conditions, and specific areas where the effects of human error would be particularly
serious. Examples include requirements for adjustable-height work stations, coior and duration
of error messages, physicai piacement of criticai indicators or buttons, and use of auditory
signals.
Trainina-related rea uiremen~. This paragraph shaii specify the system requirements,
3.14
if any, pertaining to training. Exampies include training devices and training materials to be
inciuded in the system.
oistics -related reaulr ements. This paragraph shaii specif y the system requirements,
3.15
if any, concerned with logistics considerations.
These considerations may inciude: system
maintenance, software support, system transportation modes, supply-system requirements,
impact on existing facilities, and impact on existing equipment.
Qther reauiremen&.
This paragraph shail specify additional system requirements, if
3.16
Exampies include requirements for system
any, not covered in the previous paragraphs.
documentation,
such as specifications,
drawings,
technical manuais, test plans and
procedures, and installation instruction data, if not covered in other contractual documents.
This section shall specify the requirements,
3.17
Packa aina reau iremen~.
packaging, labeling, and handiing the system and its components for delivery.
military specifications and standards may be referenced if appropriate.

if any, for
Applicable

3.18
Precedence and criticality of reau irement$. This paragraph shali specify, if applicable,
the order of precedence, criticality, or assigned weights indicating the reiative importance of
the requirements in this specification.
Examples include identifying those requirements
deemed critical to safety, to security, or to privacy for purposes of singiing them out for
special treatment.
If all requirements have equai weight, this paragraph shali so state.
4. Qua iificat ion movision~. This section shall define a set of qualification methods and shall
specify for each requirement in Section 3 the method(s) to be used to ensure that the requirement has been met. A tabie may be used to present this information, or each requirement in
Section 3 may be annotated with the method(s) to be used. CMaiification methods may
include:

Page ~
Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source to verify that this is the current version before use.

of J)_

System/Subsystem
Specification
DI-IPSC-81431
10.

PREPARATION

INSTRUCTIONS

-- 10.2

(SSS)

Content Requirements

(continued)

a.

Demonstration:
The operation of the system, or a part of the system, that relies on
observable functional operation not requiring the use of instrumentation, special test
equipment, or subsequent analysis.

b,

Test: The operation of the system, or a part of the system, using instrumentation
other special test equipment to collect data for later analysis.

c.

Analysis:
methods.

d.

Inspection:

e.

Any special qualification methods for the system,


Special qualification methods.
such as special tools, techniques, procedures, facilities, acceptance limits, use of
standard samples, preproduction or periodic production samples, pilot models, or piiot
lots.

or

The processing of accumulated data obtained from other qualification


Examples are reduction, interpolation, or extrapolation of test results.
The visual examination

of system components,

documentation,

etc.

5. Reau irements tracea bility. For system-ievel specifications, this paragraph does not apply.
For subsystem-level specifications, this paragraph shail contain:
a.

Traceability from each subsystem requirement in this specification to the system


requirements it addresses.
(Alternatively,
this traceability may be provided by
annotating each requirement in Section 3.)
Note:
Each ievel of system refinement may result in requirements not directiy
For example, a system architectural design
traceabie to higher-ievel requirements.
that creates two subsystems may resuit in requirements about how the subsystems
wili interface, even though these interfaces are not covered in system requirements.
Such requirements may be traced to a generai requirement such as system
implementation or to the system design decisions that resulted in their generation.

b.

Traceability from each system requirement that has been allocated to the subsystem
covered by this specification to the subsystem requirements that address it. Aii
system requirements allocated to the subsystem shall be accounted for. Those that
trace to subsystem requirements contained in IRSS shall reference those IRSS.

6. ~ote~. This section shall contain any general information that aids in understanding this
document (e.g., background information, giossary, rationale). This section shail contain an
alphabetical listing of all acronyms, abbreviations,
and their meanings as used in this
document and a iist of any terms and definitions needed to understand this document.
A. ADDe ndixe~. Appendixes may be used to provide information pubiished 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.).

Page Q

of -Q

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Form Approved
OMB NO. 0704-0188

DATA ITEM DESCRIPTION


Ptihc

raportt~

rnwfrn,

of ttw

omfnrIrq

bud.n
d

cdlactom

rnumm_qI

cdlactm.n of tnf~mn,

H!ghway,

?A1O 1204,

of NW mfetmtiw!
tfu dbu rvakd

induh~

A4trqlon,

cmtlocu

VA 222024302,

.mlmatti

to W.IW

1- N4UCIIW tfn
ad

110

cOttwl.lNQ ud revmwInJ
10 I*

Otftm

budm

of M~

hour-

pm

row.-,

tfn
cdlecuon

10 WmhIIXIIOn

$ndudtna

d wdormmlon.
Hsdoumrn

and Budtjm. Pamrwtwk

lb

tuna

6arvIc9a,

101 Iw.wna

IIUtIUCIIW,

IagNdt!_g Otto bud.n

Cwwtorstc

M OPW#tIofu

R4UCIIOII

PIqcc1

-Itmuo

%porta.

10704 -O IS@l, WaduWIon

2.

SOFTWARE

ud

xImwKI dam

awch+rw

comrnwns

w my mlm
1216

ac!
Davm

, DC 20603.

lDE~ATION

TEST DESCRIPTION (STD)

Jdf-

NU~

DI-IPSC-81439

3. DESCRIPTION/PURPOSE
3.1 The Software Test Description (STD) describes the test preparations, test cases, and test procedures
to be used to perform qualification testing of a Computer Software Configuration Item (CSCI) or a software
system or subsystem.
3.2 The STD enables the acquirer to assess the adequacy of the qualification testing to be performed.

4 APPROVAL
DATE
m

OFFICE OF PRIMARY RESPONSIBILITY

941205

6a.

DTIC APPLICABLE

Bb. GJDEP APPLICABLE

EC

SHIP

1. APPLICA~RELATION

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 test preparations, test cases,
and test procedures to be used for CSCI qualification testing or for system qualification testing of a
software system,
7,3 The Contract Data Requirements List (CDRLJ (DD 1423) 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-eided software engineering
[CASE) or other automated tool rather than in the form of a traditional document.
7,4 This DID supersedes DI-MCCR-80015A

E. APPROVAL
UMITATION

Sm.APPLICABLE
FORMS

Limited Approval from 12/S/94


10.~ARATION

10.1

INS-

and DI-MCCR-8031 O.

64. AMSCNUMBER

through 12/S/96

N7082

I ONS

Ge neral instruction$.

a. Automated techniaues. Use of automated techniques is encouraged. The term document in this
DID means a collection of data regardless of its medium.
b, Alternate wesentation stvle~. 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.
(Continued on Page 2)
i i.DISTRIBUTION
DISTRIBUTION

STATEMENT
STATEMENT

1
1..
D6J Form 1664. APR 89
135/1 23

A. Approved for public release; distribution is unlimited.


Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z
Check the source Previous
to verify that
this isare
the obsolete
current version before use.
editions

Page _l_ of

Software

10.

PREPARATION

INSTRUCTIONS

Test Description
DI-IPSC-81439

(STD)

-- 10.1 General Instructions

(continued)

c.

The document shall include a title page containing, as


Title Daae or identifier.
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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

The document shall contain a table of contents providing the


Table of conten~.
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

&Qe numbe rinaflabe Iinq. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

If a paragraph is tailored out of this DID, the


ResDonse to ta ilorina instruct ions.
resulting document shall 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.

9.

DaraQraDhS
JVluhkie

h.

standard data desc ric)tion~. 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.

Commercial or other existing documents


Subst itut ion of existina doc umen~.
substituted for all or part of the document if they contain the required data.

and subDa ragrar)h~. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

may be

10.2
co ntent reau iremen~.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION

INSTRUCTIONS

Test Description
DI-IPSC-81439

-- 10.2

(STD)

Content Requirements

SCODQ. This section shall be divided into the following

(continued)

paragraphs.

1.1 @entificat ion. This paragraph shall 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
verview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 ~ment
overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2. Befe renced docu men~. This section shall list the number, title, revision, and date of all
documents referenced in this document.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
Safety
3. Test meDa ration$. This section shall be divided into the following paragraphs.
precautions, marked by WARNING or CAUTION, and security and privacy considerations shall
be included as applicable.
3.x JProie ct-uniaue ide ntifier of a tes~. This paragraph shall identify a test by project-unique
identifier, shall provide a brief description, and shall be divided into the following subparagraphs. When the information required duplicates information previously specified for another
test, that information may be referenced rather than repeated.
3.x. 1
Ha rdware tweoa ration. This paragraph shall describe the procedural necessary to
prepare the hardware for the test. Reference may be made to published operating manuals
for these procedures. The following shall be provided, as applicable:
a.

The specific hardware to be used, identified by name and, if applicable,

b.

Any switch settings and cabling necessary to connect the hardware

c.

One or more diagrams to show hardware,

d.

Step-by-step

instructions

interconnecting

for placing the hardware

number

control, and data paths

in a state of readiness

3.x.2
software me ~aration. This paragraph shall describe the procedures necessary to
prepare the item(s) under test and any related software,
including data, for the test.
Reference may be made to published software manuals for these procedures. The following
information shall be provided, as applicable:
a.

The specific software

to be used in the test

b.

The storage medium of the item(s) under test (e.g., magnetic tape, diskette)

c.

The storage medium of any related software (e.g., simulators, test drivers, databases)

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS

Test Description
DI-IPSC-81439

-- 10.2

(STD)

Content Requirements

(continued)

d.

Instructions

for loading the software,

including required sequence

e.

Instructions

for software

common to more than one test case

initialization

This paragraph shall describe any other


Other me-test me~ aration~.
3. X.3
personnel actions, preparations, or procedures necessary to perform the test.

pre-test

4. Test des criLMions. This section shall be divided into the following paragraphs. Safety
precautions, marked by WARNING or CAUTION, and security and privacy considerations shall
be included as applicable.
4.x JProiect -unia ue identifier of a tes~. This paragraph shall identify a test by project-unique
When the required
identifier and shall be divided into the following subparagraphs.
information duplicates information previously provided, that information may be referenced
rather than repeated.
4.x.y
JProiect-uniaue identifier of a test cas@ . This paragraph shall identify a test case by
project-unique identifier, state its purpose, and provide a brief description.
The following
subparagraphs shall provide a detailed description of the test case.
4.x.y.l
Reau irements add ressecj, This paragraph shall identify the CSCI or system requirements addressed by the test case. (Alternatively, this information may be provided in 5a. )
4.x.y.2
J%ereauiQ@ condtion~.
This paragraph shall identify any prerequisite conditions that
I
must be established prior to performing the test case. The following considerations shall be
discussed, as applicable:
a.

Hardware

and software

configuration

b.

Flags, initial breakpoints, pointers, control parameters,


prior to test commencement

c.

Preset hardware

d.

Initial conditions to be used in making timing measurements

e.

Conditioning

f.

Other special conditions peculiar to the test case

or initial data to be set/reset

conditions or electrical states necessary to run the test case

of the simulated environment

4.x.y.3
Jest irmut~. This paragraph shall describe the test inputs necessary for the test case.
The following shail be provided, as applicable:
of each test input

a.

Name, purpose, and description (e.g., range of values, accuracy)

b.

Source of the test input and the method to be used for selecting the test input

c.

Whether

d.

Time or event sequence of test input

e.

The manner in which the input data will be controlled to:

Page ~

of ~

the test input is real or simulated

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10,

PREPARATION

Test Description (STD)


DI-IPSC-81439

-- 10.2

INSTRUCTIONS

Content Requirements

(continued]

1)

Test the item(s) with a minimum/reasonable

number of data types and values

2)

Exercise the item(s) with a range of valid data types and values that test for
overload, saturation, and other worst case effects

3)

Exercise the item(s) with invalid data types and values to test for appropriate
handling of irregular inputs

4) Permit retesting, if necessary


4.x. Y.4 ~xc)ected test reSulu! This paragraph shall identify all expected test results for the
test case. Both intermediate and final test results shall be provided, as applicable.
4.x.y.5
Criteria for evalu atina results. This paragraph shall identify the criteria to be used for
evaluating the intermediate and final results of the test case. For each test result, the
following information shall be provided, as applicable:
a.

The range or accuracy over which an output can vary and still be acceptable

b,

Minimum number of combinations or alternatives


constitute an acceptable test result

c.

Maximum/minimum

d.

Maximum

number of interrupts,

e.

Allowable

severity of processing errors

f.

Conditions under which the result is inconclusive and re-testing is to be performed

Conditions under which the outputs are to be interpreted as indicating irregularities


in input test data, in the test database/data files, or in test procedures

h.

Allowable indications of the control, status, and results of the test and the readiness
for the next test case (may be output of auxiliary test software)

i.

Additional

allowable

of input and output conditions that

test duration, in terms of time or number of events

criteria not mentioned

halts, or other system breaks that may occur

above.

4.x.Y.6 Test Drocedu r~. This paragraph shall define the test procedure for the test case. The
test procedure shall be defined as a series of individually numbered steps listed sequentially
in the order in which the steps are to be performed.
For convenience
in document
maintenance, the test procedures may be included as an appendix and referenced in this
paragraph.
The appropriate level of d,etail in each test procedure depends on the type of
software being tested. For some software, each keystroke may be a separate test procedure
step; for most software, each step may include a logically related series of keystrokes or other
actions. The appropriate level of detail is the level at which it is useful to specify expected
results and compare them to actual results. The following shall be provided for each test
procedure, as applicable:
a.

Test

operator

commands,

actions and equipment

as applicable,

operation

required for each step, including

to:

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

PREPARATION

10.

INSTRUCTIONS

Test Description
DI-IPSC-81439

(STD)

Content Requirements

-- 10.2

1]

Initiate the test case and apply test inputs

2)

Inspect test conditions

3)

Perform interim evaluations

4)

Record data

5)

Halt or interrupt the test case

6)

Request data dumps or other aids, if needed

7)

Modify the database/data

8)

Repeat the test case if unsuccessful

9)

Apply alternate modes as required by the test case

1 o)

Terminate

(continued)

of test results

files

the test case

b.

Expected result and evaluation

c.

identification
of which test
If the test case addresses multiple requirements,
procedure step(s) address which requirements.
(Alternatively, this information may
be provided in 5.)

d.

Actions to foilow in the event of a program stop or indicated error, such as:

e.

criteria for each step

1)

Recording of critical data from indicators for reference purposes

2)

Halting or pausing time-sensitive

3)

Collection of system and operator records of test results

test-support

software

and test apparatus

Procedures to be used to reduce and analyze test results to accomplish the following,
as applicable:
1)

Detect whether an output has been produced

2)

Identify media and location of data produced by the test case

3)

Evaluate output as a basis for continuation

4)

Evaluate test output against required output

of test sequence

4.x.y.7 ~ ssumDtions and co nstrain t ~. This paragraph shall identify any assumptions made
and constraints or limitations imposed in the description of the test case due to system or test
conditions, such as limitations on timing, interfaces, equipment, personnel, and database/data
files. if waivers or exceptions to specified limits and parameters are approved, they shall be
identified and this paragraph shall address their effects and impacts upon the test case.
5.

Reau irements traceab ility.


a.

Page &

This paragraph shall contain:

Traceability from each test case in


addresses. If a test case addresses
of test procedure steps to the
traceability may be provided in 4.x.

of ~

this STD to the system or CSCI requirements it


multiple requirements, traceability from each set
requirement(s)
addressed.
(Alternatively,
this
Y.l. )

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION
b.

INSTRUCTIONS

Test Description
DI-IPSC-81439

-- 10.2

(STD)

Content Requirements

(continued)

Traceability from each system or CSCI requirement covered by this STD to the test
case(s) that address it. For CSCI testing, traceability from each CSCI requirement in
the CSCIS Software Requirements Specification (SRS) and associated Interface
Requirements Specifications
(IRSS).
For system testing, traceability from each
system requirement in the systems System/Subsystem
Specification {SSS) and
associated IRSS. If a test case addresses multiple requirements, the traceability shall
indicate the particular test procedure steps that address each requirement.

6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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. ADD endixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Fiwm Appro ved


OMB NO. 0704-0188

DATA ITEM DESCRIPTION


Pubhc mpOrtoIWbudm
Joucn,

OWWIW

to vww

tm cohmtwn et On mlormm,m to atlm.td

md mmntmmm tho 6SM rnadad ud

of NW COOOCWI!# lr!bfmwum.

inchdkqI ~ttem

Highway, Suto 1204, &ht-@en,

VA 22202-4302,

fat t-utfw
&

110 Iwum pw taom91,

cow@otIIw UUI r.vmw ttw tln cdhclmn


ltw butin

to Wdnwton

#o tlu OttIm d M Onakwmonlud

mclud<q tln mu

to. f.vnwmg

nvtructwfu,

01Inlamml on. Smxl comrnunc rcoud!~

Moakquwtaro 6avtca.

Buloet, Punrwork

Dwoclorbto of OIMf@I~

s.

et.

ual Ibparts, 1216 Jdtor.on

IDE

TEST PLAN (STP)

.mWtIW

rnt!mow or my OWUI -POCI

%ductmm Propct (0704 -018BI, WNtwW?M


I

SOFTWARE

9DwchItI0

1A bwdm

D.vrn

DC 20603,

NTIFICAT)ON

NU~

DI-IPSC-81438

3.1 The Software

Test Plan (STP) describes plans for qualification testing of Computer Software
Configuration Items (CSCIS) and software systems. It describes the software test environment to be used
for the testing, identifies the tests to be performed, and provides schedules for test activities.
3.2 There is usually a single STP for a project. The STP enables the acquirer to assess the adequacy of
planning for CSCI and, if applicable, software system qualification testing.

4.

APPROVAL

~m

DATE

APPLICATION-R

7.1

5.

OFFICE OF PRIMARY RESPONSIBklTY

941205

6a.

6b . GIDEP APPLICABLE

DTIC APPLICABLE

EC

~TIoNsHIP

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 develop and record plans for conducting
qualification testing and/or system qualification testing of a software system.

CSCI

7.3 The Contract Data Requirements List (CDRL) (DD 1423) 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 suppoti 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.
7,4 This DID supersedes DI-MCCR-8001
DI-MCCR-80309.

B. APPROVAL

LIMITATION

Limited Approval from 12/5/94


)0.

4A, DI-IPSC-80697,

PREPARATION

9*.

DI-MCCR-80307,

APPLICABLE FORMS

DI-MCCR-80308,

9b.

and

AMSC NUMBER

through 12/S/96

N7081

lNSTR~ONS

10.1 Ge neral instru ction~.


a.

Automated tec hniaues. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

b.

Alternate

mesentation

stvle~,

Diagrams, tables, matrices,

The term document-

and other presentation

in this

styles are

acceptable substitutes for text when data required by this DID can be made more readable using
these styles.

(Continued on page 2)
~ fi:

DISTRIBUTION

1DISTRIBUTION

STATEMENT

STATEMENT

00 Ferm 1664, APR 89


136/123

A.

Approved

for public release;

distribution

is unlimited.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source Previous
to verify that
this isare
theobsolete
current version before use.
editions

Page J_ of ~

Pages

Software Test Plan (STP)


DI-IPSC-81438
10.
c.

PREPARATION
Title

INSTRUCTIONS

DaQe or id entifier.

The

-- 10,1

General

document

shall

Instructions
include

(continued)
a title

page

containing,

as

indicator; security
document
number;
volume
number; version/revision
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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.
applicable:

d.

Table of content$.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Paae numberina/labe Iin g . Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Resr)onse to tailorina instru ctions,


If a paragraph is tailored out of this DID, the
resulting document shall 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.

9.

Multicde cmraaraDhs and sub Daraaracrh~. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

If a data description required by this DID has been


Sta ndard dat a desc rif)tions.
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.

Wbst itut ion of existina docu ment~. Commercial or other existing documents
substituted for all or part of the document if they contain the required data.

may be

10.2
co ntent reau irement$.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Plan (STP)


DI-IPSC-81438
10.
1.
1.1

PREPARATION
-.

INSTRUCTIONS

-- 10.2

Content Requirements

This section shall be divided into the following


Identificat

ion.

This

paragraph

shall contain

(continued)

paragraphs,

a full identification

of the system

to which this document applies, including, as applicable, identification


title(s), abbreviation(s), version number(s), and release number(s).
software

and the

number(s),

1.2 Svste m overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Pocu ment overview. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
1.4

Relationship)

STP to related

to other

project

dan~.

This paragraph

management

shall describe

the relationship,

if any, of the

plans.

2. Referenced doc ument~. This section shall list the number, title, revision, and date of all
documents referenced in this plan.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
This section shall be divided into the following paragraphs
3. so ftware test environment.
to describe the software test environment at each intended test site. Reference may be mada
to the Software Development Plan (SOP) for resources that are described there.
3.x JName of test site~.
This paragraph shall identify one or more test sites to be used for
the testing, and shall be divided into the following subparagraphs to describe the software test
environment at the site(s). If all tests will be conducted at a single site, this paragraph and
its subparagraphs shall be presented only once. If multiple test sites use the same or similar
software

test environments,

test site descriptions

they may be discussed

may be reduced

by referencing

together.

Duplicative

earlier

descriptions.

information

among

3. X,1
so ftware items. This paragraph shall identify by name, number, and version, as
applicable, the software items (e.g., operating systems, compilers, communications software,
related applications software, databases, input files, code auditors, dynamic path analyzers,
test drivers, preprocessors, test data generators, test control software, other special test
software, post-processors) necassary to perform the planned testing activities at the test
site(s). This paragraph shall describe the purpose of each item, describe its media (tape, disk,
etc.), identify those that are expected to be supplied by the site, and identify any classified
processing or other security or privacy issues associated with the software items,
3.x.2
Hardware and firmware items. This paragraph shall identify by name, number, and
version, as applicable, the computer hardware, interfacing equipment, communications
equipment, test data reduction equipment, apparatus such as extra peripherals (tape drives,
printers, plotters), test message generators, test timing devices, test event records, etc., and
firmware items that will be used in the software test environment at the test site(s). This
paragraph shall describe the purpose of each item, state the period of usage and the number

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Plan (STP)


DI-IPSC-81438
10.

PREPARATION

INSTRUCTIONS

-- 10-2

Content Requirements

(continued)

of each item. needed, identify those that are expected to be supplied by the site, and identify
any classified processing or other security or privacy issues associated with the items.
3.x.3
Other mate rial~. This paragraph shall identify and describe any other materials
needed for the testing at the test site(s). These materials may include manuals, software
listings, media containing the software to be tested, media containing data to be used in the
tests, sample listings of outputs, and other forms or instructions. This paragraph shall identify
those items that are to be delivered to the site and those that are expected to be supplied by
the site. The description shall include the type, layout, and quantity of the materials, as
applicable. This paragraph shall identify any classified processing or other security or privacy
issues associated with the items.
3.x.4
Promietarv natur~a
uirers riahts. and licensing. This paragraph shall identify the
proprietary nature, acquirers rights, and licensing issues associated with each element of the
software test enwronment.
3.x.5
Insta Ilation. test ins. and co ntroi. This paragraph shall identify the developers plans
possibly in conjunction with personnel at the test site(s):
for performing each of the following,
a.

Acquiring

or developing

each element of the software

b.

Installing and testing each item of the software

c.

Controlling

and maintaining

test environment

test environment

each item of the software

prior to its use

test environment

ParticiDat ina oraani7ationS. This paragraph shall identify the organizations that will
3.x.6
participate in the testing at the test sites(s) and the roles and responsibilities of each.
3.x.7
Personnel. This paragraph shall identify the number, type, and skill level of personnel
needed during the test period at the test site(s), the dates and times they will be needed, and
any special needs, such as multishift operation and retention of key skills to ensure continuity
and consistency in extensive test programs.
3.x.8

Qrient ation

t)lan.

This

paragraph

shall describe

any orientation

and training

to be

This information shall be related to the personnel needs


given before and during the testing.
given in 3.x.7. This training may include user instruction, operator instruction, maintenance
and control group instruction, and orientation briefings to staff personnel. If extensive training
is anticipated, a separate plan may be developed and referenced here.
3.x.9
to be Derf ormed. This paragraph shall identify,
tests to be performed at the test site(s).

by referencing section 4, the

4. Test identificat ion. This section shall be divided into the following paragraphs to identify
and describe each test to which this STP applies.
4.1 Ge neral information.
This paragraph shall be divided into subparagraphs
general information applicable to the overall testing to be performed.
4.1.1
Tes t levels.
This paragraph shall describe
performed, for example, CSCI level or system level.
Page ~

of&

the levels at which

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

to present

testing

will be

Software Test Plan (STP)


DI-IPSC-81438
10,

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

4.1.2
Test classes. This paragraph shall describe the types or classes of tests that will be
performed (for example, timing tests, erroneous input tests, maximum capacity tests).
4.1.3
!3e neral test co nditions. This paragraph shall describe conditions that apply to all of
the tests or to a group of tests. For example: Each test shall include nominal, maximum,
and minimum values; each test of type x shall use live data; execution size and time shall
be measured for each CSCI. Included shall be a statement of the extent of testing to be
performed and rationale for the extent selected. The extent of testing shall be expressed as
a percentage of some well defined total quantity, such as the number of samples of discrete
Also included shall be the
operating conditions or values, or other sampling approach.
for retesting/regression testing,
approach to be followed
4.1.4
Test moaress ion. In cases of progressive or cumulative
explain the planned sequence or progression of tests.

tests, this paragraph shall

4.1.5
Data reco rdina, redu ction, and a nalvsis. This paragraph shall identify and describe
the data recording, reduction, and analysis procedures to be used during and after the tests
and
identified in this STP. These procedures shall include, as applicable, manual, automatic,
semi-automatic
techniques
for recording test results, manipulating
the raw results
suitable for evaluation, and retaining the results of data reduction and analysis.

4.2 P~.
This paragraph shall be divided into the following
describe the total scope of the planned testing.

into a form

subparagraphs

to

4.2.x
Jltem(s) to be testedl. This paragraph shall identify a CSCI, subsystem, system, or
other entity by name and project-unique identifier, and shall be divided into the following subparagraphs to describe the testing planned for the item(s). (Note: the tests in this plan are
collections of test cases. There is no intent to describe each test case in this document. )
4.2.x.y jProiect -uniau e identifier of a testl. This paragraph shall identify a test by project-unique identifier and shall provide the information specified below for the test. Reference may
be made as needed to the general information in 4.1.
a.

Test objective

b,

Test level

c.

Test type or class

d.

Qualification

e.

Identifier of the CSCI requirements and, if applicable, software system requirements


addressed by this test. (Alternatively, this information may be provided in Section 6.)

f.

Special requirements {for example, 48 hours of continuous facility time, weapon


simulation, extent of test, use of a special input or database)

9.

Type of data to be recorded

h.

Type of data recording/reduction/analysis

method(s)

as specified in the requirements

specification

to be employed

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Plan (STP)


DI-IPSC-81438
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content

Requirements

(continued)

i.

Assumptions and constraints, such as anticipated limitations on the test due to


system or test conditions--timing,
interfaces, equipment, personnel, database, etc.

j.

Safety, security, and privacy considerations

associated with the test

5. Test schedules. This section shall contain or reference the schedules for conducting the
tests identified in this plan. It shall include:

6.

a.

A listing or chart depicting the sites at which the testing will be scheduled and the
time frames during which the testing will be conducted

b.

A schedule for each test site depicting the activities and events listed below, as
applicable, in chronological order with supporting narrative as necessary:
1)

On-site

test

period

and periods

2)

Pretest on-site period needed for setting up the software test environment
other equipment, system debugging, orientation, and familiarization

3)

Collection of database/data
needed for the testing

4)

Conducting

5)

Preparation,

the tests,

assigned

to major

of the testing

and

file values, input values, and other operational data

including

planned

retesting

review, and approval of the Software

Reau irements traceab ility.

portions

Test Report (STR)

This paragraph shall contain:

a.

Traceability from each test identified in this plan to the CSCI requirements and, if
applicable,
software
system requirements
it addresses.
(Alternatively,
this
traceability may be provided in 4.2.x.y and referenced from this paragraph. )

b.

Traceability from each CSCI requirement and, if applicable, each software system
requirement covered by this test plan to the test(s) that address it. The traceability
shall cover the CSCI requirements
in all applicable Software
Requirements
Specifications (SRSS) and associated Interface Requirements Specifications (IRSS),
and, for software systems, the system requirements in all applicable System/
Subsystem Specifications (SSSs) and associated system-level IRSS.

7. w.
This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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. ADDe ndixe$.
Appendixes
may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

DATA ITEM DESCRIPTION


PLMC

rowut,~ bud.n

00WCU, omhrI~

tacdt.twm et this
matntwvn@ rln data

of trw colisclwn of ttdnnnmton, tmcld~


ti~hwsy,
1.

tit.

1204, Arlm@m,

mtwmeuon m ntnnti.d
nndui

ud

~tlam

cotn@wtItw

fof ~

VA 222024302,

to W-W
utd

rwnow

ttN budu!

and to tho OffIa

110 hotm pm rmp-,

tti
cdbct!m

to WdwWlon

of Muupsmom

ad

mcld,~

of Iniwmmmn.
HOXINS

6UKI cafnmoftm ?qardrg

6-WICU,

tti

bwdm al,mata

DItoctor#w d 00WMION

a,

BUC+WI,Pumrwo!k llaductmn Propel D704.01 BE), W*rUmn

I 2.

TITLE

SOFTWARE

Form Approved
(2M8 NO. O704-0188

1
lhD II!IU for tevwv#vw Itntvwtmru, matchmJ xutbw d.!.
Dovm

, DC 20603.

10E~CA71 oN ~

TEST REPORT [STR)

w any etlmt QCf

1216 Jdtuwn

DI-IPSC-81440

3.1 The Software Test Report (STR) is a record of the qualification testing performed on a Computer
Software Configuration Item ICSCI), a software system or subsystem, or other software-related item,
3.2

The STR enables the acquirer to assess the testing and its results.

APPROVAL

DATE

941205
A-TION~R

5.

OFFICE OF PRIMARY RE6PDNS161LITY

6a.

DTIC AP PLICABLE

6b.

GIDEP APPUCABLE

EC

-m

EIATIONSlllP

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 01D is used when the developer is tasked to analyze and record the results of CSCI qualification

testing, system qualification testing of a software system, or other testing identified in the contract.
7.3 The Contract Data Requirements List (CDRL) (DD 1423) 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.
7,4

This DID supersedes DI-MCCR-8001

). APPROVAL LIMITATIoN
Limited Approval from 12/5/64

7A, DI-IPSC-80698,

throuoh 12/5/66

10. PREPARATION
IN6TWCTIONS

9a.

and DI-MCCR-80311.

APPLICABLE FORMS

9b . AMSC NUMBER

N7083

10,1 Se neral instru ction~.


a. Automated

tec hniaue~. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

b.

The term document

in this

Alternate Presentation stvle~, 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.

(Continued on Page 21
: 11.DISTRIBUTION
[ i71STR16UT10N

STATEMENT
STA~EME~T

ti~ Form 1664, APR 89


135/1

23

A.

Approved

for public release; distribution

is unlimited.

Source: https://assist.dla.mil
-- Downloaded:
2016-03-31T14:47Z
Previous editions
are obsolete
Check the source to verify that this is the current version before use.

Page J_ 01 &

Pages

Software

Test

Report

(STR)

DI-IPSC-81440

10.
c.

PREPARATION

INSTRUCTIONS

-- 10.1 General Instructions

(continued)

Title ciaae or ide ntifier.


The document shall 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
For data in a database or other alternative
organization; and distribution statement,
form,

this information

identification

shall be included

on external

and internal

labels or by equivalent

methods.

d.

Table of contents.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

Ptme numberindlabe Iinq. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

ResDonse to t ailorina instruct icmS. If a paragraph is tailored out of this DID, the
paragraph number and title, followed
resulting document shall contain the corresponding
by This paragraph
form,

has been tailored

this representation

need occur

out. For data in a database

or other alternative

only in the table

or equivalent.

of contents

g.

Multide DaraaraDhs and subDa raararlh$. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

Standard data desc ritNions.


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.

s ubst itution of existina docu ment s . Commercial or other existing documents


substituted for all or part of the document if they contain the required data.

may be

10.2
content reau irement~.
Content requirements begin on the following page.
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.

Page J_ of &

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Report (STR)


DI-IPSC-81440
10.
1.

PREPARATION
~CQDQ.

INSTRUCTIONS

This section

-- 10.2

shall be divided

Content Requirements

into the following

(continued)

paragraphs.

1.1
Identific ation.
This paragraph
shall 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 Wstem
This paragraph shall briefly state the purpose of the system and the
o verview.
software
to which this document applies.
It shall describe the general nature of the system
and software;
summarize
the history
identify the project sponsor, acquirer,

of system

development,

operation,

and maintenance;

user, developer, and support agencies; identify current


and planned operating sites; and list other relevant documents.
1.3

Pocu ment overview. This paragraph shall summarize the purpose and contents of this
and shall describe any security or privacy considerations associated with its use.

document

2. Be ferenced docu ment~. This section shall list the number, title, revision, and date of all
documents referenced in this report.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3. Qverview of tes t resu 1~. This section shall be divided into the following
provide an overview of test results,
3.1

Qverall assess ment of the software tested.

paragraphs to

This paragraph shall:

a.

Provide an overall assessment


in this report

of the software

b.

Identify any remaining deficiencies, limitations, or constraints that were detected by


the testing performed.
Problem/change reports may be used to provide deficiency
information.

c.

For each remaining deficiency,

limitation,

as demonstrated

or constraint,

describe:

1)

Its impact on software


requirements not met

and system

2)

The impact on software

and system design to correct it

3)

A recommended

solution/approach

performance,

by the test results

including

identification

of

for correcting it

3.2 lm~act of test environment. This paragraph shall provide an assessment of the manner
in which the test environment may be different from the operational environment and the
effect of this difference on the test results.
3.3 Reco remended imrxovement~.
This paragraph shall provide any recommended
improvements in the design, operation, or testing of the software tested. A discussion of
each recommendation and its impact on the software may be provided. If no recommended
improvements are provided, this paragraph shall state None.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Report (STR)


DI-IPSC-81440
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

resu 1~. This section shall be divided into the following paragraphs to
iledtest
Pets
describe the detailed results for each test. Note: The word test means a related collection
of test cases.

4.

4.x (Proie ct-uniaue identifier of a tes~. This paragraph shall identify a test by project-unique
identifier and shall be divided into the following subparagraphs to describe the test results.
4.x. 1
Su mmarv of test resul~. This paragraph shall summarize the results of the test. The
summary shall include, possibly in a table, the completion status of each test case associated
with the test (for example, all results as expected, problems encountered , deviations
required). When the completion status is not as expected, this paragraph shall reference
the following paragraphs for details.
4.x.2
Problems encounterecj.
This paragraph shall be divided into subparagraphs
identify each test case in which one or more problems occurred.

that

4.x.2.y
JProiect -uniaue ide ntifier of a test ca sq). This paragraph shall identify by projectunique identifier a test case in which one or more problems occurred, and shall provide:
a.

A brief description

of the problem(s) that occurred

b.

Identification

of the test procedure step(s) in which they occurred

c.

Reference(s)
applicable

to the associated

d.

The number of times the procedure or step was repeated in attempting


problem(s) and the outcome of each attempt

e.

Back-up points or test steps where tests were resumed for retesting

problem/change

report(s)

and backup

data,

as

to correct the

4.x.3
Deviations from test cases/D r oced ures. This paragraph shall be divided into subparagraphs that identify each test case in which deviations from test case/test procedures
occurred.
4.x.3.y
JProiect-uniaue identifier of a test case ). This paragraph shall identify by projectunique identifier a test case in which one or more deviations occurred, and shall provide:
a.

A description of the
occurred and nature
procedural steps not
be used to show the

deviation(s) (for example, test case run in which the deviation


of the deviation, such as substitution of required equipment,
followed, schedule deviations}. (Red-lined test procedures may
deviations)

b.

The rationale for the deviation(s)

c.

An assessment

of the deviations

impact on the validity of the test case

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software Test Report (STR)


DI-IPSC-81 440
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

{continued)

5. Test log. This section shall present, possibly in a figure or appendix, a chronological
record of the test events covered by this report. This test log shall include:
a.

The date(s), time(s), and location(s) of the tests performed

b.

The hardware and software configurations used for each test including, as applicable,
part/model/serial
number, manufacturer, revision level, and calibration date of all
hardware, and version number and name for the software components used

c.

The date and time of each test-related activity, the identity of the individual(s) who
performed the activity, and the identities of witnesses, as applicable

6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall 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. ADDendixe~. Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alpha beticaii y (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Page Ji_ of ~

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Form Approved
OMB NO.0704-O 188

DATA ITEM DESCRIPTION


PLINK mvcutIIw budm

101cdbctmn

OCVUIIQ and mmmamrw

-Mm,

ot ttn cdlutmn

of mform~at,

of thm mformmmn .unnmd

ffn data

ru.dd

ud

tncfdww ~ttom

cau9Mrw

10 W.IW
-

for ?aduewq lh

Htphwcy, Suta 1204, ArltWton. VA 22202+302,

&

to rfu Oft!-

110 how

?ewwm
ti-

tho

to WVhww!m

ffaadquuum

t and ltuIwi,

of M~

Inclldqi

f~,

Cokctmof mfotmmmn.
P~wtJIh

tb

tlnn Im I*VNW mg 11-www,olu, amctwql

Swnd conmmnm wgudmg I*

Scwm.
ftduaon

Dwaformc wt Opsfmwrm ad

Rawrm

PIC+OC!IO7O4-O1O8I, Wdnqtm

9x4411~6ua
m mv ottu! ~cl

1216 J@t -

SOFTWARE

TRANSITION

PLAN (STrP)

Dovn

, DC 20603

I 2 DE NTIFtCATION

TITLE

~.

Lwdsn attmuc

N~

DI-IPSC-81429

3. DESCRIPTION/PURPOSE

3.1 The Software Transition Plan (STrP) identifies the hardware, software, and other resources needed for
life cycle support of deliverable software and describes the developers plans for transitioning deliverable
items to the support agency.
3.2 The STrP is developed if the software support concept calls for transition of responsibility from the
developer to a separate suppon agency, The STrP may also be used by the acquirer for updating the
Computer Resources Life Cycle Management Plan.

4. APPROVAL

DAtE

941205

OFFICE OF PRIMARY

~1

6a.

RESPONSIBILITY

EC

DTIC APPLICABLE

6b.

GIDEP APPLICABLE

7.1 This Data hem Description (DID) contains the format and content preparation instructions
product generated by specific and discrete task requirements as delineated in the contract.
7.2 This DID is used when the developer
items to the suppon agency.

for the data

is tasked to develop and record plans for transitioning

deliverable

7.3 The Contract Data Requirements List (CDRL) (DD 1423) 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 suppon 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.

7.4 This DID supersedes DI-MCCR-80024A.

B. APPROVAL

llM ITATION
Limited Approval from 12/5/94

)0,

PREPARATION

9a.

f4b. AMSC NUMBER

APPLICABLE FORMS

through 12/5/96

N7072

INSTRU CTIONS

10.1 Ge neral instruct ion~,


a. Automated

tec hnim.te$, Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

The term document

in this

b. Alte mate r)resentat ion styles.


acceptable substitutes
these styles.

I
.- .-. .

11. DISTRIBUTION

DISTRIBUTION

(Continued on Page 2)
STATEMENT

STATEMENT

,.-

CIDForm 1664, APR 89


135/123

Diagrams, tables, matrices, and other presentation styles are


for text when data required by this DID can be made more readable using

A.

Approved

for public release; distributicm

is

unlimited.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source toPrevious
verify that
this is the
version before use.
editions
are current
obsolete

..J

Page ~

of &

Pages

Software

10.

PREPARATION

INSTRUCTIONS

Transition Pian (STrPJ


DI-IPSC-8 1429

-- 10.1 General Instructions

(continued)

c.

The document shall include a title page containing, as


~itle DWM or ide ntifier.
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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

Table of conten~.
The document shall contain a table of contents providing the
number, title, and page number of each titled paragraph, figure, table, and appendix.
For data in a database or other alternative form, this information shall 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.

PJNle numbe rina/labelinq, Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

ResDonse to t ailorina
resulting

document

instruc tion~.
If a paragraph
is tailored
out of this DID, the
shall contain the corresponding
paragraph number and title, followed

by This paragraph has been tailored out.


For data in a database
need occur only in the table of contents
form, this representation

or other alternative

or equivalent.

9.

JVlultide LX!ragrallhs and subt3araara trh~. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

standard data desc riDtionS.


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.

bst itut ion of existina docu men@. Commercial or other existing documents
substituted for all or part of the document if they contain the required data.

may be

10.2
reau irementS.
The
Content
requirements
begin on the following
page.
Gontent
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
SCODQ.

INSTRUCTIONS

Transition Plan (STrP)


DI-IPSC-81429

-- 10.2

Content

Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1 tie ntificat ion. This paragraph shall 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 Svste m overview. This paragraph shall briefly state the purpose of the system and the
software to which this document applies, It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.
1.3 Pocu~e n t o verview.
This paragraph
document
and shall describe any security

shall summarize
the purpose and contents
of thfs
or privacy considerations
associated
with its use.

1.4
Relationship
to ot her dan~. This paragraph shall describe the relationship,
STrP to other project management plans.

if any, of the

2. Referenced docu ment~. This section shall list the number, title, revision, and date of all
documents referenced in this document.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3.

~oftwa re suDDo rt resou rce~. This section shall be divided into paragraphs to identify and

describe
include
to

the resources
items needed

specify,

modifications

design,

needed

to control,

to support

the deliverable

copy, and distribute

implement,

document,

test,

software.

the software
evaluate,

resources

shall

and its documentation,

and

control,

These
copy,

and

distribute

to the software.

3.1 Facilities. This paragraph shall describe the facilities needed to support the deliverable
software. These facilities may include special buildings, rooms, mock-ups, building features
such as raised flooring or cabling; building features to support security and privacy
requirements
(TEMPEST
shielding, vaults, etc.), building features to support safety
requirements (smoke alarms, safety glass, etc.), special power requirements, and so on. The
purpose of each item shall be described. Diagrams may be included as applicable.
3.2 Hardware.
This paragraph shall identify and describe the hardware and associated
documentation
needed to support the deliverable software.
This hardware may include
computers, peripheral equipment, hardware simulators, stimulators, emulators, diagnostic
equipment, and non-computer equipment. The description shall include:
a.

Specific models, versions, and configurations

b.

Rationale

c.

Reference to user/operator

d.

Identification
will
have,

for the selected

manuals or instructions

for each item, as applicable

of each hardware item and document as acquirer-furnished,

be delivered
an item

hardware

to the support

the support

agency

agency,
must

an item
acquire,

the

support

or other

agency

description

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

an item that
is known

of status

to

Software

10.

PREPARATION

Transition Plan (STrP)


DI-IPSC-81429

-- 10.2

INSTRUCTIONS

Content Requirements

(continued)

e.

If items must be acquired, information


about a current source of supply, including
whether the item is currentiy available and whether it is expected to be available at
the time of delivery

f.

Information about manufacturer support, licensing, and data rights, including whether
the item is currently supported by the manufacturer, whether it is expected to be
supported at the time of delivery, whether licenses will be assigned to the support
agency, and the terms of such licenses

9.

Security and privacy considerations,

limitations,

or other items of interest

3.3 ~oftware.
This paragraph shall identify and describe the software and associated
documentation
needed to support the deliverable software.
This software may include
computer-aided software engineering (CASE) tools, data in these tools, compilers, test tools,
test data, simulations, emulations, utilities, configuration management tools, databases and
data files, and other software.
The description shall include:
a.

Specific
names,
identification
configurations,
as applicable

b.

Rationale for the selected software

c.

Reference to user/operator

d.

Identification of each software item and document as acquirer-furnished, an item that


will be delivered to the support agency, an item the support agency is known to
have, an item the support agency must acquire, or other description of status

e.

If items must be acquired, information about a current source of supply, including


whether the item is currently available and whether it is expected to be available at
the time of delivery

f.

information about vendor support, licensing, and data rights, including whether the
item is currently supported by the vendor, whether it is expected to be supported at
the time of delivery, whether licenses will be assigned to the support agency, and the
terms of such licenses

9.

Security and privacy considerations,

numbers,

version

numbers,

manuals or instructions

limitations,

release

numbers,

and

for each item, as applicable

or other items of interest

3.4 Qther document ation. This paragraph shall identify any other documentation needed to
The list will include, for example, plans, reports, studies,
support the deliverable software.
specifications, design descriptions, test Cases/procedures, test reports, user/operator manuals,
and support manuals for the deliverable software. This paragraph shall provide:
a.

Names, identification

numbers, version numbers, and release numbers, as applicable

b.

Rationale for including each document

c.

Identification of each document as acquirer-furnished, an item that will be delivered


to the support agency, an item the support agency is known to have, an item the
support agency must acquire, or other description of status

d.

If a document

in the list

must be acquired, information about where to acquire it

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION

INSTRUCTIONS
about

Transition Plan (STrP)


DI-IPSC-81429

-- 10.2

Content

Requirements

(continued)

licensing and data rights

e.

Information

f.

Security and privacy considerations,

3.5 Pe rsonnel. This paragraph


software, including anticipated
This
and security clearances,
development project as a basis

limitations,

or other items of interest

shall describe the personnel needed to support the deliverable


number of personnel, types and levels of skills and expertise,
paragraph shall cite, as applicable, actual staffing on the
for the staffing needs cited.

This paragraph shall identify any other resources needed to support the
3.6 g~.
deliverable software.
Included may be consumables such as magnetic tapes and diskettes,
together with an estimate of the type and number that should be acquired.
This paragraph shall identify the interrelationships of
3.7 lnterrelationshio of comr)onen~.
the components identified in the preceding paragraphs, A figure may be used to show the
interrelationships.
4.
Recommended
D r ocedu re~. This section shall be divided into paragraphs as needed to
describe any procedures, including advice and lessons learned, that the developer may wish
to recommend to the support agency for supporting the deliverable software and associated
support environment.

This section shall be divided into paragraphs as appropriate to describe the


5. Trai@.
developers plans for training support personnel to support of the deliverable software.
This
section shall include:
a.

The schedule, duration, and location for the training

b.

The delineation

c.

Provision (either directly or by reference) for:

between

classroom training and hands-on training

1)

Familiarization

with the operational software

2)

Familiarization

with the support software

6. Anticipated a reas of chana~.


the deliverable software.

and target computer(s)

and host system

This section shall describe anticipated

areas of change to

7. Transition danninQ. This section shall be divided into paragraphs as needed to describe
the developers plans for transitioning the deliverable software to the support agency. This
section shall address the following:
a.

All activities to be performed to transition the deliverable software to the support


agency. These activities may include planning/coordination meetings; preparation of
items to be delivered to the support agency; packaging, shipment, installation, and
checkout of the software support environment; packaging, shipment, installation, and
checkout of the operational software; and training of support personnel.

b.

Roles and responsibilities

for each activity

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.

PREPARATION
c.

d.

INSTRUCTIONS

Transition Plan lSTrP)


DI-IPSC-81429

-- 10.2

Content Requirements

(continued)

The resources needed to carry out the transition activities and the source from which
each resource will be provided
Schedules and milestones for conducting the transition activities. These
shall be compatible
with the contract master schedule.

schedules

and milestones

e.

Procedures for
environment

installation

and

checkout

of deliverable

items

in the

support

shall contain any general information that aids in understanding this


document (e.g., background information, glossary, rationale). This section shall 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.
8.

a.

This section

A.
Dendixe$. Appendixes may be used to provide information published separately for
convenience in document maintenance (e. g., charts, classified data). As applicable, each
appendix shall be referenced in the main body of the document where the data would normally
Appendixes
may be bound as separate documents
for ease in handling.
have been provided.
Appendixes

Page ~

shall be lettered

of Jj_

alphabetically

(A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

fbrm Approved
OMB NO. 0704-0188

DATA ITEM DESCRIPTION


PdIk

mCWOrtJ bud.n

ouca,

o.IlurIrq

lo! U4WIIMI

of lhn ml o?mmmn m .wttmarad to

manfn+um ttu dma rm.dad d

d ttw cdl.cfmn d Infwmm!an, md@IIW

WOowoom

Hwhwav, 6U1C 1204, &lIfwton< VA 22202.4302,

SOFTWARE
3.

canoktwm M
fof ?oduiq

.vofap

110 houw cm tawxw,

UUIUS$WJ
trn !mw to! 18v18wqf nmwuctwm, 8.-

rcwuwl!u Mu cc.lloclim .4 mfwmaltom

ftn bwdon to WdnrWtcm

to lhc OffIW of M~

t d

USER MANUAL

S.rd

C-.W

Hcadqusrfaw 6UVIC.8, Dmcfaate

B@oDt, P~wwk

rq!wdtfw lFMObud..
of OmtttIom

fkducl,cm PIOPCI i0704~l

chmo mtrq

uflmolc

Rapum.

BB), Wtir@Ion

deta

w my etlut npmt

1216 Hi-

Dawn

, DC 20603.

(SUM)

DESCRIPTK)NIPURPOSE

3.1 The Software User Manual (SUM) tells a hands-on software user how to install and use a Computer
Software Configuration Item (CSCI), a group of related CSCIS, or a software system or subsystem.
It may
also cover a panicular aspect of software operation, such as instructions for a particular position or task.
3.2 The SUM is developed for software that is run by the user and has a user interface requiring on-line
user input or interpretation of displayed output, If the software is embedded in a hardware-software
system, user manuals or operating procedures for that system may make separate SUMS unnecessary.

Sb. GIDEP APPIJCA


941205

~w

7.1 This Data Item Description (DID] contains the format and content preparation instructions
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 identify and record information
users of software.
7,3 The SUM is an alternative to the Software Input/Output
Center Operator Manual {SCOM) (DI-IPSC-81 444).

for the data

needed by hands-on

Manual (SIOM) (DI-IPSC-81

445) and Software

7.4 The Contract Data Requirements List (CDRL) (DD 1423) should specify whether deliverable data are to
De delivered on paper or electronic media; are to be in a given electronic form (such as ASCII, CALS, or
:ompatible 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
ICASE) or other automated tool rather than in the form of a traditional document,
7.5 This DID supersedes
31-MCCR-80315.

DI-MCCR-8001

9A, DI-IPSC-80694,

E APPROVAL LIMITATION
Limited Approval from 12fSt94

9a.

DI-MCCR-8031

APPLICABLE FORMS

3, DI-MCCR-8031

9b.

4, and

AMSC NUMBER

through 12151e6

N7086

10. ~s
10.1 5e neral instruct ions.
a. Auto mated techniaues. Use of automated techniques is encouraged. The term document in this
DID means a collection
b.

Alternate

of data regardless of its medium.

cwesentation stvle~,

acceptable substitutes
these styles,

Diagrams, tables, matrices, and other presentation styles are


for text when data required by this DID can be made more readable using

(Continued on Page 21
l.OISTRIBUTION

STATEMENT

DISTRIBUTION
----.

U!J tarnl
23
135/1

------lbb4,

STATEMENT
AIW

--

83

A.

Approved

for public release;

distribution

is unlimited.
..

Source: https://assist.dla.mil
-- Downloaded:
2016-03-31T14:47Z
Previous editions
are obsolete
Check the source to verify that this is the current version before use.

Page ~

of &

Pages

Software User Manual (SUM)


DI-IPSC-81443
10.

PREPARATION

INSTRUCTIONS

-- 10.1

General

Instructions

(continued)

c.

Title Daae or ident ifier.


The document shall 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
For data in a database or other alternative
organization; and distribution statement.
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

Table of contents a nd index. The document shall contain a table of contents providing
the number, title, and page number of each titled paragraph, figure, table, and appendix,
and an index providing an alphabetic listing of key terms and concepts covered in the
document and the pages or paragraphs in which the terms or concepts are covered.
For data in a database or other alternative form, this information shall 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.

Paae numberinaflabe Iinq. Each page shall 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 shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.

f.

Res~onse to t ailorirm instru ctionS.


If a paragraph is tailored out of this DID, the
resulting document shall 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.

Mukirie DaraaraDhs and subDa raara r)h$. Any section, paragraph, or subparagraph in
this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

$tandard data desc ritltio~.


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.

stitut ion of existina docu menu.


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

maybe

10.2
co ntent requirements.
Content requirements begin on the following page.
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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software User Manual (SUM)


DI-IPSC-81443
10.

1.

PREPARATION
~CODQ.

INSTRUCTIONS

-- 10.2

Content

Requirements

This section shall be divided into the following

(continued)

paragraphs.

1.1
Identificat ion. This paragraph shall contain a full identification
of the system and the
software
to which this document
applies, including,
as applicable,
identification
number(s),
abbreviation(s),

1.2

This paragraph shall briefly state the purpose of the system and the
ste m overview.
to which this document
applies.
It shall describe the general nature of the system

software

and software;

version

summarize

number(s),

and release number(s).

title(s),

the history

of system

development,

operation,

identify the project sponsor, acquirer, user, developer,


and support
and planned operating
sites; and list other relevant documents.

and maintenance;

agencies;

identify

current

1.3 DOCUment overview. This paragraph shall summarize the purpose and contents of this
manual and shall describe any security or privacy considerations associated with its use.
2. Referenced docum en~. This section shall list the number, title, revision, and date of all
documents referenced in this manual.
This section shall also identify the source for all
documents not available through normal Government stocking activities.
3.

software

sumrnary.

This section shall be divided into the following

paragraphs.

3.1 so ftware arm Iication. This paragraph shall provide a brief description of the intended
uses of the software.
Capabilities, operating improvements, and benefits expected from its
use shall be described.
3.2 so ftware inventory. This paragraph shall identify all software files, including databases
and data files, that must be installed for the software to operate. The identification shall
include security and privacy considerations for each file and identification of the software
necessary to continue or resume operation in case of an emergency,
3.3 software e nvironme n~. This paragraph shall identify the hardware, software, manual
operations, and other resources needed for a user to install and run the software.
Included,
as applicable, shall be identification of:
a.

Computer equipment that must be present, including amount of memory needed,


amount of auxiliary storage needed, and peripheral equipment such as printers and
other input/output devices

b.

Communications

c.

Other

software

equipment
that

must

that

must

be present,

be present
such as operating

systems,

databases,

data

files, utilities, and other supporting systems


d.

Forms, procedures,

e.

Other facilities,

or other manual operations that must be present

equipment,

or resources that must be present

3.4 so ftware ora anization and overview of oc)eration. This paragraph shall provide a brief
description of the organization and operation of the software from the users point of view.
The description shali include, as applicable:

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software User Manual (SUM)


DI-IPSC-81443
10.

PREPARATION

INSTRUCTIONS

-- 10.2

Content Requirements

(continued)

a.

Logical components of the software, from the users point of view, and an overview
of the purpose/operation of each component

b.

Performance

characteristics

that can be expected

by the user, such as:

1)

Types, volumes, rate of inputs accepted

2)

Types, volume, accuracy,

3)

Typical response time and factors that affect it

4)

Typical processing time and factors that affect it

5)

Limitations,

6)

Error rate that can be expected

7)

Reliability that can be expected

rate of outputs that the software

can produce

such as number of events that can be tracked

c.

Relationship of the functions


organizations, or positions

d.

Supervisory
software

performed

by the software

controls that can be implemented

with interfacing

(such as passwords)

systems,

to manage the

3.5 Gent inaencies and aIternate states and modes of oDeration. This paragraph shall explain
differences in what the user will be able to do with the software at times of emergency and
in various states and modes of operation, if applicable.
This paragraph shall contain an overview of the security and
uritv and mivacy.
3.6
privacy considerations associated with the software.
A warning shall be included regarding
making unauthorized copies of software or documents, if applicable.
3.7 Assistance and Droblem reDorting. This paragraph shall identify points of contact and
procedures to be followed to obtain assistance and report problems encountered in using the
software.
4. Access to t h e so ftwar~. This section shall contain step-by-step procedures oriented to
the first time/occasional user. Enough detail shall be presented so that the user can reliably
Safety
access the software before learning the details of its functional capabilities.
precautions, marked by WARNING or CAUTION, shall be included where applicable.
4.1 First-time use r of the softwar~.
subparagraphs.
4.1.1

This paragraph

shall be divided into the following

kau ic)ment familiarizat ion. This paragraph shall describe the following as appropriate:

a.

Procedures for turning on power and making adjustments

b.

Dimensions and capabilities of the visual display screen

c.

Appearance of the cursor, how to identify an active cursor if more than one cursor
can appear, how to position a cursor, and how to use a cursor

d.

Keyboard layout and role of different types of keys and pointing devices

e.

Procedures for turning power off if special sequencing

of operations is needed

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

User Manual (SUM)

DI-IPSC-81443
10.

PREPARATION

4,1.2

INSTRUCTIONS

Ss co ntrol.

features

of the software

-- 10.2

Content

Requirements

This paragraph

shall present

an overview

that

to the user.

The following

are visible

(continued)
of the access
items

and security

shall be included,

as applicable:

4.1.3
must

a.

How

and from

b.

How

to add, delete,

c.

Security and privacy considerations


pertaining to the storage
reports and other media that the user will generate
Insta Ilation
perform

to perform
data,

whom

or change

and setuQ.

to be identified

the installation,

and to enter

to obtain

passwords

This paragraph
or authorized

to configure

parameters

a password
under

shall describe

to access

the software,

for software

user control

or install
to delete

and marking

any procedures
software

of output

that

the user

on the equipment,

or overwrite

former

files or

operation.

4.2 [nitiatina a sess ion, This paragraph shall provide step-by-step procedures for beginning
work, including any options available. A checklist for problem determination shall be included
in case difficulties are encountered.
4.3
ina work, This paragraph shall describe how the user can cease
or interrupt use of the software and how to determine whether normal termination or
cessation has occurred.
This section shall provide the user with procedures for using
5. Process ina reference *.
the software.
If procedures are complicated or extensive, additional Sections 6, 7, ... may
be added in the same paragraph structure as this section and with titles meaningful to the
sections selected. The organization of the document will depend on the characteristics of the
For example, one approach is to base the sections on the
software being documented.
organizations in which users work, their assigned positions, their work sites, or the tasks they
must perform. For other software, it may be more appropriate to have Section 5 be a guide
to menus, Section 6 be a guide to the command language used, and Section 7 be a guide to
functions. Detailed procedures are intended to be presented in subparagraphs of paragraph
5.3. Depending on the design of the software, the subparagraphs might be organized on a
function-by-function,
menu-by-menu,
transaction-by-transaction,
or other basis.
Safety
precautions, marked by WARNING or CAUTION, shall be included where applicable,

ab ilitie~, This paragraph shall briefly describe the interrelationships of the transac5.1
tions, menus, functions, or other processes in order to provide an overview of the use of the
software.
5.2 co nventions. This paragraph shall describe any conventions used by the software, such
as the use of colors in displays, the use of audible alarms, the use of abbreviated vocabulary,
and the use of rules for assigning names or codes.
5.3 Processing Lvocedure$. This paragraph shall explain the organization of subsequent
paragraphs, e.g., by function, by menu, by screen. Any necessary order in which procedures
must be accomplished shall be described.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

User Manual
DI-IPSC-81

10.

PREPARATION

INSTRUCTIONS

-- 10.2

(SUM)

443

Content

Requirements

(continued)

The title of this paragraph shall identify the function,


5.3.x
c1 of software u*.
menu, transaction, or other process being described. This paragraph shall describe and give
options and examples, as applicable, of menus, graphical icons, data entry forms, user inputs,
inputs from other software or hardware that may affect the softwares interface with the
user, outputs, diagnostic or error messages or alarms, and help facilities that can provide online descriptive or tutorial information.
The format for presenting this information can be
adapted to the particular characteristics of the software, but a consistent style of presentation
shall be used, i.e., the descriptions of menus shall be consistent, the descriptions of
transactions shall be consistent among themselves.
5.4 Related wocess ir-vg.This paragraph shall identify and describe any related batch, off line,.
or background processing performed by the software that is not invoked directly by the user
and is not described in paragraph 5.3. Any user responsibilities to support this processing
shall be specified.
5.5

Data bac ku~. This paragraph shall describe procedures for creating and retaining backup

data that can be used to


malfunctions,
or accidents.

replace

primary

copies

of

data

in event

of

errors,

defects,

This paragraph shall present


5.6 ~eco very from errors, malfunctions. and emergencies.
detailed procedures for restart or recovery from errors or malfunctions occurring during
processing and for ensuring continuity of operations in the event of emergencies,
5.7 JVless~.
This paragraph shall list, or refer to an appendix that lists, all error messages,
diagnostic messages, and information messages that can occur while accomplishing any of
the users functions. The meaning of each message and the action that should be taken after
each such message shall be identified and described.
5.8 91J ick-reference au ide. If appropriate to the software, this paragraph shall provide or
reference a quick-reference card or page for using the software, This quick-reference guide
shall summarize, as applicable, frequently-used function keys, control sequences, formats,
commands, or other aspects of software use.
6. Notes. This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall include an
and their meanings as used in this
alphabetical listing of all acronyms, abbreviations,
document and a list of terms and definitions needed to understand this document. If section
5 has been expanded into section(s) 6,..., this section shall be numbered as the next section
following section n,
A.

ADD

endixe~.

Appendixes

may

be used to provide

information

published

separately

for

As applicable,
each
convenience
in document
maintenance
(e g., charts, classified data).
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
Appendixes shall be lettered alphabetically (A, 3, etc.).

documents

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

for ease in handling.

DATA ITEM DESCRIPTION


PtdJhcWIXWWIWbudm
out.u,

tot colkcttm 01 NW tnfotmaf,m wttmmd

md mmma?uw

osvhuIfw

tlu

dab

fmakl

of ttuo cnlbctton d Warmtim,

mcltdIcw ~Iw

HI@nvu.

VA 22202-4302,

6uto 1204, &lkqtm,

md comphtww
fw ~
ud

to vwqw
ud
*

10 tvu Oft!u

110 IWW8 pm IMKIWN,

budm

uwludImJOn mm fo< rOVIOWIW tmtmcttom

Vho cdiccwm of mlonmmmn

rw.wIfw

te W-!wlMon
-

of M~

form Approved
OMB NO.0704-O 188

I
H-dauutom

Buid@,

6md cannunts

60 WIca, Dwwi-sto

Pvwwork

RoductIon PIqml

rqpd,rq

umt,W 6ma

wmchw

IIW hudan MW?ISIO ot any OVIW qc!

of OPOIatIom UM -s,

I0704Q188),

1216 Jeff-

W~WIon

2. lDE~CATION

SOFTWARE

3.1 The Software


or more Computer
versions.

VERSION

DESCRIPTION

(SVD)

O-u

, OC 20603

DI-IPSC-81442

Version Description (SVD) identifies and describes a software version consisting of one
Software Configuration Items (CSCIS). it is used to release, track, and control software

3.2 The term version may be applied to the initial release of the software, to a subsequent release of
that software, or to one of multiple forms of the software released at approximately the same time {for
example, to different sites).

4. APPROVAL
~

DATE

6. OFFICE OF PRIMARY RESPONSIBILITY

6a. DTIC APPLICABLE

6b . GIDEP APPUCABLE

EC

941205
~

7,1 This Data Item Description (DID) contains the format and content preparation instructions
product generated by specific and discrete task requirements as delineated in the contract,

for the data

7.2 This DID is used when the developer is tasked to identify and record the exact version of software
be delivered to a user, support, or other site.

to

7.3 The Contract Data Requirements List (CDRL) (DD 1423) 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.
7,4

This DID supersedes

DI-MCCR-800

9. APPROVAL LIMITATION
Limited Approval from 12/5/S4

13A, and DI-MCCR-803

St. APPUCABLE
through 12W96

12,

FORMS

9b. AMSC NUMBER


N7085

I ONS

~6$ARA-STRUCt

10,1 Ge neral instru ction$.


a.

Automated tec hniaue~. Use of automated techniques is encouraged.


DID means a collection of data regardless of its medium.

b.

Alternate wesentation
acceptable substitutes
these styles.

The term document

in this

stv les, Diagrams, tables, matrices, and other presentation styles are
for text when data required by this DID can be made more readable using

(Continued on Paoe 21
1 ! 1.-DISTRUWJTJON STATEMENT

~ DISTRIBUTION

STATEMENT

A. Approved for public release; distribution is unlimited.


I

)~ F-

135/123

1664, ApR 99

Source: https://assist.dla.mil
-- Downloaded:
2016-03-31T14:47Z
Revious editions
are obsolete
Check the source to verify that this is the current version before use.

Page ~

of ~

Pages

Software

10.

PREPARATION

INSTRUCTIONS

Version Description
DI-IPSC-81442
-- 10.1

General

(SVD)

Instructions

(continued)

c.

~le
9aoe o r id entifier.
The document shall 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
For data in a database or other alternative
organization; and distribution statement,
form, this information shall be included on external and internal labels or by equivalent
identification methods.

d.

Table of conten~.
The document shall contain a table of contents providing the
number, title, and page number of each titied paragraph, figure, table, and appendix.
For data

in a database

internal

or

accessing,

e.

num

document

external
each

or other
table

paragraph,

of

alternative
contents

figure,

table,

form,
containing

this information
pointers

and appendix

to,

shall consist
or

instructions

of an
for

or their equivalents.

rina/labeling.
number,

Each page shall contain a unique page number and display the
including version, volume, and date, as applicable.
For data in a

database or other alternative form, files, screens, or other entities shall be assigned
names or numbers in such a way that desired data can be indexed and accessed.
f.

ResK)onse to t ailorina instruct ions. If a paragraph is tailored out of this DID, the
resulting document shall 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.

Muhirlie DaraaraDhs and subr)araaraDhS. Any section, paragraph, or subparagraph in


this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

h.

standard data desc riDtion~,


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.

Wst itut ion of existina docu menu. Commercial or other existing documents may be
substituted for all or part of the document if they contain the required data.

10.2
co ntent reau iremen~.
Content requirements begin on the following page. 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.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

Software

10.
1.

PREPARATION
~coDQ.

INSTRUCTIONS

Version Description (SVD)


D14PSC-81442
-- 10.2

Content Requirements

This section shall be divided into the following

(continued)

paragraphs,

1.1 Identificat ion. This paragraph shall contain a full identification of the system and the
software to which this document applies, including, as applicable, identification number(s),
It shall also identify the
title(s), abbreviation(s), version number(s), and release number(s).
intended recipients of the SVD to the extent that this identification affects the contents of the
software released (for example, source code may not be released to all recipients. )
1.2
te m overview. This paragraph shall brief Iy state the purpose of the system and the
software to which this document applies. It shall 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 agencies; identify current
and planned operating sites; and list other relevant documents.

1.3
ume nt overvie w. This paragraph shall summarize the purpose and contents of this
document and shall describe any security or privacy considerations associated with its use.
2.

~eferenced

documents

documents
3.

docu ment~.

This section shall list the number, title, revision, and date of all
This section shall also identify the source for all
not available through normal Government stocking activities.
referenced

in this document.

Version des criotion.

This section shall be divided into the following paragraphs.

3.1 Inventorv of mate rials released. This paragraph shall list by identifying numbers, titles,
abbreviations, dates, version numbers, and release numbers, as applicable, all physical media
(for example, listings, tapes, disks) and associated documentation that make up the software
version being released, It shall include applicable security and privacy considerations for these
items, safeguards for handling them, such as concerns for static and magnetic fields, and
instructions and restrictions regarding duplication and license provisions.
3.2 ~~
n.
This paragraph shall list by identifying numbers, titles,
abbreviations, dates, version numbers, and release numbers, as applicable, all computer files
Any applicable security and privacy
that make up the software version being released.
considerations shall be included.
3.3 Charme s installed. This paragraph shall contain a list of all changes incorporated into the
software version since the previous version. [f change classes have been used, such as the
Class I/Class II changes in MIL-STD-973,
the changes shall be separated into these classes,
This paragraph shall identify, as applicable, the problem reports, change proposals, and
change notices associated with each change and the effects, if any, of each change on
system operation and on interfaces with other hardware and software. This paragraph does
not apply to the initial software version.
3.4

Adtmtat ion data.

contained
describe

This

in the software
changes

made

paragraph

version.

shall

For software

to the adaptation

identify

or reference

versions

after

all unique-to-site

the first,

this paragraph

data.

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.

data
shall

Software

10.

PREPARATION

INSTRUCTIONS

Version Description
DI-IPSC-81442
-- 10.2

(SVD)

Content Requirements

(continued)

This paragraph
shall list by identifying
numbers, titles,
3.5 Related docu ment~,
abbreviations, dates, version numbers, and release numbers, as applicable, all documents
pertinent to the software version being released but not included in the release.
Ilation instruct ions.
3.6 ~
information, as applicable:
a.
b.

Instructions
Identification
including

3.7

This

paragraph

for installing the software


of other changes

site-unique

adaptation

that
data

have to be installed
not included

Security, privacy, or safety precautions

d.

Procedures for determining

e.

A point of contact
installation

to be consulted

or reference

the following

version

c.

whether

shall provide

for this version

in the software

to be used,

version

relevent to the installation

the version has been installed properly


if there are problems or questions

Possible ~roblems and known error$, This paragraph

shall identify

any possible

with the

problems

or known errors with the software


version at the time of release, any steps being taken to
resolve
the problems
or errors,
and instructions
(either
directly
or by reference)
for
recognizing,
avoiding, correcting,
or otherwise
handling each one. The information
presented
shall be appropriate

to the intended

recipient

of the SVD

(for example,

a user agency may

need advice on avoiding errors, a support agency on correcting them).


4.
-.
This section shall contain any general information
that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall include an
and their meanings as used in this
alphabetical listing of all acronyms, abbreviations,
document and a list of any terms and definitions needed to understand this document.
A. ADDend ixe~,
Appendixes may be used to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). AS applicable, each
appendix shall be referenced in the main body of the document where the data would normally
have been provided. Appendixes may be bound as separate documents for ease in handling.
Appendixes shall be lettered alphabetically (A, B, etc.).

Source: https://assist.dla.mil -- Downloaded: 2016-03-31T14:47Z


Check the source to verify that this is the current version before use.