CSS-Wx Section C.docx

DTFAWA-15-D-00003

CSS-Wx Option Year 3+ 5/10/2021

PART I - SECTION C

STATEMENT OF WORK

Table of Contents

This page intentionally left blank.

DTFAWA-15-D-00003

CSS-Wx Option Year 3+ 5/10/2021

PART I - SECTION C

STATEMENT OF WORK

C-i Introduction Purpose This statement of work (SOW) sets forth the requirements for the Common Support Services – Weather (CSS-Wx) contract.

Background The operation of today's National Airspace System (NAS) is supported by a variety of weather sensing and processing systems maintained by Federal agencies and private entities. These disparate sources of aviation weather data sometimes conflict with one another, creating challenges for efficient operational planning and decision-making. Furthermore, consistent NAS-wide weather information is rarely available for use in any one location. As a result, NAS-wide operational coordination requires excessive, ad hoc discussion among stakeholders, which is time-consuming and inefficient.

The realization of the Next Generation Air Transportation System (NextGen) will require changes to the FAA’s weather architecture. The integration of weather information into air traffic management decision support tools, which will require an increased use of gridded weather data with high spatial and temporal resolutions, and the increase in the number of weather data users will impose significant demands on the capacity of the FAA Telecommunications Infrastructure (FTI) Operations Internet Protocol network. The addition of new types of data sources and new users could also require costly, purpose-built connections and service adaptors to translate among data formats.

Mission Need The FAA has identified a need for a solution that will address the inconsistency of weather data and the limitations in network coverage and scalability. Through data filtering and standardization of data formats, the CSS-Wx solution will enable the efficient publication of high-resolution aviation weather data from the variety of producing systems to weather information users throughout the NAS. The solution will provide users with access to the NAS-wide weather information required for operational planning. It will also institute standard protocols for NAS systems and will be scalable to facilitate the addition of new systems, thereby minimizing the need for service adaptors.

Common Support Services – Weather The CSS-Wx System will acquire weather information from FAA and other sources and provide these data to systems that consume weather data. It will publish weather information in standardized formats for use by the FAA’s Air Traffic Organization (ATO), commercial aviation, general aviation, and other Federal agencies. The CSS-Wx System will publish aviation weather products provided by the NextGen Weather Processor (NWP), National Oceanic and Atmospheric Administration's (NOAA) NextGen Web Services, other FAA weather data sources, and non-FAA weather data sources for aviation users. The CSS-Wx System will ultimately provide the following high-level capabilities:

Standardize weather information in common formats identified by the Open Geospatial Consortium (OGC);

Filter weather information geospatially and temporally based on a user’s requirements;

Disseminate weather information via the System Wide Information Management (SWIM) system;

Perform weather data management; and Store, archive, and retrieve weather information.

Applicable Documents The documents listed in this section are referenced in this SOW. When a referenced document is in conflict with the requirements in this SOW, this SOW takes precedence. If two or more referenced documents are in conflict or two or more sections of this SOW are in conflict, the Contractor must notify the Contracting Officer (CO) to resolve the conflict.

Referenced documents are applicable to the extent specified herein. If applicability is not further specified in the text of the requirement, then the entire document is applicable.

FAA Specifications and Standards

FAA Orders

Other FAA Documents

March 2008

Other Government Documents

Industry Standards

Availability of Documents

Government-Furnished Information, Data, and Services The Government will furnish the information, software code, and software documentation listed in Section J to the CSS-Wx Contractor. The Government will provide telecommunications services to support the operation of the CSS-Wx System.

Software The Government will make software executables available to offerors with the release of the CSS-Wx solicitation package and will make software source code available to the Contractor after contract award. Use of this software does not relieve the Contractor of responsibility for meeting the requirements in this SOW or in the Attachment J-01, CSS-Wx System Specification Document (CSS-Wx SSD).

RESERVED

Scope of Work The scope of work of the CSS-Wx procurement consists of the design of the CSS-Wx System in accordance with Attachment J-01, CSS-Wx SSD, the selection of hardware, the development of system and client software, integration, testing, deployment, help desk and operational support, and maintenance of the system hardware and software. The scope of work also includes the acquisition, implementation, and integration of a NOAAPORT receiver system output into the CSS-Wx System. Lastly, the scope of work includes additional engineering services as required by the Government.

Task Orders Some work performed under this contract will be authorized by task order. Task orders will be allocated into two work packages. Attachment J-02, CSS-Wx System Requirements Allocation Matrix shows the allocation of requirements to both work packages; Work Package 2 requirements are in C.8.16.

