**REQUIREMENTS DOCUMENT** (REVISED 07/2001)

**PURPOSE**

The Requirements Document establishes the operational framework and
performance baseline for an acquisition program. The Requirements
Document becomes the performance baseline in the Acquisition Program
Baseline at the Investment Decision.

**DESCRIPTION**

The Requirements Document is the primary force driving the search for a
realistic and affordable solution to mission need during Investment
Analysis. The initial Requirements Document is developed early in
Investment Analysis by the sponsoring line of business. It translates
the \"need\" in the Mission Need Statement into initial top­level
requirements addressing such concerns as performance, supportability,
physical and functional integration, human integration, security, test
and evaluation, implementation and transition, quality assurance,
configuration management, and in-service management. The initial
Requirements Document must *not* describe a specific solution to mission
need, and should not preclude leasing, commercial, or non-developmental
solutions. During Investment Analysis, these initial requirements are
evaluated against the cost, benefits, schedule, and risk of various
candidate solutions and brought into balance with an affordable
solution.

At the Investment Decision, the Requirements Document defines exactly
the operational concept and requirements the approved acquisition
program is intended to achieve. It is the basis for evaluating the
readiness of resultant products and services to become operational.
Sponsor requirements not included in the Requirements Document at the
Investment Decision are returned to the sponsoring line of business for
disposition.

**NOTE:** The Requirements Document is NOT a design specification; it
contains only top­level requirements.

**APPROVAL**

The Associate Administrator of the line of business with the mission
need approves the Requirements Document and all changes to it.

**DISTRIBUTION** ~(Revised\ 06/2001)~

Distribute copies of the approved Requirements Document to all
headquarters, regional, and other personnel associated with the program.
Send a copy to ACM-1, NAS Configuration Management and Evaluation Staff,
which maintains a central repository of approved acquisition documents
for the Joint Resources Council.

**CONTENT** ~(Revised\ 06/2001)~

*The following summarizes the content of the Requirements Document. A
complete template and instruction is located in FAST via the Internet at
http://fast.faa.gov. The Requirements Document template must be used
when preparing the Requirements Document.*

**Signature Page.** Include: the title \"Requirements Document\" and
name of the acquisition program; signature of the Associate
Administrator of the line of business with the mission need and
signature date; name, organizational code, phone number, and FAX number
of the line of business focal point for the Requirements Document.
~(Revised\ 06/2001)~

**Table of Contents.** List every section, subsection, and other element
in the Requirements Document and provide the page number.

**Background.** Briefly describe the mission need and how the proposed
capability will satisfy the need. Describe any substantive changes to
the Requirements Document since the Investment Decision, and explain why
the changes were needed. ~(Revised\ 06/2001)~

**Operational Concept.** Briefly describe the operational environment
and intended service life for the required capability. Include how it
will be used in the operational environment, and how it will affect
major users (e.g., controllers, pilots, flow control). Define hardware
and software maintenance requirements. Quantify the total number of
units or scope of services that are required. Define any schedule
constraints.

**Technical Performance.** Define operational and functional
requirements the new capability must provide to satisfy mission need.
Define product characteristics and performance requirements.

**Physical Integration.** Define requirements associated with
integrating the products of the acquisition program into the physical
environment (e.g., real estate, space, environment, energy conservation,
heating, ventilation, air conditioning, grounding, bonding, shielding
lightning protection, cables, hazardous materials, power systems and
commercial power, telecommunications, special considerations).

**Functional Integration.** Define functional integration requirements
associated with integrating the new capability into the operational
environment. This includes integration with other elements of the
National Airspace System, as well as with non-National Airspace System
elements. It also includes software integration, spectrum management,
and standardization. ~(Revised\ 06/2001)~

**Human Integration.** Define human-product integration requirements to
achieve optimum performance from a total product perspective. Define
requirements related to employee heath and safety. Define requirements
associated with special skills and capabilities for operators,
maintainers, or support personnel.

**Security.** Define requirements relevant to physical security,
contractor-unique security, all information and information systems
security, and personnel security. ~(Revised\ 06/2001)~

**System Safety Management.** Define high-level safety requirements,
which meet the safety goals determined by the hazard identification
process. Include requirements, which may not relate to specific hazards
such as those from standards, laws, regulations, and lessons learned
from similar systems. ~(Added\ 12/1999)~

