Capabilities Requirements Documents for Information Systems (IS) and Information Technology (IT)

Lesson Objectives Review Capabilities Development documents and processes for Information Technology and Information Systems IT Box – (current JCIDS manual) 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 two Defense Business System Documents that contain capability requirements for business IT/IS development Introduce IT Box review exercise – GEMSIS IT Box CDD (conducted Thursday) 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 1

Adapting Capabilities Requirements Documents for IT /IS The JCIDS process and documents optimized for MDAP hardware Thus 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. Desired Outcome - Provide agile and responsive Capabilities Requirements documents and process to enable rapid development of IS capabilities FIVE 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 2

Assumptions 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) 3

Five areas of JCIDS affected by “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 4

Definition of the IT Box – draft JCIDS Manual : Enclosure B IS ICD, IS CDD Organization & Oversight Flag-level oversight thru [describe ] Chair: XXXX Members: XXXX , XXXX , XXXX “Boundaries” JROC-Approved IS ICD [or CDD] [Topic name] Oversight – [Name] Execute – [Name] Capabilities and Initial Objective Values Capability #1 [Describe] = MOE Etc.. [List the MOEs that specifically apply to this capability] Hardware Refresh and System Enhancements &I ntegration: Per year =$XX Lifecycle Cost = $XX Rationale…. 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 for a MAIS program beyond the level of funding validated in ICD / CDD CDDs and CPDs required for programs identified as MDAPs (there are currently no MDAP – MAIS programs)

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 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) 7 Fielding Decisions

Defense Business System Oversight and Acquisition model have moved past BCL Applicable to the acquisition of defense business systems that are expected to have a life-cycle cost in excess of $1 million over the current Future Years Defense Program A DBS is an information system, other than a National Security System, operated by, for, or on behalf of the DoD, including. 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. Financial systems Management information systems Financial data feeder systems 8

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

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. *The actual number and type of builds during the program will depend on system type.

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.

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

PREVIEW: Thursday Assignment Review GEMSIS IT Box CDD – hard copy info 1 binder per table and in K Drive Monday: Discussion template – 1 per student Document binder – 1 per table Thursday 1 hour discussion Documents for Thursday review located in: K:\ Clsrm and Conf Room Temp Files\ RQM 310 Oct 2013\ Exercises

PREVIEW: Thursday IT BOX review responsibilities Organization & Oversight Flag-level oversight:______________ Co-Charis _______________ Members ____________ _____________ Table 1 Table 2 Table 4 GEMSIS Increment 2 Sponsor- __________ MDA - __________ Capabilities & Initial MOEs ______________ Sustainment Costs Per Year =$________ Lifecycle Cost =$_____ FY_ to__ Rationale: ________ Table 5 RDP Table 3 Applications & System Software Development Per Year =$________ Lifecycle Cost =$_____ FY_ to__ Rationale: ________ 14

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