Period of Performance The base period of the CSS-Wx contract is 4 years. The base period may be followed by four 1-year options, if exercised.

Place of Performance The Contractor is responsible for providing facilities for the development of the CSS-Wx System.

The Contractor must implement the CSS-Wx System at the FAA facilities listed in Table B-4 of Attachment J-07, NextGen Weather Systems Description Document. The Government reserves the right to change the selection of these locations as late as the Preliminary Design Review (PDR).

Requirements This section contains the requirements for the services performed by the CSS-Wx Contractor. Attachment J-03, Contract Data Requirements List (CDRL) contains additional requirements with respect to required deliverables.

Program Management The Contractor must manage the activities, personnel, resources, and subcontracts involved in the performance of the CSS-Wx contract so as to mitigate risk, meet requirements, and achieve the program’s schedule milestones. The Contractor must monitor and control the effort in accordance with approved work plans and schedules. The Contractor must also provide the FAA with clear, timely, and proactive communication on the status of planned and completed activities. The Contractor must describe their approach to managing the effort, mitigating risk, and delivering high-quality products and services that meet requirements in a Program Management Plan (CDRL PM01).

Program Management Organization and Coordination The Contractor must establish a business model that fosters collaborative relationships with the FAA and with other FAA contractors. In particular, the interdependencies of the CSS-Wx and NWP Systems, combined with similar implementation schedules, require close coordination between the program vendors from architecture to deployment to increase innovation, optimization, and performance; minimize costs and risks; and integrate and deliver both systems efficiently.

The Contractor must designate a program manager to manage, coordinate, and communicate with the Government and other FAA contractors. The program manager must have sufficient corporate authority to direct, execute, and control all elements of the program.

Quality Management The Contractor must develop and implement a plan for managing the quality of the CSS-Wx System hardware, software, systems, data items, and services required under this contract in accordance with ANSI/ISO/ASQ Q9001-2008, Quality Management Systems – Requirements. The Contractor must also ensure the quality of the products and services provided by subcontractors and third party contractors. The Contractor must submit a Quality Management Plan (CDRL PM02) that describes the Contractor’s plan for managing quality.

Earned Value Management System The Contractor must utilize an earned value management system (EVMS) that complies with ANSI/EIA-748-C, Earned Value Management Systems, to plan, control, and report the status of the effort. The Contractor must develop a Contractor Work Breakdown Structure (CDRL PM03) for approval by the Government. The Contractor must submit an Integrated Program Management Report (CDRL PM04) to provide earned value information.

Monitoring and Reporting The Contractor must continuously monitor performance under this contract and all subcontracts. The Contractor must develop and maintain a risk database to manage the categorization, reporting, tracking, and resolution of risks identified and documented. The Contractor must provide read only access to the risk database to the Government, thereby allowing the Government to maintain awareness of and generate reports of risks as needed. The Contractor must provide the FAA with an assessment of project progress, risks, issues, and proposed resolutions in a Project Status Report (CDRL PM05).

Program Reviews and Conferences The Contractor must plan, host, conduct, and attend meetings and conferences to discuss topics and communicate issues related to this effort as requested by the Government. The Contractor may be required to prepare materials for presentation and distribution prior to meetings and conferences. The Contractor must prepare and submit Meeting Minutes (CDRL PM07) for Government approval following each meeting, conference, or technical review.

Post-Award Conference The Contractor must plan, host, and participate in a post-award conference at the Contractor's facility. The Government will determine the actual date of the post-award conference within 30 business days after the contract start date. The purpose of the post-award conference is for the Contractor and the Government to:

Reach a mutual understanding of the contract requirements; and Review the integrated baseline review (IBR) preparations and EVMS tailoring.

Integrated Baseline Review The Contractor must plan, host, and participate in an IBR within 6 months of contract award. The purpose of the IBR is to:

Evaluate the Contractor’s implementation of the performance measurement baseline;

Ensure that the Government and the Contractor mutually understand program scope, schedule, resources, inherent risk, and program management processes;

Establish a schedule for program management reviews (PMRs);

Ensure early and adequate planning;

Identify risks to be tracked; and Ensure appropriate reporting levels have been identified and variance thresholds are agreed to by the Government and the Contractor.

The Contractor must provide access to the records and data that support the cost and schedule data reported. The Contractor must conduct the IBR as a separate review until such time as the Government determines that it can be integrated into PMRs. The Contractor may also be required to participate in an IBR within six months of a major design or requirements change that dictates a re-baselining of the program or after major modifications to the contract or after the Government exercises a new contract option.