**Integrated Logistics Support.** Define supportability requirements for
the following as appropriate: staffing, supply support, support
equipment, technical data, training and training support, first and
second level repair, packaging, handling, shipping, and transportation.
~(Revised\ 02/2001)~

**Test and Evaluation.** Define test and evaluation requirements
including mandatory evaluations of safety, environmental, and energy
conservation issues prior to joint acceptance and inspection. Specify
whether independent operational test and evaluation is required. State
whether operational testing will be required at the FAA William J.
Hughes Technical Center before testing at an operational site.
~(Revised\ 06/2001)~

**Implementation and Transition.** Define requirements related to
transition from the current capability to the new capability so as to
not disrupt on-going National Airspace System operations. Implementation
requirements typically encompass implementation planning,
pre­installation checkout, installation and checkout, site integration,
system shakedown, dual operations, and removal/disposal of replaced
systems, equipment, land, facilities, and other items.
~(Revised\ 06/2001)~

**Quality Assurance.** Define quality assurance requirements for such
functions as contractor status reporting, metrics, in­plant Quality
Reliability Officers, independent verification and validation, vendor
quality assurance, and Capability Maturity Model assessment of the
software development processes of potential suppliers.

**Configuration Management.** Define requirements for the configuration
management of hardware, software, facilities, data, interfaces, tools,
and documentation.

**In-Service Management.** Define requirements for monitoring,
assessing, and optimizing the performance of this capability during the
in-service management phase of the acquisition lifecycle.

**Appendix I. Requirements Correlation Matrix.** Where applicable,
specify a threshold value and an objective value for each requirement in
the Requirements Document using the table format of Appendix I in
Requirements Document Template.

**Appendix II. Mission Need Correlation Matrix.** Develop a correlation
matrix that maps where every need in the Mission Need Statement is
addressed in the Requirements Document. Use the table format of Appendix
II in the Requirements Document Template.

**Appendix III. Definitions.** Define important non-standard terms used
in the Requirements Document.

**Appendix IV. Acronyms.** Define all acronyms used in the Requirements
Document.

**Attachment - Residual Technical Requirements.** Specify those final
sponsor requirements that are not intended to be satisfied by the
acquisition program approved at the Investment Decision. Resolution of
these deferred requirements is the responsibility of the sponsoring line
of business.

**Template for the Requirements Document\
(Revised 07/2001)**

**Using This Template** ~(Revised\ 07/2001)~

This template provides guidance for preparing the Requirements Document.
It supplements information found in Appendix B of the FAA Acquisition
Management System. Text of the template that is italicized is intended
to guide preparation of the Requirements Document. Non-italicized text
defines the format and structure of the document (title page, table of
contents, section head and numbers, tables and titles). Not all sections
of the Requirements Document template apply to every mission need,
particularly requirements that will be satisfied by human resource
services. Simply state \"not applicable\" for those sections which do
not apply to the acquisition program or candidate solution.

**About the Requirements Document** ~(Revised\ 07/2001)~

At the beginning of investment analysis, the initial Requirements
Document does not contain any requirement that would unduly restrict the
search for solutions to mission need. As investment analysis proceeds,
the initial Requirements Document evolves to a set of tailored draft
Requirements Documents, each containing the requirements intended to be
satisfied by a candidate solution to mission need. Typically, these
draft Requirements Documents have a very high degree of commonality,
with some parameters tailored to the specific capability to be provided.
Sponsor requirements not intended to be satisfied by a candidate
solution are compiled in an attachment to each draft Requirements
Document. At the Investment Decision, the Requirements Document of the
candidate solution selected for implementation becomes the performance
baseline of the acquisition program. The attachment containing any
unsatisfied requirements is returned to the sponsoring line of business
for deposition.

Specifications, standards, executive orders, and mandates are referenced
in the appropriate section or subsection of the Requirements Document.
Tailor them carefully so only applicable sections are applied. Use
industry and international standards to the greatest possible extent.

Appendix I is a Requirements Correlation Matrix that specifies a
threshold value and an objective value for each requirement in the
Requirements Document, where practical. The threshold value is the
minimum performance required for acceptable operational suitability and
effectiveness. The objective value represents a measurable increase in
capability that has practical operational benefit to the FAA and its
customers.

Appendix II is a Mission Need Correlation Matrix that traces where each
need statement in the Mission Need Statement is addressed in the
Requirements Document.

**Joint Resources Council - Controlled Parameters** ~(Revised\ 07/2001)~

