NAS SE Portal 10

“The combination of our people, processes and systems engineering tools and information align us to provide systems engineering leadership throughout the agency.”

Michele Merkle,
NAS Systems Engineering & Integration Directorate

Welcome to the NAS Systems Engineering Portal (SEP). This site renames the NAS Enterprise Architecture Portal and acknowledges a more robust systems engineering and planning perspective along with the NAS Enterprise Architecture. This redesign addresses usability concerns we heard from you ─ our users. We’ve also taken this opportunity to refresh the underlying technology to provide new dynamic interactive features, improved navigation and a more intuitive user experience. Whether you’re an architect, systems engineer, investment analyst, researcher or play any other role in NAS planning, you‘ll easily find here information to help you perform your job. Thank you for visiting the NAS Systems Engineering Portal. We hope you find the new look and feel easier to use, and that you will return to this website often to support your role in NAS evolution.

Systems Engineering by AMS Life Cycle

Interactive AMS Life Cycle Diagram

A typical investment program within the AMS undergoes a life cycle shown above. Please click on any of the phases to view a systems engineering perspective on how a solution - a program, system, or investment - passes through the various stages of the life cycle.

The FAA Acquisition Management System (AMS) was established in 1996 to address the unique needs of the agency and provide for more timely and cost-effective management of investments in equipment, materials, and services. This policy covers many management disciplines, including strategic planning, budgeting, enterprise architecture, portfolio management, and investment decision-making. Further information on acquisition management policy is available on-line via the FAA Acquisition System Toolset (FAST)

Service Analysis and Strategic Planning

Info

You can view the description and download templates, where available, by clicking on the individual document icons

Validated FAA need or opportunity

A validation that the expressed need is traceable to an approved FAA enterprise document or ConOps

Risk Assessment

Initial Risk Status

Configuration Management Plan

The initial configuration management plan

Integrated Safety Assessment

Early identification of safety gaps and hazards that may arise from concepts that interact with other systems.

Enterprise Architecture change notices

The recommended changes to the enterprise architecture to accommodate the planned initiative. This ensures that it is on a strategic roadmap.

Initial functional requirements

Initial high-level analysis of needed functionality

Preliminary Shortfall Analysis Report

Describes qualitatively the service need, shortfall, and legacy assets that perform functions

Concept Definition Plan

A plan for accomplishing the CRD phase.

Information System Security Risk Factors Assessment

This assessment prepares inputs for Cloud Suitability Assessment: (1) The provisional investment initiative security category, i.e., a provisional ranking of the damage that would result if the confidentiality, integrity, or availability of the information capability is lost, and (2) the security threat profile, the potential unauthorized persons or entities with the motivation, means, and opportunity to access and misuse the envisioned investment capability.

The first official phase of the AMS life cycle management process is Service Analysis and Strategic Planning. This initial phase establishes the basis for long-range strategic planning by individual service organizations and the FAA as a whole. The objectives of this lifecycle phase and the following one – Concept and Requirements Definition (CRD) – are to identify a capability shortfall, quantify a need, and identify potential technological opportunities to address that need.

SE Legend icon = Required as inputs to Concepts Definition (CRD)

Validated FAA need or opportunity

Risk Assessment

Configuration Management Plan

Integrated Safety Assessment

Enterprise Architecture change notices

Initial functional requirements

Preliminary Shortfall Analysis Report

Concept Definition Plan

Information System Security Risk Factors Assessment

Concepts Definition (CRD)

Info

You can view the description and download templates, where available, by clicking on the individual document icons

Preliminary Shortfall Analysis Report

Describes qualitatively the service need, shortfall, and legacy assets that perform functions

Concept Definition Plan

A plan for accomplishing the CRD phase.

Operational Capability Integration Plan (OCIP)

Plans how each investment increment will integrate with other increments in the capability portfolio and the FAA Enterprise Architecture.

Systems Engineering Management Plan (SEMP)