Program Management Review The Contractor must convene PMRs at least monthly for the first year of the contract to update the Government on the status of the Contractor’s efforts and project milestones. At each PMR, the Contractor must review the monthly project status report with the Government. The Contractor must propose the dates of the PMRs for Government approval. The PMRs will normally be conducted at the Contractor's facility; however, the location of a PMR may be changed through mutual agreement between the Government and the Contractor. PMRs may also be held virtually, through mutual agreement between the Government and the Contractor.

Proposal Preparation The contractor may be asked by the Contracting Officer to submit proposals for new work within the scope of this contract. The Contracting Officer will provide the contractor a not to exceed amount for the contractor’s proposal effort. Providing a ROM, an alternate design material, or investigations of already in-scope tasks may not constitute a proposal for new work funded under Proposal Prep. If the contractor anticipates needing additional funding for the proposal generation, the contractor must receive approval from the Contracting Officer prior to exceeding the not to exceed amount. The contractor will be reimbursed for their costs of the proposal. There will be no fee provided for proposal preparation work.

System Engineering and Design The Contractor must design, develop, and integrate all components of the CSS-Wx System to meet the requirements contained in the CSS-Wx SSD. The Contractor must integrate the NOAAPORT receiver system output into the CSS-Wx System. The Contractor must also develop and integrate hosted algorithms as specified in Attachment J-04, CSS-Wx Hosted Algorithm Description ATC-413 and the CSS-Wx SSD.

System Engineering Management The Contractor must develop and implement a System Engineering Management Plan (SEMP) (CDRL SE01) that describes the Contractor’s plan for the definition, design, development, verification, integration, and testing of the CSS-Wx System requirements. The Contractor’s SEMP must address all aspects of performance, quality, life-cycle cost, maintainability, reliability, schedule, risk, data processing reserves, and future growth requirements.

System Requirements Analysis The Contractor must assess and refine the A-level requirements in the CSS-Wx SSD and submit a revised CSS-Wx System Specification Document (Revision) (CDRL SE02) to the Government. The Contractor must decompose the requirements in the revised SSD to define the lower-level (B-level) requirements of the CSS-Wx System, define the functional subsystems and components of the CSS-Wx System, and allocate the B-level requirements to the subsystems and components. The Contractor must develop a System/Subsystem Specification (SSS) (CDRL SE03) that documents the allocation of B-level requirements to subsystems and components and demonstrates the traceability of the B-level requirements to the A-level requirements in the CSS-Wx SSD.

Interface Requirements Analysis and Design The Contractor must develop the interface design documents listed in Attachment J-05, CSS-Wx System Interface Deliverables. The Contractor must develop each CSS-Wx System Interface Design Description (IDD) (CDRL SE04) in accordance with the Interface Design Description data item description (DID) in FAA-STD-026A, Software Development for the NAS. The Contractor must develop WSDDs (CDRL SE05) in accordance with FAA-STD-065A, Preparation of WSDDs. The Contractor must develop each CSS-Wx System Interface Control Document (ICD) (CDRL SE06) in accordance with the referenced attachment and with FAA-STD-025F, Preparation of Interface Documentation. The Contractor must develop Product Description Documents (PDDs) (CDRL SE07) for new weather products derived from the Attachment J-07, NextGen Weather Systems Description Document (e.g., new weather products that are re-organization, quantization and/or graphical representations of binary or ASCII Producer data) that are the output of the CSS-Wx System’s Web or Java Message Service (JMS)-based services and made available to consumers other than CSS-Wx itself PDD requirements must be traceable to the requirements contained in the Government-provided Web Service Requirements Documents (WSRDs). The Contractor must develop a Java Messaging Service Description Document (JMSDD) (CDRL SE21) in accordance with FAA-STD-073, Preparation of Java Messaging Service Description Documents.

The Contractor must explain to the Government how the design of the CSS-Wx System incorporates SWIM Messaging Services. The Contractor must be prepared to present analyses to justify the design.

System Architecture Definition The Contractor must define and develop the CSS-Wx System architecture baseline and allocated baseline. The Contractor must develop a Software Requirements Specification (CDRL SE08), Interface Requirements Specification (CDRL SE09), and System/Subsystem Design Description (CDRL SE10) that describe the allocated subsystems and segments. The Contractor must document the relationships between the system, subsystems, and equipment drawings in an Engineering Drawing Tree (CDRL SE11).

