Key Learning Objectives

At the conclusion of this course, participants are expected to have learned:

• the types of information that collectively define a military (or any other) problem;
• how to capture and validate the information which defines the problem;
• the distinctly different information content and purpose of an OCD (Operational Concept Description) and a CONOPS (concept of operations);
• the importance of each of these documents in development of military capability, as well as their relationship to requirements documents, various forms of solution description, architectural frameworks such as DODAF, and to acquisition;
• how to capture and validate requirements, etc. at a capability system level;
• how to prepare an OCD; and
• how to develop the information content and prepare a CONOPS.

Training Method and Materials

A mixture of stand-up instruction, with numerous examples, and substantial workshop activity, is used to deliver a very practically-oriented learning experience. A single capability problem with evolving life-cycle-based solution is the focus for the course.

You will be provided with:

• comprehensive course notes containing presentation material;
• a Workbook containing workshop exercises, with extensive worked examples tracking the whole process; numerous supplementary descriptions, checklists, forms and charts which you can put to use immediately;
• a reference set of military capability development documents, as follows:
  • Example Capability System Concept of Employment – CONEMP
  • Example Capability System Concept of Use – CONUSE. Note: also known as OCD
  • Example Capability System Requirements Specification – CapSyRS
  • Example Capability System Operational Solution Description – OSD. Note: also known as CONOPS
  • Example Materiel Item Concept of Use – CONUSE. Note: also known as OCD
  • Example Materiel Item System Requirements Specification – SyRS
  • Example Materiel Item Verification Requirements Specification – VRS
  • Example Statement of Work – SOW – for materiel item Operator Training; and
• complimentary access to PPI’s evolving Systems Engineering Goldmine.

Some Key Questions:

• What is the difference between an OCD and a CONOPS?
• How should each be developed?
• How does each relate to requirements?
• Why should an OCD not be the primary driver to development of requirements for a technology item?
• What are agile development methods and techniques and why are they relevant?
• What are the best public domain standards for OCD and CONOPS?

Who Should Attend this Course?

This course is intended for Military Capability Developers, Systems Engineers working on military capability development and sustainment programs, Requirements Managers for capability systems, Program and Project Managers for development of capability and parts thereof. Whilst oriented in examples to the development of military capability, the course can be easily transferred in application to any substantial business system, public infrastructure system, or other large undertaking involving people and technology as a part of the solution.

Do you Offer Tailoring of this Course?

Yes. All courses are tailored informally verbally in delivery by selecting, where possible, examples matched to the domains of interest to the class. We can also work with you to design a formally customized curriculum for the development of your people. We have done so for many client companies, and we would love to work with you to this end. We always suggest that a client takes the corresponding standard course prior to any customization. For systems engineering, this is because systems engineering is the problem-independent and solution technology-independent principles and supporting methods for the engineering of systems, based on systems thinking. So the objectives of customization need to be very clear and focused on adding further value. In practice, customization, if performed, usually becomes the replacement of examples and possibly the main workshop system with domain-specific equivalents. Substitution of the workshop system usually involves substantial redevelopment of courseware. Out of necessity, formal tailoring of courseware is performed on a fee basis.

1. Concepts and Definitions

• defining the problem, and developing a complete solution
• life cycle basis of problem definition & solution
• example requirements and MOEs relating to a capability
• example physical levels of solution definition relating to a capability
• definition: problem
• problem description definitions
  • definition: requirement/threshold
  • definition: measure of effectiveness
  • definition: measure of performance
  • definition: target/goal/objective
  • definition: value (effectiveness) model
  • definition: operational effectiveness
  • definition: requirement importance
• definition: requirements specification
• concepts related to problem description
  • definition: need
  • definition: want
  • definition: desire
  • definition: intent
  • definition: expectation
  • definition: constraint
• definition: OCD – Operational Concept Description/CONUSE – Concept of Use
• definition: solution
• definition: solution description
• definition: architecture
• definition: architectural design description
• definition: architectural framework
• definition: CONOPS – Concept of Operation(s)/OSD – Operational Solution Description
• definition: detailed design
• definition: stakeholder
• definition: verification
• definition: verification requirement
• definition: verification requirements specification
• definition: validation

2. General Concepts of Problem Solving

• problem definition
• emergence
• divergence
• convergence
• systems thinking

3. Relationships Between Requirements Document, OCD, Architectural Design Description, CONOPS

• a system solution
• systems of systems

4. Types of Requirements

• eight basic types
• workshop 1 – categorizing requirements for a capability by type

5. The Quality of Requirements

• requirements quality attributes

6. Requirements Analysis for the Capability: OCD and SyRs Content