Plans the systems engineering efforts – personnel and tasking – required to progress the giveninitiative through the anticipated milestones and decision points, including vendor oversight activities. As an optional work product, the systems engineer and/or program manager make a judgment as to whether the program is sufficiently complex to require a SEMP. Can be initiated during any phase of solution development

Operational Safety Assessment (OSA)

Develops coordinated, systematic safety objectives and requirements for the overall solution (including procedural considerations) early in the development phase.

ACAT designation request

The ACAT is based on dollar thresholds as well as qualitative factors such as program risk, complexity, political sensitivity, and likelihood of changes to the safety of the NAS.

Operational Services and Environment Definition (OSED)

Describes the modes of operation and intended operational environments for a proposed solution

Functional Architecture

Translates service needs into high-level functions that must be performed to achieve the desired service outcome in every operating environment in which the solution will perform.

Final Shortfall Analysis Report

Serves as the basis for: (1) clearly understanding the nature, urgency, and impact of the service need; (2) defining preliminary requirements; (3) determining realistic and economic alternative solutions; (4) quantifying likely program costs and benefits

Preliminary Program Requirements Document (pPRD)

High-level functional, performance, interface,safety, security, and constraint requirements that must be solution-agnostic

Rough order of magnitude cost estimate for each alternative

Provides more precision than the cost estimate produced in Service Analysis.

Solution Concept of Operations (ConOps)

How the proposed solution will satisfy the service need and work with existing and planned assets.

Realistic alternatives

Preliminary range of alternatives with descriptions, including pros and cons for each. May include monetized shortfall estimates.

Enterprise Architecture products and amendments

EA products (e.g., “views”) that are built during CRD. The Integrated Systems Engineering Framework (ISEF) provides guidance on which products are needed for a given initiative.

(Initial) Investment Analysis Plan

A plan for accomplishing the Initial Investment Analysis phase. Ensures that sufficient resources are in place to complete IIA requirements.

Preliminary Information System Security Assessment

This assessment provides: (1)the final investment initiative security category, which determines the NIST SP 800-53 security requirements baseline for the envisioned capability; (2) information security requirements for the preliminary program requirements document based on an initial tailoring of the NIST SP 800-53 security requirements baseline; (3) the factors for a rough ISS cost estimate of alternative solutions and factors for a rough estimate of the annual operational benefits that would result from implementing security requirements; (4)input to the determination of the investment initiative Acquisition Category (ACAT).

The Concept and Requirements Definition (CRD) phase accomplishes three primary tasks:

1. Translate priority operational needs into a Concept of Operations document

2. Quantify the service shortfall in order to define a functional architecture and preliminary requirements

3. Identify the most promising alternative solutions and estimate the associated rough order of magnitude costs

SE Legend icon = Inputs from Service Analysis and Strategic Planning

SE Legend icon = Required as inputs to Initial Investment Analysis

Preliminary Shortfall Analysis Report

Concept Definition Plan

Inputs

CRD Work Products

Operational Capability Integration Plan (OCIP)

Systems Engineering Management Plan (SEMP)

Operational Safety Assessment (OSA)

ACAT designation request

Operational Services and Environment Definition (OSED)

Functional Architecture

Final Shortfall Analysis Report

Preliminary Program Requirements Document (pPRD)

Rough order of magnitude cost estimate for each alternative

Solution Concept of Operations (ConOps)

Realistic alternatives

Enterprise Architecture products and amendments

(Initial) Investment Analysis Plan

Preliminary Information System Security Assessment

Initial Investment Analysis

Info

You can view the description and download templates, where available, by clicking on the individual document icons

Functional Architecture

Translates service needs into high-level functions that must be performed to achieve the desired service outcome in every operating environment in which the solution will perform.

Final Shortfall Analysis Report

Preliminary Program Requirements Document (pPRD)

High-level functional, performance, interface,safety, security, and constraint requirements that must be solution-agnostic