The Contractor must propose a failover procedure, for government approval, that will function with the redundant component concept described in Attachment J-7 NextGen Weather Systems Description Document, Section 2.2 Systems and Operations. The failover procedure may be automated with manual initiation.

Software Design and Development The Contractor must design, code, integrate, install, test, and deliver the CSS-Wx System software to meet the requirements in the CSS-Wx SSD in accordance with FAA-STD-026A. The Government will monitor software design and development. The Government will monitor software sprint demonstrations. The Contractor must provide online access to software artifacts (e.g., design and development source code, scripts, procedures, source code configuration management information) to the Government. The Government reserves the right to audit the software artifacts at any time.

Software Development Plan The Contractor must develop a Software Development Plan (CDRL SE12) that describes the Contractor’s plan for designing and developing the CSS-Wx System software.

Software Design The Contractor must design, develop, integrate, and document new and modified software in accordance with the Government-approved Software Development Plan. The Contractor must submit a Software Design Description (CDRL SE13) for Government approval. The Contractor must prepare or update all software documentation for developmental and modified software to show how the developmental software is integrated with the non-developmental software in accordance with the Software Development Plan. If any commercial software is used to satisfy requirements, the Contractor must submit corresponding commercial documentation, licensing agreements, and usage limitations to the Government for approval. The Contractor must ensure that the Government has unrestricted access to additional copies of commercial software documentation.

The Contractor must design the CSS-Wx System software to be hardware-platform independent and compatible with the IEEE Standard 1003.1, 2004 Edition, Standard for Information Technology - Portable Operating System Interface (POSIX). The Contractor must develop software that can operate on virtualized hardware using a hypervisor that has been approved by the Government.

Open Source Software Verification The Contractor must identify open source software (OSS) used in the development of the CSS-Wx System. The Contractor is responsible for resolving any OSS issues that affect the performance of the CSS-Wx System.

Software Testing Software Development Testing The purpose of software development testing is to verify specifications at the B-level. The Contractor must conduct software testing on software decomposed into computer software configuration items (CSCIs), computer software components, and functional design components (i.e., unit testing, user story testing, sprint testing, epic testing, regression testing, and software integration testing). The Contractor must conduct software testing at the Contractor’s site or at the William J. Hughes Technical Center (WJHTC) in accordance with the Government-approved Contractor Master Test Plan (CMTP) (Section C.8.3.3). The Government reserves the right to monitor all software testing activities.

RESERVED

Software Increment Testing The purpose of software increment testing is to verify execution of the system through multiple computer software components during agile software development activities. Software increment testing verifies specifications at the B level. Software increment testing is conducted at the Contractor’s facility. The Government will monitor the Contractor software increment testing. The Government will monitor agile increment demonstrations.

Software Quality Measurement The Contractor must measure the quality of CSS-Wx System software at the method (function), class, and file levels, including shared library routines and weather library routines. The Contractor must evaluate each individual software module and submit a Software Quality Report (CDRL SE14) to the Government. The Government will review and approve the Software Quality Report based on an independent verification of the metrics utilizing the Contractor’s baselined source code. Any code designated as “undesirable” will require inspection by the Government. After inspection of the code, the Government will determine if corrective action will need to be taken.

Software Products and Deliverables The Contractor must develop the following products and deliverables:

Software Product Specification (CDRL SE15) that contains or references the executable software, source files, and software support information, including "as built" design information and compilation, build, and modification procedures, for a CSCI;

Software User Manual (CDRL SE16) that describes how to install and use a CSCI, a group of related CSCIs, or a software system or subsystem. It may also cover a particular aspect of software operation, such as instructions for a particular administrative task; and Software Version Description (CDRL SE17) that identifies and describes a software version consisting of one or more CSCIs. It is used to release, track, and control software versions.

NAS Service Registry/Repository Support The Contractor must support the registering of CSS-Wx services in the NAS Service Registry Repository. The Contractor must provide the metadata for CSS-Wx services to the Government in accordance with FAA-STD-070, Preparation of Web Service Requirements Documents, FAA-STD-065A, Preparation of WSDDs, and FAA-STD-073, Preparation of Java Messaging Service Description Documents.

Hardware Selection The Contractor must select the hardware to be used in the system design to meet the requirements in the CSS-Wx SSD. The Contractor must conduct analysis to justify the proposed hardware approach to the Government. The Government will provide power constraints and weight limitations of the hardware to the Contractor prior to PDR. The Contractor must submit the hardware listing for Government approval.

