Applying the SystemsEngineering Method for the Joint
Capabilities Integration andDevelopment System (JCIDS)
Chris Ryder and Dave Flanigan
27 October 2005
Briefing Date
slide 2
Purpose
� JCIDS prescribes a joint forces approach to identifycapability gaps against current force capability needs
� The Systems Engineering (SE) Method applies to eachiteration of the systems life-cycle from capabilityinception through system retirement
� Good systems engineering practice is necessary forsuccessfully implementing JCIDS
� Use of model-driven SE facilitates JCIDS throughout thesystems life-cycle
Briefing Date
slide 3
Agenda
� The Joint Capabilities Integration and DevelopmentSystem (JCIDS)
� The Systems Engineering Method� Model-Driven Systems Engineering for JCIDS� Why use the Systems Engineering Method JCIDS?
Briefing Date
slide 4
Functional Area Analysis
ICD
CDD
CPD
Joint Operating ConceptsJoint Functional ConceptsIntegrated Architectures
Strategic PolicyGuidance
Joint Operations Concepts
DOTMLPF ChangesCJCSI 3180
Process
Functional Solution Analysis
DO
TMLP
FA
naly
sis
Materiel ChangesCJCSI 3170
process
Ideas forMateriel
Approaches
Analysisof MaterielApproaches
Alternative NAlternative 2
Alternative 1
PostIndependent
Analysis
DOTMLPF ChangeRecommendation
FunctionalNeeds
Analysis
JCIDS Analysis
Briefing Date
slide 5
JCIDS Events� Functional Area Analysis (FAA)
o Identify operational task, conditions, and standards needed toaccomplish military objectives
o Result: Tasks to be accomplished� Functional Needs Analysis (FNA)
o Assess ability of current and programmed capabilities to accomplishthe tasks
o Result: List of capability gaps� Functional Solutions Analysis (FSA)
o Operational based assessment of DOTMLPF approaches to solvingcapability gaps
o Result: Potential DOTMLPF approaches to capability gaps� Post Independent Analysis
o Independent analysis of approaches to determine best fito Result: Initial Capabilities Document
Briefing Date
slide 6
JCIDS� JCIDS analytical process stresses the fundamentals for applying an
effective systems engineering program by any accepted standard� It guides the “front-end” phases of the SE process for each capability
iterationo Enterprise (operational) analysiso Requirements definitiono Life-cycle phase
� The analysts must have a thorough understanding of existing capabilitiesas well as the capability needs
� The JCIDS analysis team eventually determines the optimumcombination of material and non-material alternatives to achieve thecapability needs to the Battle Force
Briefing Date
slide 7
Systems Engineering Method
� Regardless of the analytical phase performed by theJCIDS SE team,o The basic application of the SE method is constant
throughout the process� Each SE Method activity is performed in some form in
each phase of the system life-cycle
Briefing Date
slide 8
Systems Engineering Method Over Life Cycle
Operation& Support
ProductionIntegration &Evaluation
Engineering DesignAdvancedDevelopment
Concept DefinitionConceptExploration
Needs Analysis
TransitionConstructionElaborationInception
PostDevelopment
Engineering DevelopmentConcept Development
ProductionSupport
Full-scaleProduction
ProductionPreparation
DevelopmentTechnical FeasibilityConceptual
SupportUtilizationProductionDevelopmentConcept
SystemDemonstration
SystemIntegration
ComponentAdvanced Development
Concept Exploration
Operation & SupportProduction &Deployment
System Development &DemonstrationConcept And Technology DevelopmentMission NeedDetermination
DOD5000
Phases
ISO/IEC15288Stages
NPSEStages
SystemEngineering
Stages
SystemEngineering
Phases
RationalUnified
Process for SE
MS AMS A MS BMS B MS CMS C
ICDICD CDDCDD CPDCPDJCIDSFAA/FNA/FSA
FAA/FNA/FSA
From Systems Engineering: Principles and PracticeKossiakoff and Sweet
Briefing Date
slide 9
RequirementsAnalysis
FunctionalDefinition
PhysicalDefinition
From Preceding Phase
To Next Phase
DesignValidation
System Model
Functions
Objectives
Requirements
From Systems Engineering: Principles and PracticeKossiakoff and Sweet
The Systems Engineering Method
Briefing Date
slide 10
Systems Engineering Method
Need
Solution(s)
UserRequirements
Analysis
UserRequirements
Analysis
FunctionalDefinition
FunctionalDefinition
DesignValidationDesign
Validation
PhysicalDefinitionPhysical
Definition
Require
ments
Function
s
Potentia
l Solu
tions
If current step is not executable, thenloop back to previous step (or further) and fix things!!
Verify that the solutionmeets the need
Before starting,verify the “as stated”
need is valid
FunctionalArea
Analysis FunctionalNeeds
Analysis FunctionalSolutionsAnalysis
ProgramIndependentAssessment
Briefing Date
slide 11
Systems Engineering Method
ProblemDefinitionProblem
Definition
Rationale, Scope,& Context
Rationale, Scope,& Context
FunctionalDecomposition
FunctionalDecomposition
Legacy OperationalActivities
Legacy OperationalActivities
Sponsor-derivedProblem Set
Sponsor-derivedProblem Set
TechnologicalContributions
TechnologicalContributions
DirectedFunctionsDirected
Functions
FunctionalImprovements
FunctionalImprovements
AnalysisAnalysis
M&SM&S
Problemsatisfied?Problem
satisfied?
YesYes
NoNo
User Requirements Analysis
Functional Definition
Design Validation
CapabilitiesCapabilities
CollectCandidateSystems
CollectCandidateSystems
DOTMLPFElements
DOTMLPFElements
Material / Non-Material solution?Material / Non-Material solution?
Physical Definition
Non-Material
Material
Briefing Date
slide 12
Systems Engineering Method
ProblemDefinitionProblem
Definition
Rationale, Scope,& Context
Rationale, Scope,& Context
LegacyOperational
Activities
LegacyOperational
Activities
Sponsor-derivedProblem Set
Sponsor-derivedProblem Set
User Requirements Analysis
CapabilitiesCapabilities
To Functional Analysis Phase
Briefing Date
slide 13
Problem Definition
� At one point in time there is a problem that must be solved dueto:o Deficient capability with existing systemso Desire to improve existing performance
� Need to understand what the objectives are to provide thedesired capability
� Define the operational context within the Capability Enterprise!
Briefing Date
slide 14
Requirements Analysis Products
� A clear definition of the problem� A proper scope of the problem� Operational context documents and data bases
o Design Reference Missiono Strategy-to-Task Mappingo Concept of Operationso Physical Environment Databaseo Threat Representation Databaseo Blue Capabilities Database
� Relevant Operational Views
Captured within a SE Requirements Model
Briefing Date
slide 15
Systems Engineering Method
FunctionalDecomposition
FunctionalDecomposition
TechnologicalContributionsTechnologicalContributions
DirectedFunctionsDirected
Functions
FunctionalImprovements
FunctionalImprovements
Functional Definition
From Requirements Definition
To Physical Definition
Briefing Date
slide 16
Functional Definition Products
� Functional Decomposition of required activitieso Functional diagrams (FFBD, UML AD)
� Associated metrics with these functions (threshold / objective?)� Analysis process that determines if you can solve with a material / non-
material / both solutiono Be able to document and defend this process
� How do we know it’s right?o The functions are legitimate, correct, and validated by users
� Functional Area Analysis� Relevant operational views
Functional Analysis Documented in a SE Functionalor Logical Model
Briefing Date
slide 17
Systems Engineering Method
Collect CandidateSystems
Collect CandidateSystems
DOTMLPFElements
DOTMLPFElements
Material / Non-Material solution?Material / Non-Material solution?
Physical Definition
Non-Material
Material
From Functional Definition
To Design Validation
Briefing Date
slide 18
Physical Definition Products
� Provide system alternatives towards satisfying required functionalityo Assignment of functions to physical elements
� DOTMLPF analysis productso Based on the functional definition phase
� CONOPS changes / recommendationso Based on DOTMLPF analysis
� Risk management strategies of the system� System roadmaps to bridge the gap between the current and future
capabilities� Functional Needs Analysis� Relevant operational and SYSTEMS views
SE Logical Model with Physical Definition BeginsEvolution Toward a Systems Model
Briefing Date
slide 19
Systems Engineering Method
AnalysisAnalysis
M&SM&S
Problemsatisfied?Problem
satisfied?
YesYes
NoNo
Design Validation
Reassess requirements,functional elements orphysical details
To next life-cycle phase:Requirements Definition
From Physical Definition
Briefing Date
slide 20
Design Validation Products
� Demonstrate the analysis documents the assumptions, follows arigorous process, and arrives at meaningful conclusions that arejustifiableo There may be multiple processes and products dependent on the
sponsor, personnel/time availability, experienceo This may be an iterative process for ICD, CDD, CPD
� Trade studies� VV&A� Risk Management� Cost Analysis� Force Allocation� Functional Solutions Analysis� Program Independent Assessment
Attain a Fully Validated Systems Engineering Model
Briefing Date
slide 21
Architectures in JCIDS
� “Integrated Architectures” are a foundation for theanalytical processo Stated requirements, attributes and measures
� Direct reference to DoD Architecture Framework (DoDAF),however:o Architecture is misused term within the realm of SE
� It is important to differentiate “architecture” from“architectural views”
� The JCIDS SE Model is the foundation for the architectureand the architectural views
Briefing Date
slide 22
Systems Engineering Model
� Model is a simplified view of a complex systemo Assists stakeholders, including engineers, to understand
something that is not easily comprehensibleo Communicates the organization of the system to the
stakeholders� Rechtin
o “Contributes to the structural stability of a system.”o Enhances understanding of interfaces, relationships,
operations and risk
“If you don’t model it, you won’t understand it.”Ivar Jacobson
Briefing Date
slide 23
Model-Driven SE
� An Systems Engineering model captures the essential elementsof the systems engineering life-cycle
� “Dynamic and recursive process” (Bootch, Rumbaugh, Jacobson)
o Iteratively captures enterprise capabilities and systemsrequirements
o Promotes incorporation of technology evolution� Forms basis for a sound, long-term SE and analysis
o Fully compliant with precepts of DoDAF and JCIDS
Model-Driven SE in Defense Systems Acquisitionbecomes Model-Driven JCIDS
Briefing Date
slide 24
Context of the Capability Enterprise
«Capability»Capability Object
«Enterprise»CapabilityEnterprise
«System»Warfare System
«System»Threat
Systems«System»
CommunicationsNetworks/ GIG
«Non-Material»DOTMLPF
Assigned to
Affects
Affected by
Supports
Supported by
Component of
Applies to
Applies
Briefing Date
slide 25
DOTMLPF� Dot-mil-pe-ef’� The “Non-Material” elements of the capability
o Doctrineo Organizationo Trainingo Materialo Logisticso Personnelo Facilities
� Investigate if a modification to any element except the “M” willenhance the Capability Enterpriseo A far less expensive option
Briefing Date
slide 26
Transition from Capability to System«System»
System As Is DOTMLPF
«Capability»Capability As Is «Capability»
Capability To Be
«System»System To Be
CapabilityGap
+Closes+Possesses
Applies to
Applies to
Assigned to
Evolves to
DOTMLPF can alsotransition from “As
Is” to “To Be”
The Legacy System
Briefing Date
slide 27
JHU/APL SE MethodologyLinkage to JCIDS
� JHU/APL SE methods can be used to produceJCIDS products/artifacts
� JHU/APL SE methods can iterate throughoutthe DoD 5000 lifecycle
� Good SE methods can produce JCIDS� Bad SE methods can produce JCIDS� Producing JCIDS does not guarantee good SE
Good SE Effective JCIDS
Briefing Date
slide 28
Final Thoughts
� JHU/APL has consistently provided SE expertise to numerousprograms, following a rigorous and structured SE approach tothe problemo “It’s all about the data”o “It’s all about the rigor”
� Program Offices have anchored their programs to ourapproaches and data
Briefing Date
slide 29
Summary
� Description of JHU/APL SE process� JCIDS is consistent with good systems engineering
practices� JHU/APL SE process is consistent with JCIDS