Rough order of magnitude cost estimate for each alternative

Provides more precision than the cost estimate produced in Service Analysis.

Solution Concept of Operations (ConOps)

How the proposed solution will satisfy the service need and work with existing and planned assets.

Realistic alternatives

Preliminary range of alternatives with descriptions, including pros and cons for each. May include monetized shortfall estimates.

Enterprise Architecture products and amendments

EA products (e.g., “views”) that are built during CRD. The Integrated Systems Engineering Framework (ISEF) provides guidance on which products are needed for a given initiative.

(Initial) Investment Analysis Plan

A plan for accomplishing the Initial Investment Analysis phase. Ensures that sufficient resources are in place to complete IIA requirements.

Final System Engineering Management Plan (SEMP)

The SEMP describes the contractor's technical approachand proposed plan for the conduct, management, and control of the integrated systems engineering effort.

Operational Capability Integration Plan (OCIP)

How the selected alternative will integrate with other investment increments in the portfolio and the FAA Enterprise Architecture.

Draft Program Statement of Work (SOW)

A detailed description of the specific services or tasks that a contractor is required to perform under a contract. SOW is usually incorporated in a contract.

Initial Program Requirements Document (iPRD)

Updates the preliminary program requirements to provide a solution-specific statement of functional and performance requirements. Used to solicit market capability information from industry. Initial Program Requirements are not vendor-specific.

Enterprise architecture products and amendments (IIA)

The enterprise architecture products that are built or updated during IIA. The ISEF provides guidance on which products are needed.

Comparative Safety Assessment (CSA)

Lists the hazards associated with a service change, alongwith a risk assessment for each alternative-hazard combination.

Recommended Alternative

Description of the solution alternative that best satisfies requirements and service shortfalls.

Initial Implementation Strategy and Planning Document (ISPD)

Implementation strategy is the manner in which an organization plans to utilize organizational structure, control systems, and culture to develop and field the product or results of the project.

Initial Business case

Captures the reasoning for initiating the potential investment. The underlying logic is that whenever resources are consumed, they support a specific business need

Final Investment Analysis Plan

A plan for accomplishing the Final Investment Analysis phase. Ensures that sufficient resources are in place to complete FIA requirements.

Initial Information System Security Assessment

This assessment provides: (1) information security requirements for the initial program requirements document based on final tailoring of 800-53 controls and sufficiently detailed to conduct a market capability survey via a Screening Information Request; and (2) An update of the cost and benefit factors for input to the initial business case.

The objective of Initial Investment Analysis (IIA) is to determine the best solution by analyzing feasible alternatives within the context of their economic, operational, performance, budgetary, and risk constraints. IIA applies only to New Investment decisions. Other investment types – such as Tech Refresh and Variable Quantity – proceed directly to Final Investment Analysis.

SE Legend icon = Inputs from Concepts Definition (CRD)

SE Legend icon = Required as inputs to Final Investment Analysis

Functional Architecture

Final Shortfall Analysis Report

Preliminary Program Requirements Document (pPRD)

Rough order of magnitude cost estimate for each alternative

Solution Concept of Operations (ConOps)

Realistic alternatives

Enterprise Architecture products and amendments

(Initial) Investment Analysis Plan

Inputs

Initial Investment Analysis Work Products

Final System Engineering Management Plan (SEMP)

Operational Capability Integration Plan (OCIP)

Draft Program Statement of Work (SOW)

Initial Program Requirements Document (iPRD)

Enterprise architecture products and amendments (IIA)

Comparative Safety Assessment (CSA)

Recommended Alternative

Initial Implementation Strategy and Planning Document (ISPD)

Initial Business case

Final Investment Analysis Plan

Initial Information System Security Assessment

Final Investment Analysis

Info

You can view the description and download templates, where available, by clicking on the individual document icons

Initial Program Requirements Document (iPRD)

