Capabilities Requirements Documents for Information Systems (IS) and Information Technology (IT) Eric Jefferies Professor, Requirements Management Defense Systems Management College Defense Acquisition University December 2016

Lesson Objectives Review Capabilities Development documents and processes for Information Technology and Information Systems IT Box – (current JCIDS manual) Introduce IT Box review exercise – CAMPS IT Box CDD (conducted Thursday) Know how the JCIDS documents and process are modified when using the IT Box guidance in JCIDS manual for warfighter IT/IS development Identify the Business System Document portion that contains capability requirements for business IT/IS development Requirements Organization & Oversight Validated Capabilities & Initial MOEs $ Estimated Sustainment Costs (Lifetime) JROC Approved IS ICD Estimated Applications & System Software Development & Integration Costs (Lifetime) DoDI 5000.02, Encl 12 replaces Defense Acquisition Guidebook Chapter 12 Conduct a Class IT knowledge level exercise. What groupings of IT/IS programs do we have. Business Embedded C2 C4 - warfighting 1

PREVIEW: THURSday Assignment Review IT Box CDD – Template and documents in K Drive K:\Clsrm and Conf Room Temp Files\RQM 310 DEC FY 17\Exercises ICD CDD FCB\Thursday 8 Dec 2016 - IT Box

PREVIEW: THURSday Assignment You are a USAF member and serving as a Requirements Manager at HQ Air Mobility Command (HQ AMC) – You are the sponsor of the Information Systems Capability Development Document for Consolidated Air Mobility Planning System (CAMPS) – JSD: JCB Interest – Bringing forward your IS-CDD to the FCB Working Group – Populate the IT Box CDD Slide to brief the FCB WG

