Mil HDBK 520a

Downloaded from http://www.everyspec.
com
NOT MEASUREMENT
SENSITIVE
MIL-HDBK-520A
19 December 2011
SUPERSEDING
MIL-HDBK-520 (USAF)
5 March 2010
DEPARTMENT OF DEFENSE
HANDBOOK
SYSTEM REQUIREMENTS DOCUMENT
GUIDANCE
This handbook is for guidance only.

Do not cite this document as a requirement.
AMSC N/A AREA SESS
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

Downloaded from http://www.everyspec.com
MIL-HDBK-520A
FOREWORD
1. This handbook is approved for use by all Departments and Agencies of the Department
of Defense (DoD).
2. This handbook was prepared solely for Government personnel and associated support
contract staff. Therefore, many of the links herein require .gov or .mil access using a Common
Access Card (CAC). Please report any broken links.
3. This handbook was initially prepared through the Continuous Capability Planning
Integrated Product Team (CCP IPT) under the Develop and Sustain Warfighting Systems
(D&SWS) Process, Acquisition Improvement Plan (AIP) 2.1: Requirements Maturation Core
Process. This core process is part of Secretary of the Air Force (SECAF) and Chief of Staff of
the Air Force (CSAF) directed transformation effort to define Air Force core processes within the
AF Smart Operations for the 21st Century (AFSO21) program. This document has been
updated as a DoD handbook for use by all programs.
4. Comments, suggestions, or questions on this document should be addressed to

ASC/ENRS, 2145 Monahan Way, Wright-Patterson AFB OH 45433-7017, or emailed to
Engineering.Standards@wpafb.af.mil. Since contact information can change, you may want to
verify the currency of this address information using the ASSIST Online database at
https://assist.daps.dla.mil.
ii
MIL-HDBK-520A
EXECUTIVE SUMMARY
A guidance document/handbook or template for developing a System/Subsystem Requirements

Document (SRD) never existed prior to MIL-HDBK-520. It was the Department of Defense
(DoD) best practice to use the System/Subsystem Specification (SSS) Data Item Description
(DID) and MIL-STD-961 as a reference point for establishing an SRD and subsequent system
and subsystem specifications. When published, the Joint Services Specification Guides
(JSSGs) also served as a convenient template for an SRD at the system or subsystem level.
Data Item Description (DID) DI-IPSC-81431, System/Subsystem Specification and MIL-STD-

961, Defense and Program-Unique Specifications Format and Content, coupled with several
different Systems Engineering (SE) guides referenced herein, formed the framework for this
System Requirements Document (SRD) handbook. DID DI-IPSC-81431 is still in use by the
United States Navy (USN) and if used in conjunction with this handbook should be updated for
systems/subsystems specification guidance. Since Acquisition Reform of the early 1990’s, DoD
Programs have relied upon industry best practices and contractor formatted specification
documents that continue to reflect the intent of DI-IPSC-81431 and MIL-STD-961. These two
documents were chosen as the baseline for this handbook as they were the stalwarts of the
DoD specification process. The latest DID version requires updating to be used on modern
contracts.
This SRD handbook includes a generic SRD template and format useable by any program in
any phase. It is meant to be used as a guide to translate warfighter capabilities or other
user/customer performance requirements into acquisition requirements, for example,
requirements for a system or subsystem in any program Milestone (MS) or phase. The
handbook focus is on requirements analysis as related to SRD development and is not intended
to be a complete Systems Engineering Handbook or a repository for system requirements.
Reference documents were used extensively in creating this handbook and were updated
herein to current DoD policy and processes. Please refer to these references for further
reading. One drawback to citing reference documents is that references change over time and
could be a challenge to keep current. With regulations and instructions, the latest release
should always be followed. However, advantages outweigh drawbacks and reference
documents provide detailed background for anyone desiring a more in-depth research into the
subject. This handbook will be reviewed periodically for updates and will attempt to remain
current.
A dedicated team of SE professionals across the AF assisted in drafting and editing the first
edition of this handbook and a wider DoD group of professionals was responsible for this
updated version. While it was originally prepared in an AF centric manner, the principles
documented herein are equally applicable for any DoD program and this version is no longer AF
centric. I welcome your comments and suggestions for future improvement.
//SIGNED//
JEFFERY L. PESLER
SRD Guidance Handbook Principal Author
iii
MIL-HDBK-520A
CHANGE HISTORY
Change Version Date

Completed Handbook Draft + 2nd Review Comments rd
3 Draft 20090822
3rd Review Comments + Formal Editing 4th Coordination 20091209
4th Review Comments + Formal Editing 1.0 Draft 20100128
Contract Change Proposal (CCP)- Defense Standardization 1.0 Draft 20100226
Program (DSP) Review
Final Edit and Publication 1.0 20100304
First DoD Draft 2.0 Draft 20110310
Defense Standardization Program (DSP) Review 2.0 Draft 20111017
Final Edit and Publication 2.0 20111219
iv
MIL-HDBK-520A
TABLE OF CONTENTS
PARAGRAPH PAGE
1. SCOPE ..............................................................................................................................1
1.1 Scope. ........................................................................................................................1
2. APPLICABLE DOCUMENTS .............................................................................................1
2.1 General. ......................................................................................................................1
2.2 Government documents. .............................................................................................1
2.2.1 Specifications, standards, and handbooks. ..........................................................1
2.2.2 Other Government documents, drawings, and publications. ................................1
3. DEFINITIONS. .......................................................................................................................3
4. PURPOSE .......................................................................................................................10
4.1 Introduction. ..............................................................................................................10
4.2 Functional baseline (FBL). ........................................................................................11
4.3 SRD guidance applicability. ......................................................................................10
4.4 SRD purpose. ...........................................................................................................10
4.5 Early systems engineering (SE). ...............................................................................11
5. SRD DESCRIPTION ........................................................................................................12
5.1 Requirements development. .....................................................................................12
5.2 Attributes. .................................................................................................................12
5.3 Capabilities documents. ............................................................................................12
5.4 Warfighter attributes..................................................................................................12
5.5 Contract award. ........................................................................................................13
6. APPROVAL .....................................................................................................................13
6.1 Signatures and coordination. ....................................................................................13
7. SRD PREPARATION INTRODUCTION...........................................................................13
7.1 SRD preparation.. .....................................................................................................13
7.1.1 Defining acquisition requirements. .....................................................................13
7.1.2 Core SE process. ...............................................................................................14
8. REQUIREMENTS ANALYSIS PROCESS, .......................................................................14
8.1 Introduction.. .............................................................................................................14
8.2 Process inputs. .........................................................................................................14
8.2.1 Constraints.........................................................................................................14
8.2.2 System technical requirements.. ........................................................................14
8.3 Types of technical requirements.. .............................................................................15
8.3.1 Warfighter capabilities. .......................................................................................15
8.3.2 Functional requirement. .....................................................................................15
8.3.3 Performance requirements. ................................................................................15
8.3.4 Design requirements. .........................................................................................15
8.3.5 Derived requirements. ........................................................................................15
8.3.6 Allocated requirements. .....................................................................................15
8.3.7 Acquisition requirements. ...................................................................................15
8.3.8 Specific design solution......................................................................................16
8.4 Characteristics of good requirements. .......................................................................16
8.5 Requirements analysis ..............................................................................................16
8.5.1 Requirements analysis purpose. ........................................................................17
8.5.2 Requirements analysis result. ............................................................................17
8.5.3 Design basis. .....................................................................................................17
9. ROLE OF INTEGRATED TEAMS ....................................................................................17
9.1 Early Systems Engineering (SE). ..............................................................................18
v
MIL-HDBK-520A
PARAGRAPH PAGE
9.2 Early SE effort...........................................................................................................18
9.3 Systems Engineering Working Level IPT (SE-WIPT). ...............................................18
9.3.1 Team interaction. ...............................................................................................18
9.3.2 Leadership transfer. ...........................................................................................18
9.3.3 Requirements determination/validation. .............................................................19
10. REQUIREMENTS MANAGEMENT..................................................................................19
10.1 Requirements traceability..........................................................................................19
10.2 Capturing requirements. ...........................................................................................20
10.3 Requirements management tools (RMT). .................................................................20
11. NOTES ............................................................................................................................22
11.1 Intended use. ............................................................................................................22
11.2 Subject term (key word) listing. .................................................................................22
11.3 Changes from previous issue. ...................................................................................22
TABLES
TABLE I. Sample Requirements Metadata. .......................................................................... 2121
APPENDIX SECTION
APPENDIX A ............................................................................................................................23
System Requirements Document (SRD) Generic Template Guidance ...................................... 23
APPENDIX B ............................................................................................................................33
Systems Requirements Document (SRD) Format and Generic Template ................................. 33
vi
MIL-HDBK-520A
1. SCOPE
1.1 Scope.
This handbook contains guidance for preparation of a System Requirements Document (SRD)
using established Systems Engineering (SE) processes. It contains a generic SRD template
with guidance and standard SRD format. It is meant to be used as a guide to translate
warfighter capabilities into acquisition requirements for a system or subsystem in any program
Milestone (MS) or phase. The SE processes and principles found in this guidance are equally
applicable to any DoD program/project. This handbook is for guidance only and cannot be cited
as a requirement.
2. APPLICABLE DOCUMENTS
2.1 General.
The documents listed below are not necessarily all of the documents referenced herein, but are
those needed to understand the information provided by this handbook.
2.2 Government documents.
2.2.1 Specifications, standards, and handbooks.

The following specifications, standards, and handbooks form a part of this document to the
extent specified herein.
DEPARTMENT OF DEFENSE STANDARDS

MIL-STD-961 Defense and Program Unique Specifications Format and Content
MIL-STD-881 Work Breakdown Structures for Defense Materiel Items
DEPARTMENT OF DEFENSE HANDBOOKS
MIL-HDBK-61 Configuration Management Guidance
(Copies of these documents are available online at https://assist.daps.dla.mil/quicksearch/ or

from the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D,
Philadelphia, PA 19111-5094.)
2.2.2 Other Government documents, drawings, and publications.

The following other Government documents, drawings, and publications form a part of this
document to the extent specified herein.
CHAIRMAN OF THE JOINT CHIEFS OF STAFF

