Attachment 1 - TERPS PWS.pdf

UNCLASSIFIED

PERFORMANCE WORK STATEMENT (PWS) For Terminal

Instrument Procedures (TERPS) Software

RFP#: HM047626R0055

Version 2.1

22 April 2026

TERPS PWS Version Change Tracker Version No. Summary of PWS Changes

1.1 Initial Draft

1.2 Revised format and work statement at section 5.0 ‘Software Requirements’ to include development phases. Other PWS sections added:

• Section 6 ‘Software Methodology and Delivery’

• Section 7 ‘Software Security’

• Section 8 ‘Program Management’

• Section 9 ‘508 Compliance’

• Section 11 ‘Standards and Quality Management Process’

1.3 Additional revision to areas referenced in version 2.0; also revised Table of Content links and reformatting of section headers throughout the document.

1.4 Consolidated Phases to 3 Phases and revisions/edits to Sections 1, 2 and 3. Revised document Version No. scheme to ‘1.X’

1.5 Updated through Section 5.1

1.6 Updated Section 4.2 to incorporate requirements for SWAP support.

1.7 Added FAA Tool reqmt to Sec. 2.0 Scope/Para 4

1.8 Consolidated Security Requirements into Section 4.2

1.9 Removed references to ‘GFP’ in Section 9.0 and CDRL documents.

2.0 Add RFP number HM047626R0055 to title page.

2.1 Added additional file ingest requirements to ‘Scope’ Section 2.0 capabilities: Shuttle Radar Topography Mission (SRTM), TerraSAR-X add-on for Digital Elevation Measurement (TanDEM-X)

Table of Contents

1.0 Introduction

2.0 Scope

3.0 General Requirements

3.1 Place of Performance

4.0 Requirements

4.1 TERPS Functional/Capability Requirements

4.2 TERPS Integration/Deployment Requirements

4.3 Software Maintenance

4.3.1 Corrective Maintenance

4.3.2 Perfective Maintenance

4.3.3 Adaptive Maintenance

5.0 Agile Methodology and "The NGA Software Way"

5.1 Agile Release and Sprit Cycle

5.1.2 Release Planning Events

5.1.3 Sprint Planning Events

5.1.4 Sprint Review Event

5.2 Backlog Management

6.0 Program Management

6.1 Program Management Review

7.0 Unclassified Work Performance Security Requirements

8.0 Operational Security

8.1 Information Handling

9.0 Government Furnished Information (GFI)

10.0 Data Rights

11.0 List of Applicable Documents

12.0 Contract Deliverable Requirements List (CDRLs)

1.0 Introduction

The National Geospatial-Intelligence Agency's (NGA) Source Foundation Aeronautical Navigation Office

(SFA) has a worldwide requirement to provide time sensitive Safety of Navigation (SoN) Aeronautical information and data to support operational needs of the Department of Defense (DoW). The

Government’s objective is to identify and select a commercial provider to develop Terminal Instrument

Procedures (TERPS) production software that delivers the optimal user experience and become a trusted

SFA industry partner essential to SFA’s daily production of Aero Foundation GEOINT data. Aeronautical data content management includes compilation, validation, and maintenance of worldwide aeronautical navigational data, products, and services for integration into the Foundation GEOINT content.

2.0 Scope

This PWS serves as the framework for a commercial solution to meet TERPS software development requirements, software maintenance requirements and IT environment integration requirements to meet

SFA’s TERPS production mission requirements.

The scope involves the delivery of TERPS software that can selectively utilize the criteria contained within

International Civil Aviation Organization (ICAO) Doc 8168-OPS/611 procedures for Air Navigation Service

Aircraft Operations (PANS-OPS), FAA Order 8260.3 United States Standard for Terminal Instrument

Procedures (TERPS), and NATO STANAG 3759 Military Instrument Procedures Standardization (NATO

MIPS). TERPS software must be capable of ingesting NGA Digital Aeronautical Flight Information File

(DAFIF), NGA Digital Vertical Obstruction File (DVOF), NGA Digital Terrain Elevation Data (DTED), Shuttle

Radar Topography Mission (SRTM), TerraSAR-X add-on for Digital Elevation Measurement (TanDEM-X), and Aeronautical Information Exchange Model (AIXM) digital formats.