**Certain key parameters in the Requirements Document are designated for
control by the Joint Resources Council. They are highlighted with bold,
underlined text in the Requirements Document.** The Joint Resources
Council controls only those requirements that are critical to (1)
achieving operational effectiveness and suitability, (2) meeting the
needs of dependent elements of the National Airspace System, (3) and
accruing benefits ascribed to the candidate solution or acquisition
program. As a rule of thumb, the Joint Resources Council controls no
more than 10 - 20 requirements across all sections of the Requirements
Document. Mandatory Joint Resources Council controls are the total
number of units for system production, the number of facilities and/or
sites to be constructed, or the total level of services to be provided,
as appropriate to the acquisition program.

**Change Control**

The Requirements Document is intended to be a firm and stable foundation
for program implementation. As the performance baseline of the
Acquisition Program Baseline, it is subject to the change procedures of
the Acquisition Program Baseline.

**Cost** ~(Revised\ 07/2001)~

The resource estimate in the Mission Need Statement addressed by this
Requirements Document is a placeholder in agency\'s long-range planning
in the National Airspace System Architecture. It sets a rough boundary
on the acceptable cost of solutions to the mission need.

**Schedule**

The timeframe in the Mission Need Statement when the new capability must
be operational defines the time available to develop and deploy a
solution that meets the requirements in this Requirements Document.

**Benefits**

Benefit requirements at the beginning of Investment Analysis are the
benefits defined in the Mission Need Statement.

Requirements Document

for

\[enter name of acquisition program\]