Enterprise architecture products and amendments (IIA)

The enterprise architecture products that are built or updated during IIA. The ISEF provides guidance on which products are needed.

Comparative Safety Assessment (CSA)

Lists the hazards associated with a service change, alongwith a risk assessment for each alternative-hazard combination.

Recommended Alternative

Description of the solution alternative that best satisfies requirements and service shortfalls.

Initial Implementation Strategy and Planning Document (ISPD)

Implementation strategy is the manner in which an organization plans to utilize organizational structure, control systems, and culture to develop and field the product or results of the project.

Initial Business case

Captures the reasoning for initiating the potential investment. The underlying logic is that whenever resources are consumed, they support a specific business need

Final Investment Analysis Plan

A plan for accomplishing the Final Investment Analysis phase. Ensures that sufficient resources are in place to complete FIA requirements.

Risk for Solution

Risks associated with the proposed solution that threaten performance, cost, schedule, and benefit objectives are examined in greater depth during FIA.

Lifecycle Engineering (LCE) Cost for Solution

A calculation of the total lifecycle cost to design, develop, field, and operate the proposed solution.

Statement of Work (SOW)

The SOW is a detailed description of the specific services or tasks that a contractor is required to perform under a contract. The SOW is incorporated into a vendor contract.

Enterprise architecture products

The numerous "views" that describe various key aspects of the proposed solution. The ISEF document provides guidance on which products are needed.

Preliminary Hazard Analysis (PHA)

An initial effort in hazard analysis during the system design phase and the programming and requirements development phase for acquisition.

Work Breakdown Structure (WBS)

A WBS defines all work activities necessary to achieve the solution. It is the basis for project planning and estimations.

Final Implementation Strategy and Planning Document (ISPD)

Plans for utilizing organizational structure, control systems, and culture to develop and field the solution. Conveys the most critical, relevant, and meaningful information regarding the alternative selected for implementation.

System Specifications

Derived from the program requirements, specifications provide low-level detail for functional and performance attributes of the selected solution

Draft ISR checklist

A deployment planning tool to assist in identifying, documenting, and resolving deployment and implementation issues. An ISR template is available on the FAST site

Final Program Requirements Document (fPRD)

Updates the Initial Program Requirements to provide a complete statement of functional and performance requirements. Final Program Requirements are tailored to the solution selected for implementation and form the basis for program assessment during Solution Implementation.

Final Business Case

An update of the business case from prior phases. The final business case demonstrates the value of implementing the proposed investment program and specifies the resources, budgets, schedules, and contract baseline(s) required to implement the solution. It is presented to the JRC at FID.

Final Information System Security Assessment

This assessment finalizes the information security requirements based on response to market capability survey. The assessment results feed the implementation and security authorization processes.

The objective of Final Investment Analysis (FIA) is to mature the selected alternative into a low-risk, successful FAA investment program ready for solution implementation. This is accomplished through a set of integrated activities that focus on three goals: • Reduce investment risk • Begin procurement of the new asset • Plan for solution implementation

SE Legend icon = Inputs from Initial Investment Analysis

SE Legend icon = Required as inputs to Solution Implementation

Initial Program Requirements Document (iPRD)

Enterprise architecture products and amendments (IIA)

Comparative Safety Assessment (CSA)

Recommended Alternative

Initial Implementation Strategy and Planning Document (ISPD)

Initial Business case

Final Investment Analysis Plan

Inputs

Final Investment Analysis Work Products

Risk for Solution

Lifecycle Engineering (LCE) Cost for Solution

Statement of Work (SOW)

Enterprise architecture products

Preliminary Hazard Analysis (PHA)

Work Breakdown Structure (WBS)

Final Implementation Strategy and Planning Document (ISPD)

System Specifications

Draft ISR checklist

Final Program Requirements Document (fPRD)

Final Business Case

Final Information System Security Assessment

Solution Implementation

Info

You can view the description and download templates, where available, by clicking on the individual document icons