Software deployments in the NGA IT environment will be accomplished via collaboration with a third-party System Integration Contractor (FS2 Security) that will deploy/install software and manage the IT infrastructure environment.

The TERPS Software Developer shall collaborate with the FS2 Integration Contractor, SFA Subject Matter

Experts and MC&G Engineers to deliver and maintain software that meets functional requirements and is compliant with NGA’s Assessment & Authorization cybersecurity requirements, NGA Software Approval

Process (SWAP) and FAA Tool quality assessment/qualification/requirements and cloud compliance.

• The TERPS developer shall deliver software that can be deployed in a cloud-hosted environment

(OpenShift or AWS). In addition to meeting TERPS requirements from a production/workflow standpoint, the software must be interoperable with external SFA aero foundation databases and repositories and make use of enterprise-wide services such as NGA's Identity Access Management solution (currently GEOAxIS) and NGA Management & Monitoring logging services.

The Developer shall be responsible for providing Program Management required to effectively communicate, manage and maintain delivery schedule of the software using the Agile methodology and cadence described in Section 5.0.

3.0 General Requirements

3.1 Place of Performance

The management, development, delivery and coordination needed to meet TERPS requirements can be accomplished remotely/virtually from the Developer’s site.

4.0 Requirements

4.1 TERPS Functional/Capability Requirements

The Developer shall provide TERPS software, capabilities, services, and micro services that meet the production requirements identified below:

• Ability to display multiple terminal charting projections.

• Ability to display and evaluate terminal airport navigation surfaces.

• Ability to develop Area Navigation (RNAV), Required Navigation Performance (RNP) and conventional (precision and non-precision) navigation instrument approach, departure and arrival procedures.

• Ability to develop and combine similar type instrument approach procedures.

• Ability to develop and evaluate terminal approach circling areas with or without area restrictions.

• Ability to develop and evaluate multiple terminal instrument holding to include differing airspeeds, turn directions, inbound and outbound courses, leg types and altitudes at the same or different

NAVAID, navigational fix and/or waypoint (all types).

• Ability to apply terminal instrument holding reduction areas.

• Ability to automate required terminal textual charting notes, missed approach instructions, no approach light minimum notes, circling area restrictions, arrival/departure route narrative, departure climb gradient notes and other navigational remarks.

• Ability to develop and evaluate procedures against Special Use Airspace (SUA) to include comments regarding ability to evaluate procedures above and below defined altitude limits of the SUA.

• Ability to evaluate terminal instrument procedures against Navigational Aid (NAVAID) service volume and identify deviations.

• Ability to identify request for NAVAID expanded service volume.

• Ability to evaluate procedures against NAVAID restrictions.

• Ability to design procedures inside and outside of standard terminal procedure design criteria plus identify design criteria references.

• Ability to notify instrument procedures designer when the procedure or chart does not meet standard terminal procedure design criteria, situations needing attention and other information to assist in procedure development process.

• Ability to assess departure obstacles and guide user to develop RNAV and conventional navigation

Obstacle Departure and/or Standard Instrument Departure Procedures with and without Departure

Route Descriptions.

• Ability to assess terminal obstacles and guide user to develop RNAV and conventional navigation

Standard Terminal Arrival Procedures with and without Arrival Route Descriptions.

• Ability to develop and define different types of terminal instrument approach missed approach segments.

• Ability to develop and define Terminal Arrival Area, Minimum Safe and Emergency Safe Altitudes with and without sectors based on multiple center point options.

• Ability to develop and define RNAV, RNP and Conventional All-Weather, Instrument Flight Rules

Approach Procedure Operational Landing Minima for all aircraft approach categories, procedure types (straight-in, sidestep, circling, circling only, etc.) and visibility values (statute miles, meters, RVR, RVV).

• Ability to develop and assess terminal instrument approach missed approaches with different climb gradients (by rate of climb percentage and/or ft per NM) within the same approach and create associated obstacle and/or ATC climb tables.

• Ability to develop and assess terminal instrument departure procedures with different climb gradients (by rate of climb percentage and/or ft per NM) and create associated obstacle and/or ATC climb tables.

• Ability to develop and assess positive course guidance in terminal instrument approach, departure and arrival procedures.

