**TEMPLATE**

**For the**

**Exhibit 300 Program Baseline**

**Attachment 1: Program Requirements**

**General**

The Program Requirements attachment to the Exhibit 300 Program Baseline
is the primary force driving the search for a realistic and affordable
solution to mission need during investment analysis. The sponsoring line
of business develops a preliminary Program Requirements (pPR) attachment
during the concepts and requirements definition phase, which translates
the \"need\" in a Service-Level Mission Need Statement into preliminary
top-level functional and performance requirements. These preliminary
requirements ***must not*** describe a specific solution to mission
need, and should not preclude leasing, commercial, or non-developmental
alternatives. During investment analysis, these preliminary requirements
are evaluated against the cost, benefits, schedule, and risk of various
alternatives and brought into balance with an affordable solution to
mission need.

The investment analysis team develops a final Program Requirements (fPR)
attachment during final investment analysis, which is approved at the
final investment decision. This attachment defines exactly the
operational concept and requirements an approved investment program is
intended to achieve, and is the basis for evaluating the readiness of
resultant products and services to become fielded for use and
operational within the FAA. Any requirements not in the final Program
Requirements attachment at the final investment decision are returned to
the sponsoring line of business for disposition.

Note that the Program Requirements attachment to the Exhibit 300 Program
Baseline defines the functional and performance requirements an
investment program is intended to satisfy. It is NOT a system
specification and should not contain the detailed level of specification
necessary for that document. The system specification is derived from
the Program Requirements attachment and is included with a Request for
Offers to prospective providers of the capability needed to satisfy
mission need.

EXHIBIT 300, ATTACHMENT 1

**PROGRAM REQUIREMENTS**

for

\[enter name of investment program\]

Change *(#)*

Approved by: *[Signature]{.underline}*           Date:\
Director or Vice President, Service Organization with the mission need

Approved by: *[Signature]{.underline}*           Date:\
Director or Vice President, Operating Service Organization(s)

Note: One Service Organization may have both responsibilities

**Concurrence by: \_\_\_\_\_\_\_\_\_\_\_ Date:**

**Director, Office of Systems Engineering, ATO-P**

**Submitted by: \_\_\_\_\_\_\_\_\_\_\_\_ Date:**

Appropriate official of the preparing organization

# Focal Point

*Name*

*Organizational Code*

*Phone Number*

*FAX Number*

Federal Aviation Administration

800 Independence Avenue SW

Washington, DC 20591

**Exhibit 300, Attachment 1: Program Requirements**

[Table of Contents]{.underline}

1\. BACKGROUND

2\. OPERATIONAL CONCEPT

2.1. Operations

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

2.4. Schedule Constraints

3\. TECHNICAL PERFORMANCE

3.1.Operational and Functional Requirements

3.2. Product Characteristics and Performance Requirements

4\. PHYSICAL INTEGRATION

4.1. Real Property\
4.1.1. Land\
4.1.2. Space\
4.2. RESERVED\
4.3. Environmental\
4.4. Energy Conservation\
4.5. Heating, Ventilation, Air-Conditioning\
4.6. Grounding, Bonding, Shielding, and Lightning Protection\
4.7. Cables\
4.8. Hazardous Materials\
4.9. Power Systems and Commercial Power

4.10 Power and Signal Distribution\
4.11. Telecommunications

4.12 Special Considerations

5\. FUNCTIONAL INTEGRATION

5.1. Integration With Other FAA Enterprise Architecture Elements\
5.2 Information Requirements

5.3. Software Integration

5.4. Spectrum Management

5.5. Standardization

6\. HUMAN INTEGRATION

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

6.4 Federal Accessibility Standards

7\. SECURITY

7.1. Physical Security\
7.2. Information Systems Security\
7.3. Personnel Security

8\. IN-SERVICE SUPPORT

8.1. Staffing Standards Analysis\
8.2. Supply Support\
8.3. Support and Test 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

8.8 Certification of Airway Facility/Air Traffic Personnel

8.9 Service Certification

8.10 Disposal

9\. TEST AND EVALUATION

9.1. Critical Operational Issues\
9.2. Test and Evaluation Requirements

10\. IMPLEMENTATION AND TRANSITION

11\. QUALITY ASSURANCE

12\. CONFIGURATION MANAGEMENT

13\. IN-SERVICE MANAGEMENT

14\. SYSTEM SAFETY MANAGEMENT

Appendix 1. Mission Need Correlation Matrix

Appendix 2: Acronyms

**1. BACKGROUND**

Identify the Service-Level Mission Need Statement addressed by this
Program Requirements attachment 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.
If this is a revision to an approved Program Requirements attachment,
briefly summarize any substantive change since the last approval and
explain why the changes are needed.

**2. OPERATIONAL CONCEPT**

**2.1. Operations**

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 FAA Enterprise 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 the pre­existing operational environment. 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. Note how it will be operated and maintained from a safety
basis. 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**

In the final Program Requirements (fPR) attachment, 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 Business Case Analysis). Include any Congressional mandates.
Congressional mandates imposed on a program after baselining at the
final investment decision may require a baseline change.

**2.4. Schedule Constraints**

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 Enterprise Architecture elements required to achieve full
operational capability. Include Congressional mandates. Congressional
mandates imposed on a program after baselining at the business case
decision may require a baseline change.

**3. TECHNICAL PERFORMANCE**

**3.1. Operational and Functional Requirements**

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 preliminary
Program Requirements (pPR) attachment 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 alternative solutions in the pPR
attachment or the alternative selected by the JRC for implementation in
the fPR attachment.