NDIs and COTS Hardware and Software The Contractor must identify NDIs and COTS hardware and software used in the development of the CSS-Wx System. The Contractor is responsible for resolving any issues associated with the NDIs and COTS items that affect the performance of the CSS-Wx System. The Contractor must provide the Government with all applicable licenses and agreements.

Technical Reviews The Contractor must plan and participate in technical reviews to obtain approval for CSS-Wx System specifications and designs and to provide the FAA with insight into the Contractor’s progress. The Contractor must notify the CO of readiness for a technical review at least 20 business days (i.e., Monday-Friday, excluding Federal holidays) in advance of the planned start date. The Contractor must submit all deliverables required for the review at least 10 business days in advance of the planned start date. At each review, the Contractor must be prepared to present and discuss the content of required data items, the assumptions made, and the methodologies used to arrive at specific designs, plans, recommendations, and conclusions. The Contractor must make qualified personnel available to respond to Government questions.

The Contractor must obtain Government permission to proceed before conducting a technical review. The Contractor must close all action items or obtain Government approval for any open action items prior to conducting a technical review. If the Contractor has not submitted all required documents or if the preceding technical review has not been approved by the Government, the Government can postpone a technical review without prejudice to other contractual requirements. The Contractor must not consider formal reviews complete until the Government has granted approval in writing.

Combined Review The Contractor must conduct a System Requirements Review (SRR), System Design Review (SDR), and System Specification Review (SSR) as a single, combined review. The purpose of this combined review is for the Government to:

Determine whether the system requirements are consistent, achievable, testable, and complete, and whether the Government and the Contractor have a clear, mutual understanding of the system requirements;

Evaluate the status and maturity of the system design; and Evaluate the Software Requirements Specification.

The Contractor must submit an SRR/SDR/SSR Data Package (CDRL SE18) prior to the combined review. During the combined review, the Contractor must be prepared to present and discuss:

The revised SSD, and the allocation and traceability of requirements from the revised SSD to the preliminary System/Subsystem Specification, Web service requirements, interface requirements, and configuration items;

Draft Web services description documents;

The results of functional analyses, syntheses, and trade studies;

The Software Requirements Specification;

The final System/Subsystem Specification;

The System/Subsystem Design Description; and The Software Development Plan;

Preliminary Design Review The purpose of the PDR is for the Government to evaluate the Contractor’s system architecture and design approach to determine whether the Contractor is prepared to begin detailed design. Prior to the PDR, the Contractor must submit a PDR Data Package (CDRL SE19). During the PDR, the Contractor must demonstrate how the process used to arrive at the design meets the functional and performance requirements for each configuration item. The Contractor must also demonstrate that the requirements in the functional baseline are traceable to the requirements in the revised SSD, IRDs, WSRDs, and PDDs. The Contractor must be prepared to present and discuss the preliminary system design, software design, hardware design, human factors, telecommunications, interface design, and approach to testing. At the PDR, the Contractor must also provide the Government with the Contractor Master Test Plan (CMTP), Verification Requirements Traceability Matrix (VRTM), and estimated telecommunication requirements for the proposed solution in accordance with Attachment J-06, FTI Operational Network IP Users' Guide.

Critical Design Review The purpose of the Critical Design Review (CDR) is for the Government to determine whether the Contractor’s detailed design meets the requirements specified in the CSS-Wx SSD and whether the design is complete and ready to be implemented. Prior to the CDR, the Contractor must submit a CDR Data Package (CDRL SE20). During the CDR, the Contractor must be prepared to present and discuss the final system design, software design, hardware design, human factors, telecommunications, interface design, and test plans. During software development, the Contractor must update the CDR Data Package prior to development of each agile software increment. The Contractor must conduct a review of the revised CDR Data Package prior to development of each agile software increment. In addition, the Contractor must demonstrate that:

All software requirements are allocated and traceable to the computer software unit level;

The detailed designs reflect an architecture that satisfactorily meets the IRDs, WSRDs, PDDs, and minimizes risk;

The database design is complete and meets all requirements; and The Contractor has analyzed the impact of changes to requirements on the detailed software design, including interfaces.

Test and Evaluation The Contractor must establish a test and evaluation program consistent with the Government’s CSS-Wx Test and Evaluation Master Plan (TEMP) to verify that the CSS-Wx System and its components meet the physical, functional, interface, and performance requirements contained in the CSS-Wx SSD, referenced interface requirements documents, and referenced Web service requirements documents prior to putting the system in service.