• Ability to develop and define different types of terminal instrument feeder route, initial, intermediate and final approach segments (e.g. straight-in, DME arcs, course reversal methods, etc).

• Ability to generate other types of reports.

• Ability to generate graphic depictions (format, layout and legend symbols) of terminal instrument procedures, comparable to those published in NGA’s DoW Flight Information Publication (FLIP)

(Terminal) booklets.

• Ability to generate Aeronautical Radio, Inc. (ARINC) coding for terminal instrument procedures.

• Ability to generate an electronic procedure file.

• Ability to generate NAVAID/navigation fix/waypoint data reports or exports.

• Ability to input, create, evaluate and output Final Approach Segment data block (FAS DB) information (as applicable).

• Ability to perform Cyclic redundancy check calculations.

• Ability to import aeronautical, obstruction, vegetation and terrain data.

• Ability to edit aeronautical airfield and navigation data.

• Ability to validate data used by the system.

• Ability to identify terminal approach procedure ICAO Visual Segment Surface (VSS) and FAA 34:1 and

20:1 surface penetrations.

• Ability to create Instrument Approach Step-Down Fixes & Visual Descent Points.

• Ability to create IFR Takeoff Minima.

• Ability to identify Low, Close-In Obstacles.

• Ability to identify QFE and QNH altitudes.

• Ability to create ILS Category I, II and III terminal approaches.

• Ability to identify Glidepath/Glideslope angles, Vertical Descent Angles and Threshold Crossing

Heights.

• Ability to generate time and distance and continuous descent tables.

• Ability to identify segment, area and holding controlling obstacles (with all obstacle details).

• Ability to create and generate procedure notes.

4.2 TERPS Integration/Deployment Requirements

The developer will be responsible for the deployability and sustainment requirements below:

• The Developer must collaborate with the Integration Contractor to follow the NGA Cybersecurity SOP and Risk Management Framework (RMF) Implementation Guide and adhere to ICD 503 guidance for the Assessment and Authorization (A&A) of software deliveries.

• The Developer shall meet the following software delivery and security scanning requirements:

o Raw source code shall be run against the Fortify Static Code Analyzer (SCA) and checked for the OWASP TOP 10 (latest version) using the latest version rule pack.

o Each software delivery must include a Fortify file (.fpr) and a PDF report with all findings

(critical, high, medium, and low) adjudicated, corrected, or justified.

• For each software delivery, the Developer shall provide:

o Raw source code o Compiled code o Version Description Document (VDD) indicating software and dependencies version(s) o Change logs o Deployment/installation instructions and scripts o User's guide o Test plan and test results o Release report/notes o Licenses (if applicable)

• The Developer shall collaborate with the Integration Contractor’s Cybersecurity specialist (ISSO) to receive guidance to support A&A lifecycle processes to include providing any security and architecture documentation required to achieve and maintain the system’s Authority to Operate (ATO).

• POA&M Lien Management: Upon issuance of an ATO, the Developer shall support the Integration

Contractor to execute the approved POA&M.

• The Developer shall remediate security findings (e.g. vulnerabilities, policy compliance issues, etc.)

generated by NGA’s vulnerability scans of system assets within the security boundary for which the

ATO is issued.

• The Developer must use NGA SWAP approved (or approvable) software for TERPS capability. Software should not be dependent on using a single locked down/black box version of any software component that would prevent patching updates needed to maintain SWAP compliance.

• System shall operate as a Microservice and not as a Monolithic service to allow for API integration, better scalability, etc.

• Configuration files shall come from environmental variables, not a single file.

• Software shall be designed such that it can leverage as many external enterprise resources as possible, while limiting/minimizing locally stored resources.

• Software shall be able to access external storage, such as AWS S3 buckets, or be able to utilize APIs to reach externally stored data.

• Software shall be able to integrate with external SFA databases and sources and maintain data exchanges including databases and sources referenced in Appendix A.

• The Developer shall collaborate with the MC&G GPMO to provide engineering documents and support briefings needed for TERPS to go through the NGA Enterprise Readiness & Test (TAC) process and receive an NGA/TAC Certificate to Field.

• The Developer shall integrate with performance monitoring systems (SOAR and CRIBL) to produce alerts, alarms, or notifications of system performance issues.