***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**

In the fPR, 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 for the pPR
attachment 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 alternative solutions in the pPR
attachment or the alternative selected for implementation in the fPR
attachment.

***Representative 3.2 Subsections***

  ------------------------ ----------------------------------------------
  ***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
                           permissible to commercial off-the-shelf
                           hardware products).*
  ------------------------ ----------------------------------------------

**4. PHYSICAL INTEGRATION**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. In many cases, most of these sections for
the pPR attachment will simply identify "N/A."\]

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**

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

4.1.1 Land -- In the fPR attachment define briefly any requirements for
acquiring 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 acquiring
real estate may vary depending on such factors as market conditions,
siting complexities, etc., and should begin soon after the business case
decision and in close coordination with the appropriate region/center
acquiring organization.

For the pPR attachment, to the extent any of the above can be reasonably
identified without placing a constraint on available solutions, it
should be listed.

4.1.2 Space -- In the fPR attachment, define any requirements for
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.

It is unlikely this data will be known in the development of the pPR
attachment.

**4.2 RESERVED**

**4.3. Environmental**

Define requirements to achieve compliance with the National
Environmental Policy Act and other environmental regulations and
standards. Care should be taken to assure that only known requirements
are listed in the pPR attachment, while full requirements are identified
in the fPR attachment.

**4.4. Energy Conservation**

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

**4.5. Heating, Ventilation, Air Conditioning**

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**

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**

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

**4.8. Hazardous Materials**

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

**4.9. Power Systems and Commercial Power**

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**

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

**4.11. Special Considerations**

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**

\[No requirement should be entered into this section of the preliminary
Program Requirements attachment 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 in the Enterprise Architecture.

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

**5.1. Integration With Other FAA Enterprise Architecture Elements**

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 Information Requirements**

Define information requirements associated, including the identification
of existing sources of data and/or the need to collect or create new,
hitherto non-existent data. Define requirements concerning the quality
of service characteristics of or constraints on the information to be
produced or consumed, including accuracy, update frequency, security
(i.e. quality of protection), precision, etc. Define requirements to use
approved data specifications and structures already in use in the
Enterprise Architecture, such as a common flight object or message set,
registered XML schemas, standardized tables of valid values or code
lists, or other standards to facilitate data exchange. Define
requirements related to publishing or disseminating data, including
creation of information about the data products (i.e. metadata), methods
for enabling search and discovery of the data, methods for obtaining the
data, and rules for using the data. Define requirements for archiving
data and data products.

**5.3. 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.4. Spectrum Management**

Define requirements for spectrum management, including certification of
radio spectrum availability. Ensure spectrum compatibility with the rest
of the Enterprise Architecture.

**5.5. Standardization**

Define requirements to use standard products already in use in the
Enterprise Architecture. 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 alternative
solutions in the pPR attachment or the alternative selected for
implementation in the fPR attachment.. Add additional subsections as
needed.

\[No requirement should be entered into this section of the pPR
attachment 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**

**7.1. Physical Security**

Define requirements related to facility security and contractor-unique
security both for end-state operations and during transition to the new
capability. Facility security is concerned with the implementation of
facility measures designed to safeguard personnel; to prevent
unauthorized entry to facilities (access control), property, equipment,
and information; and to safeguard them against sabotage, espionage, and
other criminal or terrorist threats.

**7.2. Information Systems Security**

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 needing
suitability and/or security clearances, security training, or
investigative assistance pertaining to a security incident.

**8. IN-SERVICE SUPPORT**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to the mission need. For the fPR attachment, complete
in-service support requirements are required.\]

In-service support requirements typically do not apply to requirements
for services 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 for 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 operations 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**

**9.1. Critical Operational Issues**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. Typically when the fPR attachment is
prepared, the solution is known, and critical operational issues should
be recorded.\]

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**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. Typically when the fPR attachment is
prepared, the solution is known, and test and evaluation requirements
are required.\]

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
alternative solutions in the pPR attachment or the alternative selected
for implementation in the fPR attachment. ***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**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. Typically when the fPR attachment is
prepared, the solution is known, and implementation and transition
requirements are required.\]

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 requirements related to commissioning into the National
Airspace System*.*

**11. QUALITY ASSURANCE**

\[No requirement should be entered into this section of the pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. Typically when the fPR attachment is
prepared, the solution is known, and quality assurance requirements are
required.\]

Define quality assurance requirements. Examples include contractor
status reporting, 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 pPR
attachment that is solution-specific or would unduly restrict the search
for solutions to mission need. Typically when the fPR attachment is
prepared, the solution is known, and configuration management
requirements are required.\]

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 alternative
solutions in the pPR attachment or the alternative selected for
implementation in the fPR attachment.

***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 management lifecycle. The objective of these
requirements is to determine whether the new capability is working as
intended in the operational environment, and whether operational and
dollar benefits in the Exhibit 300 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

\[Note that different safety risk management documents are required for
the investment analysis readiness decision, initial and final investment
decisions, and in-service decision. Thus, system safety management
requirements may be different for the pPR and fPR attachments.\]

Define requirements for an appropriate system safety program over the
lifecycle of the investment program including system safety analyses and
risk-resolution and tracking processes. The objective of these
requirements is implementation of sufficient system safety analysis and
risk-resolution over the lifecycle of the investment program to ensure
the safety of the National Airspace System, the flying public, and FAA
and contract employees. Detailed guidelines for System Safety Management
are found in the FAA Acquisition System Toolset.

**Appendix. Acronyms**