Statement of Work (SOW)

The SOW is a detailed description of the specific services or tasks that a contractor is required to perform under a contract. The SOW is incorporated into a vendor contract.

Enterprise architecture products

The numerous "views" that describe various key aspects of the proposed solution. The ISEF document provides guidance on which products are needed.

Preliminary Hazard Analysis (PHA)

An initial effort in hazard analysis during the system design phase and the programming and requirements development phase for acquisition.

Work Breakdown Structure (WBS)

A WBS defines all work activities necessary to achieve the solution. It is the basis for project planning and estimations.

Final Implementation Strategy and Planning Document (ISPD)

System Specifications

Derived from the program requirements, specifications provide low-level detail for functional and performance attributes of the selected solution

Draft ISR checklist

A deployment planning tool to assist in identifying, documenting, and resolving deployment and implementation issues. An ISR template is available on the FAST site

Final Program Requirements Document (fPRD)

Final Business Case

Agreement on system specifications

The successful outcome of a System Requirements Review (SRR). The SRR forms the basis for determining

(1) whether system requirements are consistent, achievable, and complete, and

(2) whether the government and contractor have a clear and mutual understanding of them.

While the contractor conducts this review, the government takes an active part by clearly defining expectations and standards before the review and by participating actively in the event.

Approval to begin detailed design

The successful outcome of a formal review of initial design concepts and documentation to confirm the preliminary design meets requirements.

Sub-system Hazard Analysis (SSHA)

Performed if a system under development contains subsystems or components that, when integrated, function together in a system. The Contractor shall examine each subsystem or component and identify hazards associated with normal or abnormal operations and determine how operation or failure of components or any other anomaly adversely affects the overall safety of the system.

System Hazard Analysis (SHA)

A safety risk assessment of a system that analyzes the interfaces of a system with other systems, as well as the interfaces between the subsystems of the system under study. The contractor-performed SSHA serves as input to the SHA.

Risks

The risks associated with developing the propose solution.

Request for Action (RFA) (When Needed)

When applicable - In the event that some aspect of the design does not meet requirements, a request to take action to correct the problem is made.

Production Decision

A successful outcome of the Critical Design Review (CDR) which evaluates the completeness of the design, its interfaces, and suitability to start initial manufacturing or development. Note: Could be part of a Decision Analysis Report (DAR)

Test Readiness Review (TRR) products

The contractor conducts a System Test Readiness Review (TRR) using a process similar to that in MIL-STD-1521B to provide documented proof that all requirements necessary to start Formal Qualification Testing (FQT) have been met. Includes Final System Test Procedures and Agreement to proceed with Formal Qualification Testing.

Verified and validated solution products

Performance of Formal Qualification Testing (FQT) shows that the proposed solution can perform all required design functions and satisfy final requirements.

Functional Configuration Audit (FCA) Report

The output from a Physical Configuration Audit (PCA). The service team conducts a PCA after all test programs are completed, as close to production of the first unit as possible. The PCA examines the "as-built" product against its design documentation to establish the product baseline. The PCA includes a detailed audit of engineering drawings, specifications, technical data, and tests used in the production of HWCIs, and design documentation, code listings, and manuals for CSCIs. The review includes an audit of released engineering documentation and quality control records to ensure the "as- built" and "as-coded" configuration is reflected by this documentation.

Verified Program Baseline

Baselines and Updated Baselines

Baselines are established during the CM process and any changes to these baselines are released in the form of updated baselines.

Baseline Changes

The operational baseline is the approved technical documentation representing installed operational hardware and software. This represents a product baseline adapted to local conditions. Operational baselines comprise the technical documentation that initially describes a delivered solution.

Configuration Status Accounting Reports (CSAR)

Configuration status accounting reports (CSAR) provide the current status of CI configuration items or work products. CSARs can be generated electronically and are provided on demand or at scheduled intervals by the supporting CM process.