Change *(#)*

Approved by: *[Signature]{.underline}*           Date:\
(Associate Administrator, Sponsoring Line of Business)

Submitted By: *[Signature]{.underline}*           Date:\
(Appropriate Director, Preparing Organization)

**[Focal Point]{.underline}**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

*Name*

*Code*

*Phone Number*

*FAX Number*

Federal Aviation Administration

800 Independence Avenue SW

Washington, DC 20591

**Requirements Document**

**Table of Contents**

**1. BACKGROUND** ~(Revised\ 07/2001)~

**2. OPERATIONAL CONCEPT** ~(Revised\ 07/2001)~

2.1. Operations ~(Revised\ 07/2001)~

2.2. Maintenance\
2.2.1. Hardware Maintenance\
2.2.2. Software Maintenance\
2.3. Quantities and Location

2.4. Schedule Constraints ~(Revised\ 07/2001)~

**3. TECHNICAL PERFORMANCE** ~(Revised\ 07/2001)~

3.1.Operational and Functional Requirements

3.2. Product Characteristics and Performance Requirements
~(Revised\ 07/2001)~

**4. PHYSICAL INTEGRATION** ~(Revised\ 07/2001)~

4.1. Real Property ~(Revised\ 07/2001)~\
4.1.1. Land ~(Added\ 07/2001)~\
4.1.2. Space ~(Revised\ 07/2001)~\
4.2. RESERVED ~(Added\ 07/2001)~\
4.3. Environmental ~(Revised\ 07/2001)~\
4.4. Energy Conservation ~(Revised\ 07/2001)~\
4.5. Heating, Ventilation, Air-Conditioning ~(Revised\ 07/2001)~\
4.6. Grounding, Bonding, Shielding, and Lightning Protection
~(Revised\ 07/2001)~\
4.7. Cables ~(Revised\ 07/2001)~\
4.8. Hazardous Materials ~(Revised\ 07/2001)~\
4.9. Power Systems and Commercial Power ~(Revised\ 07/2001)~\
4.10. Telecommunications ~(Revised\ 07/2001)~\
4.11 Special Considerations ~(Revised\ 07/2001)~

**5. FUNCTIONAL INTEGRATION** ~(Revised\ 07/2001)~

::: Definition-Term
> 5.1. Integration With Other National Airspace System
:::

> (and non-National Airspace System) Elements ~(Revised\ 07/2001)~\
> 5.2. Software Integration
>
> 5.3. Spectrum Management\
> 5.4. Standardization

**6. HUMAN INTEGRATION**

6.1. Human-Product Interface\
6.2. Employee Safety and Health\
6.3. Specialized Skills and Capabilities

**7. SECURITY** ~(Revised\ 07/2001)~

7.1. Physical Security\
7.2. Information Security ~(Revised\ 07/2001)~\
7.3. Personnel Security

**8. IN-SERVICE SUPPORT**

8.1. Staffing\
8.2. Supply Support\
8.3. Support Equipment\
8.4. Technical Data\
8.5. Training and Training Support\
8.6. First and Second Level Repair\
8.7. Packaging, Handling, Storage, and Transportation

**9. TEST AND EVALUATION** ~(Revised\ 07/2001)~

9.1. Critical Operational Issues\
9.2. Test and Evaluation Requirements ~(Revised\ 07/2001)~

**10. IMPLEMENTATION AND TRANSITION** ~(Revised\ 07/2001)~

**11. QUALITY ASSURANCE** ~(Revised\ 07/2001)~

**12. CONFIGURATION MANAGEMENT**

**13. IN-SERVICE MANAGEMENT**

**14. SYSTEM SAFETY MANAGEMENT** ~(Revised\ 07/2001)~

**Appendix I. Requirements Correlation Matrix**

**Appendix II. Mission Need Correlation Matrix**

**Appendix III. Definitions**

**Appendix IV. Acronyms**

**Attachment - Residual Technical Requirements**

**1. BACKGROUND** ~(Revised\ 07/2001)~

Identify the Mission Need Statement addressed by this Requirements
Document and summarize the mission need. Describe briefly the deficiency
in capability or technological opportunity, and how the proposed
capability will satisfy the mission need. Identify National Airspace
System assets this capability is intended to replace. Briefly summarize
any substantive changes to the Requirements Document since the
Investment Decision, and explain why the changes were needed.

**2. OPERATIONAL CONCEPT** ~(Revised\ 07/2001)~

**2.1. Operations** ~(Revised\ 07/2001)~

Briefly describe the operational concept and intended service life for
the required capability. This is based largely on agency long-range
operational concepts and the National Airspace System Architecture.
Explain how the capability will be used in the operational environment,
and how it will affect major users (e.g., controllers, pilots, flow
control). To the extent known, explain how this operational concept
interacts, modifies, and folds into pre­existing National Airspace System
operations. Assess the impact of this new capability on existing
operational rules and procedures. Use block diagrams and flowcharts to
illustrate this discussion.

For requirements likely to be satisfied through a manpower services
program, describe how the services will resolve an existing or emerging
operational or other capability shortfall.

**2.2. Maintenance**

Describe the intended life of the capability from contractor acceptance
inspection through disposition, including sustainment engineering,
pre-planned product improvement, and other in-service management
activities such as condition assessment and routine operations and
maintenance. Define the intended End of Service Life for this product or
service.

For requirements likely to be satisfied through a manpower services
program, describe the support concept that will be applied to any
facility or equipment needed to support the services program.

**2.2.1. Hardware Maintenance**

Define hardware maintenance requirements (e.g., in-house FAA maintenance
or contractor maintenance, (preventive, preemptive, corrective), first
and second level depot repair, lowest level of repair). Indicate any
restrictions on who or how maintenance will be done (e.g., FAA or
contractor). Define any time­phasing requirements for all levels of
maintenance (e.g., preventive maintenance not to exceed \"x\" times per
year, depot repair within 30 days, corrective maintenance within 24
hours). Define requirements concerning the degree of on-site and
centralized maintenance. Identify whether new equipment will be
monitored by RMMS/NIMS*.*

**2.2.2. Software Maintenance**

Define requirements for software maintenance (e.g., in-house FAA or
contractor). Define requirements concerning the degree of on-site and
centralized maintenance. Indicate any restrictions on who or how
maintenance will be done (e.g., FAA or contractor). Define any
requirements related to release of new software into operational use.

**2.3. Quantities and Location**

Identify the total number of units or scope of services that will be
needed to meet the mission need. Provide as much location information as
possible (e.g., initially the number of units per region, evolving to
specific locations during Investment Analysis). Include Congressional
mandates. Congressional mandates imposed on a program after baselining
at the Investment Decision may require a baseline change.

**2.4. Schedule Constraints** ~(Revised\ 07/2001)~

Identify the date by which products or services must achieve full
operational capability at the first site. Identify the date by which all
sites must achieve operational capability. Identify schedule constraints
associated with any predecessor and successor interfacing or
interdependent National Airspace System elements required to achieve
full operational capability. Include Congressional mandates.
Congressional mandates imposed on a program after baselining at the
investment decision may require a baseline change.

**3. TECHNICAL PERFORMANCE** ~(Revised\ 07/2001)~

**3.1. Operational and Functional Requirements** ~(Revised\ 07/2001)~

Define operational and functional requirements the new capability must
provide to satisfy mission need (e.g., detect, identify, and track
aircraft in the en route airspace).

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

The subsection titles in the following table are representative. Select
and/or develop appropriate subtitles to describe operational and
functional requirements for the candidate solution or acquisition
program.

***Representative 3.1 Subsection Titles***

  -----------------------------------------------------------------------
  ***Subsection Title***

  *3.1.1 Surveillance Processing*

  *3.1.2 Track Processing*

  *3.1.3 Flight Data Processing*

  *3.1.4 Display Information*

  *3.1.5 Data Recording*

  *3.1.6 Data Playback*

  *3.1.7 Traffic Management*
  -----------------------------------------------------------------------

**3.2. Product Characteristics and Performance Requirements**

Define product characteristics and performance requirements. Performance
requirements must be achievable, measurable, and specified in
operational terms whenever practical.

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

The following subsection titles are representative. Select and/or
develop titles appropriate to the candidate solution or acquisition
program.

***Representative 3.2 Subsections***~(Revised\ 07/2001)~

  ------------------------ ----------------------------------------------
  ***Subsection Heading*** ***Description***

  *3.2.1 Service Levels*   *Define mission scenarios that may imply
                           different levels of acceptable service (e.g.,
                           whether performance is different for normal
                           and emergency back-up service, whether peak
                           loading is substantially different from
                           minimum or average loading).*

  *3.2.2 Recovery*         *Define the period of time for the product to
                           recover full service after power loss.*

  *3.2.3 Reliability,      *Define reliability requirements (e.g., mean
  Maintainability,         time between failure (MTBF)). Define
  Availability*            maintainability requirements (e.g., mean time
                           to repair (MTTR)). Define availability
                           requirements (e.g., full service availability,
                           emergency service availability).*

  *3.2.4 Enhanceability*   *Define requirements related to modularity and
                           the ability of a product\'s hardware and
                           software components to be improved without
                           requiring changes to components other than
                           those being improved.*

  *3.2.5 Scalability*      *Define requirements related to whether the
                           product must provide for a range of capacity,
                           functionality, and capability for a range of
                           applications.*

  *3.2.6 Operational       *Identify requirements concerning the
  Software*                selection and deployment of operational
                           software (e.g., whether a specific higher
                           order language must be used, whether software
                           must be transferable between platforms).*

  *3.2.7 Operational       *Define requirements concerning operational
  Hardware*                hardware (e.g., whether modifications are
  ~(Revised\ 07/2001)~     permissible to commercial off-the-shelf
                           hardware products).*
  ------------------------ ----------------------------------------------

**4. PHYSICAL INTEGRATION** ~(Revised\ 07/2001)~

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

Physical integration concerns the integration of a solution into the
physical environment. Initially, these requirements will be general,
perhaps defined in terms of \"not to exceed\" values based on existing
capabilities. Derived requirements are defined for each candidate
solution during Investment Analysis. Many physical integration
requirements do not apply to requirements for services, unless equipment
or facilities will be acquired to support the services.

**4.1. Real Property** ~(Revised\ 07/2001)~

Real property includes owned and leased land and space and other
structures under the FAA control.

4.1.1 Land -- Define briefly the strategy for acquiring any required
real estate, i.e. land, including completion of the National
Environmental Protection Act process, the appropriate Environmental Due
Diligence Audit and any other applicable environmental law before any
agreement to acquire property. Be aware that the lead time for
acquisition of real estate may vary depending on acquisition factors
such as market conditions, siting complexities, etc., and should begin
soon after the investment decision and in close coordination with the
appropriate region/center acquiring organization. ~(Added\ 07/2001)~

4.1.2 Space -- Define briefly the strategy for acquiring the physical
space needed to accommodate systems, auxiliary equipment, and personnel
both for end-state operations and during transition to the new
capability. Depending on need and complexity, acquisition times may
vary. Coordination with appropriate acquiring organization is
recommended at the earliest possible time. ~(Revised\ 07/2001)~

**4.2 RESERVED** ~(Added\ 07/2001)~

**4.3. Environmental** ~(Revised\ 07/2001)~

Define requirements to achieve compliance with the National
Environmental Policy Act and other environmental regulations and
standards.

**4.4. Energy Conservation** ~(Revised\ 07/2001)~

Define requirements to achieve compliance with energy and water
conservation mandates of the National Energy Conservation Policy Act.

**4.5. Heating, Ventilation, Air Conditioning** ~(Revised\ 07/2001)~

Define heating, ventilation, and air conditioning requirements both
during transition and for end-state operations. For services, define
requirements for the workforce that will provide the services.

**4.6. Grounding, Bonding, Shielding, and Lightning Protection**
~(Revised\ 07/2001)~

Define grounding, bonding, shielding, and lightning protection
requirements both during transition to the new capability and for
end-state operations. See FAA­G­2100 and associated standards
directives*.*

**4.7. Cables** ~(Revised\ 07/2001)~

Define cable, cable routing, and raised­floor requirements both during
transition to the new capability and for end-state operations.

**4.8. Hazardous Materials** ~(Revised\ 07/2001)~

Define requirements *for the handling, eventual removal, cleanup, and
recycling of hazardous materials.*

**4.9. Power Systems and Commercial Power** ~(Revised\ 07/2001)~

Define power system requirements and commercial power requirements both
during transition to the new capability and for end-state operations.
Identify harmonic requirements for all contractor­provided equipment, as
well as any deviations from current FAA standards.

**4.10. Telecommunications** ~(Revised\ 07/2001)~

Define telecommunications requirements both during transition to the new
capability and for end-state operations.

**4.11. Special Considerations** ~(Revised\ 07/2001)~

Define unique requirements relating to such factors as fiber optics,
water and sewer, roadway, and access both during transition to the new
capability and for end-state operations.

**5. FUNCTIONAL INTEGRATION** ~(Revised\ 07/2001)~

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

Define functional integration requirements associated with integrating
the new capability into the operational environment. This involves
integration with the approximately 14,000 primary air traffic control
and air navigation systems of the National Airspace System. It also
includes functional integration with non-National Airspace System
elements.

Functional integration requirements typically do not apply to
requirements for services.

**5.1. Integration With Other National Airspace System (and Non-National
Airspace System) Elements** ~(Revised\ 07/2001)~

Identify all other systems, subsystems, networks, facilities, and
organizations, including all states and modes of operation (e.g.,
primary and back-up) that will interface with this capability, and for
which Interface Requirements Documents and Interface Control Documents
must be developed. Include remote maintenance monitoring and operational
command and control integration requirements.

**5.2. Software Integration**

Identify procedural and technical software interface requirements, as
well as specifications, protocols, and standards to ensure compatibility
and interoperability with other fielded systems. Identify computer
resource constraints (e.g., language, computer, database, architecture,
or interoperability constraints). Identify any unique user interface
requirements, demonstration needs, and special software certification.

**5.3. Spectrum Management**

Define requirements for spectrum management, including certification of
radio spectrum availability. Ensure spectrum compatibility with the rest
of the National Airspace System.

**5.4. Standardization**

Define requirements to use standard products already in use in the
National Airspace System. Define any other standardization requirement
to facilitate functional and physical integration. Identify any ICAO,
ISO, space management, or other standard to ensure ease of training,
logistics, workforce mobility, architecture and engineering, or
compliance with international, national, state and local codes and laws.

**6. HUMAN INTEGRATION**

Address the following subsections when appropriate to the candidate
solution or acquisition program. Add additional subsections as needed.

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.

**6.1. Human/Product Interface**

Define human/product interface requirements intended to achieve optimum
performance from a total product perspective. Typically, human factors
requirements are intended to ensure products are designed and
appropriate for the human workforce that will operate, maintain, and
support them.

**6.2. Employee Safety and Health**

Define requirements related to compliance with Occupational Safety and
Health Administration mandates and other safety and health regulations
and standards (e.g., adequate workspace for maintenance, access to
serviceable components, environmentally friendly fuels and oils, proper
handling of exhaust, waste disposal, and fall protection). Define health
and safety requirements related to optimizing performance and avoiding
conditions that degrade performance. Define operating environment
requirements related to such factors as lighting, means of egress,
temperature, noise, fire protection, stairs, and ladders. Define
requirements for sensing or detecting and automatic shut-down for
malfunctions that may cause a serious safety or health risk to employees
or the public (e.g., microwave radiation exposure due to a radar
malfunction).

**6.3. Specialized Skills and Capabilities**

Define appropriate cognitive, physical, sensory, and performance
requirements for operators, maintainers, or support personnel. Define
manpower and human performance thresholds and criteria (e.g., the number
of operators per equipment, capability or proficiency of
operators/maintainers) that influence or shape the operational
environment. Define constraints, limitations, and unique or specialized
requirements related to training, staffing levels, and personnel skills.
Human factors requirements must be consistent with the nature, size, and
complexity of the product(s) or services that will be acquired.

**7. SECURITY** ~(Revised\ 07/2001)~

**7.1. Physical Security**

Define requirements related to the physical plant and contractor­unique
security both for end­state operations and during transition to the new
capability.

**7.2. Information Security** ~(Revised\ 07/2001)~

Define requirements related to the storage, processing, or transfer of
information related to air traffic control or other sensitive
information, both for end­state operations and during transition to the
new capability*.*

**7.3. Personnel Security**

Define any security requirements related to personnel, security
clearances, security training, and access control methods

**8. IN-SERVICE SUPPORT**

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to the mission need.\]