• The Developer shall provide system documentation and artifacts to the Government required to operate and sustain the software. These will include (not all-inclusive):

o Detailed breakdown of TERPS database interfaces and connectivity with any associated and/or required files and/or systems.

o System Description Documents o Interface Description documentation o Architectural drawings, workflows, data flows o Operational and command set handbook if applicable o Applicable process diagrams and procedures

• The Developer shall conduct code quality checks and unit testing prior to delivering application source code to the Integration Developer’s Test environment.

• The Developer shall provide documentation and support required for NGA’s Technology Disaster

Recovery (ITDR) planning.

• Upon receiving QMS certification from SFA Quality Management team, the Developer shall provide their yearly Surveillance or Recertification ISO 9001 or AS9100 Certificate & Report to the SFA QM

Team upon receiving it from the certification body.

4.3 Software Maintenance

TERPS software provider shall provide required software maintenance support consisting of Corrective, Perfective and Adaptive Maintenance as defined below:

4.3.1 Corrective Maintenance

Modifications that Identify, isolate, and rectify a fault or problem to restore a system or application to an operational state:

• Fixing minor application bugs, including system restarts

• Reconfiguring COTS for specific user / use case errors

• Working with ISP, CSP and other system admins to resolve Discrepancy Report (DR) caused by external factors that arise with non-TERPS systems

• Fast, one-time fixes that do not involve agile software development, backlog creation, or using the formal development and sustainment processes.

4.3.2 Perfective Maintenance

Modifications to improve system or application performance or maintainability.

4.3.3 Adaptive Maintenance

Modifications necessary to keep a system or application usable in a changed or changing environment.

The TERPS developer should be able to perform:

• Small and simple tasks (e.g., processing a new or modified data type from an existing source).

• Moderately complex tasks (e.g., incorporating a new Aero source file type).

• Extensive and highly complex changes requiring modification of the system, components or application design, source code and/or COTS modification, and testing (regression testing on all deliverables, verification, validation, and security). The extensive/complex changes require close coordination with users, other Developers, COTS vendors, and external customers. Examples of the larger and highly complex tasking include redesign of critical interfaces (e.g. ADDE DB, Source files), Database major version upgrades, significant code re-writes due to security-driven updates, etc.), adapting a system or application to IT environment changes (hardware/cloud or operating system change).

5.0 Agile Methodology and "The NGA Software Way"

The Developer shall utilize an Agile and iterative development approach, to deliver high-quality software.

The Developer is required to align with the Software Solution Stack Standards and **The NGA Software

Way**. Key software development principles include:

• **Core Metrics:** Track and report on Availability, Lead Time for Changes, Deployment Frequency, and Product-Specific Metrics.

• **Mandatory Practices & Tools:**

• **Version Control: ** All source code must be delivered/available in NGA's enterprise GitLab.

• **Automated CI/CD:** Use of NGA's enterprise pipeline (GitLab CI is recommended) to automate testing, security scans, and deployments.

• **Automated Testing:** Implement a full suite of automated tests (unit, integration, end-to-end).

• **Work Tracking:** Use Jira and Confluence for backlog management, documentation, and tracking work.

• **Automated Monitoring & Alerting:** Integrate with NGA's enterprise tools for monitoring and have

"runbooks" for incident response.

5.1 Agile Release and Sprit Cycle

The Developer shall establish and maintain an eight-week software release cycle, except for high priority incident reports and security vulnerabilities which shall be released as needed. Each eight-week software release cycle includes four (4), two (2) week software development sprints. The Developer shall perform software maintenance, enhancements and testing during all four (4) sprints. If the eight-week release and / or two (2) week sprint cycle needs to be updated or changed for any reason, the

Government may direct the Developer to adjust the Sprint/Release cycle for a given period of time.

5.1.2 Release Planning Events

The Developer will conduct a Release Planning Event (RPE) every eight weeks of select user stories targeted for the upcoming release balanced against schedule, budget, and developer capacity. The RPE is an iterative process of estimation and negotiation between the SFA Product Owners, the Developer’s scrum team and the MC&G GPMO to deliver selected user stories during the release cycle.

The Developer shall coordinate with the Government to lead and synchronize the RPE. The Developer conducts a pre-release planning meeting with each of the participants to validate requirements for the release.