• purpose of requirements analysis and its relationship to OCD
• relationship to CONOPS
• requirements analysis (capture & validation) methodology
• context analysis, and relationship to OCD
• workshop 2 – context analysis for a capability system
• states & modes analysis, and relationship to OCD
• workshop 3 – states and modes for a capability system
• parsing analysis, and relationship to OCD
• workshop 4 – parsing analysis
• functional analysis, and relationship to OCD
• workshop 5 – functional analysis for a capability system
• rest of scenario analysis, and relationship to OCD
• ERA analysis, and relationship to OCD
• out-of-range analysis, and relationship to OCD
• value analysis, and relationship to OCD
• workshop 6 – building a capability system value (system effectiveness) model
• operational effectiveness
• operational effectiveness versus overall effectiveness
• extracting information for an OCD and requirements document from users (and others)

7. Operational Concept Description (OCD) as a Document

7.1     Content and Purpose of an OCD

• users and uses of an OCD, in detail
• types of OCD
• principles regarding content
• use cases, mission profiles, scenarios and the OCD
• how does support relate to an OCD?
• relationship of the OCD to the requirements document
• OCD standards and guides
  • Operational Concept Documents, DID DI-MCCR-80023, SDD Documentation Set – Data Item Descriptions for DoD-STD-2167, U.S.A. Department of Defense, 1985
  • Concept Data Item Description, SMA-DID-P100, NASA Product Specification Document Standard, Release 4.3, 1989
  • ANSI/AIAA G-043-1992, Guide for the Preparation of Operational Concept Documents, 1992
  • Operational Concept Description (OCD), DID DI-IPSC-81430, Data Item Descriptions for MIL-STD-498, U.S.A. Department of Defense, 1994
  • IEEE Standard 1362, IEEE Guide for Information Technology – System Definition – Concept of Operations Document, 1998
  • ACC Instruction 10-650, Development and Use of Concepts of Operations, U.S. Department of the Air Force, 1998
  • Guide for the Preparation of Operational Concept Documents, ANSI/INCOSE/AIAA, G-043:2012
  • PPI’s OCD/CONUSE DID
• who should prepare an OCD
• timing of preparation of an OCD versus requirements document

7.2     Preparing an OCD

• characteristics of a good OCD
• workshop 7 – review of sample OCDs
• pitfalls in OCD preparation
• workshop 8 – review of an OCD for a military aircraft system
• workshop 9 – preparing a basic OCD
• use of graphics in OCDs
• level of detail in the OCD
• design content – when, and when not?
• makeup of an OCD development team
• the role of users
• beyond the basic OCD
• extending OCDs to other stakeholders
• pitfalls in preparing OCDs

8. CONOPS/OPERATIONAL SOLUTION DESCRIPTION

8.1       Content and Purpose of a CONOPS

8.2       Relationship of CONOPS to Overall Solution

8.3       Styles of Solution Development

• the solution domain: key concepts, relationships, and work products
• workshop 10 – principles of CONOPS development
• waterfall, incremental, evolutionary and spiral capability development approaches
• workshop 11 – capability solution development strategies

8.4      Concepts of Architecture – Physical and Logical, in CONOPS Development

• physical architecture (structural view) – basic concepts
• the role of technology and innovation
• techniques for stimulating innovation in solution development
• use of design driver requirements
• perspiration engineering: configuration items
• criteria for selecting configuration items
• relationship of CI definition to future system integration
• workshop 12 – physical conceptualization of capability system solution
• logical architecture – basic concepts of model-based architecting
• logical architecture related to physical architecture
• useful forms of logical representation – functional, state-based, mathematical, …
• model-based design in practice 

8.5       Functional Modeling in CONOPS Development

• functional modeling in CONOPS development – how to do it
  • functional analysis/architecture process
  • item flow and control flow
  • coupling, cohesion, connectivity
  • unallocatable and allocatable functions
  • pitfalls in defining functions
  • workshop 13 – a simple functional solution
  • workshop 14 – physical and functional solution
  • FMECA in functional solution
  • performance thread analysis
  • SysML, and alternative languages incorporating behavior modeling
  • other functional modeling languages
  • software tools supporting functional and physical solution
  • pitfalls in functional solution development

8.6       Return to Physical Solution Development in CONOPS Development

• facilities, procedures, people, and other types of solution element
• some common pitfalls in developing CONOPS
• adding the detail to the solution
• solution creates requirements – the duality of requirements and solution
• interface engineering
• evolution of interfaces in solutions having levels of structure
• interface requirements specifications versus interface design descriptions
• some common pitfalls in interface engineering

8.7       Decision-Making in CONOPS Development

• solution development for feasibility
• solution development for effectiveness: approach to solution optimization
  • the role of MOEs and goals
  • using a value (system effectiveness) model
  • taking account of risk relating to goals
  • taking account of risk relating to satisfaction of requirements
  • event-based uncertainty
  • risk aversion
  • workshop 15 – using a value (system effectiveness) model in developing solution for a capability problem
  • cost/capability, return on investment and like concepts
  • iterative optimization of solution – an effective methodology
  • software tools supporting CONOPS decision-making
  • common pitfalls in CONOPS development

8.8       CONOPS Document

• CONOPS Template
• Example CONOPS 

9. Development of Requirements and Requirements Specifications for Elements of  Solution

10. Summary and Key Points

• action plan

11. References and Recommended Reading