In-service support requirements typically do not apply to requirements
for service unless equipment or facilities will be acquired to support
the human resources who will provide the services.

Define maintenance and support requirements for the following
categories, as appropriate.

**8.1. Staffing**

Direct person work-hours required to perform operations and maintenance
actions*.*

**8.2. Supply Support**

Requirements related to obtaining, cataloging, receiving, storing, and
issuing items of supply*.*

**8.3. Support Equipment**

Tools and equipment required to install and support the operation and
maintenance of a facility, system, or equipment. Support facility
requirements should be identified in the physical facility element of
this document.

**8.4. Technical Data**

Requirements related to recorded information such as manuals,
specifications, drawings, and operational testing procedures to operate
a product over its intended lifecycle.

**8.5. Training and Training Support**

Requirements related to the processes, procedures, course material, and
skills necessary to train personnel to install, operate, and maintain a
facility, system, or equipment*.*

**8.6. First and Second Level Repair**

Requirements related to processes and procedures for on-site and
second-level engineering support for both hardware and software.

**8.7. Packaging, Handling, Storage, and Transportation**

Requirements related to resources and methods to ensure that systems,
equipment, and support items are preserved, packaged, handled, and
transported safely.

**9. TEST AND EVALUATION** ~(Revised\ 07/2001)~