The Developer shall provide a Release Plan at least five (5) business days before the RPE including but not limited to the following content:

• Release number, software version, release start and end dates

• Selected User stories targeted for the upcoming release that include:

o Sprint Number o Priority o Minimum Viable Product (MVP) where applicable

• Potential Risks and Concerns

• Special requirements for deployment

The Developer shall deliver a Release Planning Event Report (CDRL A009) NLT than five (5) business days after the RPE to the Government and the Integration Contractor to include the schedule of activities tied to the capability to be deployed.

An End of Release Report shall be delivered NLT than five (5) business days after the end of a Release to the Government and Integration Contractor.

5.1.3 Sprint Planning Events

The Developer shall facilitate a Sprint Planning Event to define what can be delivered in the sprint and how that work will be achieved. Sprint Planning activities shall include the review of features for the current and next sprint. The Sprint Planning Event may include topics such as architectural refinements, technical debt, infrastructure, integration, research and design activities, automation, Story writing, capability elaboration, documentation, and backlog refinement.

5.1.4 Sprint Review Event

The Developer shall facilitate a Bi-Weekly Sprint Review for the Government to present the work accomplished in the sprint, issues, risks, blockers, the upcoming sprint’s expected backlog, release dates if applicable, and a product demonstration if applicable.

5.2 Backlog Management

The Release and Sprint Backlog shall be managed in a Jira application that is accessible by the Government and the Developer. The Developer shall define and continually refine Features, Stories and Tasks under

Epics in the product backlog in collaboration with the Government Product Owner.

• The Developer shall maintain and provide access to a Jira Kanban board or similar work tracking system that is accessible by Integration team, SFA and the MC&G GPMO to communicate status of enhancements, dependencies, issues etc.

A Story is a requirement that may be written from a technical or user perspective that captures functions that the application needs to do for them and is sized for implementation within one sprint. A Story may document features to be built, defects to be fixed, design details, and decisions. The

Story shall document acceptance criteria and/or a definition of done.

The Developer and Government shall schedule Technical Exchange Meetings as required. This may include design and implementation strategies and feature feedback.

6.0 Program Management

The Developer shall provide program management to manage cost, schedule and performance of the

TERPS capability and communicate status to SFA and the MC&G GPMO stakeholders.

6.1 Program Management Review

The Developer shall conduct a quarterly Program Management Review (PMR) to the Government to present schedule, risks, and financial performance.

7.0 Unclassified Work Performance Security Requirements

Uncleared Developer personnel are authorized to work on this contract up to the Unclassified level, with access to DoW Controlled Unclassified Information (CUI) at the Developer site without the requirement of a security clearance.

Any Developer personnel working with CUI information must receive a favorable HSPD-12 and/or HSPD-

12 Tier 1 adjudication prior to accessing CUI information. Developer personnel who require access to

CUI for 60 days or less must receive a favorable HSPD-12 adjudication. Developer personnel who require

CUI access for more than 60 days must receive a favorable HSPD-12 Tier 1 adjudication.

NGA will sponsor the HSPD-12 and HSPD-12 Tier 1 background investigation for required program personnel. NOTE: Developer personnel submitted for SCI access cannot be submitted for a HSPD-12 or

HSPD-12 Tier 1 adjudication while waiting for their SCI approval.

Foreign nationals are permitted to perform unclassified work under the terms of this contract.

Developer personnel shall not release any unclassified information, regardless of medium (e.g. film, tape, document), pertaining to any part of this contract or any program related to this contract, unless the COR has given prior written approval or in performance of a project that has been scoped and negotiated by NGA.

Developer personnel visiting NGA facilities and/or sites will receive the appropriate visitor badge and be escorted, as appropriate. The visitor badge will be returned at the end of each visit day. NOTE: NGA reserves the right to refuse access to any personnel.

Developer personnel are forbidden from bringing in prohibited, unauthorized, and/or Portable

Electronic Devices (PEDs) items into any NGA installation or any secure office/working location covered under this agreement. A list of PEDs includes but is not limited to cell phones, cameras, two-way pagers, laptops, recorders (e.g. digital, tape, etc.), flash drives, or any other kind of removable media, without prior approval and approval paperwork from NGA. See NGA instructions/regulations/policy for a full list of prohibited and unauthorized items. Security violation repercussions will be determined on the severity of the violation.