Test Process The Contractor’s test and evaluation program must include the development testing (DT) activities described in Table 1. The Contractor must perform DT activities as indicated in the table below to demonstrate that all specified technical and performance requirements have been met. These activities will be considered Run-For-Record (RFR).

Table 1: Development Testing Activities

Formal Test Activities FAT and all test activities conducted after FAT are designated as formal test activities. The Contractor must meet the entrance and exit criteria for formal test activities described in this section.

Formal Test Entrance Criteria The Contractor must complete the following actions prior to the start of each formal test activity:

Submit and obtain Government approval for test procedures;

Baseline the test system;

Document the test configuration;

Complete test tool/capability accreditation and baseline the test tools and capabilities;

Complete all dry-run testing and incorporate redline changes into final test procedures;

Confirm all formal dry-run testing was conducted on the same software baseline as the formal CRT event;

Verify that there are no open program trouble reports (PTRs) that affect the configuration under test;

Analyze, document, submit, and obtain Government approval for test configuration deficiencies;

Coordinate test activities with affected users (e.g., internal and external users, NAS and non-NAS weather interface users, and WJHTC test bed users);

In lieu of the Test Readiness Review (TRR), complete the Pre-test Briefing;

Notify the Government of the Contractor’s intent to conduct tests at least 20 business days prior to beginning testing;

Train contractor personnel in accordance with the Contractor Master Test Plan (CMTP);

Identify and make required contractor personnel available to support test activities;

Familiarize Government personnel with the system being tested; and Identify and request that Government personnel required to support testing activities be available.

Formal Test Exit Criteria The Contractor must complete the following actions prior to the completion of each formal test activity:

Complete all test activities in accordance with the approved test plan and test procedure;

Complete the post-test briefing;

Verify that all requirements are completed;

Submit and receive Government acceptance of the test results;

Document, assess, and indicate the disposition of all PTRs;

Update all required documentation to reflect changes made during testing;

Log all pertinent test data in accordance with approved quality assurance processes;

Update the VRTM master database;

Document updates to test tools/capabilities identified during testing; and Document and implement required updates to the system test configuration.

Contractor Master Test Plan The Contractor must develop a CMTP (CDRL TE01) that describes, at a high level, the complete test approach for the tests listed in Table 1. The CMTP must include the following:

Test management approach;

Identification and description of the major test areas, test tools, test environment, and test schedule;

Configuration management and quality assurance approach;

Methods for tracking requirements, including safety requirements and the VRTM (CDRL TE02);

An approach for integration testing;

A test strategy for NDIs and COTS products, interfaces to the NAS, and security;

A process for submitting PTRs and taking corrective action;

Required initial system certifications (e.g., certification for NextGen Weather Radar (NEXRAD) connectivity); and The requirements for access to Government facilities for testing.

Test Plans and Procedures The Contractor must submit a Test Plan (CDRL TE03) and Test Procedures (CDRL TE04) for approval by the Government for all formal test activities listed in Table 1. The Contractor must follow the Government-approved test and evaluation plans and procedures for each formal test. A test procedure may be individually developed for a formal test activity or may be a component of an overall plan implemented repeatedly as the articles under evaluation dictate. The Government will approve deviations from approved plans or procedures.

Reserved Pre-Test Briefing Prior to each individual formal test, the Contractor must conduct an informal pre-test briefing. The purpose of this briefing is to ensure that the objectives and requirements for the test will be verified during the test and post-test activities. During the pre-test briefing, the Contractor must:

Overview of testing to be performed Status of all applicable test documentation, (for example: plans, procedures, test tool certification results, test bed configuration diagrams, test tool accreditation results) Identification of required Government and contractor resources and personnel Configuration control and accreditation of test tools and test items (both hardware and software) and any other items necessary for the successful conduct of testing, including Data Reduction and Analysis (DR&A) tools and equipment Prior test results, including those from any dry runs of tests List of recommended test plan or test procedure changes, for FAA review Summary of all PTRs, including status of relevant hardware, firmware, and software problems Review of test baseline, configuration, and environment System CM status GFE, GFI, and GFP status (if applicable) Traceability between requirements and their associated tests using the DT VRTM Test schedules Identify test limitations, deviations, and workarounds that apply to the test Test Execution The Contractor must execute testing in accordance with the Contractor’s testing approach as documented in the CMTP, applicable test plans, and applicable test procedures. The Contractor must collect all applicable test output during execution of each test procedure. Through the execution of a test procedure, the Contractor must verify assigned system requirements by demonstration, test, or analysis, or through a combination of all three methods.