**9.1. Critical Operational Issues**

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

Define the critical operational issues to be used by Independent
Operational Test and Evaluation when determining whether a new
capability is operationally acceptable. Critical operation issues
typically relate to operational effectiveness which measures the degree
to which a product satisfies mission requirements when used by
representative personnel in the planned operational environment, and to
operational suitability which measures the degree to which a product
meets its availability, operability, maintainability, safety, human
factors, and support requirements.

Critical operational issues do not apply to requirements that will be
satisfied with services provided by human resources.

**9.2. Test and Evaluation Requirements** ~(Revised\ 07/2001)~

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to the mission need.\]

Define test and evaluation requirements. Include mandatory evaluations
of safety, environmental, and energy conservation issues prior to joint
acceptance and inspection. Specify whether independent operational test
and evaluation is required. State whether operational testing will be
required at the FAA William J. Hughes Technical Center before testing at
an operational site.

Test and evaluation requirements typically do not apply to services
requirements unless equipment or facilities will be acquired to support
the services.

The following table contains representative test and evaluation
subsection titles that should be addressed when applicable to the
candidate solution or acquisition program.

***Representative Test and Evaluation Subsection Titles***

  -----------------------------------------------------------------------
  ***Subsection Title***

  *9.2.1 System Test Requirements*

  *9.2.2 IOT&E Test Requirements*

  *9.2.3 Field Familiarization Test Requirements*
  -----------------------------------------------------------------------