8.0 Operational Security

The Developer shall ensure it maintains Operational Security (OPSEC) in performance of the contract.

OPSEC includes the awareness of potential threats and the adoption of behaviors to mitigate those threats. As an OPSEC best practice, the Developer should assume it is being monitored by adversaries.

The Developer shall follow all applicable NGA, IC, and DoW information security, operational security, and cybersecurity policies and guidance when accessing and transmitting data over networks during performance of the contract.

8.1 Information Handling

Developer personnel will comply with the NGA, DoW, and IC policies and regulations (to include, but not limited to, the Consolidated NGA (CoNGA) Security Classification Guide) to properly mark (to include portion marking) classified and unclassified documentation, media, etc.

Document markings will be in accordance with the lowest security classification possible to ensure the confidentiality and integrity for the greatest release to partners in accordance with NGA and mission partner marking guides for classified information.

9.0 Government Furnished Information (GFI)

NGA will provide the Developer with one (1) or more of the following data sources, database models and account accessibility:

• Access to Aeronautical data models (current/future)

• Outputs from Aeronautical Database as required to support data population/validation

• Agency data holdings to support Aeronautical charting needs

• Applicable APIs supporting SFA production

• Airfield Shapefiles

• Vertical Obstruction outputs

• Production Timelines (Exhibit A)

• Credentials/Logins for Developer to access APS Servers and workstations on the Agency’s

Unclassified Servers

• SFA QMDC/QMS-approved documentation for enhancement/maintenance support

The Developer shall complete and provide the Government with a GFI Material List (CDRL A003) as outlined in Section 12.0.

All Government-furnished information released to the Developer or created in the performance of this contract will be destroyed or returned by the Developer to NGA upon contract termination or when no longer required for contract performance. The determination to destroy or return will be at the direction of the NGA CO or COR.

10.0 Data Rights

All technical data and noncommercial computer software required to be developed and delivered under this contract (including technical data and noncommercial computer software delivered or ordered under DFARS 252.227-7026 and 252.227-7027) will be delivered to the Government with no less than Government Purpose Rights as defined in DFARS 252.227-7013 and 252.227-7014, unless otherwise agreed to in writing by the Contracting Officer specifically mentioning this provision.

However, if the Government is entitled to greater rights pursuant to DFARS 252.227-7013 and 252.227-

7014, the technical data or non-commercial computer software will be delivered with greater rights.

Specifically, the Government requires the delivery of the code written to perform the functions required in the SOW with no less than Government Purpose Rights.

11.0 List of Applicable Documents

• NGA DAFIF Specification

• NGA Software Approval Process

• TES Risk Management Framework Implementation Guide

• MC&G Version Description Document Template

• MC&G System Design Document Template

• MC&G CONOPs Template

• NGA Intelligence Community Directive (ICD) 503 Risk Management Framework Implementation

Guide, Version 8, September 2021

• The NGA Software Way

• NGA MC&G Foundation GEOINT (FG) Software Solution Stack Standards, Version 1.2, March 24, 2022

• 508 Compliance

12.0 Contract Deliverable Requirements List (CDRLs)

CDRL # Deliverable Title Initial Due Date Frequency

A001 Program and Funding Status

Award + 30 calendar days

Monthly, or as directed

A002 Sprint Review Report Award + 30 calendar days

NLT 3 business days after end of sprint

A003 GFI Material List Award + 30 calendar days

As directed

A004 Customer Engagement, Meeting Minutes & Action Items

Award + 30 calendar days

As directed

A005 Software Code and Software Documentation

Award + 60 calendar days

As directed

A006 Training Plan Award + 30 calendar days

As directed

A007 Quality Control Plan Award + 30 calendar days

Monthly

A008 Staffing Plan Award + 30 calendar days

As directed

A009 Release Planning Event Report

5 business days after

RPE

After each Release Planning Event

A010 Program Management Review

Award + 90 calendar days

Quarterly, or as directed

A011 Design Review Presentation

As directed As directed

A012 Corrective Action Report

As directed As directed

A013 End of Release Report 5 business days after Release

After each Release