Operating Hazard Analysis (O)

Performed by the Contractor primarily to identify and evaluate hazards associated with the interactions between humans and equipment/systems. These interactions include all operations conducted throughout the lifecycle of the solution.

Operational Baseline

System Safety Assessment Report (SSAR)

A report to provide management an overall assessment of the risk associated with the solution prior to fielding, but also must be employed, prior to operation of the solution. This is accomplished by providing summaries of the analyses and testing results.

System Safety Program Plan (SSPP)

The Safety office will review the prime vendor's System Safety Program Plan (SSPP) and if it meets all requirements, they will accept the plan.

Operator and User Manuals

Manuals that prescribe the proper use of the installed equipment or software.

Initial Security Authorization Package

The security authorization package includes a documentation of all the implemented security requirements (controls), their independent assessment, and a plan of actions and milestones (POA) for controls that did not satisfy the independent assessment. The POA includes recommended remediation actions, point of contact, required resources, and scheduled dates for completion.

Solution Implementation (SI) commences with the approval and funding of an investment program, and ends when a new service or capability is commissioned into operational use at all sites. The overarching goal of SI is to satisfy requirements documented in the final requirements document and achieve the benefit targets in the business case.

SE Legend icon = Inputs from Final Investment Analysis

Statement of Work (SOW)

Enterprise architecture products

Preliminary Hazard Analysis (PHA)

Work Breakdown Structure (WBS)

Final Implementation Strategy and Planning Document (ISPD)

System Specifications

Draft ISR checklist

Final Program Requirements Document (fPRD)

Final Business Case

Inputs

Product Realization Work Products

Agreement on system specifications

Approval to begin detailed design

Sub-system Hazard Analysis (SSHA)

System Hazard Analysis (SHA)

Risks

Request for Action (RFA) (When Needed)

Production Decision

Test Readiness Review (TRR) products

Verified and validated solution products

Functional Configuration Audit (FCA) Report

Verified Program Baseline

Baselines and Updated Baselines

Deployment Work Products

Baseline Changes

Configuration Status Accounting Reports (CSAR)

Operating Hazard Analysis (O)

Operational Baseline

System Safety Assessment Report (SSAR)

System Safety Program Plan (SSPP)

Operator and User Manuals

Initial Security Authorization Package

In-Service Management

Info

You can view the description and download templates, where available, by clicking on the individual document icons

NAS Change Proposal (NCP) (When needed)

The formal method to request a change to the NAS. This usually occurs when a system or part of a system needs to be modified from its final specifications due to new discoveries while operating the system.

Emergency Sustainment Plans

Plans for the continuity of operations in the event of an emergency that might impact some aspect of normal operations. Planning would include sustainment of utilities, buildings, grounds, structures, roads, telecommunications, and security

Hardware Discrepancy Reports (When needed)

The service team test lead monitors, tracks, and assesses asset performance on a continuing basis throughout in-service management. When a hardware discrepancy is discovered, a report is issued.

Continued Investment Recommendation

An output of In-Service Performance Review (ISPR) used to characterize In-Service technical and operational health of the deployed asset by providing an assessment of risk, readiness, technical status, and trends in a measurable form that will substantiate In- Service support and funding.

Periodic Security Authorization Package

Every operational system must undergo an annual security assessment (formerly known as annual self-assessment) that supports annual security status reporting and continuous monitoring. The system's SCD, SSP, and other supporting documents in the security authorization package are updated in accordance with findings in compliance with the FAA ISS Authorization Handbook and Templates.

Activity during in-service management supports execution of the FAA mission of providing air traffic control and other services. This entails operating, maintaining, securing, and sustaining systems, products, services, and facilities in real-time to provide the level of service required by users and customers. It also entails periodic monitoring and evaluation of fielded products and services, and feedback of performance data into service and investment analysis as the basis for revalidating the need to sustain deployed assets or taking other action to improve service delivery