**10. IMPLEMENTATION AND TRANSITION** ~(Revised\ 07/2001)~

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need\]

Define requirements related to transition from the current capability to
the new capability so as to not disrupt services. Implementation
requirements typically encompass implementation planning,
pre-installation checkout, installation and checkout, site integration,
system shakedown, dual operations, and the removal/disposal of replaced
systems, equipment, land, facilities, and other items. For services
programs where there will be transitions from an existing services
provider to a different services provider, implementation requirements
may include training, setting up contacts, office automation, support
systems, databases, and operational procedures. The In­Service Review
Checklist (see FAST) identifies implementation concerns. Define any
rulemaking changes related to commissioning into the National Airspace
System*.*

**11. QUALITY ASSURANCE** ~(Revised\ 07/2001)~

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to mission need.\]

Define quality assurance requirements. Examples include contractor
status reporting, metrics, an in-plant Quality Reliability Officer,
independent verification and validation, vendor quality assurance plans,
or a documented process for software development. Specify whether a
Capability Maturity Model assessment of the software development
processes of potential suppliers is required. Identify whether and what
ISO or FAA quality standards are invoked.

Quality assurance requirements for services requirements typically
relate to ensuring the quality of the services to be provided.

**12. CONFIGURATION MANAGEMENT**

\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solutions to the mission need.\]