IT BOX CDD review responsibilities Organization & Oversight Chair: Co-chairs: Table 1 Table 2 Table 4/7 Hardware Refresh and System Enhancements & Integration Lifecycle Cost= $ (FY Per year = $ M Rationale: Capability Name Approval: Validation: Capability Oversight: Program Management Oversight: Table 6 Key Performance Parameters • KPP#l • KPP#2 • KPP#3 Table 5 RDP Applications & System Software Development • Lifecycle Cost = $ (FY__ to __ ) • Per year = $ Rationale: Provide Table 3/8

Definition of the IT Box – JCIDS Manual : Enclosure D IS ICD Organization & Oversight Flag-level oversight thru [describe ] Chair: XXXX Members: XXXX , XXXX , XXXX IS ICD, JCIDS Manual Page D-32 “Boundaries” JROC-Approved IS ICD [Topic name] Oversight – [Name] Execute – [Name] Capabilities and Initial Minimum Values Hardware Refresh and System Enhancements &I ntegration: Per year =$XX Lifecycle Cost = $XX Rationale…. NR KPP Table Capability #1 [Describe] = initial value Capability #2 [Describe] = initial value Etc. [List the operational attributes/ initial values that apply to this IS-ICD] Application and System Software Development: Per year =$XX Lifecycle Cost = $XX Rationale…. Biannual status review by the Lead FCB Revalidation by JCB / JROC if: a) new core capabilities added to the ICD b) Increase programmed development and integration funding c) Disestablishment of oversight body or designation of new oversight body d) Exception: Changes to MAIS programs proposed in conjunction

Definition of the IT Box – JCIDS Manual : Enclosure D IS CDD Organization & Oversight Flag-level oversight thru [describe ] Chair: XXXX Members: XXXX , XXXX , XXXX IS CDD, JCIDS Manual page D-65 Key Performance Parameters “Boundaries” JROC-Approved IS CCD [Topic name] Oversight – [Name] Execute – [Name] Hardware Refresh and System Enhancements &I ntegration: Per year =$XX Lifecycle Cost = $XX Rationale…. NR KPP Table Capability #1 [Describe] = initial value Capability #2 [Describe] = initial value Etc. [List the operational attributes/ initial values that apply to this IS-ICD] Application and System Software Development: Per year =$XX Lifecycle Cost = $XX Rationale…. Biannual status review by the Lead FCB Revalidation by JCB / JROC if: a) new core capabilities added to the ICD b) Increase programmed development and integration funding c) Disestablishment of oversight body or designation of new oversight body d) Exception: Changes to MAIS programs proposed in conjunction

JCIDS Document Tracks JROC JCB Sponsor Joint Staffing Designator (JSD) FCB review & prioritization JROC Interest JCB Review JROC KM/DS staffing & comment ACAT I/IA programs & Joint DCRs FCB review & prioritization JCB Interest JCB KM/DS staffing & comment ACAT II & below with impact on interoperability Sponsor FCB review & prioritization Joint Integration KM/DS staffing & comment ACAT II & below that require endorsements & certifications The J-8 Gatekeeper (J-8/Deputy Director for Requirements) assigns a Joint Staffing Designator (JSD) after the Sponsor submits a JCIDS document to the Knowledge Management/Decision Support (KM/DS) tool on the SIPRNET. The Gatekeeper will also assign the document to the appropriate Functional Capability Board (FCB) for review, assessment, and prioritization. The FCB (often assisted by other supporting FCBs), will conduct their review concurrent with the review of the document by all other stakeholders via KM/DS. The Sponsor will adjudicate comments from those stakeholders, and when necessary ask the FCB for assistance. Comments submitted to KM/DS in response to document staffing are expected to be signed out at the GO/FO, or civilian equivalent, level. For documents with JSDs below JCB or JROC Interest, the JROC delegates validation authority to the Sponsor organization, and Sponsors may use their own internal staffing processes for review and validation. Sponsor processes must accommodate the time required to obtain Joint Staff endorsements and/or certifications where applicable. Endorsements and certifications include: J-7 (Training KPP and non-materiel solutions); J-2 (Threat validation and intelligence certification); J-8 (weapon safety endorsement); J-6 (Net-Ready KPP certification); J-4 (review and endorsement of sustainment and energy KPPs); Protection FCB (review and endorsement of Force Protection and Survivability KPPs) FCB review & prioritization Joint Information KM/DS staffing & comment ACAT II & below that do not require endorsements & certifications Validation Authority KM/DS: Knowledge Management/Decision Support tool

BACKUP

Adapting Capabilities Requirements Documents for IT /IS IF: The JCIDS process and documents optimized for MDAP hardware with high cost of sustainability THEN: JCIDS documents and process tend not to be supportive of the rapid pace of development and deployment IS systems/capabilities needed to meet operational needs. PROCESS TO-BE: Provide agile and responsive Capabilities Requirements documents and process to enable rapid development of IS capabilities PROCESS IMPROVEMENT: SEVEN aspects of the JCIDS process are modified by the “IT Box” in conjunction with changes in the acquisition process, to meet the needs of the operational user so that new capabilities can be delivered rapidly, and adapted as necessitated by changes in the operational environment This describes why additional change was required for the IT Box process in the 19 Jan 2012 JCIDS Manual Discussion: What are some typical categories of DoD and Service IT/IS systems? 9

Assumptions Information System (IS) development is different from major weapon systems development Modify their processes and documentation expectations accordingly (DODI 5000.02) The test and certification communities can deliver more responsive test and certification processes to achieve timely delivery of capabilities Necessitates incremental/iterative development and testing Validation authority for managing requirements can be pushed down to a lower level to better enable adjustment to capability deployment schedule and KPP level performance decisions (normally retained as a JROC authority) 10

areas of JCIDS modified With “IT Box” guidance Capabilities Document content and supporting Analysis for ICD and CDD FCB briefing format Validating JROCM format Follow on capability document format loosely defined as Requirements Definition Package (RDP) with Capabilities Drops (CD) Designation of an Oversight Body with more authority than typically delegated for Joint Capabilities Requirements NR KPP table defined immediately Funding table defined immediately 11

Funding Table & NR KPP Table NR KPP Attribute Key Performance Parameter Initial Minimum Support to military operations Mission: Tracking and locating (Finding, Fixing, Finishing) High-Value Target (HVT) Measure: Timely, actionable dissemination of acquisition data for HVT Conditions: Targeting quality data to the neutralizing/tracking entity <10 minutes   Area denial of HVT activities Mission Activities: Find HVT Measure: Location accuracy Conditions: Individual differentiation 100 meter circle Identify armed/ not armed Enter and be managed in the network Network: SIPRNET Measure: Time to connect to an operational network from power up Conditions: Continuous Network Connectivity <2 minutes Network: NIPRNET Conditions: Continuous Network Connectivity Up to 2 minutes Exchange information Information Element: Target Data Measure: Dissemination of HVT biographic and physical data Measure: Latency of data Condition: NSA Type 1 Certified Encryption Condition: Continuous Network Connectivity <10 seconds <5 seconds Resources Required (Note 2) Base Year $$ (Note 1) FYxx FYxx+1 FYxx+2 FYDP Total Post-FYDP (FYyy-FYzz) Life Cycle Cost (FYxx-FYzz) Application and System Software Development Costs   Hardware Refresh, System Integration Costs Total Note 1: All resources normalized to a standard base year (BY) reference – BY$$. Note 2: Current year is FYxx. First post-FYDP year is FYyy. End of planned capability life, or end of 30-year TOA projection if no planned service life, is FYzz. Table D-4. Example Life Cycle Cost Summary Table for IS-ICDs (JCIDS Manual) Example NR KPP table (derived from Table D-E-3 , JCIDS Manual) 12

Applicability of the JCIDS IT Box (see JCIDS Manual IS ICD, IS CDD) Efforts where an IT box may be considered: JROC Gatekeeper oversight (Life cycle program costs ≥ $15 million) Hardware: All hardware associated with an IS-ICD must be COTS/GOTS. Hardware modifications are restricted to those necessary for system integration and enhancements to meet capability requirements. Includes periodic refresh through lifecycle. Software - Development, integration, and acquisition of customized applications, including commercial IS capability solutions with integrated, DOD-specific performance characteristics/standards. Includes continued development and deployment through lifecycle. IT box IS NOT appropriate where: Software is embedded as a subset of a capability solution developed under other validated capability requirement documents. IT capability gap is better addressed by DBS process 13 DBS: Defense Business Systems HW: Hardware COTS: Commercial off the shelf GOTS: Government off the shelf

IT Box & Requirements Management Must meet data requirements for NR KPP certification CDDs and CPDs required for programs identified as MDAPs (there are currently no MDAP – MAIS programs) 14 14 Fielding Decisions

defense business system description -enclosure of 12 dodi 5000 defense business system description -enclosure of 12 dodi 5000.02 jan 7, 2015 Have a life-cycle cost in excess of $1 million over the current Future Years Defense Program An information system, other than a National Security System, operated by, for, or on behalf of the DoD, including: financial systems management information systems financial data feeder systems the information technology and cybersecurity infrastructure used to support business activities, such as contracting pay and personnel management systems some logistics systems financial planning and budgeting installations management human resource management 15 15

Updated Problem Statement Capabilities Requirements in Business System Lifecycle Documents – DoDI 5000.02 Encl 12 Prior to MDD: Problem Statement After MDD: Updated Problem Statement Model 2: Defense Unique Software Intensive Program Model 3: Incrementally Fielded Software Intensive Program Hybrid Program B (Software Dominant) 16

Model 2: Defense Unique Software Intensive Program Complex, usually defense unique, software program that will not be fielded until several software builds have been completed. Examples: command and control systems and significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft. Several software builds are typically necessary to achieve a deployable capability. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds Examples of this type of product include military unique command and control systems and significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft. 17 *The actual number and type of builds during the program will depend on system type.

Resources BBP 3.0 http://bbp.dau.mil NSS http://www.whitehouse.gov/sites/default/files/docs/2015_national_security_strategy.pdf QDR http://www.defense.gov/pubs/2014_Quadrennial_Defense_Review.pdf Joint Electronic Library + JDEIS CAC enabled https://jdeis.js.mil/jdeis/index.jsp JCIDS CAC enabled https://intellipedia.intelink.gov/wiki/JCIDS DoD 5000.02 http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf#page=139 4. DBS PROBLEM STATEMENT.

Model 3: Incrementally Fielded Software Intensive Program B A Materiel Development Decision Development RFP Release CDD Validation IOC Limited Fielding Decisions Materiel Solution Analysis Risk Reduction Development & Deployment Sustainment Build 0 Build OT&E Build 1.1 Build 1.2 . . . Full Deployment Decision (FDD) Full (FD) Operations & Support Build 1.n Increment N Development RFP Release Decision Limited Fielding Decisions FD Development & Build n.1 Build n.2 Build n.n Increment 2 FDD Build 2.1 Build 2.2 Build 2.n Sustainment Disposal This model will apply in cases where commercial off-the-shelf software, such as commercial business systems with multiple modular capabilities, are acquired and adapted for DoD. This model is distinguished by the rapid delivery of capability through multiple acquisition increments, each of which provides part of the overall required program capability. 19

Model 6. Hybrid Program B (Software Dominant) Development RFP Release CDD Validation B A C Build 1.1.1 Build 1.1.2 Build 1.0.1 Integration Build 1.1.3 Build 1.2 Materiel Solution Analysis Technology Maturation & Risk Reduction Production and Deployment Engineering & Manufacturing Development Sustainment Materiel Development Decision IOC FD FDD Build 1.3.1 Build 1.3.2* Limited Deployment LD) Operations & Support OT&E Increment 2 Development RFP Release Decision Build 2.1.1 Build 2.1.2 Build 2.3.1 Sustainment Disposal LD Build 2.3.2 Technology Maturation & Risk Reduction Build 2.1.3 Build 2.2 Depicts how s/w intensive product development can include mix of incrementally fielded software products or releases that include intermediate software builds Risk Management: Highly-integrated, complex s/w & h/w development risks must be managed throughout life cycle -- special interest at decision points and milestones