DRAFT_Attachment_2_GAP_CIE_Joint_Requirements__Development_Process.pdf

Attachment 02

THE GLOBAL ADAPTIVE PLANNING COLLABORATIVE INFORMATION

ENVIRONMENT (GAP CIE)

JOINT REQUIREMENTS/DEVELOPMENT PROCESS

Solicitation # FA8707-12-R-0014

Date: 15 March 2013

1.0. Introduction

This document describes the process by which the Government refines development and maintenance requirements, in collaboration with the developer, to ensure that delivered capabilities meet user needs.

2.0. Roles and Responsibilities

2.1. Functional Management Office (FMO) Staff

The FMO staff formalizes requirements on behalf of GAP CIE’s worldwide users. FMO staff members themselves use GAP CIE, and have experience with the doctrinal processes it facilitates. They interface daily with operational users, providing training and observing how various users apply the capability to their operations.

GAP CIE has a number of interrelated requirements sources:

USSTRATCOM sponsored the Joint Requirements Oversight Council (JROC)-validated ISPAN

Modernization Capability Development Document (CDD), whose Increment 2 requirements are the basis for this sustainment effort. The FMO decomposes CDD requirements in finer detail, via the Technical Requirements Document (TRD).

Other programs that provide development funds do so to address their own requirements. To the degree that satisfying other program requirements also addresses the GAP CIE CDD, this approach will reduce the remaining unsatisfied requirements.

Users individually contact the FMO to report deficiencies and recommend enhancements to the system. The ISPAN Deficiency Review Board (DRB) reviews and, if valid, documents these maintenance needs as Deficiency Reports (DRs). The FMO staff prioritizes these and other needed system improvements for each maintenance delivery.

During the joint requirements/development process, the FMO staff works closely with the developer to clarify requirements/deficiencies before they go on contract, resulting in better technical solutions. Even after these specific, clarified requirements are on contract and have approved solutions, however, there is room for stylistic differences in user-facing implementation. The FMO staff provides further detail as software development occurs influencing details such as button layout, zoom behavior, and visualization of user-entered data. This interaction helps the developer understand the use case and activity flows, and it significantly improves user satisfaction with the end result.

The developer gives the FMO staff the opportunity to review technical documentation, to evaluate prototypes and actual functionality during coding, and to test the new functionality/deficiency patch prior to fielding. The FMO makes the fielding decision for each unit of capability or maintenance work.

2.2. Program Management Office (PMO) Staff

The PMO is a division of the Air Force Lifecycle Management Center (AFLCMC), co-located at

USSTRATCOM with the FMO staff. The PMO is responsible for all acquisition activities associated with

GAP CIE. Its contracting staff awards contracts and delivery orders. Its engineering staff provides configuration management for virtual server suite allocation, monitors system performance and availability, reviews technical documentation, and provides Information Assurance support. Its Integrated

Test Team (ITT) leads Government Developmental Test and Evaluation (GDT&E) of software packages and chairs the DRB and Test Readiness Review (TRR). The GAP CIE Branch oversees costs and schedules, administers the Production Readiness Review (PRR), and interfaces with the USSTRATCOM network services provider.

2.3. Developer

The developer works with the PMO and FMO staffs, translating requirements/DRs into technical solutions at progressively finer levels of detail until software coding begins, as required. During this time, the developer may also prototype complex segments of requested capability, in order to seek early

Government feedback. During the software and DR coding and testing phase, the developer continues to interact with the Government staff to ensure that the two parties have a shared understanding of how the finished product will function.

3.0. Process Steps

Refer to the diagram on the final page of this document for a visual depiction of the process. Bold text in the narrative indicates terms that appear in the diagram. The following sections divide the process into informal phases.

3.1. Requirements Clarification Phase

To begin the process, the FMO staff prepares a draft list of desired requirements for a planned delivery and provides this list to the PMO. These requirements are traceable to the CDD.

Next, the PMO staff reviews, and possibly refines, the FMO requirements/DRs and produces an initial

Government cost estimate, and the contracting officer issues a Request for Proposal to the developer.