Define configuration management requirements for hardware, software,
data, documentation, interfaces, and tools. These requirements should be
appropriate to the nature (e.g., commercial, non-developmental,
developmental) and complexity of the product(s) that will be needed to
satisfy mission need. Allow flexibility in the management of commercial
products.

Configuration management requirements typically do not apply to
requirements for services unless equipment or facilities will be
acquired to support the services.

The following table contains representative configuration management
subsection titles that should be included when applicable to the
candidate solution or acquisition program.

***Representative Configuration Management Subsection Titles***

  ----------------------------------- -----------------------------------
  ***Subsection Title***              ***Description***

  *12.1 Software Configuration        *Software configuration management
  Management*                         requirements should cover source
                                      code, source­code­level programming
                                      instructions of programmable
                                      firmware devices, test procedures,
                                      and test cases.*

  *12.2 Hardware Configuration         
  Management*                         

  *12.3 Facility Configuration         
  Management*                         

  *12.4 Documentation Configuration    
  Management*                         
  ----------------------------------- -----------------------------------

**13. IN-SERVICE MANAGEMENT**

Define requirements for monitoring, assessing, and optimizing the
performance of this capability during the in­service management phase of
the acquisition lifecycle. The objective is to determine whether the new
capability is working as intended in the operational environment, and
whether operational and dollar benefits in the Acquisition Program
Baseline are being achieved. These requirements also relate to
determining the capacity of deployed assets to meet emerging demand for
services so that replacement or upgraded capability can be obtained and
in place when needed.

14\. SYSTEM SAFETY MANAGEMENT ~(Revised\ 07/2001)~

*\[No requirement should be entered into this section of the initial
Requirements Document that is solution-specific or would unduly restrict
the search for solution to the mission need.\]*

*Define high-level safety requirements, which meet the safety goals
determined by the hazard identification process. Include requirements
not related to specific hazards such as those from standards, laws,
regulations, and lessons learned from similar systems.*

**Appendix I. Requirements Correlation Matrix**

Where applicable, specify in the following table a threshold value and
an objective value for each requirement in the Requirements Document.
The threshold value is the minimum performance required for acceptable
operational suitability and effectiveness. The objective value
represents a measurable increase in capability that has practical
operational benefit to the FAA and its customers.

+-------+-------------+-------------+---------------------------------+
| *     | **Re        | **          | **Objective**                   |
| *Sect | quirement** | Threshold** |                                 |
| ion** |             |             |                                 |
|       |             |             |                                 |
| *     |             |             |                                 |
| *\#** |             |             |                                 |
+-------+-------------+-------------+---------------------------------+
|       | *Av         | *.900*      | *.995*                          |
|       | ailability* |             |                                 |
+-------+-------------+-------------+---------------------------------+
|       | *Range*     | *30 miles*  | *40 miles*                      |
+-------+-------------+-------------+---------------------------------+
|       | *           | *5 square   | *2 square meters*               |
|       | Resolution* | meters*     |                                 |
+-------+-------------+-------------+---------------------------------+
|       |             |             |                                 |
+-------+-------------+-------------+---------------------------------+

**Appendix II. Mission Need Correlation Matrix**

Develop a correlation matrix that maps by section number and need
statement where every need in the Mission Need Statement is addressed in
the Requirements Document. Use table format.

  ------------------------------ ------------------------- ---------------------------------------------- --------------------------------
  ***^MNS\ Section\ Number^***   ***^Need\ Statement^***   ***^RD\ Section\ or\ Sub-Section\ Number^***   ***^Requirement\ Statement^***

                                                                                                           
  ------------------------------ ------------------------- ---------------------------------------------- --------------------------------

**Appendix III. Definitions**

**Appendix IV. Acronyms**

**Attachment Residual Technical Requirements**

Specify those final sponsor requirements that are not intended to be
satisfied by the approved acquisition program. Resolution of these
deferred requirements via other Mission Need Statements or product
upgrades is the responsibility of the sponsoring line of business.