CJCSI 3170.01 Joint Capabilities Integration and Development System
JCIDS Manual Manual for the Joint Capabilities Integration and Development System
(Copies of these documents are available online at

https://acc.dau.mil/communitybrowser.aspx?id=267116 or
http://www.dtic.mil/cjcs_directives/cjcs/instructions.htm.)
1
MIL-HDBK-520A
DATA ITEM DESCRIPTION (DID)

DI-IPSC-81431 System/Subsystem Specification (SSS)
(Copies of this document are available online at https://assist.daps.dla.mil/quicksearch/ or from

the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA
19111-5094.)
DEFENSE ACQUISITION UNIVERSITY (DAU)
Defense Acquisition Guidebook (DAG)
Glossary of Defense Acquisition Acronyms and Terms
Systems Engineering Fundamentals
(Copies of these documents are available from the Defense Acquisition University Press, Ft
Belvoir VA, 22060-5565 or on line at https://dag.dau.mil/Pages/Default.aspx for the DAG,
https://dap.dau.mil/glossary/Pages/Default.aspx for the Glossary and
http://www.dau.mil/pubs/pdf/SEFGuide%2001-01.pdf or
http://www.dau.mil/pubs/gdbks/sys_eng_fund.asp for Systems Engineering Fundamentals.)
NATIONAL ACADEMIES PRESS

Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and
Benefits for Future Air Force Systems Acquisition
(Copies of this document are available on line at http://www.acq.osd.mil/se/pg/spec-studies.html
or http://www.nap.edu/catalog/12065.html.)
U.S. GOVERNMENT PRINTING OFFICE

Public Law 111-23 Weapon Systems Acquisition Reform Act of 2009
(Copies of this document are available from the U.S. Government Bookstore, 710 North Capitol
St. N.W., Washington D.C. 20401 or on line at http://www.gpo.gov/fdsys/pkg/PLAW-
111publ23/content-detail.html.)
DEPARTMENT OF DEFENSE ISSUANCES

DoDD 5000.01 The Defense Acquisition System
DoDD 5230.24 Distribution Statements on Technical Documents
DoDD 5230.25 Withholding of Unclassified Technical Data from Public Disclosure
DoDD 8320.02 Data Sharing in a Net-Centric Department of Defense
DoDD 8500.01 Information Assurance (IA)
DoDI 5000.02 Operation of the Defense Acquisition System
DoDI 8500.2 Information Assurance (IA) Implementation
DoD 5200.1-R Information Security Program
DoD 5200.1-PH DoD Guide to Marking Classified Documents
2
MIL-HDBK-520A
(Copies of these documents are available online at http://www.dtic.mil/whs/directives/.)
NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

NASA/SP-2007-6105 NASA Systems Engineering Handbook
(Copies of this document are available on line at http://ntrs.nasa.gov/search.jsp or from NASA
Center for AeroSpace Information, 7115 Standard Drive, Hanover MD 21076-1320.)
3. DEFINITIONS.
The following definitions and acronyms are applicable to this handbook.
3.1 Allocated Baseline.

Documentation that designates the Configuration Items (CIs) making up a system and then
allocates the system function and performance requirements across the CIs (hence the
cated baseline It includes all functional and interface characteristics that are
allocated from those of a higher-level CI or from the system itself, derived requirements,
interface requirements with other CIs, design restraints and the verification required to
demonstrate the achievement of specified functional and interface characteristics. The
performance of each CI in the allocated baseline is described in its item performance
specification (DAU Glossary).
3.2 Architecture.
Structure of components, their relationships and the principles and guidelines governing their
design and evolution over time (JCIDS Manual).
3.3 Attribute.
A quantitative or qualitative characteristic of an element or its actions (CJCSI 3170.01).
3.4 Capabilities Based Assessment (CBA).

The CBA is the Joint Capabilities Integration and Development System (JCIDS) analysis
process. It defines the mission, identifies capabilities required, determines attributes/standards
of the capabilities, identifies gaps, assesses operational risk associated with the gaps, prioritizes
gaps, identifies and assesses potential non-materiel solutions and provides recommendations
for addressing the gaps (CJCSI 3170.01).
3.5 Capability.
Ability to achieve a desired effect under specified standards and conditions through
combinations of means and ways across doctrine, organization, training, materiel, leadership
and education, personnel, and facilities (DOTMLPF) to perform a set of tasks to execute a
specified course of action. It is defined by the warfighter and expressed in broad operational
terms in an Initial Capabilities Document (ICD) or a joint DOTMLPF change recommendation.
In the case of materiel proposals/documents, the definition will progressively evolve to
DOTMLPF performance attributes identified in the capability development document (CDD) and
the capability production document (CPD) (CJCSI 3170.01).
3.6 Capability Development Document (CDD).

A document that captures information necessary to develop a proposed program, normally
using an evolutionary acquisition strategy. The CDD outlines an affordable increment of
3
MIL-HDBK-520A
militarily useful, logistically supportable and technically mature capability. The CDD may define
multiple increments if there is sufficient definition of the performance attributes (key
performance parameters (KPPs), key system attributes (KSAs), and other attributes) to allow
approval of multiple increments (CJCSI 3170.01).
3.7 Capability need.

A capability identified through the CBA, required to being able to perform a task within specified
conditions to a required level of performance (CJCSI 3170.01).
3.8 Capability Production Document (CPD).

A document that addresses production elements specific to a single increment of an acquisition
program. The CPD defines an increment of militarily useful, logistically supportable, and
technically mature capability that is ready for a production decision. The CPD defines a single
increment of performance attributes (key performance parameters (KPPs), key system
attributes (KSAs), and other attributes) to support a MS C decision. (CJCSI 3170.01).
3.9 Derived Requirements.

These arise from constraints, consideration of issues implied but not explicitly stated in the
requirements baseline, factors introduced by the selected architecture, Information Assurance
(IA) requirements and the design. Derived requirements are defined through requirements
analysis as part of the overall Systems Engineering Process (SEP) and are part of the allocated
baseline (DAU Glossary).
3.10 Family of Systems (FoS).

A set of systems that provide similar capabilities through different approaches to achieve
similar or complementary effects. For instance, the warfighter may need the capability to
track moving targets. The FoS that provides this capability could include unmanned or
manned aerial vehicles with appropriate sensors, a space-based sensor platform or a
special operations capability. Each can provide the ability to track moving targets but with
differing characteristics of persistence, accuracy, timeliness, etc. (JCIDS Manual).
3.11 Function.
A task, action or activity performed to achieve a desired outcome (ASC Systems Engineering
Guide). Action or actions that an item is designed to perform (MIL-HDBK-61).
3.12 Functional Baseline (FBL).

Documentation describing system/segment functional characteristics and the verification
required to demonstrate the achievement of those specified functional characteristics. The
system or segment specification establishes the functional baseline (Glossary of Defense
Acquisition Acronyms and Terms).
3.13 Initial Capabilities Document (ICD).

Summarizes a CBA and justifies the requirement for a materiel or non-materiel approach or an
approach that is a combination of materiel and non-materiel to satisfy specific capability gap(s).
It identifies required capabilities and defines the capability gap(s) in terms of the functional area,
the relevant range of military operations, desired effects, time, and doctrine, organization,
4
MIL-HDBK-520A
training, materiel, leadership and education, personnel and facilities (DOTMLPF) and policy
implications and constraints. The ICD summarizes the results of DOTMLPF and policy analysis
and the DOTMLPF approaches (materiel and non-materiel) that may deliver the required
capability. The outcome of an ICD could be one or more joint DOTMLPF Change
Recommendations (DCRs) or recommendations to pursue materiel solutions (CJCSI 3170.01).
3.14 Key Performance Parameters (KPP).

Those attributes or characteristics of a system that are considered critical or essential to
development of an effective military capability and those attributes that make a significant
contribution to characteristics of future joint force as defined in the Capstone Concept for Joint
Operations. KPPs must be testable to enable feedback from test and evaluation efforts to the
requirements process. KPPs are validated by the Joint Requirement Oversight Council (JROC)
for JROC Interest documents, by the JCB for JCB Interest documents, and by the DOD
component for Joint Integration, Joint Information, or Independent documents. CDD and CPD
KPPs are included verbatim in the acquisition program baseline. (CJCSI 3170.01).
3.15 Key System Attribute (KSA).

An attribute or characteristic considered crucial to achieving a balanced solution/approach to a
system, but not critical enough to be designated a KPP. KSAs provide decision makers with an
additional level of capability performance characteristics below the KPP level and require a
sponsor four-star, Defense Agency commander or Principal Staff Assistant to change (JCIDS
Manual).
3.16 Measure of Effectiveness (MOE).

Measure designed to correspond to accomplishment of mission objectives and achievement of
desired results. MOEs may be further divided into Measures of Performance (MOPs) and
Measures of Suitability (MOSs) (Glossary of Defense Acquisition Acronyms and Terms).
3.17 Measure of Performance (MOP).

Measure of a system’s performance expressed as speed, payload, range, time-on-station,
frequency, or other distinctly quantifiable performance features. Several MOPs and/or
Measures of Suitability (MOSs) may be related to the achievement of a particular Measure of
Effectiveness (MOE) (Glossary of Defense Acquisition Acronyms and Terms).
3.18 Measure of Suitability (MOS).

Measure of an item’s ability to be supported in its intended operational environment. MOSs
typically relate to readiness or operational availability and, hence, reliability, maintainability, and
the item’s support structure. Several MOSs and/or Measures of Performance (MOP) may be
related to the achievement of a particular Measure of Effectiveness (MOE) (Glossary of Defense
Acquisition Acronyms and Terms).
3.19 Metadata.
Information describing the characteristics of data; data or information about data; or descriptive
information about an entity’s data, data activities, systems, and holdings. For example,
discovery metadata is a type of metadata that allows data assets to be found using enterprise
search capabilities (DoDD 8320.02).
5
MIL-HDBK-520A
3.20 Operational Requirements.

Top level system performance attributes or capabilities of the system or subsystem documented
in the warfighter’s capabilities documents.
3.21 Performance Requirements.

Requirements defining the extent to which a mission or function should be executed, generally
measured in terms of quantity, quality, coverage, timeliness or readiness.
3.22 Regulatory Requirements.

Requirements directed by military regulations and other governmental agencies (DoDI 5000.02).
3.23 Requirements Analysis.

Requirements Analysis encompasses definition and refinement of system, subsystem, and
lower-level functional and performance requirements and interfaces to facilitate the Architecture
Design process. Requirements Analysis needs to provide measurable and verifiable
requirements. Requirements being developed by the materiel developer balance requirements
to include performance, functional and technical constraints and both life-cycle costs and
development cycle time (DAG, https://dag.dau.mil).
3.24 Requirements Management.

Requirements Management provides traceability back to user-defined capabilities as
documented through either the Joint Capabilities Integration and Development System or other
user-defined source, and to other sources of requirements. Requirements traceability is one
function of requirements management. As the systems engineering process proceeds,
requirements are developed to increasing lower levels of the design. Requirements traceability
is conducted throughout the system life cycle and confirmed at each technical review.
Traceability between requirements documents and other related technical planning documents,
such as the Test and Evaluation Master Plan, is maintained through a relational data base,
numbering standards or other methods that show relationships. A good requirements
management system allows for traceability from the lowest level component all the way back to
the user capability document or other source document from which it was derived (DAG,
https://dag.dau.mil).
3.25 Statutory Requirements.

Requirements directed by public law (DoDI 5000.02).
3.26 Subsystem.
A grouping of items satisfying a logical group of functions within a particular system.
3.27 Synthesis.
Translation of input requirements (including performance, function, and interface) into possible
solutions (resources and techniques) satisfying those inputs. Defines a physical architecture of
people, product and process solutions for logical groupings of requirements (performance,
function and interface) and then designs those solutions.
6
MIL-HDBK-520A
3.28 System.
An integrated composite of people, products and processes that provide a capability to satisfy a
stated need or objective.
3.29 Systems Analysis and Control.

Imposition of structure and discipline into system evolution by: measuring progress based on
demonstrated performance; identifying, developing and examining alternatives; making
decisions based on cost, schedule, performance and risk to affect balanced results;
documenting evolution and rationale; and controlling resulting configurations.
3.30 Systems Engineering (SE).

Systems engineering is an interdisciplinary approach and process encompassing the entire
technical effort to evolve, verify and sustain an integrated and total life cycle balanced set of
system, people, and process solutions that satisfy customer needs. Systems engineering is the
integrating mechanism for the technical and technical management efforts related to the
concept analysis, materiel solution analysis, engineering and manufacturing development,
production and deployment, operations and support, disposal of, and user training for systems
and their life cycle processes. (DAG, https://dag.dau.mil).
3.31 System of Systems (SoS).

A set or arrangement of interdependent systems that are related or connected to provide a
given capability. The loss of any part of the system will degrade the performance or capabilities
of the whole. An example of an SoS could be interdependent information systems. While
individual systems within the SoS may be developed to satisfy the peculiar needs of a given
warfighter group (like a specific Service or agency), the information they share is so important
that the loss of a single system may deprive other systems of the data needed to achieve even
minimal capabilities (Acquisition Community Connection
https://acc.dau.mil/CommunityBrowser.aspx?id=54715).
3.32 Weapon Systems Acquisition Reform Act (WSARA).

The Weapon System Acquisition Reform Act (WSARA) of 2009, Public Law 111-23, May 22,
2009. Weapon Systems Acquisition Reform Act of 2009 One Hundred Eleventh Congress of
the United States of America AT THE FIRST SESSION Begun and held at the City of
Washington on Tuesday, the sixth day of January, two thousand and nine An Act To improve
the organization and procedures of the Department of Defense for the acquisition of major
weapon systems, and for other purposes. Be it enacted by the Senate and House of
Representatives of the United States of America in Congress assembled
(http://www.gpo.gov/fdsys/pkg/PLAW-111publ23/pdf/PLAW-111publ23.pdf)
3.33 Acronyms.
ABL Allocated Baseline
AF Air Force
AFROC Air Force Requirements Oversight Council
AFRL Air Force Research Laboratory
AFSO21 AF Smart Operations for the 21st Century
7
MIL-HDBK-520A
AIP Acquisition Improvement Plan

AoA Analysis of Alternatives
ASC Aeronautical Systems Center
C2 Command and Control
CAC Common Access Card
CBA Capabilities-Based Assessment
CBP Capabilities Based Planning
CCP Continuous Capability Planning and Contract Change Proposal
CCTD Concept Characterization and Technical Designation
CDD Capability Development Document
CI Configuration Item
CJCSI Chairman of the Joint Chiefs of Staff Instruction
CoE Concept of Employment
CONOPS Concept of Operations
CPD Capability Production Document
CRRA Capabilities Review and Risk Assessment
CSAF Chief of Staff of the Air Force
CWBS Contract Work Breakdown Structure
DAG Defense Acquisition Guidebook
DAU Defense Acquisition University
DCR DOTMLPF Change Recommendation
DID Data Item Description
DoD Department of Defense
DoDD Department of Defense Directive
DoDI Department of Defense Instruction
DOTMLPF Doctrine, Organization, Training, Materiel, Leadership and Education,
Personnel, and Facilities
DSP Defense Standardization Program
D&SWS Develop and Sustain Warfighting Systems
ECP Engineering Change Proposal
ESOH Environment, Safety, and Occupational Health
FBL Functional Baseline
FoS Family of Systems
IA Information Assurance
ICD Initial Capabilities Document
8
MIL-HDBK-520A
INCOSE International Council on Systems Engineering

IPSC Information Processing Standards for Computers
IPT Integrated Product Team
IRS Interface Requirements Specification
ISP Information Support Plan
JACG Joint Aeronautical Commander’s Group
JCB Joint Capabilities Board
JCD Joint Capabilities Document (Obsolete)
JCIDS Joint Capabilities Integration and Development System
JROC Joint Requirements Oversight Council
JSSG Joint Services Specification Guide
KPP Key Performance Parameter
KSA Key System Attribute
LRU Line Replaceable Unit
MAJCOM Major Command
MIL-HDBK Military Handbook
MOE Measure of Effectiveness
MOP Measure of Performance
MOS Measure of Suitability
MS Milestone
NASA/SP National Aeronautics and Space Administration/Special Publication
NRC National Research Council
OFP Operational Flight Program
POC Point of Contact
PWBS Program Work Breakdown Structure
RFP Request for Proposal
RMT Requirements Management Tools
SE Systems Engineering
SECAF Secretary of the Air Force
SE-WIPT Systems Engineering-Working Level Integrated Product Team
SME Subject Matter Expert
SOO Statement of Objectives
SoS System of Systems
9
MIL-HDBK-520A
SOW Statement of Work

SRD System Requirements Document
SSS System/Subsystem Specification
T&E Test and Evaluation
TEMP Test and Evaluation Master Plan
TRD Technical Requirements Document
USAF United States Air Force
USN United States Navy
WBS Work Breakdown Structure
WLPT Working-Level Integrated Product Team
WSARA Weapon Systems Acquisition Reform Act
4. PURPOSE
4.1 Introduction.
This SRD handbook provides a bridge between warfighter and acquisition communities. It was
developed to standardize and formalize the requirements analysis process used to translate
warfighter capabilities into acquisition requirements using Data Item Description (DID) DI-IPSC-
81431 and MIL-STD-961 as the framework. It is intended to guide a program Systems
Engineering Team in preparation of an SRD for any DoD program during Request for Proposal
(RFP) development, pre-contract award, Engineering Change Proposal (ECP) development
after contract award, or any other application requiring translation of warfighter capabilities into
acquisition requirements. It may be used by any DoD component or acquisition organization.
Guidance is meant to be generic enough to be used in support of all program MSs and phases,
and has been written to encompass system as well as subsystem development, modification, or
update. A detailed template is provided to guide SRD development. This handbook offers
maximum flexibility in creating an SRD and accommodates any given set of warfighter
capabilities. Requirements analysis processes are applicable to any MSs or phases, and
support early acquisition as well as mature programs undergoing modification or update.
Development of an SRD is a critical Systems Engineering skill necessary to ensure warfighter
capabilities are understood by the offeror/contractor and the resulting system/subsystem meets
the warfighter’s mission need.
4.2 SRD guidance applicability.

The SRD guidance in this handbook applies to any DoD program and also applies to
applications previously using a Technical Requirements Document (TRD). Previously, there
was no policy, standard or handbook to guide preparation of an SRD or a TRD. Both
documents served the purpose of translating warfighter capabilities into acquisition
requirements. This handbook provides guidance for development of a standardized SRD for all
programs having to translate warfighter capabilities into acquisition requirements.
4.3 SRD purpose.

Used during source selection, an SRD is documents the warfighter’s capabilities in contractual
language. An SRD is prepared early during RFP development and is normally based upon a
10
MIL-HDBK-520A
capabilities document approved by a Service/Agency requirements authority and the Joint

Requirements Oversight Council (JROC) (CJCSI 3170.01). It translates required warfighter
capabilities into system/subsystem acquisition requirements addressing such concerns as
performance; supportability; physical and functional integration; human system integration;
security, test and evaluation; quality assurance; hardware; software; etc. The SRD will also be
used on mature programs to add or modify current capabilities.
4.4 Functional baseline (FBL).

An SRD establishes the basis for an acquisition program FBL (see MIL-HDBK-61). It
documents acquisition requirements translated from a warfighter capabilities document (CJCSI
3170.01) into an acquisition format used as a baseline for a system or subsystem specification
typically prepared by an offeror/contractor. It communicates government system or subsystem
requirements in a concise, measurable and understandable fashion. At contract award the SRD
is replaced by a documented FBL in a contractor prepared system or subsystem specification.
The generic SRD template in this handbook is written in a very broad fashion without
documenting specific requirements. It was meant to be used to facilitate documentation of
acquisition requirements for a range of systems or subsystems that can be passed to a
contractor as part of an RFP or ECP. The generic SRD template accommodates any MS (for
example, pre MS A, MS A, MS B, MS C) or program phase. As every program is unique with its
own set of capabilities and requirements, so will each respective SRD be unique. There is no
one single template or format suitable for all systems and subsystems hence a generic template
was developed.
4.5 Early systems engineering (SE).

Throughout the acquisition process, SE provides the technical foundation for an acquisition
program. Particularly in early stages of an acquisition, SE analysis and products are vital to a
program office’s ability to assess feasibility of addressing warfighter capabilities, technology
needs of potential solutions, and robust estimates of cost, schedule, and risk, all leading to a
predictable, disciplined acquisition. With increased emphasis in the Weapons Systems
Acquisition Reform Act (WSARA) and the new DoDI 5000.02 on the Materiel Solution Analysis
Phase (Enclosure 2, paragraph 4 of DoDI 5000.2) and the Technology Development Phase
(Enclosure 2, paragraph 5 of DoDI 5000.2) there is a need for increased emphasis on SE during
these activities. “The ability of U.S. military forces to field new weapon systems quickly and to
contain their cost growth has declined significantly over the past few decades. There are many
causes including increased complexity, funding instability, bureaucracy, and more diverse user
demands, but a view that is gaining more acceptance is that better SE could help shorten
development time.” To investigate this assertion in more detail, the US Air Force asked the
National Research Council (NRC) to examine the role that SE can play during the acquisition
life cycle to address root causes of program failure especially during pre-milestone A and early
program phases. This study assessed the relationship between SE and program outcome;
examined the SE workforce and analyzed SE functions and guidelines. It includes a definition
of the minimum set of SE processes that need to be accounted for during project development.
The study report, Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective
Review and Benefits for Future Air Force Acquisition, National Research Council, 2008, The
National Academies Press, can be accessed at The National Academies Press website 1.
1. Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for
Future Air Force Acquisition, National Research Council, 2008, The National Academies Press,
http://www.nap.edu/catalog.php?record_id=12065
11
MIL-HDBK-520A
5. SRD DESCRIPTION
5.1 Requirements development.

A program office engineering team defines system or subsystem level functional and
performance requirements derived from warfighter capabilities documents, Concept of
Operations (CONOPS), Concept of Employment (CoE), Analysis of Alternatives (AoA), system-
level performance metrics, mission threads/use cases, and usage environment, which are
captured in a program’s SRD. These requirements known as acquisition requirements or
system/subsystem requirements because taken as an aggregate, they are written in
acquisition/contractual terms and they define the entire system/subsystem performance
characteristics. Further complicating the terminology used, these aggregate requirements are
also now known as attributes.
5.2 Attributes.
The program office engineering team defines acquisition requirements in terms of system level
attributes and associated constraints defined by the warfighter. Attributes are further broken out
and prioritized as Key Performance Parameters (KPPs) and Key System Attributes (KSAs).
Acquisition requirements are written using performance language. The SRD avoids describing
a specific solution unless there is a compelling warfighter capabilities need. It should not
preclude leasing, commercial, or non-developmental solutions. An SRD should not contain any
programmatic or Statement of Work (SOW) or Statement of Objectives (SOO) language that
belong in other sections of an RFP or ECP. During the subsequent source selection, these
performance requirements, as documented in the offeror’s draft system or subsystem
specification, are evaluated for cost, performance, schedule, and risk of various candidate
solutions resulting in a best value solution. Note: The Defense Acquisition Guidebook (DAG)
uses the term “system performance specification” interchangeably with “system specification.”
System specification is used exclusively throughout this handbook.
5.3 Capabilities documents.

There are three Joint Capabilities Integration and Development System (JCIDS) capability
documents used for materiel development: Initial Capabilities Document (ICD), Capability
Development Document (CDD) and Capability Production Document (CPD). Details on use,
content and format of JCIDS documents are located in CJCSI 3170.01 and the JCIDS Manual.
The Joint Capabilities Document (JCD) was rescinded by CJCSI 3170.01G but may still exist on
some programs. Additionally, there are Service specific alternative means for documenting
capabilities that are used in some situations, for example, system modification.
5.4 Warfighter attributes.

JCIDS capability documents, (for example, ICD, CDD, CPD) identify warfighter attributes in the
form of Key Performance Parameters (KPPs), Key System Attributes (KSAs), and other
Attributes. The JCIDS capability document lists each capability requirement, associated
threshold, objective and rationale/analytical reference. Section 3 of the SRD documents these
system capability attributes and associated thresholds and objectives. Section 4 of the SRD
contains verification provisions for each requirement (attribute) implementing a verification
methodology matrix documenting how each requirement is to be verified. Section 5 contains a
requirements traceability matrix that traces SRD requirements up to warfighter capability
documents and down to the lowest level hardware/software component that implements the
requirement. The requirements traceability matrix will be completed by the offeror/contractor in
the resulting SSS. Section 6 contains definitions and acronyms. Each SRD, KPP and KSA
12
MIL-HDBK-520A
should have an associated threshold and objective. Other attributes should include thresholds
and objectives as applicable. SRDs will display applicable thresholds and objectives in each
paragraph. Individual requirements should be uniquely identified and traceable and have a
unique identifier and/or paragraph number. Automated tools used for traceability should be
capable of supporting required metadata (see 10.1 through 10.3), including rationale and
analytical references for each requirement. Metadata should be included for each requirement
in an SRD, SSS and lower tiered specifications. If an automated tool is not used, rationale and
analytical reference for each requirement should be manually documented as part of the
requirements traceability matrix.
5.5 Contract award.

At contract award, the program’s FBL is documented in a contractually binding approved system
or subsystem specification which now defines requirements an acquisition program intends to
achieve. When an SRD is replaced by a performance specification the thresholds and
objectives contained in the SRD must be replaced in the specification by the actual performance
values the contractor is going to deliver. These performance values may be expressed as min
or max values, as a range of values, etc. However they are expressed, they must be in terms
that can be verified by analysis, demonstration, examination, or test. For a mature program, an
SRD provides the basis of FBL modifications documented in an approved system or subsystem
specification. The system or subsystem specification forms a basis for Test and Evaluation
(T&E) of the resultant system or subsystem. Refer to MIL-HDBK-61 for a detailed description of
an FBL and allocated baseline (ABL). The SRD is typically written at Work Breakdown
Structure (WBS) Level I per MIL-HDBK-881 whether prepared for a system or subsystem. The
SRD is not a design specification; it contains only top level performance requirements for a
system or subsystem. While written at WBS Level I, a system-level SRD includes lower WBS
elements that have system level requirements, for example, allocation of system/subsystem
reliability requirements.
6. APPROVAL
6.1 Signatures and coordination.

Program Manager and Program Chief Engineer sign the SRD certifying the performance
requirements contained within. It is recommended that the MAJCOM coordinate on the SRD.
7. SRD PREPARATION INTRODUCTION
7.1 SRD preparation.

Preparation of an SRD requires a thorough understanding of the requirements analysis process.
Requirements analysis is an iterative SE process used to understand warfighter capabilities and
translate those capabilities into acquisition requirements. With this understanding, and the
generic SRD template, an acquisition program office engineering team will be able to create an
SRD that is easily translatable into a system or subsystem specification by an offeror or
contractor.
7.1.1 Defining acquisition requirements.

An acquisition program office engineering team employs requirements analysis iteratively
throughout an SRD development effort to define acquisition requirements for the weapon
system to achieve a complete, balanced system design. The FBL, as documented in a SSS,
13
MIL-HDBK-520A
captures the performance description in terms of performance requirements and verification

methods for each element of a system or subsystem.
7.1.2 Core SE process.

Requirements analysis is a core SE process that begins with definition of a warfighter’s
capabilities. The acquisition community should be involved during development of the
warfighter’s capabilities documents and the warfighter should be a participant on the SRD
development team. This collaboration ensures complete understanding of the warfighters
capabilities and capabilities/requirements will be developed using characteristics of good
requirements listed in 8.4.
8. REQUIREMENTS ANALYSIS PROCESS
8.1 Introduction.
This section is derived from the requirements analysis process described in the DAG and
Chapter 4 of the DAU Systems Engineering Fundamentals. Requirements Analysis
encompasses the definition and refinement of system, subsystem, and lower-level functional
and performance requirements and interfaces to facilitate the Architecture Design process.
Requirements Analysis needs to provide measurable and verifiable requirements. Requirements
should avoid specifying technological implementations. The requirements being developed by
the materiel developer should balance requirements to include performance, functional and
technical constraints, and both life-cycle costs and development cycle time.
8.2 Process inputs.

Typical inputs to the SE requirements analysis process (Chapter 4, DAU Systems Engineering
Fundamentals) include but are not limited to: warfighter needs, objectives and operational
requirements in the form of capabilities, missions, Measures of Effectiveness/Measures of
Suitability/Measures of Performance (MOE/MOS/MOP), environments, KPPs, KSAs, other
attributes, technology base, output requirements from prior application of SE processes,
program decision requirements, suitability requirements and project constraints. Warfighter
capabilities relate directly to desired performance characteristics of the system. They are stated
in terms of life-cycle warfighter capabilities needs and objectives for the system/subsystem and
relate to how well the system/subsystem will work in its intended environment over its service
life (Chapter 4, DAU Systems Engineering Fundamentals).
Input requirements should be comprehensive and defined for both system products and system
processes such as development, manufacturing, verification, deployment, operations, support,
training and disposal (eight primary functions).
8.2.1 Constraints.
Constraints are conditions that exist because of limitations imposed by cost, schedule, external
interfaces, project support, need for standardization/commonality, technology, or life cycle
support systems. Constraints limit development teams’ design opportunities and should be
used selectively.
8.2.2 System technical requirements.

System technical requirements are a primary focus in the SRD process because the primary
objective is to transform the warfighter’s capabilities into acquisition requirements used to
contract for the system design and development. System and subsystem design and
14
MIL-HDBK-520A
development are based upon these system technical requirements within a definitive set of
constraints and policy. All requirements should be verified to ensure they meet both
performance and constraints.
8.3 Types of technical requirements.

Technical requirements define system attributes and are categorized in several ways. The
following are common categories of requirements that relate to technical management. A
warfighter’s capabilities can be in the form of functional, performance, operational or design
requirements. These requirements are analyzed using requirements analysis and are further
refined by the acquisition team into acquisition requirements documented in the SRD (Chapter
4, DAU Systems Engineering Fundamentals).
8.3.1 Warfighter capabilities.

Warfighter capabilities are capability statements and assumptions that define system or
subsystem expectations and needs in terms of needed performance, mission objectives,
environment, constraints, MOEs, MOSs and MOPs (Chapter 14, DAU Systems Engineering
Fundamentals). Capabilities are prioritized as KPPs, KSAs and Attributes.
8.3.2 Functional requirement.

A functional requirement is a necessary task, action or activity required to be accomplished.
Functional (what has to be done) requirements identified in requirements analysis will be used
as the top level functions for requirements analysis at a lower WBS level.
8.3.3 Performance requirements.

Extent to which a mission or function should be executed; generally measured in terms of
quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance
(how well it has to be done) requirements will be interactively developed across all identified
functions based on system life cycle factors; and characterized in terms of degree of certainty in
their estimate, degree of criticality to system success and relationship to other requirements.
8.3.4 Design requirements.

“Build to,” “code to” and “buy to” requirements for products, and “how to execute” requirements
for processes, expressed in technical data packages and technical manuals, warfighter’s
capabilities documents or the SRD. Design requirements should be used judiciously at the
system/subsystem level to avoid placing undue constraints on the design team.
8.3.5 Derived requirements.

Implied or transformed requirements broken out from higher-level requirements, for example, a
requirement for long range or high speed may result in a derived design requirement for low
weight and/or drag.
8.3.6 Allocated requirements.

Allocated requirements are assigned to a specific system or subsystem element, regardless of
level of indenture, without being decomposed into their lower level components.
8.3.7 Acquisition requirements.

System requirements are derived from the warfighter’s capabilities and written in performance
terms that further define system or subsystem attributes using the requirements analysis
process. Acquisition requirements, prioritized by KPPs, KSAs and attributes, may use design,
15
MIL-HDBK-520A
derived and allocated requirements to further define required system attributes. Acquisition
requirements are documented in the SRD and facilitate communication of the warfighter’s
capabilities to a contractor or offeror in contractual terms, i.e., each requirement is in its own
paragraph and contains a “shall” statement. Once the contractor or offeror further refine
acquisition requirements, they become contractually documented in a system or subsystem
specification.
8.3.8 Specific design solution.

In special circumstances where there is need for commonality across a System of Systems
(SoS) or Family of Systems (FoS) a specific design solution may be necessary. Justification of
a specific solution should be provided by the warfighter community and documented in the
approved acquisition strategy.
8.4 Characteristics of good requirements.

Good requirements have certain common characteristics that should be strictly adhered to
(Chapter 4, DAU Systems Engineering Fundamentals). Characteristics of good requirements
include the following:
a. A requirement is achievable. It specifically reflects thresholds and/or objectives for

which a solution is technically realistic at costs considered affordable.
b. A requirement is verifiable. It is not to be defined by ambiguous words, for example,

excessive, sufficient, resistant, minimal, etc. Expected performance and functional
utility is expressed in a manner that allows verification to be objective, preferably
quantitatively measureable.
c. A requirement is unambiguous. It has only one possible meaning so it is uniquely

testable and verifiable.
d. A requirement is complete. It contains all information needed to interpret and verify the
requirement including environmental and/or operational conditions relevant to the
requirement.
e. A requirement is written in performance terms. It is expressed in terms of need, not

solution, i.e., it addresses “why” and “what” of a need, not how to do it.
f. A requirement is consistent with other requirements. Conflicts are to be resolved up

front prior to release of an RFP or ECP.
g. A requirement is appropriate for the level of system hierarchy. It is not too detailed that
it constrains solutions for the current level of design, for example, detailed requirements
relating to components would not normally be in a system-level specification.
8.5 Requirements analysis

Requirements analysis (Chapter 4, Systems Engineering Fundamentals) begins in support of
the warfighter’s capabilities development. Requirements analysis involves defining warfighter
capabilities needs and objectives in the context of planned warfighter use, environments,
constraints, and identified system characteristics which are then used to develop acquisition
requirements documented in an SRD. Any prior analyses are reviewed and updated, refining
16
MIL-HDBK-520A
mission and environment definitions to support system definition (for example, other system
items, performance requirements for identified functions) and verify that people, product, and
process solutions (from synthesis) can satisfy the warfighter capabilities needs. Requirements
analysis is conducted iteratively with requirements analysis to optimize performance
requirements for identified functions, and to verify that synthesized solutions can satisfy
warfighter capabilities needs.
8.5.1 Requirements analysis purpose.

The purpose of requirements analysis is to:
a. Develop warfighter capabilities and objectives;
b. Define initial performance capabilities and objectives and refine them into acquisition
requirements;
c. Identify and define constraints that limit solutions; and
d. Define functional and performance requirements based on warfighter provided

MOEs/MOSs/MOPs.
8.5.2 Requirements analysis result.

In general, requirements analysis should result in a clear understanding of:
a. Functions: what the system has to do;
b. Performance: how well the functions and resultant system or subsystem have to
perform;
c. Interfaces: environment in which the system or subsystem will perform; and
d. Other requirements and constraints.
8.5.3 Design basis.

Understanding that comes from requirements analysis establishes a basis for functional and
physical designs to follow. Good requirements analysis is fundamental to successful design
definition. Requirements analysis is a highly iterative process and is used by the warfighter to
create capabilities documents, by an acquisition program office to define acquisition
requirements as documented in an SRD, and by developing organization (for example, offeror,
contractor) that produces system/subsystem requirements that form an FBL consisting of all
necessary derived and allocated requirements used to design and develop a
system/subsystem.
9. ROLE OF INTEGRATED TEAMS

Warfighters typically have operational expertise with particular weapon systems but not
acquisition experience, whereas acquisition program office staff members are not necessarily
well versed in operational aspects. Typically, a warfighter’s capabilities need is neither clearly
nor completely expressed in a way directly usable by developers. Teamwork between
warfighter and acquisition communities is necessary to understand the problem, analyze
capability needs, and prepare acquisition requirements. Warfighters often find it easier to
describe a system that attempts to solve a problem rather than to describe the problem itself.
17
MIL-HDBK-520A
Although these “solutions” may be workable to some extent, an optimum solution is obtained
through a proper technical development effort that balances warfighter mission objectives,
functions, MOEs/MOSs/MOPs, and constraints. An integrated approach (Chapter 4, DAU
Systems Engineering Fundamentals) to capability need and acquisition requirements
development will balance the analysis of requirements by providing understanding and
accommodation between the warfighter and acquisition communities.
9.1 Early Systems Engineering (SE).

Throughout the acquisition process, systems engineering provides the technical foundation for
the acquisition program. Particularly in the early stages of an acquisition, systems engineering
analysis and products are vital to the early program office's ability to assess appropriately the
feasibility of addressing user needs, technology needs of potential solutions, and robust
estimates of cost schedule and risk, all leading to predictable, disciplined acquisition. With the
increased emphasis in the new DoD Instruction 5000.02 on Materiel Solution Analysis and
Technology Development, there is the need for increased emphasis on systems engineering
during these phases. A white paper discussing these issues can be accessed at the AT&L (SE)
web site (DAG, Chapter 4).
9.2 Early SE effort.

Systems Engineering (SE) conducted during the early, pre-MS A, stages of concept
development is referred to as early SE, whether for a new program start or for
modifications/upgrades to a legacy system. Capabilities Based Assessment (CBA)/JCIDS
scope and trade-space characterization of early SE efforts typically will occur concurrently. The
using or sponsoring major command (MAJCOM) owns the CBA/JCIDS process, and leads team
efforts supported by acquiring commands (or Laboratories) to identify any capability shortfalls.
(JCIDS Manual, CJCSI3170.01).
9.3 Systems Engineering Working Level IPT (SE-WIPT).

Systems engineering is typically implemented through multidisciplinary teams of subject matter
experts (SMEs) (often formally chartered as an Integrated Product Team (IPT)) and through an
SE-WIPT. SE-WIPTs generally start up during early SE efforts, and continue past MDD and
through instantiation of a program office (Defense Acquisition Guidebook). The SE-WIPT
translates warfighter-defined capabilities into acquisition requirements consistent with cost,
schedule, and performance constraints (see DoDD 5000.01, and Chapter 11, Defense
Acquisition Guidebook discussions of Knowledge-Based Acquisition).
9.3.1 Team interaction.

There should be active participation by the acquisition community early in development of any
warfighter, or other user, capabilities requiring a materiel solution. The acquisition community
should involve active participation of the warfighter, or other user, community in requirements
analysis that result in an SRD. It is expected that all other required functional organizations will
participate in the development of the warfighter, or other user, capabilities and SRD. The
following paragraphs describe roles played by warfighter and acquisition communities in early
SE processes. An SRD will be prepared any time warfighter capabilities are translated into
acquisition requirements in order to facilitate a contractual relationship with a development
organization.
9.3.2 Leadership transfer.

During pre-program initiation activities, the users (MAJCOMs) are responsible for CBA/JCIDS
efforts, requirements maturation, MDD and AoA execution, while early SE efforts for potential
18
MIL-HDBK-520A
materiel solutions are conducted by the acquisition community. A co-relationship should exist
between the using command, the acquiring command and Service laboratory organizations
providing support, as formulated in service instructions/charters. At MDD, the MAJCOM is
responsible for seeking MDA approval and authorization to enter into the acquisition life-cycle.
If the MDA directs an AoA be prepared, the effort is led by the MAJCOM. A co-relationship
should exist between the using command, the acquiring command and Service laboratory
organizations providing support as formulated in service instructions/charters (JCIDS Manual,
CJCSI3170.01).
9.3.3 Requirements determination/validation.

Requirements determination/validation is a disciplined process starting with warfighter
capabilities needs and shortfalls coming out of the JCIDS and Capabilities Review and Risk
Assessment (CRRA) process. It involves all operational, command and supporting
stakeholders; and results in materiel solutions being identified, designed and delivered to meet
stated capability needs and shortfalls with speed and credibility.
10. REQUIREMENTS MANAGEMENT

Requirements management (Defense Acquisition Guidebook) is an important support activity to
the warfighter capabilities, the SRD and subsequent system/subsystem development: providing
configuration control, documentation of decisions, and traceability of all requirements to ensure
the pedigree of each requirement. Requirements management provides traceability back to
warfighter-defined capabilities as documented through either a JCIDS capabilities document or
other warfighter-defined source, and to other sources of requirements.
10.1 Requirements traceability

As the SE process proceeds, requirements are developed to increasing lower levels of design.
Requirements traceability is conducted throughout the system life cycle and confirmed at each
technical review. Traceability between requirements documents and other related technical
planning documents, such as the Test and Evaluation Master Plan (TEMP), should be
maintained through a relational data base, numbering standards, or other methods that show
relationships and associated metadata, for example, who, what, when, why (DoDD 8320.02). A
good requirements management system should allow for traceability from the lowest level
component all the way back to the warfighter capability document or other source document
from which it was derived. Traceability should be maintained from the SRD to applicable higher
level documentation and provides baseline traceability for the resultant system or subsystem
specification. After contract award, the SRD is replaced by a system or subsystem specification
that is traceable to applicable higher level documentation and required test & verification
methodologies and lower level specifications. The program manager should institute
requirements management to do the following:
a. Maintain traceability of all requirements and associated test and verification

methodologies from capabilities needs through design and test, down to the lowest
system/subsystem component throughout the entire life cycle,
b. Document derived requirements and approved changes to requirements, and
c. Record all metadata including rationale for derived requirements and changes.
19
MIL-HDBK-520A
10.2 Capturing requirements.
At the time requirements are written, it is important to capture requirements statements along
with metadata associated with each requirement (DoDD 8320.02). Metadata is supporting
information necessary to help clarify and link requirements, for example, date created, date
changed, point of contact (POC), approval authority, etc. Method of verification should also be
thought through and captured for each requirement when developed. Verification method
includes test, inspection, analysis, and demonstration. New or derived requirements uncovered
during determination of the verification method should be documented. An example is requiring
an additional test port to give visibility to an internal signal during integration and test. If a
requirement cannot be verified, then either it should not be a requirement or the requirement
statement needs to be rewritten. For example, the requirement to “minimize noise” is vague
and cannot be verified. If the requirement is restated as “the noise level of the component X
shall remain under Y decibels” then it is clearly verifiable. Examples of the types of metadata
are provided in TABLE I.
10.3 Requirements management tools (RMT).

With ever increasing system complexity there is an increased need for RMTs with ever
increasing capabilities. Modern RMTs should ensure requirements traceability and document
rationale and heritage of each requirement using metadata. Underlying analysis supporting
trade study results and subsequent rationale for any requirement should be retained in the
RMT. The analysis should include all relevant conditions and data that would enable analysis
re-creation if necessary. Metadata is crucial to convey and track the lineage of requirements
passed to offerors/contractors. The International Council on Systems Engineering (INCOSE)
has reviewed many of the RMTs available and has compiled the results on their RMT survey
webpage, http://www.incose.org/ProductsPubs/products/rmsurvey.aspx.
20
MIL-HDBK-520A
TABLE I. Sample Requirements Metadata. 1/
1/ NASA/SP-2007-610
21
MIL-HDBK-520A
11. NOTES
11.1 Intended use.

This handbook is guidance for the preparation of System/Subsystems Requirements
Documents using established Systems Engineering processes. It is meant to be used as a
guide to translate warfighter Capability Based Requirements into acquisition requirements for a
system or subsystem in any program Milestone or phase.
11.2 Subject term (key word) listing.

Acquisition requirements
Capability requirements
Generic
Performance requirements
Requirements analysis
Systems engineering
Template
11.3 Changes from previous issue.

Marginal notations are not used in this revision to identify changes with respect to the previous
issue due to the extent of the changes.
22
MIL-HDBK-520A
APPENDIX A
System Requirements Document (SRD) Generic Template Guidance
A.1 SCOPE
This section is divided into the following subparagraphs:
A.1.1 System or subsystem identification.

This paragraph contains a full identification of the system or subsystem and associated software
to which this document applies, including as applicable, identification number(s), title(s),
abbreviation(s), and release number(s) where known.
A.1.2 System or subsystem overview.

This paragraph briefly states the purpose of the system or subsystem and associated software
to which this document applies. It describes the general nature of the system or subsystem and
software; summarizes the history of system development, operation, and maintenance;
identifies project sponsor, acquirer, warfighter, developer, and support agencies; identifies the
current and planned operating sites; and lists other relevant documents.
A.1.3 Document overview.

This paragraph summarizes purpose and contents of this document and describes any security
or privacy considerations associated with its use.
A.2 APPLICABLE DOCUMENTS

This section lists number and title of all documents referenced herein. This section also
identifies the source for documents.
A.2.1 General.
Provide overview of documentation section. This statement should be placed in all SRD
documents and resulting specifications: “The documents listed in this section are specified in
sections 3, 4, or 5 of this SRD (or resulting specification). This section does not include
documents cited in other sections of this SRD (or resulting specification) or recommended for
additional information or as examples. While every effort has been made to ensure the
completeness of this list, document users are cautioned that they must meet all specified
requirements of documents cited in sections 3, 4, or 5 of this SRD (or resulting specification),
whether or not they are listed.”
A.2.2 Government documents.

List applicable Government documents.
A.2.2.1 Specifications, standards, and handbooks.

List Government specifications, standards, and handbooks. This statement should be placed in
all SRD documents and resulting specifications: “The following specifications, standards, and
handbooks form a part of this document to the extent specified herein. Unless otherwise
specified, the issues of these documents are those cited in the solicitation or contract.”
23
MIL-HDBK-520A
APPENDIX A
INTERNATIONAL STANDARDIZATION AGREEMENTS
FEDERAL SPECIFICATIONS
FEDERAL STANDARDS
COMMERCIAL ITEM DESCRIPTIONS
DEPARTMENT OF DEFENSE SPECIFICATIONS
DEPARTMENT OF DEFENSE STANDARDS
DEPARTMENT OF DEFENSE HANDBOOKS
(Copies of these documents are available online at https://assist.daps.dla.mil/quicksearch/ or

from the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D,
Philadelphia, PA 19111-5094.)
A.2.2.2 Other Government documents, drawings, and publications.

List other Government documents, drawings, and publications. This statement should be
placed in all SRD documents and resulting specifications: “The following other Government
documents, drawings, and publications form a part of this document to the extent specified
herein. Unless otherwise specified, the issues of these documents are those cited in the
solicitation or contract.”
(A parenthetical source statement should follow each individual document or each group of
related documents providing the name and address of the source. If possible, an Internet
source for viewing or obtaining the documents should be provided.)
A.2.3 Non-Government publications.

List non-Government publications. This statement should be placed in all SRD documents and
resulting specifications: “The following documents form a part of this document to the extent
specified herein. Unless otherwise specified, the issues of these documents are those cited in
the solicitation or contract.”
(A parenthetical source statement should follow each respective issuing non-Government

standards organization listing of documents, providing the name and address of the source. If
possible, an Internet source for viewing or obtaining the documents should be provided.)
A.2.4 Order of precedence.

This statement should be placed in all SRD documents and resulting specifications: “Unless
otherwise noted herein or in the contract, in the event of a conflict between the text of this
document and the references cited herein (except for related specification sheets), the text of
this document takes precedence. Nothing in this document, however, supersedes applicable
laws and regulations unless a specific exemption has been obtained.” [The parenthetical
phrase “(except for related specification sheets)” is omitted from the paragraph for specifications
that do not have related specification sheets.]
24
MIL-HDBK-520A
APPENDIX A
A.3 SYSTEM OR SUBSYSTEM REQUIREMENTS

This section identifies basic system or subsystem requirements needed by the warfighter. This
section is divided into the following paragraphs to specify system or subsystem requirements,
for example, those characteristics of the system or subsystem that are conditions for its
acceptance. Each requirement should be assigned a project-unique identifier (to support testing
and traceability), and should be stated in such a way that an objective verification can be
defined for it. Project unique identifiers should use the Program Work Breakdown Structure
(PWBS) pre-contract award and the Contract Work Breakdown Structure (CWBS) post-contract
award. Each requirement should be annotated with associated verification method(s) (see A.4)
and, for subsystems, traceability to system requirements (see A.5.2), if not provided in those
sections. The degree of detail to be provided is guided by the following rule: Include those
characteristics of the system or subsystem that are conditions for system or subsystem
acceptance; defer to design descriptions those characteristics an acquirer is willing to leave up
to the developer. If there are no requirements in a given paragraph, the paragraph should so
state. If a given requirement fits into more than one paragraph, it may be stated once and
referenced from the other paragraphs.
Each SRD, KPP and KSA should have an associated threshold and objective. Attributes should
include thresholds and objectives as applicable.
The symbols used are:

T Threshold - Minimum requirement level.
O Objective - Desired requirement level.
T=O Threshold and Objective are the same requirement level. No effort will be expended
to exceed the Threshold requirement.
Key Performance Parameters (KPPs) and Key System Attributes (KSAs) are indentified in the
body of section 3 of the SRD or resulting specification and provided in a tabular format ranked in
order of importance in Appendix A.
A.3.1 Required states and modes.

If a system or subsystem is required to operate in more than one state or mode having
requirements distinct from other states or modes, this paragraph identifies and defines each
state and mode. Examples of states and modes include: idle, ready, active, training, degraded,
emergency, backup, wartime, peacetime. The distinction between states and modes is
arbitrary. A system or subsystem 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 should so state, without the need to create artificial distinctions. If
states and/or modes are required, each requirement or group of requirements in the SRD or
resulting specification should 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.
A.3.2 System or subsystem functional requirements.

This paragraph is divided into subparagraphs to itemize requirements associated with each
system or subsystem function. A "function" is defined as a group of related requirements, for
example, avionics subsystem requirements.
25
MIL-HDBK-520A
APPENDIX A
A.3.2.X System or subsystem function.

This paragraph (beginning with 3.2.2 in the SRD or resulting specification) itemizes
requirements associated with each system or subsystem function. If the function can be more
clearly specified by dividing it into constituent functions, for example, avionics can be broken
down into mission/operational definition, characteristics, design and construction, characteristics
of subordinate elements, etc., the constituent functions should be specified in subparagraphs.
A.3.3 System external interface requirements.

This paragraph is divided into subparagraphs to specify requirements for the system's or
subsystem’s external interfaces. This paragraph may reference one or more Interface
Requirements Specifications (IRSs) or other documents containing these requirements.
A.3.3.1 Interface identification and diagrams.

This paragraph identifies required external system or subsystem interfaces. Identification of
each interface includes a project unique identifier and designates interfacing entities (systems,
configuration items, warfighter’s, etc.) by name, number, version, and documentation
references, as applicable. The identification states 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 are provided to depict the interfaces.
A.3.3.X Project-unique identifier of interface.

This paragraph (beginning with 3.3.2 in the SRD or resulting specification) identifies a system or
subsystem external interface by project-unique identifier, identifies interfacing entities and is
divided into subparagraphs as needed to state requirements imposed on the system or
subsystem to achieve the interface. Interface characteristics of other entities involved in the
interface are 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 (for example, data dictionaries, standards for communication protocols, and
standards for warfighter interfaces) in place of stating the information here. Requirements
include the following, as applicable, presented in any order suited to the requirements, and
notes any differences in these characteristics from the point of view of the interfacing entities
(for example, different expectations about size, frequency, or other characteristics of data
elements): NOTE: Detailed external interface elements may not be known during SRD
development, in which case external interface requirements will be in broader, performance
terms. Also, external interfaces will be described in more detail in the architecture diagrams and
Information Support Plan (ISP). In many instances, interface requirements are known in great
detail as they are associated with current operational systems. Net Ready KPP requirements
are also addressed herein.
a. Priority the system assigns to the interface.
b. Requirements on type of interface (for example, real-time data transfer, storage-and

retrieval of data, etc.) to be implemented.
c. Provide required commercial or Government external interface standards for data

information transfer.
d. Provide required external communication links.
26
MIL-HDBK-520A
APPENDIX A
A.3.4 System internal interface requirements.

This paragraph specifies requirements imposed on interfaces internal to the system or
subsystem. If all internal interfaces are left to the design or to requirement specifications for
system or subsystem components, this fact is so stated.
A.3.5 System internal data requirements.

This paragraph specifies requirements imposed on data internal to the system or subsystem.
Included are requirements 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
or subsystem components, this fact is so stated.
A.3.6 Adaptation requirements.

This paragraph specifies requirements concerning installation-dependent data that the system
or subsystem is required to provide (for example, site dependent latitude and longitude) and
operational parameters that the system is required to use that may vary according to operational
needs (for example, parameters indicating operation-dependent targeting constants or data
recording).
A.3.7 Environmental, Safety, and Operational Health (ESOH) requirements.

This paragraph specifies system or subsystem requirements concerned with preventing or
minimizing unintended hazards to personnel, property, and the physical environment.
Examples include restricting use of hazardous materials; mitigating the potential for system
failures or mishaps, including critical software failures; classifying explosives for purposes of
shipping, handling, and storing; abort/escape provisions from enclosures; gas detection and
warning devices; grounding of electrical systems; decontamination; mitigating noise and other
emission hazards; and explosion proofing. This paragraph includes system or subsystem
requirements for nuclear components, including, as applicable, requirements for component
design, prevention of inadvertent detonation, and compliance with nuclear safety rules. Criteria
related to ESOH regulatory compliance requirements associated with the operation and
maintenance of the system throughout its life cycle are also included.
A.3.8 Security and privacy requirements.

This section specifies system or subsystem requirements concerned with maintaining security
and privacy. The requirements include, as applicable, security/privacy environment in which the
system or subsystem should operate, type and degree of security or privacy to be provided,
security/privacy risks the system or subsystem should withstand, required safeguards to reduce
those risks, security/privacy policy, security/privacy accountability the system or subsystem
provides, and criteria for security/privacy certification/accreditation. Paragraphs should be
included for IA requirements in accordance with DoDD 8500.01 and DoDI 8500.2 as required.
A.3.9 System environment requirements.

This paragraph specifies requirements regarding the environment in which the system or
subsystem operates. Examples for a hardware-software system include environmental
conditions that the system or subsystem withstands during transportation, storage, and
operation, for example, conditions in the natural environment (wind, rain, temperature,
geographic location), induced environment (motion, shock, noise, electromagnetic radiation),
and environments due to enemy action (explosions, radiation).
27
MIL-HDBK-520A
APPENDIX A
A.3.10 Computer resource requirements.

This paragraph is divided into the following subparagraphs. Depending upon the nature of the
system or subsystem, computer resources covered in these subparagraphs may constitute the
environment or components of the system or subsystem.
A.3.10.1 Computer hardware requirements.

This paragraph specifies requirements regarding computer hardware that is used by, or
incorporated into, the system or subsystem. Requirements may include equipment types,
numbers of each type, size and capacity. Characteristics of processors, memory devices,
input/output devices, auxiliary storage, communications/network equipment and other
equipment may be required.
A.3.10.2 Computer hardware resource utilization requirements.

This paragraph specifies the requirements on the system's or subsystem’s computer hardware
resource utilization, for example, maximum allowable use of processor capacity, memory
capacity, input/output device capacity, auxiliary storage device capacity, and
communications/network equipment capacity. Requirements (stated, for example, as
percentages of the capacity of each computer hardware resource) include conditions under
which the resource utilization is to be measured.
A.3.10.3 Computer software requirements.

This paragraph specifies requirements regarding computer software that is used by, or
incorporated into, the system or subsystem. 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 are provided.
A.3.10.4 Computer communications requirements.

This paragraph specifies additional requirements concerning computer communications that is
used by, or incorporated into, the system or subsystem. 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.
A.3.11 System quality factors.

This paragraph specifies requirements pertaining to system or subsystem quality factors.
Examples include quantitative requirements concerning system functionality (ability to perform
required functions), reliability (ability to perform with correct, consistent results, for example,
mean time between failure for equipment), maintainability (ability to be easily serviced, repaired,
or corrected), availability (ability to be accessed and operated when needed), flexibility (ability to
be easily adapted to changing requirements), portability of software (ability to be easily modified
for a new environment), reusability (ability to be used in multiple applications), testability (ability
to be easily and thoroughly tested), usability (ability to be easily learned and used), and other
attributes.
A.3.12 Design and construction constraints.

This paragraph specifies requirements that constrain design and construction of the system or
subsystem. For hardware-software systems, this paragraph includes physical requirements
imposed on the system or subsystem. These requirements may be specified by reference to
28
MIL-HDBK-520A
APPENDIX A
appropriate commercial or military standards and specifications. Examples include

requirements concerning:
a. Use of a particular system or subsystem architecture or requirements on the

architecture, for example, required subsystems, use of standard, military, or existing
components, or use of Government 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, use of existing software; workmanship
requirements and production techniques.
c. Physical characteristics of the system or subsystem (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
people.
d. Materials that may and may not be used, requirements on handling and disposal of
toxic materials, limits on electromagnetic radiation and hazardous emissions that the
system is permitted to generate.
e. Use of nameplates, part marking, serial and lot number marking, and other identifying
markings.
f. Flexibility and expandability should be provided to support anticipated areas of growth

or changes in technology, threat, or mission.
g. Include manufacturing requirements and constraints associated with producing the

system or subsystem.
A.3.13 Personnel-related requirements.

This paragraph specifies the system or subsystem requirements included to accommodate the
number, skill levels, duty cycles, training needs, or other information about the personnel who
will use or support the system. Examples include requirements for the number of workstations
to be provided and for built-in help and training features. Also included are human factors
engineering requirements imposed on the system or subsystem. These requirements include,
as applicable, considerations for capabilities and limitations of humans, foreseeable human
errors under both normal and extreme conditions, and specific areas where effects of human
error would be particularly serious. Examples include requirements for adjustable-height
workstations, color and duration of error messages, physical placement of critical indicators or
buttons, and use of auditory signals.
A.3.14 Training-related requirements.

This paragraph specifies the system or subsystem requirements pertaining to training.
Examples include training devices and training materials to be included in the system.
A.3.15 Logistics-related requirements.

This paragraph specifies the system requirements concerned with logistics considerations.
These considerations may include: system maintenance, software support, system
29
MIL-HDBK-520A
APPENDIX A
transportation modes, supply-system requirements, impact on existing facilities and impact on

existing equipment.
A.3.16 Other requirements.

This paragraph specifies additional system or subsystem requirements not covered in the
previous paragraphs. Examples include requirements for system or subsystem documentation,
for example, specifications, drawings, technical manuals, test plans and procedures, and
installation instruction data, if not covered in other contractual documents.
A.3.17 Packaging requirements.

This section specifies the requirements for packaging, labeling and handling the system or
subsystem and its components. Applicable military specifications and standards may be
referenced if appropriate.
A.3.18 Statutory, regulatory, and certification requirements.
A.3.18.1 Statutory requirements.

This paragraph specifies, if applicable, statutory requirements for the system or subsystem.
A.3.18.2 Regulatory requirements.

This paragraph specifies, if applicable, regulatory requirements for the system or subsystem.
A.3.18.3 Certification requirements.

This paragraph specifies, if applicable, certification requirements for the system or subsystem.
A.3.19 Precedence and criticality of requirements.

This paragraph specifies, if applicable, order of precedence, criticality, or assigned weights
indicating relative importance of 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 so states.
Key Performance Parameters (KPPs) and Key System Attributes (KSAs) are identified in the
body of section 3 of the SRD or resulting specification and provided in a tabular format ranked in
order of importance.
A.3.20 Demilitarization and disposal.

Demilitarization and disposal at the end of a life-cycle include activities necessary to ensure
disposal of decommissioned, destroyed or irreparable system components meets applicable
regulations, directives and Environmental, Safety, and Occupational Health (ESOH) constraints.
A.4 VERIFICATION PROVISIONS

This section defines a set of verification methods and specifies for each requirement in section 3
of the SRD or resulting specification the method(s) to be used to ensure the requirement has
been met. A matrix is used to present verification information for every requirement and is
documented in an SRD appendix. The SRD contains verification methods desired by the
Government. A contractor may offer alternative verification methods with associated
justification.
30
MIL-HDBK-520A
APPENDIX A
A.4.1 Verification methods.
A.4.1.1 Demonstration.
Operation of the system, subsystem or a part of the system that relies on observable, functional
operation, not requiring use of instrumentation, special test equipment or subsequent analysis.
A.4.1.2 Test.
Operation of the system, subsystem or a part of the system using instrumentation or other
special test equipment to collect data for later analysis.
A.4.1.3 Analysis.
Processing of accumulated data obtained from other qualification methods. Examples are
reduction interpolation or extrapolation of test results.
A.4.1.4 Inspection.
Visual examination of system components, documentation, etc.
A.4.1.5 Special verification methods.

Special verification methods for the system or subsystem, for example, special tools,
techniques, procedures, facilities, acceptance limits, use of standard samples, preproduction or
periodic production samples, pilot models or pilot lots.
A.5 REQUIREMENTS TRACEABILITY

For a system level SRD, this paragraph includes traceability requirements to a warfighter
Capability Document and down to applicable subsystems. For a subsystem level SRD, this
paragraph includes traceability to the system specification and down to applicable line
replaceable units (LRUs), including software Operational Flight Programs (OFPs) or equivalent.
Use of automated tools is highly encouraged and tools that maintain detailed artifacts of each
requirement are preferred.
A.5.1 Traceability to capability document or system specification.

This paragraph contains a description of the traceability to a Capability Document, for example
ICD or CDD, or System Specification. It also defines associated attributes that an automated
tool should capture to document each requirement.
A.5.2 Traceability to subsystems requirements.

This paragraph contains a description of traceability to a subsystem or lower tiered requirement
document. It also defines associated attributes that an automated tool should capture to
document each requirement.
A.6 NOTES.
This section does not contain any requirements. Section 6 contains information of a general of
explanatory nature. Such information may assist in determining the applicability of the SRD or
resulting specification.
A.6.1 Definitions and acronyms.

List definitions in alphabetical order in section 6. A parenthetical phrase referring to the
applicable paragraph in section 6 will follow the terms to indicate the existence of a definition,
for example “(see 6._._)”. When a standard definition exists, the definition should be quoted
31
MIL-HDBK-520A
APPENDIX A
word for word and the source cited. A complete list of acronyms may also be included in
section 6 of the SRD or resulting specification.
A.7 APPENDIXES
A.7.1 Appendix A: Key Performance Parameters (KPP)/Key System Attributes (KSA).

This appendix contains tabularized KPPs, and KSAs, if applicable, listed in prioritized order.
A.7.2 Appendix B: Requirements Traceability Matrices.

This appendix contains tabularized requirements traceability to the source documentation and to
the next lower tier documentation where known. If not known, pre-contract award, lower tier
traceability is to be included in the resultant system or subsystem specification.
A.7.3 Appendix C: Verification Matrices.

This appendix contains tabularized verification method for every system or subsystem
requirement. If not known, pre-contract award, the verification method is to be included in the
resultant system or subsystem specification.
32
MIL-HDBK-520A
APPENDIX B
System Requirements Document (SRD) Format

and Generic Template
B.1 PAGE LAYOUT GUIDANCE.

Use the following page layout guidance in preparing an SRD.
a. Cover Page: No page number shown on Cover Page, apply correct Distribution
Statement (DoDD 5230-34) and Classification (see DoDD 5230.35).
b. Backside of Cover Page: Show page numbers between the cover and the first
section, numbering consecutively in the bottom center of each page, with lower-case
Roman numerals. - “This Page is Intentionally Blank”.
c. Change History: Page Number iii.
d. Backside of Change History Page: Page Number iv - “This Page is Intentionally

Blank”.
e. Contents: Page Number v.
f. 1. Scope: Page Number 1, Start page 1, SCOPE on a right hand page, insert
preceding blank page when necessary.
g. Number pages consecutively, ensure Classification Markings, if applicable, appear

Top and Bottom, Front and Back of every page (DoD 5200.1R and DoD 5200.1-PH).
33
MIL-HDBK-520A
APPENDIX B
CLASSIFICATION MARKING (if applicable)
SYSTEM REQUIREMENTS DOCUMENT
SYSTEM NAME
and NOMENCLATURE (if available)
Day Month Year (Ex: 01 January 2011)
Status (Draft or Final)
Prepared for:
Office or Customer
Military Base, State
Prepared by:
Company or Individual Name

Street Address
Mail Stop
City, State (2 ltr abbreviation) Zip Code
Under: (Where applicable)

Contract XXX (Where applicable)
CDRL Item XXX (Where applicable)
Authenticated by: Approved by:
________________________________ ________________________________
First Name MI. Last Name First Name MI. Last Name
Chief or Lead Engineer Program Manager
Day Month Year (Ex: 01 January 2011) Day Month Year (Ex: 01 January 2011)
DISTRIBUTION STATEMENT-Ensure Proper Distribution Statement is Applied to Cover Page
CLASSIFICATION MARKING (if applicable)
34
MIL-HDBK-520A
APPENDIX B
THIS PAGE IS INTENTIONALLY BLANK
ii
35
MIL-HDBK-520A
APPENDIX B
CHANGE HISTORY
Change Version Date
iii
36
MIL-HDBK-520A
APPENDIX B
THIS PAGE IS INTENTIONALLY BLANK
iv
37
MIL-HDBK-520A
APPENDIX B
TABLE OF CONTENTS
PARAGRAPH PAGE
CHANGE HISTORY ................................................................................................................... iii
1. SCOPE .................................................................................................................................1
1.1 System identification.. ......................................................................................................
1.2 System overview. .............................................................................................................
1.3 System requirements document overview ........................................................................
2. APPLICABLE DOCUMENTS ..................................................................................................
2.1 General. ...........................................................................................................................
2.2 Government documents. ..................................................................................................
2.2.1 Specifications, standards, and handbooks ..............................................................
2.2.2 Other Government documents, drawings, and publications. ....................................
2.3 Non-Government publications ..........................................................................................
2.4 Order of precedence ........................................................................................................
3. REQUIREMENTS ...................................................................................................................
3.1 Required states and modes ..............................................................................................
3.2 System capability requirements ........................................................................................
3.2.1 System capability ....................................................................................................
3.3 System external interface requirements ...........................................................................
3.3.1 Interface identification and diagrams .......................................................................
3.3.2 Project unique interface identifier ............................................................................
3.4 System internal interface requirements ............................................................................
3.5 System internal data requirements ...................................................................................
3.6 Adaptation requirements ..................................................................................................
3.7 Environmental, Safety, and Operational Health requirements ..........................................
3.8 Security and privacy requirements ...................................................................................
3.9 System environment requirements ...................................................................................
3.10 Computer resource requirements .....................................................................................
3.10.1 Computer hardware requirements ...........................................................................
3.10.2 Computer hardware resource utilization requirements ............................................
3.10.3 Computer software requirements ............................................................................
3.10.4 Computer communication requirements ..................................................................
3.11 System quality factors ......................................................................................................
3.12 Design and construction constraints .................................................................................
3.13 Personnel related requirements........................................................................................
3.14 Training related requirements ...........................................................................................
3.15 Logistics related requirements ..........................................................................................
3.16 Other requirements ..........................................................................................................
3.17 Packaging requirements ...................................................................................................
3.18 Statutory, regulatory, and certification requirements .........................................................
38
MIL-HDBK-520A
APPENDIX B
3.18.1 Statutory requirements ............................................................................................

3.18.2 Regulatory requirements .........................................................................................
3.18.3 Certification requirements .......................................................................................
3.19 Precedence and criticality of requirements .......................................................................
3.20 Demilitarization and disposal ............................................................................................
4. VERIFICATION PROVISIONS ................................................................................................
4.1 Verification methods .........................................................................................................
4.1.1 Demonstration.........................................................................................................
4.1.2 Test .........................................................................................................................
4.1.3 Analysis ..................................................................................................................
4.1.4 Inspection ...............................................................................................................
4.1.5 Special verification methods....................................................................................
5. REQUIREMENTS TRACEABILITY .........................................................................................
5.1 Traceability to capability document or system specification ..............................................
5.2 Traceability to subsystems requirements..........................................................................
6. NOTES.
6.1 Definitions ...........................................................................................................................
APPENDIX SECTION
Appendix A – Key Performance Parameters/Key System Attributes ..........................................
Appendix B – Requirements Traceability Matrices .....................................................................
Appendix C – Verification Matrices ............................................................................................
vi
39
MIL-HDBK-520A
CONCLUDING MATERIAL
Custodians: Preparing Activity:

Army – AR Air Force - 11
Navy - SH
Air Force - 11 Project No. SESS-2011-006
Review activities:
Army – AT, AV, MI
Navy - AS
Air Force – 13, 44, 71
NOTE: The activities listed above were interested in this document as of the date of this
document. Since organizations and responsibilities can change, you should verify the currency
of the information above using the ASSIST Online database at https://assist.daps.dla.mil.
40

Mil HDBK 520a

Uploaded by

Copyright:

Available Formats

Mil HDBK 520a

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mil HDBK 520a

Uploaded by

Copyright:

Available Formats

Downloaded from http://www.everyspec.

This handbook is for guidance only.

AMSC N/A AREA SESS

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

4. Comments, suggestions, or questions on this document should be addressed to

A guidance document/handbook or template for developing a System/Subsystem Requirements

Data Item Description (DID) DI-IPSC-81431, System/Subsystem Specification and MIL-STD-

Change Version Date

TABLE I. Sample Requirements Metadata. .......................................................................... 2121

2.2 Government documents.

2.2.1 Specifications, standards, and handbooks.

DEPARTMENT OF DEFENSE STANDARDS

(Copies of these documents are available online at https://assist.daps.dla.mil/quicksearch/ or

2.2.2 Other Government documents, drawings, and publications.

CHAIRMAN OF THE JOINT CHIEFS OF STAFF

(Copies of these documents are available online at

DATA ITEM DESCRIPTION (DID)

(Copies of this document are available online at https://assist.daps.dla.mil/quicksearch/ or from

NATIONAL ACADEMIES PRESS

U.S. GOVERNMENT PRINTING OFFICE

DEPARTMENT OF DEFENSE ISSUANCES

(Copies of these documents are available online at http://www.dtic.mil/whs/directives/.)

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

3.1 Allocated Baseline.

3.4 Capabilities Based Assessment (CBA).

3.6 Capability Development Document (CDD).

3.7 Capability need.

3.8 Capability Production Document (CPD).

3.9 Derived Requirements.

3.10 Family of Systems (FoS).

3.12 Functional Baseline (FBL).

3.13 Initial Capabilities Document (ICD).

3.14 Key Performance Parameters (KPP).

3.15 Key System Attribute (KSA).

3.16 Measure of Effectiveness (MOE).

3.17 Measure of Performance (MOP).

3.18 Measure of Suitability (MOS).

3.20 Operational Requirements.

3.21 Performance Requirements.

3.22 Regulatory Requirements.

3.23 Requirements Analysis.

3.24 Requirements Management.

3.25 Statutory Requirements.

3.29 Systems Analysis and Control.

3.30 Systems Engineering (SE).

3.31 System of Systems (SoS).

3.32 Weapon Systems Acquisition Reform Act (WSARA).

AIP Acquisition Improvement Plan

INCOSE International Council on Systems Engineering

SOW Statement of Work

4.2 SRD guidance applicability.

4.3 SRD purpose.

capabilities document approved by a Service/Agency requirements authority and the Joint

4.4 Functional baseline (FBL).

4.5 Early systems engineering (SE).

5.1 Requirements development.

5.3 Capabilities documents.

5.4 Warfighter attributes.

5.5 Contract award.