Representatives of the PMO, FMO, and the developer then begin any needed clarification sessions to ensure the developer understands the intent behind each requirement/DR. Clarification culminates with the developer’s Technical Approach Document, which will be submitted as part of the proposal and become the Technical Requirement document on the awarded delivery order. The PMO then engages the developer in negotiations, which leads to award of a contract delivery order.

3.2. Requirements Decomposition and Detailed Design Phase

As soon as the requirements/DRs are on contract, developer technical representatives, PMO, and FMO subject matter experts begin holding iterative Development In-Process Review (IPR) sessions, as required. The purpose of Development IPR sessions in this phase is the progressive decomposition of functional requirements into such detail that the resulting design solutions are ready for software coding.

Development IPR sessions occasionally bring to light deficiencies or enhancement needs that the

Government will consider for future work.

Prior to the start of software coding, the PMO, FMO and developer collaborate on the Software

Requirement Specification (SRS) decomposition document. The PMO and FMO staffs then conduct a review of this document for about 1 week. The review culminates with a Technical Interchange

Meeting (TIM), and typically the PMO approves the SRS document the following day.

Next, the PMO, FMO and developer hold further Development IPR sessions, using the SRS document to create various Systems Design documents. The Systems Designs are the final products that link requirements to solutions. The PMO and FMO staffs review the design documents, leading to their approval by the PMO.

Throughout this phase, the developer may build prototypes of solutions that are particularly complex or risky, to gain more specific feedback from the Government.

3.3. Coding and Testing Phase

The approved Systems Design serves as instructions for the developer’s software coders. During Code and Unit Test (CUT), Development IPR sessions continue, allowing coders to ask detailed questions of the Government regarding how users want the software to function and behave.

CUT concludes with a Test Readiness Review (TRR), at which the PMO and FMO staffs assess the preliminary software delivery readiness to transition into Contractor Developmental Test and

Evaluation (CDT&E). While the developer tests the software, Development IPR sessions continue.

CDT&E is complete when another TRR is held and the Government approves the transition to

Government Developmental Test and Evaluation (GDT&E). During GDT&E, the FMO and PMO staffs test the software delivery in an environment that closely mirrors the operational environment.

Development IPR sessions continue, and the developer provides patches as needed to correct software deficiencies. Meanwhile, the PMO staff updates the Information Assurance products necessary to gain the modified system’s Authority to Operate. A Production Readiness Review (PRR) approves the software for fielding, and the Government accepts the delivery.

4.0. Change Management

The joint requirements/development process demands significant discipline. Any changes to Technical

Approach Document may affect cost, schedule, and/or performance and thus are under the sole control of the Contracting Officer. When operational needs change, the PMO and FMO must consider priorities in determining whether to recommend changes to a delivery for which requirements have already been specified on the contract. When such a change is necessary, the Contracting Officer will notify the developer and initiate a contract modification.

5.0. Schedule Management

The overlapping nature of the requirements/development process requires schedule discipline as well. All parties involved must maintain visibility into all the products on the “assembly line” at any given time.

The FMO staff maintains a schedule of desired deliveries and their major capability requirements, looking out 2-3 years, with decreasing fidelity in the later deliveries. The FMO works with the PMO to award delivery orders to meet warfighter’s desires.

Since Development IPR sessions are the most time-consuming part of the process (3-4 hours per session), and a very small core group of Government staffers participates in most of them, consistent scheduling is very helpful. For example, when several deliveries are in progress, each one can be assigned a day of the week.

6.0. Conclusion

The GAP CIE joint requirements/development process is resource-intensive but highly effective at rapidly delivering user-focused software to meet warfighter needs. Operational users cannot write requirements with coding-quality accuracy and detail in a timely manner (i.e., fast enough to keep up with technology), and software developers cannot accurately discern all the specific behaviors that operational users will expect from a finished system. Consistent interaction between the Government and software developers is the critical link that provides an iterative conversion of requirements to code, resulting in frequent deliveries of useful capabilities.

GAP CIE Joint Requirements Analysis / Development Process diagram