+--------------------------------+------------+--------+--------------+
|                                | !          | F      |              |
|                                | [](media/i | ederal |              |
|                                | mage1.jpeg | Av     |              |
|                                | ){width="0 | iation |              |
|                                | .999305555 |        |              |
|                                | 5555556in" | Ad     |              |
|                                | height="0. | minist |              |
|                                | 9993055555 | ration |              |
|                                | 555556in"} |        |              |
+--------------------------------+------------+--------+--------------+
|                                |            |        |              |
+--------------------------------+------------+--------+--------------+
|                                |            | Fully  |              |
|                                |            | Rele   |              |
|                                |            | asable |              |
|                                |            |        |              |
|                                |            | POC:   |              |
|                                |            | Kip    |              |
|                                |            | Spurio |              |
|                                |            |        |              |
|                                |            | V      |              |
|                                |            | ersion |              |
|                                |            | 2.0    |              |
|                                |            |        |              |
|                                |            | Sep    |              |
|                                |            | tember |              |
|                                |            | 08,    |              |
|                                |            | 2006   |              |
+--------------------------------+------------+--------+--------------+
| Concept and Requirements       |            |        |              |
| Definition Guidelines          |            |        |              |
|                                |            |        |              |
| Air Traffic Organization       |            |        |              |
|                                |            |        |              |
| Operations Planning Service    |            |        |              |
|                                |            |        |              |
| Systems Engineering            |            |        |              |
|                                |            |        |              |
| NAS Architecture Group         |            |        |              |
+--------------------------------+------------+--------+--------------+

Table of Contents

[1 Introduction 3](#introduction)

[2 Overview of Concept and Requirements Definition
3](#overview-of-concept-and-requirements-definition)

[3 Plan for CRD 5](#plan-for-crd)

[3.1 Develop the CRD Plan 5](#develop-the-crd-plan)

[3.2 Form CRD Team 5](#form-crd-team)

[4 Initiate CRD 6](#initiate-crd)

[5 Conduct Detailed Shortfall Analysis
7](#conduct-detailed-shortfall-analysis)

[6 Analyze Operational Functions 7](#analyze-operational-functions)

[7 Develop Range of Alternatives 8](#develop-range-of-alternatives)

[8 Develop Safety Risk Management Decision Memo
9](#develop-safety-risk-management-decision-memo)

[9 Develop Concept(s) of Use 9](#develop-concepts-of-use)

[10 Develop Preliminary Requirements
10](#develop-preliminary-requirements)

[11 Estimate Rough Order Lifecycle Cost
11](#estimate-rough-order-lifecycle-cost)

[12 Develop Enterprise Architecture Products and Amendments
12](#develop-enterprise-architecture-products-and-amendments)

[13 Conduct Technical Review 12](#conduct-technical-review)

[14 Conduct Financial Review 13](#conduct-financial-review)

[15 Plan for Investment Analysis 13](#plan-for-investment-analysis)

[16 Prepare for Investment Analysis Readiness Decision
13](#prepare-for-investment-analysis-readiness-decision)

[Appendix A: Template for the Concept and Requirements Definition Plan
15](#appendix-a-template-for-the-concept-and-requirements-definition-plan)

[Appendix B: Template for the Shortfall Analysis Report
22](#appendix-b-template-for-the-shortfall-analysis-report)

[Appendix C: Template for the Functional Architecture
27](#appendix-c-template-for-the-functional-architecture)

[Appendix D: Template for the Alternative Descriptions
31](#appendix-d-template-for-the-alternative-descriptions)

[Appendix E: Template for the Investment Analysis Readiness Decision
Briefing
36](#appendix-e-template-for-the-investment-analysis-readiness-decision-briefing)

[Appendix F: Definitions and Acronyms
38](#appendix-f-definitions-and-acronyms)

# Introduction

This document describes the activities of the concept and requirements
definition (CRD) phase of Federal Aviation Administration (FAA) mission
analysis. It will be maintained and hosted on the FAA Acquisition System
Toolset (FAST) website ([http://fast.faa.gov](http://fast.faa.gov/) ).
Revisions and additions will be made periodically to incorporate lessons
learned and process improvements. This document currently represents
only one segment of an overall mission analysis process document that is
planned to be released at a later date.

The guidelines and specific procedures described in this document
generally apply to all FAA organizations seeking an investment decision.
However, the guidelines do not apply to the Airport Improvement Program.
Additionally, initiatives dealing with technologies which are not
commercial off the shelf (COTS) solutions ready for implementation must
follow the appropriate research guidelines before entering into CRD.

CRD is meant to be flexible; and it is recognized that some steps may be
conducted concurrently or iteratively. Under exceptional circumstances,
the FAA Acquisition Executive (FAE) may waive some of the activities.
All lines of business (LOB) must coordinate their CRD activities with
the appropriate systems engineering organization to ensure consistency
with the FAA Enterprise Architecture (EA). The FAA EA defines the
operational and technical framework for all capital assets of the FAA.
It describes the agency's current and target architectures, as well as
the transition strategy for moving from the current to the target
architecture. The EA is approved annually by the Joint Resources Council
(JRC) in support of budget and strategic management processes. The
Office of Operations Planning (ATO-P) Systems Engineering provides
advice on National Airspace System (NAS) Operations EA initiatives and
the Office of Information Services (AIO) provides advice on Mission
Support and Administrative EA initiatives.

# Overview of Concept and Requirements Definition

The CRD phase of mission analysis follows service analysis. Service
analysis is an annual, cyclic process at the service organization level
that first conducts and then keeps current a service-level mission need
assessment (SLMNA). The SLMNA is developed within the context of, and is
incorporated into, the EA. When the EA specifies the need to start a
specific investment opportunity to meet a priority service need, CRD
begins with development and approval of the plan for CRD. CRD is the
start of the lifecycle management process for a specific investment
initiative. The purpose of CRD is to ensure readiness for investment
analysis. Readiness is based on development of sound and measurable
preliminary requirements; a concept of use acceptable to the user; a
viable set of alternatives that would satisfy the need; and the
availability of resources to conduct investment analysis. Figure 2-1
shows the normal set of CRD activities that will be followed for all
proposed investment analyses (except when any type of waiver has been
approved).

The following products are required for initiation of CRD:

-   Approved SLMNA/EA Roadmap

-   FAA EA changes

-   Functional Architecture

-   CRD Plan.

These products are completed during service analysis. See Section 3 for
a description of the CRD Plan.

Due to the breadth and scope of CRD activities, multiple service
organizations may participate in CRD activities and contribute resources
(people and funds) to ensure quality products are produced. The Office
of Operations Planning (ATO-P) Systems Engineering is responsible for
providing oversight and guidance throughout CRD, leading up to an
investment analysis readiness decision (IARD).

The ATO Chief Operating Officer or Associate Administrator (non-ATO) of
the LOB makes the IARD and authorizes entry into investment analysis or
makes other disposition such as returning the need to CRD or directing
research activity to reduce risk. The investment analysis begins
immediately after a successful IARD.

![](media/image1.wmf)

**Figure 2-1. Concept and Requirements Definition**

# Plan for CRD

This section begins to describe CRD activities that lead up to the
investment analysis readiness decision. Two pre-CRD activities must take
place prior to the official start of CRD: (1) a CRD Plan must be
developed and approved; and (2) the CRD Team must be formed. Subsequent
sections of this document describe the activities that occur during CRD.

## Develop the CRD Plan

The ATO-P Systems Engineering organization will work collectively with
the service organization and other organizational elements to develop a
plan for completing CRD activities to achieve proposed or required
deadlines for the investment analysis readiness decision. The CRD Plan
specifies the deliverables, tasks, schedules, organizational roles and
responsibilities, and resources needed to successfully complete CRD.
Specific roles and responsibilities of CRD team members are specified in
the CRD Plan as agreed to by the service organization, ATO-P Systems
Engineering, and affected organizational elements. The Plan will also
include as attachments: definition of any required analyses and a legacy
system description (if applicable). The expected time frame for
completing CRD is two to five months. The ATO Vice President or Director
(non-ATO) of the service organization with the mission need and
operating service organization(s) approve the CRD Plan after
coordination with affected organizations. The CRD Plan is to be
developed in accordance with Section 4.2 of the System Engineering
Manual. Appendix A of this document provides a template for the Plan.

## Form CRD Team

The ATO-P Systems Engineering organization appoints a CRD Team Lead who
is responsible for advising the service organization in developing the
CRD Plan. The CRD Team Lead will identify and obtain commitment of the
requisite team members to facilitate the development of each of the
necessary deliverables to be produced during CRD, monitor and
participate in their development, and ensure that major milestones are
specified in the approved CRD Plan. Table 3-2 identifies generic roles
and responsibilities for each of the deliverables to be produced during
CRD.

Table 3-2. Generic Roles and Responsibilities for CRD Activities

  -------------------------- ---------------------- ---------------------
  **Task**                   **Responsible Lead**   **Participants**

  Plan for CRD               Joint effort between   Office of Information
                             Service Organization & Services (AIO) SE as
                             CRD Team Lead          appropriate

  Initiate CRD               CRD Team Lead          CRD Team

  Conduct Detailed Shortfall Service Organization   ATO-P Strategy and
  Analysis                                          Business Planning
                                                    Organization:
                                                    Operations Research

  Analyze Operational        Service Organization   ATO-P SE: NAS
  Functions                                         Operations Concepts
                                                    and Service
                                                    Engineering / AIO SE

  Develop Range of           Service Organization   ATO-P NAS
  Alternatives                                      Architecture / AIO SE

  Develop Concept(s)of Use   Service Organization   ATO-P SE: NAS
                                                    Operations Concepts
                                                    and Service
                                                    Engineering / AIO SE
                                                    (non-ATO)/ ATO-P
                                                    Human Factors (HF)

  Develop Preliminary        Service Organization   Participating Service
  Requirements                                      Organizations / ATO-P
                                                    SE NAS Requirements
                                                    and Interface
                                                    Management (ATO
                                                    projects)/ AIO SE
                                                    (non-ATO
                                                    projects)/Safety
                                                    Services/ATO-P
                                                    Security
                                                    Advisors/ATO-P HF

  Estimate Rough Order       Service Organization   ATO Finance (ATO-F)
  Lifecycle Costs                                   Investment Planning
                                                    and Analysis

  Develop Enterprise         Service Organization   ATO-P NAS
  Architecture Products and                         Architecture / AIO SE
  Amendments                                        

  Conduct Technical Review   System Engineering     CRD Team
                             Council                

  Conduct Financial Review   ATO-F                  CRD Team

  Plan for Investment        Service Organization   ATO-F Investment
  Analysis                                          Planning and Analysis

  Prepare for IARD           CRD Team               CRD Team
  -------------------------- ---------------------- ---------------------

# Initiate CRD

The CRD Team Lead plans and holds a kick-off meeting. The kick-off
meeting is the official start of the CRD. CRD meeting minutes are
provided to all affected personnel.

**Responsible Agent**: CRD Team Lead.

**Product**: Kick-off meeting; CRD meeting minutes.

**Approving Agent**: NA.

**Supporting Tools and guidance:** CRD Plan[^1]; System Engineering
Manual (SEM) (<http://www.faa.gov/asd/SystemEngineering>).

# Conduct Detailed Shortfall Analysis

The service organization will quantify the priority infrastructure or
service shortfall in the EA and its impact on service capability in
sufficient detail to serve as the basis for determining realistic and
economic alternative solutions to the service need, developing a concept
of use, and defining preliminary program requirements. This detailed
shortfall analysis is also the basis for quantifying likely program
costs and benefits during investment analysis. The service organization
will work with the ATO-P Operations Research (OR) to quantify the
shortfalls. The service organization will work with the ATO Finance
(ATO-F) Investment Planning and Analysis (IP&A) organization to quantify
the shortfall whenever the shortfall analysis involves cost avoidance
and also to refine the legacy case. The information regarding data,
assumptions, and methodology used to generate shortfall estimates, as
well as the legacy case, may be captured in a Shortfall Analysis Report
(SAR). Appendix B provides a template for the SAR.

**Responsible Agent:** Service organization with advice from ATO-P OR
and ATO-F IP&A.

**Product:** SAR; Legacy Case.

**Approving Agent:** Service organization.

**Supporting Tools and Guidance:** SAR Template (See Appendix B).

# Analyze Operational Functions 

The ATO-P SE National Airspace System (NAS) Operations Concepts and
Service Engineering organization completes an analysis of operational
functions during service analysis. During CRD the service organization
will provide a further refinement of the functional analysis that began
in service analysis. The analysis translates user needs and human
performance (capabilities and limitations) into a sequenced and
traceable Functional Architecture. The Functional Architecture captures
the functions and sub-functions necessary to provide the needed service
or operational capability. The approach is to analyze what must be done
without defining specifically how to do it. The Functional Architecture
is the foundation for the Preliminary Program Requirements. The
functional analysis is performed in accordance with Section 4.4 of the
System Engineering Manual (SEM).

The Functional Architecture will be documented for use in investment
analysis.

**Responsible Agent:** Service organization with advice from ATO-P SE
NAS Operations Concepts and Service Engineering.

**Product:** Functional Architecture.

**Approving Agent:** Manager, service organization with concurrence from
Manager, ATO-P SE NAS Operations Concept and Service Engineering or the
FAA EA Chief Architect (for non-NAS initiatives).

**Supporting Tools and Guidance:** Functional Architecture template
(Appendix C); SEM (<http://www.faa.gov/asd/SystemEngineering>).

# Develop Range of Alternatives

The service organization working with the systems engineering and
Research, Engineering, and Development (RE&D) organizations \-- develops
a set of feasible alternatives to resolve the mission shortfall(s).
Alternatives must:

Satisfy the capability shortfall (Alternatives may not meet 100 percent
of preliminary requirements.)

Have a positive impact on FAA performance metrics.

At least one alternative comes from the Enterprise Architecture (EA).
The market place is surveyed to identify additional feasible and
economic alternatives to service need. Both material and non-material
opportunities are evaluated. Key factors to consider are operational
cost efficiencies (particularly those related to telecommunications and
information systems security), technological maturity, and impact on the
EA. Alternatives should be qualitatively different from each other; for
example, airborne-based vs. ground-based, satellite-based vs.
ground-based, traditional system acquisition vs. service acquisition,
etc.; so that maximum creativity, flexibility, and innovation can be
encouraged in developing and evaluating investment proposals.
Operationally suitable commercial or non-developmental solutions are
preferred.

At least three diverse alternative descriptions must be developed to
satisfy the OMB Capital Planning and Investment Control (CPIC)
requirements described in OMB Circular A-11, Part 7. During CRD, these
alternatives will be developed as high-level concepts and will be called
Preliminary Alternative Descriptions. During investment analysis, these
concepts will later be documented as detailed descriptions that provide
the Joint Resources Council (JRC) and cost and benefits estimators with
a complete understanding of what is being proposed.

If necessary, trade studies should be conducted to support the
development of preliminary alternatives. Trade Studies are conducted in
accordance with the System Engineering Manual (SEM)
(<http://www.faa.gov/asd/SystemEngineering> ). Results of the trade
studies are recorded in Trade Study Reports as described in the SEM,
Section 4.6.

A nonmaterial solution that emerges at this point may be implemented
without proceeding further in the lifecycle management process, provided
it satisfies the need, can be achieved within approved budgets, and is
acceptable to the users and customers. This determination is presented
to the appropriate JRC Subordinate Board.

The Preliminary Alternative Descriptions are documented for use in the
initial investment analysis process.

**Responsible Agent:** Service organization.

**Product:** Preliminary Alternative Descriptions; Trade Study
Report(s).

**Approving Agent:** Director of the operating service organization
after concurrence by the appropriate systems engineering organization.

**Supporting Tools and Guidance:** Alternative Descriptions template
(Appendix D); Trade Study Report template in the SEM
(<http://www.faa.gov/asd/SystemEngineering> ); RE&D, FAA Enterprise
Architecture, and systems engineering representative(s).

# Develop Safety Risk Management Decision Memo

ATO Safety Services will guide the operational service unit / LOB to
determine what safety work is required for this initiative. The
resulting plan will be submitted to the chair of the System Safety
Working Group (SSWG) for concurrence. If it is determined that there is
no safety impact to the NAS, the service team will produce a signed
Safety Risk Management (SRM) Decision Memo containing rationale why the
proposed initiative does not impact the safety of the NAS. The SRM
Decision Memo will be presented to the appropriate JRC Subordinate
Investment Review Board as input to the investment analysis readiness
decision.

**Responsible Agent:** Service organization.

**Product:** SRM Decision Memo.

**Approving Agent:** ATO Safety Services Representative, after
concurrence from the SSWG Chair.

**Supporting Tools and Guidance:** ATO Safety Services Representative.

# Develop Concept(s) of Use 

The service organization develops the Concept of Use. The Concept of Use
defines how capabilities will function within the operational
environment or service delivery concept and how the capabilities will
satisfy the service need. It also defines the roles and responsibilities
of key participants (e.g., controllers, operators, and pilots) and key
elements of the required capability. It explains operational issues that
systems engineers must understand to develop requirements, identifies
procedural issues that may lead to operational change, and establishes a
basis for evaluating benefits. The Concept of Use must not be based on a
particular solution to the capability shortfall or mission need.

The Concept of Use focuses on the operation of specific ***components***
of the NAS or LOB system under consideration, and must be consistent
with the NAS or LOB Concept of Operations. The Concept of Use must show
how each new part or component complements, fits into, and harmonizes
with the NAS or LOB Concept of Operations.

The Concept of Use clearly defines needed *functions* and provides the
initial set of performance indicators of the required *performance with
human-in-the-loop*. Therefore, the Concept of Use must be developed
***before*** *operational requirements* are defined.

The Concept of Use specifies how the capability is to be used, and what
in the FAA will be done differently as a result of implementing the new
concept. Specifically, the concept will illustrate how, when, and where
the new approach will improve FAA performance and satisfy ATO or other
LOB metrics.

The Concept of Use identifies *benefit mechanisms* that will be
incorporated into the system design. For example:

"Through improved surveillance detection and greater position accuracy,
allow a 5% increase in the number of aircraft handled safely in each
sector by en route controllers through greater situational awareness of
the entire sector and its boundary conditions."

The Concept of Use is developed in accordance with Section 4.4 of the
System Engineering Manual (SEM). The Concept of Use will be incorporated
in the Preliminary Program Requirements.

**Responsible Agent:** Service organization with advice from the
appropriate systems engineering organization.

**Product:** Concept(s) of Use.

**Approving Agent:** ATO Director or the Division Manager (non-ATO) of
the service organization with the mission need and the ATO Director or
the Division Manager (non-ATO) of the operating service organization
with concurrence from the manager of ATO-P Systems Engineering NAS
Operations Concepts and Service Engineering.

**Supporting Tools and Guidance:** Section 2 of the Preliminary Program
Requirements template ( [http://fast.faa.gov](http://fast.faa.gov/) );
SEM section 4.4, System Level Concept of Operations template (
<http://www.faa.gov/asd/SystemEngineering> ).

# Develop Preliminary Requirements

Requirements definition translates operational needs described in the
service level mission need assessment into Preliminary Program
Requirements. This defines the capability or service required by the
agency. It is imperative that key functional disciplines such as safety,
security, and human factors participate in the activities of CRD in
order to determine mandatory requirements and evaluate their impact on
potential alternative solutions.

Preliminary requirements should specify:

What functions the new capability must perform

How well the new capability must perform these intended functions

What interfaces it must have with related systems, facilities, and
users.

Research and analysis, simulation, modeling, prototyping, or full-scale
development may be necessary to fully identify the acceptable and
achievable range of requirements. At this early stage, an in-depth
requirements document is neither necessary nor desirable. Instead,
provide a relatively high-level summary statement to describe the major
functions and performance the new capability must deliver. Also, address
any major constraints (e.g., latest acceptable operational readiness
date) that must be satisfied.

Preliminary requirements must *not* be written so that they constrain
the answer to a single solution. Instead, they should specify
functional, performance, and interface requirements in a way that
permits several alternative solutions to be evaluated. Preliminary
requirements are to be developed in accordance with Section 4.3 of the
System Engineering Manual (SEM).

Preliminary requirements specify performance parameters of the new
capability. Care must be taken to specify only function and performance
and *not* define a specific solution. Express preliminary requirements
such that performance values can be defined for measuring and evaluating
the degree to which a particular solution satisfies the functional
requirements.

Key performance parameters (KPP) are those relatively few (perhaps five
to six) most important performance characteristics of the Preliminary
Program Requirements set that are crucial to its operational or economic
value. The KPP requirements should be expressed ("scaleable") such that
the degree to which different solutions satisfy them can be measured.

**Responsible Agent:** Service organizations, corporate mission and
requirements analysis organizations, and ATO-P NAS Requirements and
Interface Management.

**Product:** Preliminary Program Requirements.

**Approving Agent:** ATO Vice President or the Director (non-ATO) of the
service organization with the mission need and the ATO Vice President or
the Director (non-ATO) of the operating service organization.
Concurrence by Director ATO-P Systems Engineering.

**Supporting Tools and Guidance:** Preliminary Program Requirements
template ([http://fast.faa.gov](http://fast.faa.gov/) ); SEM (
<http://www.faa.gov/asd/SystemEngineering> ).

# Estimate Rough Order Lifecycle Cost 

A rough order of magnitude (ROM) lifecycle cost estimate for each
alternative is developed. The service organization develops the ROM cost
estimate using standard ATO-F cost estimating techniques. The service
organization will use the Preliminary Alternative Descriptions as the
main basis for computing estimated costs. The Technical Alternative
Descriptions will be produced during investment analysis and will
provide the information needed for developing a detailed cost estimate.

**Responsible Agent:** Service organization with advice from ATO-F
Investment planning and Analysis (IP&A).

**Product**: ROM Lifecycle Cost Estimate for each alternative solution.

**Approving** **Agent:** Director, service organization with the mission
need.

**Supporting Tools and Guidance**: FAA Investment Analysis Standards and
Guidelines (cost estimation).

#  Develop Enterprise Architecture Products and Amendments

Service organizations work with the appropriate systems engineering
organization to define Enterprise Architecture (EA) products and
amendments. For NAS Operations initiatives, the EA products and
amendments include the Operational (business rule) and Systems
(engineering) View families. These families facilitate development,
support, and execution of both service and infrastructure investment
programs. The Administrative and Mission Support initiatives use the
Federal Enterprise Architecture Framework (FEAF). For non-NAS
initiatives, the operational view is split between the business process,
application, and data views. The systems view in the FEAF is specified
in the technical view. The service organization will submit NAS EA
products and amendments to the NAS EA Board (EAB) through the NAS Chief
Architect. The EAB will review the products for consistency with the EA.
After review, the EAB will work with the service organization to update
the NAS EA Products or forward the EA products to the Vice President,
Operations Planning for approval. The service organization will present
Mission Support and Administrative products and amendments to the
Architecture Review Board (ARB) through the FAA EA Chief Architect.

**Responsible Agent:** Service organization with advice from the
appropriate systems engineering organization.

**Product**: Enterprise Architecture products and amendments.

**Approving** **Agent:** ATO-P Vice President approves NAS EA products
and amendments after concurrence by the Director of the Service
Organization and the EAB. The CIO approves Mission Support and
Administrative Architecture products and amendments after concurrence by
the ARB and FAA EA Chief Architect.

**Supporting Tools and Guidance**: Consultation with CRD Team Lead and
FAA EA Chief Architect for guidance; FAA Enterprise Architecture.

# Conduct Technical Review

For key initiatives, the System Engineering Council (SEC) will review
specific CRD products for maturity and readiness for investment
analysis. These may include, but are not limited to, the Preliminary
Alternative Descriptions, Concept (s) of Use, Preliminary Program
Requirements and Enterprise Architecture products and amendments. Based
on the results of the reviews, the SEC may update the products or
recommend updates to the products as necessary for entry into investment
analysis. The SEC will provide a statement as to whether the products
are mature enough for investment analysis or what needs to be done to
make the products mature enough. The information will be used as input
to JRC Subordinate Investment Review Board decision-making. The SEC will
include appropriate stakeholders in its reviews.

**Responsible Agent:** Director, ATO-P Systems Engineering.

**Product:** Statement of readiness for technical products; CRD
technical product updates; recommendations for CRD technical product
updates.

**Approving Agent:** ATO-P Vice President.

**Supporting Tools and Guidance:** SEC; System Engineering Manual

(<http://www.faa.gov/asd/SystemEngineering> ).

# Conduct Financial Review

ATO-F will conduct quality reviews of the rough order of magnitude (ROM)
cost estimates of the proposed investment. The ROM cost estimates may be
updated to accommodate any recommendations from the quality reviews.

**Responsible Agent**: ATO-F.

**Product**: Approval of ROM cost estimate methodology.

**Approving Agent**: ATO-F Investment Planning and Analysis (IP&A).

**Supporting tools and guidance**: ATO-F IP&A.

# Plan for Investment Analysis

The service organization develops the Initial Investment Analysis Plan
(IAP), with assistance from ATO Finance (ATO-F), as the final step prior
to the IARD. The plan for investment analysis: (1) defines scope and
assumptions; (2) defines alternatives and rough-order lifecycle cost
estimates; (3) defines organizational roles and responsibilities, (4)
specifies a target schedule, and (5) estimates resources needed for the
work. By signing the plan for investment analysis, the organizations
that will conduct the analysis agree to provide the resources necessary
to complete the work.

**Responsible Agent**: Service organization with advice from ATO-F.

**Product:** Initial IAP.

**Approving Agent**: ATO Vice President or Director (non-ATO) of the
service organization.

**Supporting Tools And Guidance**: Initial IAP template
(<http://fast.faa.gov/investment/iarapp-a.htm>).

# Prepare for Investment Analysis Readiness Decision 

The investment analysis readiness decision (IARD) Brief is presented to
the JRC Subordinate Investment Review Board. The CRD Team will assemble
all of the material needed to assess the readiness for proceeding into
investment analysis. When consensus is reached to proceed, a briefing is
prepared and presented by the service organization to the appropriate
JRC Subordinate Investment Review Board.

The IARD entrance criteria are:

Preliminary Program Requirements

Enterprise Architecture products and amendments

Signed Initial Investment Analysis Plan

Safety Risk Management Decision Memo (if applicable).

**Responsible Agent:** Service organization.

**Product:** Briefing package to the JRC Subordinate Board.

**Approving Agent:** CRD Team / Service organization.

**Supporting Tools And Guidance:** IARD Briefing template
(<http://employees.faa.gov/worktools/branding_guidelines/powerpoint/>
and Appendix E).

#  {#section .unnumbered}

#  {#section-1 .unnumbered}

#  {#section-2 .unnumbered}

#  {#section-3 .unnumbered}

#  {#section-4 .unnumbered}

#  {#section-5 .unnumbered}

#  {#section-6 .unnumbered}

#  {#section-7 .unnumbered}

#  {#section-8 .unnumbered}

#  {#section-9 .unnumbered}

#  {#section-10 .unnumbered}

#  {#section-11 .unnumbered}

#  {#section-12 .unnumbered}

#  {#section-13 .unnumbered}

# Appendix A: Template for the Concept and Requirements Definition Plan  {#appendix-a-template-for-the-concept-and-requirements-definition-plan .unnumbered}

# 

+-----------------------------------+-----------+-----------------+---+
|                                   | ![](me    | Federal         |   |
|                                   | dia/image | Aviation        |   |
|                                   | 1.jpeg){w |                 |   |
|                                   | idth="0.9 | Administration  |   |
|                                   | 993055555 |                 |   |
|                                   | 555556in" |                 |   |
|                                   | hei       |                 |   |
|                                   | ght="0.99 |                 |   |
|                                   | 930555555 |                 |   |
|                                   | 55556in"} |                 |   |
+-----------------------------------+-----------+-----------------+---+
|                                   |           |                 |   |
+-----------------------------------+-----------+-----------------+---+
|                                   |           | Fully           |   |
|                                   |           | Releasable      |   |
|                                   |           |                 |   |
|                                   |           | Version x.x     |   |
|                                   |           |                 |   |
|                                   |           | Date            |   |
+-----------------------------------+-----------+-----------------+---+
| Concept and Requirements          |           |                 |   |
| Definition Plan for the (name of  |           |                 |   |
| proposed investment initiative)   |           |                 |   |
|                                   |           |                 |   |
| Line of Business                  |           |                 |   |
|                                   |           |                 |   |
| (Name of) Service Organization    |           |                 |   |
|                                   |           |                 |   |
| (Name of) Service Office          |           |                 |   |
|                                   |           |                 |   |
| Approved By:                      |           |                 |   |
|                                   |           |                 |   |
| \                                 |           |                 |   |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |           |                 |   |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |           |                 |   |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_Date |           |                 |   |
| \_\_\_\_\_\_\_                    |           |                 |   |
|                                   |           |                 |   |
| ATO Vice President or Director    |           |                 |   |
| (non-ATO)                         |           |                 |   |
|                                   |           |                 |   |
| of the Service Organization with  |           |                 |   |
| the mission need and the          |           |                 |   |
| Operating Service Organizations   |           |                 |   |
+-----------------------------------+-----------+-----------------+---+

#   {#section-15 .unnumbered}

#  {#section-16 .unnumbered}

**Concept and Requirements Definition Plan**

**for**

**(Proposed service/infrastructure initiative(s))**

This Plan specifies the scope, assumptions, constraints, methods, data
sources, resources, control strategy, team composition, roles and
responsibilities, schedule, and deliverables for a proposed concept and
requirements definition (CRD) activity that addresses a priority service
need within the Service-Level Mission Need Assessment/Enterprise
Architecture and develops the information necessary for an investment
analysis readiness decision (IARD).

**Scope:** Identify the specific capabilities or components of the
Service-Level Mission Need Assessment that will be examined. Define how
these capabilities or components fit into the overall service delivery
strategy of your service organization.

**Assumptions, Constraints, and Guidance**: State the key assumptions,
constraints, and guidance that will govern the CRD Team as they conduct
CRD activities. These *[may]{.underline}* include:

The quantified capability shortfall that will be addressed

The remaining service life of the existing capability

The required operational date of any needed new or replacement
capability

Any component of the proposed new capability that has a higher priority
for early delivery than the entire capability

The required mission life or economic service life of the proposed new
capability

The proposed date for the IARD---date by which all CRD activity must be
complete with findings and recommendations presented to the appropriate
decision board (Executive Council (EC) for Air Traffic Organization
(ATO); Information Technology Executive Board (ITEB), which reviews and
recommends investments related to FAA administrative and some mission
support services; and the lines of business (LOB) review boards that
review and recommend investments within a LOB

Any design cost, unit acquisition cost, Operations cost, or any other
economic goal that must be satisfied by the new or replacement
capability (e.g., "Unit initial acquisition cost must be less than \$2
Million.")

Any LOB performance goal that must be satisfied by the new or
replacement capability (e.g., "Reduce cost per flight by 1%.")

Any milestone constraint (i.e., external influences) that must be
satisfied by the new or replacement capability

Any human resource constraints on staffing levels, training time,
personnel abilities or attributes ,or human-system performance data.

Any constraints on the choice of an alternative (e.g., "No alternative
may be developed that will require the mandatory carriage of new
avionics by the airlines and other National Airspace System (NAS)
users.")

Any policy guidance that influences, constrains, or dictates the choice
of a new or replacement capability or operational requirement

Any interdependencies with other new, existing, or proposed Federal
Aviation Administration assets that must be satisfied (e.g., "Delivery
of new digital Airport Surveillance Radar-11 radars must be completed
prior to installation of new digital Standard Terminal Automation
Replacement Systems.")

Any NAS safety issues that influence, constrain, or dictate the choice
of a new or replacement capability

Any required safety risk acceptance and safety risk management
documentation.

**Methods:** Define methods and techniques to be used in each CRD
activity and task.

**Data Sources:** Define the data sources that will be used for each CRD
activity.

**Resources Required:** Identify the resources and respective costs
needed to complete CRD activities. For example: team members, required
skill levels, level of effort, level of contract support needed,
consultants needed, and travel, training, or technology (software or
hardware) required.

**CRD Team Composition:** Define the CRD Team composition alphabetically
by name and affiliated FAA organization. Acquisition Management System
policy designates ATO Operations Planning (ATO-P) Systems Engineering as
lead.

**Roles and Responsibilities:** Define the roles and responsibilities of
each team member for each CRD activity and deliverable. Attachment 1
provides boilerplate material for this section.

**Control Strategy:** Describe the control strategy that will be used by
the CRD Team Lead to ensure timely delivery of quality CRD products to
the JRC Subordinate Investment Review Board. Discuss how commitment to
these activities will be obtained (e.g., through a request for
participation, memorandum for action or of understanding, letter of
agreement, bargaining negotiations, or management coordination).

**Deliverables:** List and describe all deliverables; and provide the
required completion date for each. At a minimum, CRD deliverables shall
include a Preliminary Program Requirements document; a Concept of Use;
Functional Architecture; a description of the preliminary alternatives;
a rough estimate of lifecycle cost for each alternative; Safety Risk
Management Decision Memo (if applicable); and Investment Analysis Plan.

Attachment 1

CRD Roles and Responsibilities

There are many program and service organization members, as well as
support contractors, that make up an effective CRD team. The roles and
responsibilities of team members generally fall into four categories,
which are addressed here. They include the CRD Team Lead, CRD Sub-Team
Lead, Subject Matter Expert (SME), and service organization project
manager or point of contact. A team member may assume one or more of
these roles.

**CRD Team Lead**

ATO-P Systems Engineering is responsible for providing oversight and
guidance throughout the CRD phase. The CRD Team Lead, appointed by
ATO-P, performs quality assurance functions to ensure the CRD plan is
implemented and the expectations of all deliverables are met. In
addition, the Lead manages the team process. This leadership and
management is accomplished by (1) acting as an information hub, (2)
bringing the different units and elements together within ATO-P and
other organizations for synergistic purposes of completion, and (3)
driving the process for establishing schedules in conjunction with other
SMEs and program stakeholders.

As the information hub, the CRD Team Lead maintains insight into the
status of all deliverables. The Lead is proactive in evaluating
collaborative feedback from team members; scheduling and attending
meetings; and maintaining records on activities, issues, and deliverable
status. By openly soliciting information, the Lead identifies area/team
issues or concerns as they emerge. The Lead seeks resolution to keep the
process moving forward and on track in accordance with the CRD Plan. In
addition, the Lead keeps the Management informed through regularly
scheduled progress reports.

The CRD Team Lead creates a synergistic team environment by promoting
and reinforcing cohesion and commitment to complete the products and
tasks. This individual drives the process by establishing and fostering
teamwork and facilitating consensus through agreed to performance
metrics.

**Sub-Team Lead**

Sub-teams may be established for each deliverable produced in CRD.
Sub-Team Leads will be appointed and may be responsible for leading one
or more sub-teams. These individuals are expected to perform quality
assurance functions to ensure the intents of their respective
deliverables are achieved. In addition, they are responsible for keeping
the Team Lead informed of progress and issues.

**Subject Matter Experts (SMEs)**

The SMEs from ATO-P, ATO Finance (ATO-F), Office of Information
Services, or other organizations may act as consultants and advisors to
the LOBs or service organizations or may develop information and data to
satisfy the investment analysis readiness decision criteria. They are
responsible for ensuring the completion of respective products of the
CRD phase by not only serving as experts and remaining engaged, but also
providing direction and vision to completing the task at hand. SMEs are
a resource for helping the team complete the designated product.

**Line of Business/Service Organization Point of Contact (POC)**

The POC may hold the title of project manager or program lead for the
investment opportunity. This individual is responsible for the
coordination of resources within the LOB/service organization. This
individual also serves as part of the communication hub interacting with
the ATO-P CRD Team Lead, Sub-Team Leads, and SMEs in establishing and
meeting timelines, producing deliverables, and coordinating CRD
activities within the LOB/service organization.

**Line of Business/Service Organization Technical Representative**

This Technical Representative is responsible for supporting the
development and coordination of technical products whether developed by
the service organization or other organizations. This individual must
have knowledge about the current system/capability, if applicable, and
requirements for any future capabilities needed to address the mission
need or performance shortfall.

#  {#section-17 .unnumbered}

#  {#section-18 .unnumbered}

#  {#section-19 .unnumbered}

#  {#section-20 .unnumbered}

#  {#section-21 .unnumbered}

#  {#section-22 .unnumbered}

#  {#section-23 .unnumbered}

#  {#section-24 .unnumbered}

#  {#section-25 .unnumbered}

#  {#section-26 .unnumbered}

#  {#section-27 .unnumbered}

#  {#section-28 .unnumbered}

#  {#section-29 .unnumbered}

#  {#section-30 .unnumbered}

# Appendix B: Template for the Shortfall Analysis Report {#appendix-b-template-for-the-shortfall-analysis-report .unnumbered}

+-----------------------------------+-----------+----------------+---+
|                                   | ![](me    | Federal        |   |
|                                   | dia/image | Aviation       |   |
|                                   | 1.jpeg){w |                |   |
|                                   | idth="0.9 | Administration |   |
|                                   | 993055555 |                |   |
|                                   | 555556in" |                |   |
|                                   | hei       |                |   |
|                                   | ght="0.99 |                |   |
|                                   | 930555555 |                |   |
|                                   | 55556in"} |                |   |
+-----------------------------------+-----------+----------------+---+
|                                   |           |                |   |
+-----------------------------------+-----------+----------------+---+
|                                   |           | Fully          |   |
|                                   |           | Releasable     |   |
|                                   |           |                |   |
|                                   |           | Version x.x    |   |
|                                   |           |                |   |
|                                   |           | Date           |   |
+-----------------------------------+-----------+----------------+---+
| Shortfall Analysis Report         |           |                |   |
|                                   |           |                |   |
| Line of Business                  |           |                |   |
|                                   |           |                |   |
| Service Organization              |           |                |   |
|                                   |           |                |   |
| Service Office or Division        |           |                |   |
|                                   |           |                |   |
| Service Group or Branch           |           |                |   |
|                                   |           |                |   |
| Approved By:                      |           |                |   |
|                                   |           |                |   |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  |           |                |   |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ |           |                |   |
| _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |           |                |   |
| Date \_\_\_\_\_\_\_\_\_\_\_\_\_   |           |                |   |
|                                   |           |                |   |
| Service Organization with the     |           |                |   |
| mission need                      |           |                |   |
+-----------------------------------+-----------+----------------+---+

**Shortfall Analysis Report for (name of initiative)**

**Purpose:** The service organization is required to identify shortfalls
and quantify their impacts to support the mission need decision. This
work requires research and analysis. This document provides the
requirements and guidelines to capture the details of this research and
analysis.

**Description:** This document is completed for all initiatives. It
captures all of the detailed information regarding the data,
assumptions, and methodology used to generate the shortfall estimates.
This shortfall document can also point out anticipated analytical
challenges that would be helpful to the business case analysis after the
mission need decision.

Comprehensive documentation is essential for future validation,
verification, and accuracy of the estimate. Detailed documentation also
provides important methodological guidance for future benefit estimates.
The shortfall analysis report should explain how and what was done to
generate the shortfall estimate. The major elements of a sound
capability shortfall document should include the following sections:

1)  **Introduction**

> *Historical background of the **initiative:** Explain the
> **initiative**, including a brief technical description.*
>
> *Describe the scope of the analysis: List and explain shortfall
> categories. First, list all possible service gaps and explain how and
> why this situation could theoretically lead to a service shortfall.
> Select a subset of these categories for quantification. That is, in
> the service analysis stage, quantify categories that will be enough to
> justify the program and support the mission need decision. Select
> categories that have accessible data and are anticipated to be the
> main drivers of the shortfall. Analyze these selected categories, some
> of which may yield low estimates*
>
> *List the participants involved.*

2)  **Ground Rules and Assumptions**

> *List and explain all general assumptions that apply to all shortfall
> categories.*
>
> *Define all specific assumptions that apply to certain shortfall
> categories. This may include very detailed explanations and/or
> justifications for specific assumptions. Supply data used for the
> assumptions and explain the methodology implemented to develop these
> assumptions. This explanation should include any reference or source
> material.*

3)  **Data Inputs**

> *In the narrative data inputs section, the quality of the data used
> should be discussed and evaluated. Any corrective procedures or
> adjustments to the data, including the rationale for the adjustment
> should also be provided.*
>
> *If the shortfall analysis involves costs, include quantities, unit
> costs, schedules, inflation and discount rates used, and other cost
> parameters.*
>
> *This section would also include the use of previous analyses and/or
> studies on benefits estimation. Protocol for data inputs citations and
> referencing also applies to the use of previous analyses and/or
> studies.*
>
> *Input data should also identify those shortfalls of previous analysis
> which have already been addressed as well as those which have to be
> addressed in the horizon year of the shortfall.*

4)  **Measures Chosen**

> *All benefits should be listed and then organized into general
> benefits/measures groupings. Assistance may be found by reviewing the
> connection between the benefits and the Benefits Breakdown Structure.
> Explanations and justifications for the measures chosen and how they
> will be measured should be included.*

5)  **Description of Methodology**

> *Overview of methodology should clearly explain what was done and how
> it was done in a step-wise chronological progression.*
>
> *All diagrams and tables depicting the methodology should have
> citations and headings describing their contents.*
>
> *Models used in the estimation process should be identified and
> described in detail, including how they operate, input assumptions,
> known weaknesses, and outputs. References should also be provided.
> Describe any risk analyses and adjustments that were done.*
>
> *If the shortfall analysis involves cost, provide basis of estimate
> document by FAA WBS element in the format contained in "Documentation
> Guidance for FAA Cost Estimates."*

6)  **Results**

> *Report the shortfall estimate and display it in appropriate tables
> and graphs. Include any explanation that might be helpful to the
> service team.*

7)  **Qualitative Shortfalls (non-quantified, enabling, and quantified,
    non-monetized)**

> *Due to expediency, these shortfall categories are treated in a
> qualitative fashion.*
>
> *Discuss why these were not quantified---lack of available data, would
> require too much work, anticipated small shortfall, etc.*

8)  **Future Work/Next Steps**

> *Helpful hints or challenges to overcome in concept and requirements
> definition.*
>
> *Comments on how a more accurate analysis can be conducted during
> concept and requirements definition, as required, than was done in
> service analysis.*

*Summary of shortfall categories that were not pursued in the service
analysis phase, but probably should be considered in concept and
requirements definition.*

#  {#section-31 .unnumbered}

#  {#section-32 .unnumbered}

#  {#section-33 .unnumbered}

#  {#section-34 .unnumbered}

#  {#section-35 .unnumbered}

#  {#section-36 .unnumbered}

#  {#section-37 .unnumbered}

#  {#section-38 .unnumbered}

#  {#section-39 .unnumbered}

#  {#section-40 .unnumbered}

#  {#section-41 .unnumbered}

# Appendix C: Template for the Functional Architecture {#appendix-c-template-for-the-functional-architecture .unnumbered}

########  {#section-42 .unnumbered}

####  {#section-43 .unnumbered}

+--------------------------------+------------+-----------------+-----+
|                                | !          | Federal         |     |
|                                | [](media/i | Aviation        |     |
|                                | mage1.jpeg |                 |     |
|                                | ){width="0 | Administration  |     |
|                                | .999305555 |                 |     |
|                                | 5555556in" |                 |     |
|                                | height="0. |                 |     |
|                                | 9993055555 |                 |     |
|                                | 555556in"} |                 |     |
+--------------------------------+------------+-----------------+-----+
|                                |            |                 |     |
+--------------------------------+------------+-----------------+-----+
|                                |            | Fully           |     |
|                                |            | Releasable      |     |
|                                |            |                 |     |
|                                |            | Version x.x     |     |
|                                |            |                 |     |
|                                |            | Date            |     |
+--------------------------------+------------+-----------------+-----+
| Functional Architecture for    |            |                 |     |
| the (name of proposed          |            |                 |     |
| investment initiative)         |            |                 |     |
|                                |            |                 |     |
| Air Traffic Organization       |            |                 |     |
|                                |            |                 |     |
| Operations Planning Service    |            |                 |     |
|                                |            |                 |     |
| Systems Engineering            |            |                 |     |
|                                |            |                 |     |
| NAS Operations Concepts and    |            |                 |     |
| Service Engineering            |            |                 |     |
|                                |            |                 |     |
| Approved By:                   |            |                 |     |
|                                |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_         |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                 |     |
| Date\_\_\_\_\_\_\_\_\_\_       |            |                 |     |
|                                |            |                 |     |
| Director of Organization with  |            |                 |     |
| Mission Need                   |            |                 |     |
|                                |            |                 |     |
| Concurred By:                  |            |                 |     |
|                                |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_         |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                 |     |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                 |     |
| Date \_\_\_\_\_\_\_\_\_        |            |                 |     |
|                                |            |                 |     |
| Manager, NAS Operations        |            |                 |     |
| Concepts and                   |            |                 |     |
|                                |            |                 |     |
| Service Engineering, Systems   |            |                 |     |
| Engineering,                   |            |                 |     |
|                                |            |                 |     |
| Operations Planning Service,   |            |                 |     |
| Air Traffic Organization       |            |                 |     |
+--------------------------------+------------+-----------------+-----+

**Functional Architecture for the (proposed initiative)**

**Purpose:** Functional analysis translates user needs and human
performance (capabilities and limitations) into a sequenced and
traceable functional architecture that captures the functions and
sub-functions necessary to provide the needed service or operational
capability. The approach is to analyze what must be done without
defining how to do it. The output is a Functional Architecture, which is
the primary foundation for defining requirements and physical
architectures, in accordance with the FAA Enterprise Architecture.

The functional architecture presents a function list to the requirements
management systems engineering process for analysis and development of
requirements.

**Content:** The general content of a Functional Architecture
description includes:

**Functional Analysis:** Describe how top-level functions were
decomposed to lower-level functions. Define and depict functional
interface.

> ***Functional Architecture**:* Assemble and integrate all of the
> foregoing into a complete Functional Architecture. The Systems
> Engineering Manual (SEM), <http://www.faa.gov/asd/SystemEngineering>
> ), Section 4.4, should be consulted for the format and process for
> developing a Functional Architecture.

**Inputs:** Inputs to a functional analysis vary depending upon the
scope of a given functional analysis effort and iteration of the
process. Section 4.4 of the SEM provides information regarding generic
inputs to functional analysis.

#  {#section-44 .unnumbered}

#  {#section-45 .unnumbered}

#  {#section-46 .unnumbered}

#  {#section-47 .unnumbered}

#  {#section-48 .unnumbered}

#  {#section-49 .unnumbered}

#  {#section-50 .unnumbered}

#  {#section-51 .unnumbered}

#  {#section-52 .unnumbered}

#  {#section-53 .unnumbered}

#  {#section-54 .unnumbered}

#  {#section-55 .unnumbered}

#  {#section-56 .unnumbered}

#  {#section-57 .unnumbered}

#  {#section-58 .unnumbered}

#  {#section-59 .unnumbered}

#  {#section-60 .unnumbered}

# Appendix D: Template for the Alternative Descriptions  {#appendix-d-template-for-the-alternative-descriptions .unnumbered}

+--------------------------------+------------+------------------+----+
|                                | !          | Federal Aviation |    |
|                                | [](media/i |                  |    |
|                                | mage1.jpeg | Administration   |    |
|                                | ){width="0 |                  |    |
|                                | .999305555 |                  |    |
|                                | 5555556in" |                  |    |
|                                | height="0. |                  |    |
|                                | 9993055555 |                  |    |
|                                | 555556in"} |                  |    |
+--------------------------------+------------+------------------+----+
|                                |            |                  |    |
+--------------------------------+------------+------------------+----+
|                                |            | Fully Releasable |    |
|                                |            |                  |    |
|                                |            | Version x.x      |    |
|                                |            |                  |    |
|                                |            | Date             |    |
+--------------------------------+------------+------------------+----+
| Alternative Descriptions for   |            |                  |    |
| the (proposed investment       |            |                  |    |
| initiative)                    |            |                  |    |
|                                |            |                  |    |
| Line of Business               |            |                  |    |
|                                |            |                  |    |
| Service Organization           |            |                  |    |
|                                |            |                  |    |
| Service Office                 |            |                  |    |
|                                |            |                  |    |
| Approved By:                   |            |                  |    |
|                                |            |                  |    |
| \_                             |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                  |    |
| Date                           |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_   |            |                  |    |
|                                |            |                  |    |
| ATO Director or Division       |            |                  |    |
| Manager (non-ATO)              |            |                  |    |
|                                |            |                  |    |
| (Service Organization with the |            |                  |    |
| mission need)                  |            |                  |    |
|                                |            |                  |    |
| Concurred By:                  |            |                  |    |
|                                |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_       |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ |            |                  |    |
| \_\_\_ Date                    |            |                  |    |
| \_\_\_\_\_\_\_\_\_\_\_\_\_\_   |            |                  |    |
|                                |            |                  |    |
| Manager, (Appropriate Systems  |            |                  |    |
| Engineering Organization)      |            |                  |    |
+--------------------------------+------------+------------------+----+

**Alternative Descriptions for the (proposed investment initiative)**

**Purpose:** This document provides Federal Aviation Administration
(FAA) Executives engaged in making investment decisions with a basic
understanding of each alternative solution being proposed to meet a
mission or service need. It provides the technical basis for estimating
lifecycle costs and facilitating the estimation of benefits. During
concept and requirements definition, it supports estimating costs to a
rough order of magnitude (ROM)[^2]. During initial investment analysis
phases, this document describes each alternative in sufficient technical
and programmatic detail so that it can support accurate cost and
benefits estimates. This is a "living document," which is updated for
major reviews and decision points.

**Constraints:** At least three alternatives are necessary to satisfy
the Office of Management and Budget (OMB) Capital Planning and
Investment Control (CPIC) requirements described in OMB Circular A-11.
In concept and requirements definition, these alternatives will be
developed as high-level concepts and will be called Preliminary
Alternative Descriptions. During initial investment analysis, these
concepts will later be documented as detailed descriptions that provide
the Joint Resources Council (JRC) and cost and benefits estimators with
a complete understanding of what is being proposed.

Alternatives should be qualitatively different from each other (e.g.,
airborne-based vs. ground-based, satellite-based vs. ground-based,
traditional system acquisition vs. service acquisition, etc.) so that
maximum creativity, flexibility, and innovation can be encouraged in
developing and evaluating investment proposals. Each proposed
alternative must be capable of meeting any design-to-cost goals or unit
cost goals.

The alternatives must:

Satisfy the capability shortfall (alternatives may not meet 100% of
requirements)

Have a positive impact on FAA performance measures

Contain a quantitative and narrative description, including the
technical, physical, and performance features pertinent to costing the
alternative and quantifying the benefits

Describe all efforts and impacts associated with an alternative
regardless of the funding source or performing organization (e.g.,
staffing, training, infrastructure).

**Responsibilities:** The service organization; working with the
sponsor, appropriate systems engineering organization, and Research,
Engineering, and Development (R,E&D) organization; develops the set of
alternative concepts to resolve the service shortfall.

**Alternatives:** Describe each alternative. Include descriptions of the
Reference Case. The Reference Case (current capability or legacy case)
may assume a modest level of sustainment (e.g., buy-out of spare parts
and line replacement units) to extend service life as much as feasible,
but it should not assume significant levels of investment, such as a
service life extension program would require.

**Content:** Costs are estimated according to how closely the proposed
new capability matches an existing capability whose actual costs are
known. This is called *analogous estimation*. To facilitate analogous
cost estimation, write the Alternative Descriptions in a way that
facilitates cost estimation. Include reasonable assumptions and
analogies of any new capability's similarities to and differences from
existing systems, in cases in which specific information on a proposed
capability is not available. Describe an existing or under-development
capability that is reasonably similar in function, size, or complexity
to the proposed capability. Describe any current operational product(s)
that is similar in nature and performance (e.g., same functions, same
size) to this proposed alternative. Summarize the similarities and
differences between the analogous products and this alternative.

Highlight technical, operational, and programmatic similarities and
differences that drive cost differences among alternatives and are
relevant to their costing (e.g., different acquisition strategy, such as
competitive down-select or sole source from the outset). Include the
following information for each alternative:

**Product Overview**: Describe the product and its key performance
parameters, as well as a diagram or concept drawing with major segments,
parts, and sub-elements.

**Characteristics**: Briefly describe prime mission equipment
facilities, hardware and software; the discussion should follow the
elements in the FAA standard Work Breakdown Structure. Describe the
principal physical and functional features of the proposed new
capability, as compared to the analogous capability. These include:

-   New hardware: Describe required equipment types and quantities. If
    not known specifically, then identify generically and explain how
    the planned capability differs from the analogous capability.

-   New software: State the number of Source Lines of Code or Function
    Points; if not known, estimate the size relative to the analogous
    system (e.g., "50% larger"). Identify the expected software language
    to be used.

-   Facilities Requirements: Describe any new facilities or major
    modifications to existing facilities needed to support the
    development, production, or deployment of the alternative. If a new
    facility will be needed, state its relative size in square feet and
    where it will be located. For each facility type (Air Route Traffic
    Control Center, Terminal Radar Approach Control facility, Air
    Traffic Control Tower, Air Traffic Control System Command Center,
    etc.), describe the expected impact (i.e., low, medium, high) of the
    alternative on existing facilities (e.g., space, power, lighting).

**Performance Quality Factors**: Describe requirements for operational
availability, reliability, and maintenance.

**Maintenance Concept**: State whether the alternative needs specific
organic (in-house) or contractor maintenance and, in general, how
maintenance will differ from that of the analogous capability.

**Interface Requirements**: Describe needed interfaces between the
alternative and new or existing NAS or other FAA systems or facilities
with which it must interact, either physically or functionally.

**Telecommunications Requirements**: Describe any major
telecommunications requirement that will be needed beyond what the
current/future FAA Telecommunications Infrastructure program or its
follow-on will provide.

**Quantities**: State the number of sites and number of assets per site
for each alternative.

**Schedule**: Identify contract award, initial operating capability, and
final operating capability target dates.

**Complexity**: Give the reasons why acquisition and deployment of this
capability will be more or less difficult, unique, or complex than the
analogous system or other prior FAA experience.

**Risks**: Describe where the alternative likely is "pushing the
envelope," either in its production (i.e., process risks that threaten
cost and schedule growth in production) or its in-service use (i.e.,
product risks) that may prevent the product from being successful in its
intended use). This may include major risk or uncertainty areas such as
software development, software certification, pilot acceptance,
controller acceptance, human-system interface optimization, concept of
use, technology maturity, schedule, acquisition strategy, competition,
staffing and training, or other major risk areas.

**Interdependencies**: Describe other initiatives or programs that may
have a potential impact on this alternative, or those on which this
initiative may have an impact.

**Testing Strategy**: Describe the testing and evaluation strategy that
will be used.

**Staffing and Training Impact**: Describe the estimated changes in
manpower levels, personnel selection criteria, and training requirements
for all users (e.g., operators, maintainers, supervisors, and support
personnel) needed to support the system in its In-Service phase.

**Activity Rates**: Summarize the expected operational tempo in terms of
operating hours per year, number of operations per month, volume of
transactions, etc.

#  {#section-61 .unnumbered}

#  {#section-62 .unnumbered}

#  {#section-63 .unnumbered}

#  {#section-64 .unnumbered}

#  {#section-65 .unnumbered}

#  {#section-66 .unnumbered}

#  {#section-67 .unnumbered}

#  {#section-68 .unnumbered}

#  {#section-69 .unnumbered}

#  {#section-70 .unnumbered}

#  {#section-71 .unnumbered}

#  {#section-72 .unnumbered}

#  {#section-73 .unnumbered}

#  {#section-74 .unnumbered}

#  {#section-75 .unnumbered}

#  {#section-76 .unnumbered}

# Appendix E: Template for the Investment Analysis Readiness Decision Briefing {#appendix-e-template-for-the-investment-analysis-readiness-decision-briefing .unnumbered}

**Investment Analysis Readiness Decision Briefing**

**for the (proposed investment initiative)**

**Purpose:** The briefing for the investment analysis readiness decision
(IARD) provides an objective and fair assessment of the merits of
proceeding to investment analysis.

**Format:** The briefing format is located at the following web link:

<http://employees.faa.gov/worktools/branding_guidelines/powerpoint/> .

**Content:** The investment analysis readiness review is conducted after
quantifying a shortfall and developing supporting documentation. It
assesses the readiness of proceeding into initial investment analysis.

The *IARD briefing* includes:

> *Description and scope of initiative*
>
> *Integration with the strategic management process*
>
> *Integration with the FAA Enterprise Architecture*
>
> *Identification of the shortfall*

*Quantification of the shortfall*

*Criticality of the shortfall*

*Economic and verifiable operational impact of the shortfall, especially
on Federal Aviation Administration and lines of business metrics*

*How much of the shortfall will be eliminated*

*Preliminary Program Requirements, including key performance parameters*

*The set of alternatives, with limited technical descriptions of each
including the state of technology development, and degree of external
customer support*

*The rough cost estimates for each alternative, including an assessment
of the reliability of costs*

*Summary of the Initial Investment Analysis Plan (include high level
schedule)*

*High level risks (if known at this time)*

*Critical interdependencies*

*Recommendation for Investment Analysis Team Lead*

*Decision requested.*

#  {#section-77 .unnumbered}

#  {#section-78 .unnumbered}

#  {#section-79 .unnumbered}

#  {#section-80 .unnumbered}

#  {#section-81 .unnumbered}

#  {#section-82 .unnumbered}

#  {#section-83 .unnumbered}

#  {#section-84 .unnumbered}

#  {#section-85 .unnumbered}

#  {#section-86 .unnumbered}

#  {#section-87 .unnumbered}

#  {#section-88 .unnumbered}

# Appendix F: Definitions and Acronyms  {#appendix-f-definitions-and-acronyms .unnumbered}

**Definitions and Acronyms**

***Definitions***

Only terms not defined in Acquisition Management System/FAA Acquisition
System Toolset are defined here.

**Concept of Use:** A document that specifies how an operational
capability will be used in the operational environment. Provides
functions to be performed and indicates benefit mechanisms to be
employed.

**Investment Analysis Readiness Review:** A subordinate investment board
review of the readiness of a proposed new investment to enter investment
analysis. The review is intended to ensure the investment description is
sufficiently mature and complete, and needed information is in hand,
before proceeding into the considerable resource expenditure for a full
investment analysis.

Acronyms

  ---------- ------------------------------------------------------------
  AIO        Office of Information Services

  AMS        Acquisition Management System

  ARB        Architecture Review Board

  ATO        Air Traffic Organization

  ATO-F      Air Traffic Organization, Finance

  ATO-P      Air Traffic Organization, Operations Planning

  B/C        Benefit to cost ratio

  BOE        Basis of Estimate

  CIO        Chief Information Officer

  CIP        Capital Investment Plan

  CIT        Capital Investment Team

  COTS       commercial-off-the-shelf

  CPIC       Capital Planning and Investment Control

  CRD        Concept and Requirements Definition

  CSEC       Chief System Engineering Council

  EA         Enterprise Architecture

  EAB        Enterprise Architecture Board

  EC         Executive Council

  ESL        Economic Service Life

  F&E        Facilities and Equipment

  FAA        Federal Aviation Administration

  FAE        FAA Acquisition Executive

  FAST       FAA Acquisition System Toolset

  FEAF       Federal Enterprise Architecture Framework

  FOC        Full Operational Capability

  IA         Investment Analysis

  IAP        Investment Analysis Plan

  IARD       Investment Analysis Readiness Decision

  IID        Initial Investment Decision

  IP&A       Investment Planning & Analysis

  ITEB       Information Technology Executive Board

  JRC        Joint Resources Council

  KPP        Key Performance Parameters

  L          Lead

  LCC        Lifecycle Cost

  LOB        Line of Business

  MS         Microsoft

  NA         Not Applicable

  NAS        National Airspace System

  NAS-SR     NAS System Requirements

  OBS        Organizational Breakdown Structure

  Org.       Organization

  O&M        Operations and Maintenance

  OMB        Office of Management and Budget

  PM         Program Manager

  POC        Point of Contact

  PRC        Progress Review Checkpoint

  RE&D       Research, Engineering, and Development

  ROM        Rough Order of Magnitude

  S          Support

  SAR        Shortfall Analysis Report

  SE         Systems Engineering

  SEC        System Engineering Council

  SEM        System Engineering Manual

  SLMNA      Service Level Mission Need Assessment

  SME        Subject Matter Expert

  SRM        Safety risk management

  SSWG       System Safety Working Group
  ---------- ------------------------------------------------------------

[^1]: Note that the roles and responsibilities are a part of the CRD
    Plan.

[^2]: The American Association of Cost Engineers defines the ROM
    estimating accuracy boundary as --30% and +50%.