Information Operations Team Training & Information Operations Training Aid, Information Warfare ... (PDFDrive)

AFRL-RH-AZ-TR-2010-0023
Information Operations Team Training & Information

Operations Training Aid
Information Warfare Effectiveness (IWE) Program
Elisabeth Fitzhugh
Neil Ranly
Steve Schafer
SRA International, Inc.

5000 Springfield Street
Suite 200
Dayton, OH 45431
March 2010
Final Report for February 2004 to February 2010
Distribution A. Approved for public release, distribution unlimited. (Approval given

by 88 ABW/PA, 88ABW-2010-3818, 16 Jul 2010.)
AIR FORCE RESEARCH LABORATORY

711TH HUMAN PERFORMANCE WING
HUMAN EFFECTIVENESS DIRECTORATE
WARFIGHTER READINESS RESEARCH DIVISION
MESA, AZ 85212
AIR FORCE MATERIEL COMMAND
UNITED STATES AIR FORCE
NOTICE AND SIGNATURE PAGE
Using Government drawings, specifications, or other data included in this document for any
purpose other than Government procurement does not in any way obligate the U.S.
Government. The fact that the Government formulated or supplied the drawings, specifications,
or other data does not license the holder or any other person or corporation; or convey any
rights or permission to manufacture, use, or sell any patented invention that may relate to them.
Qualified requestors may obtain copies of this report from the Defense Technical Information
Center (DTIC) at http://www.dtic.mil.
AFRL-RH-AZ-TR-2010-0023 HAS BEEN REVIEWED AND IS APPROVED FOR PUBLICATION

IN ACCORDANCE WITH ASSIGNED DISTRIBUTION STATEMENT.
SARAH FOCKEL HERBERT H. BELL

Lab Contract Monitor Technical Advisor
JOEL BOSWELL, LtCol, USAF

Chief, Warfighter Readiness Research Division
Air Force Research Laboratory
Form Approved
REPORT DOCUMENTATION PAGE OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the
data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing
this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-
4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently
valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.
1. REPORT DATE (DD-MM-YYYY) 2. REPORT TYPE 3. DATES COVERED (From - To)
23-02-2010 Final Feb 2004- Feb2010
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Information Operations Team Training FA8650-04-D-6405
& Information Operations Training Aid 5b. GRANT NUMBER
Information Warfare Effectiveness (IWE) Program, Delivery Order 8 5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER

Elisabeth Fitzhugh
Neil Ranly 5e. TASK NUMBER
Steve Schafer
5f. WORK UNIT NUMBER
7184-X1-3A
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT
NUMBER
SRA International, Inc.
5000 Springfield Street
Suite 200
Dayton, OH 45431
9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
Air Force Research Laboratory AFRL; 711 HPW/RHAS
Human Effectiveness Directorate
Warfighter Training Research Division 11. SPONSOR/MONITOR’S REPORT
6030 South Kent Street NUMBER(S)
Mesa AZ 85212-6061 AFRL-RH-AZ-TR-2010 - 0023
12. DISTRIBUTION / AVAILABILITY STATEMENT
Distribution A. Approved for public release, distribution unlimited. (Approval given by 88 ABW/PA, 88ABW-2010-3818, 16 Jul 2010.)
13. SUPPLEMENTARY NOTES
14. ABSTRACT
The dual Information Operations Team Training (IOTT) and Information Operations Training Aid (IOTA) project was a joint 711 th
HPW/RHA and RHC effort designed to develop tools for Information Operations (IO) training support. The IOTT task established a set
of IO practitioner-vetted Mission Essential Competencies, standardization and evaluation techniques for the Information Warfare
Aggressor Squadron (IWAS) flights and recommendations for generating a MEC-based standardization and evaluation task. The IOTA
task developed and evaluated the usability and usefulness of a prototype rich client Influence Operations Training Aid (IFOTA) for use in
the 39th Information Operations Schoolhouse‘s introductory and advanced IO planning courses. IFOTA, which currently supports
psychological operations (PSYOP), military deception (MD), operations security (OPSEC), public affairs (PA), and counterintelligence
(CI), provides a structured planning environment for developing and deconflicting IO course of action (COA) recommendations and
developing associated briefings.
15. SUBJECT TERMS

Information Operations, Influence Operations, Air Operations Planning, Course of Action Development, Training
16. SECURITY CLASSIFICATION OF: 17. LIMITATION 18. NUMBER 19a. NAME OF RESPONSIBLE PERSON
OF ABSTRACT OF PAGES 1 Lt Sarah Fockel
a. REPORT b. ABSTRACT c. THIS PAGE 19b. TELEPHONE NUMBER (include area
UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED code)
SAR 105
(480) 988-6561 ext 425
Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39.18
This page intentionally left blank.
TABLE OF CONTENTS
Section Page
List of Figures ................................................................................................................................ iv
List of Tables ................................................................................................................................. iv
Preface............................................................................................................................................. v
Acknowledgments........................................................................................................................... v
1.0 SUMMARY ........................................................................................................................ 1
2.0 Introduction ......................................................................................................................... 1
2.1 Task One: Mission Essential Competencies (MECs) ..................................................... 1
2.2 Task Two: Information Operations Training Aid (IOTA) .............................................. 2
2.3 IOTT/IOTA Accomplishments ....................................................................................... 3
3.0 Approach ............................................................................................................................. 4
3.1 Cognitive Work Analysis ................................................................................................ 4
3.1.1 Applied Cognitive Task Analysis (ACTA)............................................................. 6
3.1.2 Work-Centered Design (WCD). ............................................................................. 6
3.1.3 CTA Artifacts, WCD and Software Requirements Specification ........................... 7
3.2 IFOTA Knowledge Elicitation ........................................................................................ 8
4.0 Results and Discussion ....................................................................................................... 8
4.1 Knowledge Elicitation Trip 1.......................................................................................... 8
4.1.1 Elicitation Findings/Discussion Points for Usefulness (Focus on the Task) ........ 11
4.1.2 Elicitation Findings/Discussion Points for Usability (Focus on the User) ........... 15
4.1.3 Requirements ........................................................................................................ 17
4.2 Knowledge Elicitation Trip 2........................................................................................ 19
4.2.1 Processes ............................................................................................................... 24
4.2.2 Task Descriptions.................................................................................................. 25
5.0 IFOTA Development ........................................................................................................ 27
5.1 IFOTA Technical Architecture ..................................................................................... 30
5.1.1 Advanced Technical Features ............................................................................... 32
5.1.2 Rich Client Integration .......................................................................................... 33
5.1.3 Training Environment Configuration ................................................................... 33
5.1.4 IFOTA System Requirements ............................................................................... 34
6.0 Discussion: Warfighter Analysis Workshops ................................................................... 34
7.0 Conclusion/Recommendations ......................................................................................... 35
8.0 References ......................................................................................................................... 37
Appendix A ................................................................................................................................. A-1
Appendix B ................................................................................................................................. B-1
Appendix C ................................................................................................................................. C-1
Appendix D ................................................................................................................................. D-1
Appendix E ..................................................................................................................................E-1
Approved for public release; distribution unlimited.

LIST OF FIGURES
Figure ....................................................................................................................................... Page
Figure 1. IFOTA opening interface and example plan tree view ................................................... 2
Figure 2. Concept map of Capstone Exercise from IOIC instructor interview. ............................. 5
Figure 3. Counterintelligence process flow ( based on interviews with CI subject matter experts)7
Figure 4. IFOTA CSE to SE information transfer. ......................................................................... 8
Figure 5. Planned Student Activities within IFOTA as initially described. ................................. 10
Figure 6. Planned Instructor Activities within IFOTA as initially described. .............................. 11
Figure 7. Initiating and terminating an IFOTA planning effort. ................................................... 25
Figure 8. IO Processes .................................................................................................................. 26
Figure 9. IFOTA 1.0 multi-tabbed PSYOP scenario showing evaluation of TA resistance ........ 28
Figure 10. IFOTA 2.0 screenshot illustrating planning template elements and visual checklists to
aid recall (allows users to move among modules in non-linear iterative planning) ..................... 28
Figure 11. IFOTA 3.0 User interface showing addition of Time Series View tab and function .. 29
Figure 12. IFOTA 4.0 showing deconfliction of MD COA and COA weighting ........................ 30
Figure 13. IFOTA 3-tiered architecture ........................................................................................ 31
Figure 14. IFOTA system component view .................................................................................. 31
Figure 15. Client stack .................................................................................................................. 32
Figure B - 1. Truncated Entity-Relationship Diagram (based on Version 2) ............................. B-2

Figure B - 2. General Class Diagram of Main Planning Elements (based on Version 2) .......... B-3
Figure B - 3. Use Case Diagram (based on Version 2) ............................................................... B-5
Figure B - 4. View Model Class Diagram (based on Version 2 - Jung) ..................................... B-5
LIST OF TABLES
Table ......................................................................................................................................... Page
Table 1. A Partial Representation of IFOTA Requirements. ........................................................ 19
Table 2. IFOTA Software Features ............................................................................................... 33
Table 3. Requirement to Capability Mapping............................................................................... 35

PREFACE
The Information Operations Team Training (IOTT) and IO Training Aid (IOTA) project was
conducted under the Information Warfare Effectiveness (IWE) program, Contract No. FA8650-
04-D-6405. Program management was provided jointly by Air Force Research Laboratory
Human Effectiveness Directorate's Warfighter Readiness Research Division (711th HPW/RHA)
and the Warfighter Interface Division (711th HPW/RHC). The current program manager is 1st Lt.
Sarah Fockel (711th HPW/RHAS). The prime contractor is SRA International, Inc.; project
management is provided by Mr. Steven Schafer.
The IOTT Mission Essential Competency task was performed by Aptima, Inc. The IOTA, which
was renamed Influence Operations Training Aid (IFOTA), has been created for use at the 39th
Information Operations Schoolhouse in their Introductory Information Operations Integrated
Course (INTRO IOIC) and their Advanced Information Operations Integrated Course (ADV
IOIC). IFOTA is designed and developed by SRA International, Inc.
ACKNOWLEDGMENTS
The IOTT/IOTA project wishes to acknowledge and thank the following individuals for their
support to successful project completion. Dr. Joseph Weeks (711th HPW/RHAS) and Dr.
Winston Bennett (711th HPW/RHAS) have provided ongoing guidance and assistance to the
IOTT effort. The IOTT team gratefully acknowledges the members of the Information Warfare
Aggressor Squadron, the Information Warfare Flights, the Network Operations Division (NOD),
the Air Force Computer Emergency Response Team (AFCERT), and INOSC-East organizations
who participated the MEC workshops. The IOTA team expresses appreciation for the interim
guidance and support to the IFOTA development effort provided by Major Tim Gameros (711th
HPW/RHC) and Major Janelle Viera (711th HPW/RHA) and Ms Alicia Bledsoe (711th
HPW/RHA). Special thanks are also due to 39th IOS personnel Lt. Col. Thaddeus P. Settlemire,
Commander, and SSgt James ―Spike‖ Szeredy, who conceived the need for IFOTA and to their
colleagues Sgt. Michelle DeAngelis, Sgt. Joe Mikos, and Sgt. Charles ―Low‖ Simpson, as well
as Mr. Russ McLaren (AFOSI) and Mr. Rolf Ludvigsen (SRA), who contributed valuable
insights from their disciplinary perspectives.

This page left blank intentionally.

1.0 SUMMARY
The dual Information Operations Team Training (IOTT) and Information Operations Training
Aid (IOTA) project was a 711th Human Performance Wing, Human Effectiveness Division
(711th HPW/RHA)-led effort designed to develop tools for Information Operations (IO) training
support. The IOTT task established a set of IO practitioner-vetted Mission Essential
Competencies (MEC), standardization and evaluation techniques for the Information Warfare
Aggressor Squadron (IWAS) flights and recommendations for generating a MEC-based
standardization and evaluation task. The IOTA task developed and evaluated the usability and
usefulness of a prototype rich client Influence Operations Training Aid (IFOTA) for use in the
39th Information Operations Schoolhouse‘s introductory and advanced IO planning courses.
IFOTA, which currently supports psychological operations (PSYOP), military deception (MD),
operations security (OPSEC), public affairs (PA), and counterintelligence (CI), provides a
structured planning environment for developing and deconflicting IO course of action (COA)
recommendations and developing associated briefings.
2.0 INTRODUCTION
The IOTT and IO Training Aid IOTA project, Delivery Order 08 under the Information Warfare
Effectiveness (IWE) task, was conducted by the Air Force Research Laboratory (AFRL) 711th
HPW/RHA during the period 25 March 2004 through 24 May 2010. IOTT/IOTA comprised two
distinct tasks: the establishment of Mission Essential Competencies (MEC) for Information
Warfare Flights and the development of the Information Operations Training Aid (IOTA). The
MEC effort was accomplished by Aptima, Inc. under the direction of prime contractor SRA,
International, Inc.. The earliest phase of the IOTA effort was initiated by Metrica, Inc.; the effort
was then transitioned to SRA International, Inc., which became solely responsible for its
completion. The IOTT/IOTA project‘s purpose was to conduct and support research and
development activities to improve the overall effectiveness of Information Warfare (IW)
operations. This report discusses the accomplishment of the IOTT/IOTA project.
2.1 Task One: Mission Essential Competencies (MECs)

The IOTT MEC effort objectives were to apply the 711th HPW RHA MEC methodology to:
1) define competency-based training requirements, 2) identify competency ―gaps‖ in operational
training, and 3) identify training methods, tools, and performance measurement criteria for
individual, flight, and squadron level combat mission readiness. Task One employed a functional
work analysis of three AF IWAS flights to identify cognitive components of the MEC construct
(including the MECs, supporting competencies, knowledge, skills, and developmental
experiences) and to analyze and evaluate training gap impact. Data collections were
accomplished in two workshops at each of the following: the IWAS, select Information Warfare
Flights (IWFs) within the Air Operations Center (AOC), the Network Operations Division
(NOD), the Air Force Computer Emergency Response Team (AFCERT), and Integrated
Network Operations and Security Center (INOSC)-East organizations.
The initial workshop tentatively identified MECs; the second workshop obtained feedback and
refined the initial collection. Specific focus was placed on identifying interconnections among
knowledge requirements, knowledge development, and information/knowledge exchange for the
1
Approved for public release; distribution unlimited .
organizations studied and their higher headquarters, customers, and supporting organizations.
Task One products included the following: 1) a recommended approach to bridge information
exchange gaps among IO units, 2) a set of standardization and evaluation techniques for the
IWAS flights, and 3) recommendations for generating a MEC-based standardization and
evaluation task. The interim and summary reports on conduct and results of the IOTT MEC
project were delivered to the government for publication separately from this report.
2.2 Task Two: Information Operations Training Aid (IOTA)

The objective of Task Two, the IOTA effort, was to integrate, demonstrate, and transition
advanced training and rehearsal technologies to facilitate successful integrated combat operations
for IO Warfighters. The effort was to provide science and leading edge technology to develop
and demonstrate an innovative training aid for Influence Operations (IFO), called IFOTA. The
effort included transition of an existing customer-mandated planning capability into a training
aid to expedite, enhance, and enrich the training of inexperienced Influence Operations trainees
in the successful planning and integration of IFO campaigns. The effort was envisioned in two
parts. The first part encompassed the development of prototype software modules and supporting
documentation, scenarios, and training materials. Proof of concept was demonstrated through
testing in a simulated classroom exercise. The second part focused on an empirically based
evaluation and assessment of the prototype software‘s usability and usefulness. Task Two
products delivered to the government were the IFOTA software and software training, a user‘s
manual, and a formal evaluation of the usability and usefulness of the IFOTA software. During
the course of the effort, the IFOTA software task was updated to incorporate a new module, a
change in platform and the addition of several functions. In consequence, the IFOTA software
deliveries were incremental; the final iteration was IFOTA version 4.0, an Eclipse-based rich
client platform (RCP) with both student and instructor modes and five IFO planning modules:
PSYOP, MD, OPSEC, PA and CI. IFOTA 4.0 incorporated both tree and Gantt-style timeline
views of the integrated, effects-based IO plan, which associated tasks with objectives and
measures of merit and a filterable, map-aided scenario selection interface.
Figure 1. IFOTA opening interface and example plan tree view
2
The primary stakeholder for the IOTA effort was the 39th Information Operations Squadron (39th
IOS) at Hurlburt Air Force Base in Florida. The 39th IOS is U.S. Air Force's premier Information
Operations and Cyber Formal Training Unit. Four courses are taught there: 1) the Information
Operations Integration Course (IOIC), 2) the Signature Management Course (military deception
and operations security for wing level SMC officers), 3) a military deception course for
operational level planners, and 4) the Undergraduate Network Warfare Training course. IO and
Cyber schoolhouse classrooms are equipped with cutting edge communication and computer
systems, including secure video teleconferencing and fiber optic infrastructures; software
applications include the Information Warfare Planning Capability (IWPC). The schoolhouse is
designed to support real-time war gaming and instruction at multiple security levels.
The IFOTA tool was initially designed to meet IFO training support needs expressed by the
instructors for the IOIC, required training for Airmen assigned to IO flight billets; IFOTA was
intended to promote guided discovery within scenario based training, to accustom students to
work within the conceptual framework of the IO portion of the Joint Air Operations Plan
(JAOP). It was also to serve as a test environment for the course capstone exercise, a role-
playing effort in which students work within a scenario to plan and submit the IO portion of the
JAOP. Promoting in depth preplanning analysis, IFOTA was envisioned as an adjunct to rather
than a replacement for the current IO planning program of record, IWPC. [Note: Although the
IOTA project was initially conceived to eventually encompass the full range of Information
Operations, the project was descoped to focus on IFO training.]
2.3 IOTT/IOTA Accomplishments

The IOTT/IOTA project produced both Information Operations training guidance and a
prototype tool for instructional and refresher use at the 39th IOS and at the IWFs. The project
built upon prior work by Aptima, Inc., in MEC definition, and leading edge software design
approaches being developed by SRA International, Inc. It also drew from guidance created by
the IWF and planning communities (e.g., handbooks, exercise materials, training briefings), and
to some extent, from published work done by Metrica, Inc., for AFRL that had begun to break
down IO tasks. The products have been successfully shared with the operational community. The
IOTA product, the IFOTA tool, was demonstrated at the 2007 JFCOM Information Operations
Planning Capability-Joint (IOPC-J) Warfighter Analysis Workshop, the 2008 Air Combat
Command Warfighter Analysis of Innovative Technologies and Concepts (WAIT-C) interactive
technology demonstration and at the 2006 and 2007 Phoenix Challenges, where it received
enthusiastic response from IO professionals. In addition, the structured planning and analysis
framework IFOTA offers drew praise from a range of AOC planners, who found its
methodology readily generalizable to strategic and operational planning.
The body of this report describes the data collection (knowledge elicitation) and design plan,
encompassing the work domain analysis (including training gap analysis), work-centered design
approach (including usability and utility testing), and proof of concept for the IOTA project. The
IOTT MEC report, as noted earlier, was delivered to the government separately and may be
requested through the government project manager.
3
3.0 APPROACH
Knowledge elicitation for the IOTA task was accomplished at the 39th IOS at Hurlburt Air Force
Base, FL. A joint Cognitive Systems Engineering and Systems Engineering (CSE/SE) team of
design specialists made two trips to collect information on site. Feedback on collected
information and requirements analysis was accomplished via teleconference.
3.1 Cognitive Work Analysis

During the course of the IOTA effort, cognitive task analysis laid the foundation for the IFOTA
design work. The design team employed cognitive task analysis (CTA) to elicit, document, and
evaluate information about the work domain and the users‘ work-centered requirements. CTA is
an integrated set of methods and tools for uncovering both the cognitive processes that control
task performance and cognitive capabilities employed in task performance. Over the course of
the IFOTA task effort, the design team evolved its CTA philosophy and methodology to refine
its processes and incorporate lessons learned in how to successfully translate CSE products into
design requirements that can be readily understood and used by the SE development team. A
foundational concept for CTA development is that insertion of an aiding tool effectively changes
the work environment, and therefore, business processes, opening opportunities for business
process redesign (BPR). The IFOTA team integrated several Unified Modeling Language (UML)
modeling techniques to enhance the usefulness of their elicitation opportunities and improve
communication between cognitive systems and software engineers. There are four elements of
the IFOTA CTA process that bear mention:
 Modeling of human-to-human, human-to-system, and system-to-system workflows to
capture the current work environment and support redesign analyses.
 Frequent user validation and course correction, incorporated into an iterative design
process, is emphasized. Users get a chance to see how their inputs are interpreted in
prototype designs and to ensure both that what was heard was what was said and that new
ideas sparked by the design evolution are captured for the next iteration.
 Requirements traceability is maintained, specifying sources including underlying doctrine
and command direction as well as situational constraints and restraints and insights from
individual experience.
 Context is maintained through the organized presentation of requirements in terms of the
situationally defined work functions they support.
To serve the customer, the aiding system end user, the design team conducts unstructured
interviews, employing elements of several CTA methods for elicitation. After extensive domain
research, a joint CSE/SE team approaches the user in the user‘s workspace; the team conducts
cognitive walk-throughs of both typical and atypical work days to capture the range of work
activities in context of variable workload conditions. The team examines critical incidents for
cause and effect relationships (Flanagan, 1954) that extend its understanding of the work
environment. The team also conducts field observations and collects example work artifacts
(Eggleston, 2003 ). The team then transforms raw notes into concept maps (Moon, 2004); for an
example, see Figure 2. Other initial artifacts include product-focused procedural task diagrams
(Militello & Hutton, 1998) and communications diagrams (Moon, 2004) to capture work
structure. The IFOTA CSE/SE analysis lays out operational and system requirements,
4
maintaining traceability, and employs use cases and other SE documentation methods to ensure
system function meets operational needs (Zhou & Burns, 2004).
Figure 2. Concept map of Capstone Exercise from IOIC instructor interview.
5
3.1.1 Applied Cognitive Task Analysis (ACTA)
The CTA method employed is a modified form of the Applied Cognitive Task Analysis (ACTA)
method developed by Klein Associates. The ACTA method (Militello & Hutton, 1998) employs
verbal protocols to elicit work domain knowledge. According to Militello and Hutton, ACTA
provides streamlined CTA methods developed for training practitioners and systems designers to
elicit and represent cognitive components of skilled task performance, and the means to
transform those data into design recommendations (p. 1619). Developed under a Navy project,
the complementary elements of the ACTA elicitation method include:
 Task Diagram Interviews (scoping the task, building a roadmap of goal-oriented process)
 Knowledge Audits (determining what operators must know to successfully complete
tasks, capturing work patterns through structured interviews)
 Simulation Interviews (capturing decision points, judgments, and work-arounds through
generative interviews, expanding and refining the decision criteria for task
accomplishment)
The IFOTA design team used task diagramming interviews, abbreviated knowledge audits and
focused simulation interviews to draw requirements from the operational community. The
information obtained was represented in concept maps and task diagrams (Figures 2 and 3), in
which the capstone exercise and Counterintelligence planning process were mapped. In concert
with the above techniques, the design team documented field observations in order to capture the
realities of work activities in the work environment.
Analysis of the information collected during the knowledge elicitation phase is supported by
multiple methods. Process flow charts, Integrated Definition for Function Modeling (IDEF0),
event sequence analysis, and sequence diagrams are familiar methods to display the march of
events, decision points, and feedback loops of the tasks under investigation. The linear
appearance of the process flow and IDEF0 methods have been criticized in the past for obscuring
the complexity of the event sequence (Figure 3). Concept mapping, although traditionally used to
graphically convey information in the form of statements, is sufficiently flexible to permit the
investigator to lay out information to suit the needs of the analysis.
3.1.2 Work-Centered Design (WCD).

The guiding principles for the IFOTA CTA were found in AFRL‘s work-centered support
system method, which was developed to support work-centered design, a methodology that
emphasizes work as a dynamic process comprising problem solving/decision making,
collaboration, product development, and work management, each of which must be explicitly
addressed in the design process (Eggleston, 2003).
The IFOTA task developed a contextually based perspective on the work-centered design
concept and our focused application of several CTA knowledge acquisition capture and analysis
strategies was modified to directly support software design.
6
CI
Begin CI-specific Process With Respect to IO Plan 2
Concurrent processes O
D PS
a tI EC
re Su
Th Identify Potential Assist Identify Critical pp
Hostile Threats Information (CI) or
t
Black List:
Categorize by Threat Assist Identify Possible Individuals who pose a
Immediacy (now/future) Vulnerability Indicators recognized danger whose
capture and detention are
a priority.
For each supported tactical task
Identify Specific Assist Identify

CI Targets in AOI Adversary Threat Gray List:
Those individuals whose
loyalties and inclinations
Justify Selection Assist Justify Selection are currently unknown.
Unsure which side if any
these individuals support.
Categorize CI Targets in Assist Define Critical
White/Gray/Black Lists Information Risk Rating White List:
Individuals believed
(through action or
otherwise) to be favorable
Justify Categorization Assist Define
to our interest
Vulnerability Risk Rating
Installations:
Identify Threat Any installation that
Installations Assist Define Adversary houses or has housed
Threat Risk Rating threat individuals (Military,
Espionage Police,
Identify Threat Research/Tech Centers,
Organizations & Teams Review OPSEC Embassies. etc.)
Risk Algorithm Results
Organizations/Teams:
Identify CI-Valuable Organizations with goals
Documents & Materials Assist Prioritize OPSEC contrary to coalition
Risks goals, potential resistance
centers, covert groups
Justify Selections
Coordinate/Deconflict
OPSEC only ?
Consult w/Group
Coordinate w/ &
Apprise IO Team
Document Coordination
Document Coordination
Figure 3. Counterintelligence process flow ( based on interviews with CI subject matter experts)
3.1.3 CTA Artifacts, WCD and Software Requirements Specification

The context of work-centered aiding system design is business process reengineering (BPR)—
the insertion of an aiding system changes the business process. Therefore, the CSE/SE team
approaches each collection effort as an opportunity to document and analyze the current and
projected business process. This perspective suggests a number of commonly accepted systems
engineering methods to document analysis in a format that is readily understood and used by
CSE/SE staff.
The software design information that is captured through CTA is initially embedded in CSE
artifacts. However, once environmental constraints, task sequences, information exchanges,
decision requirements, task goals and products are identified, the information can be represented
in standard SE decompositions, such as flow charts (e.g., cross-functional flow charts, process
and information flows) and UML diagrams (e.g., sequence diagrams, use cases). This serves two
important functions: 1) it permits the CSE staff to control the translation of design guidance into
7
design specification and 2) it provides uninterrupted traceability from data collection to design
requirements and design execution. Figure 4 illustrates CSE/SE translation.
Other General Capability Requirements

• Links to Library, World Fact Book &
Rendon Group products IFOTA
• Login with permissions and paths
• Map-based and text search capability
• Save/Autosave with predefined paths has •Find scenario
• Multiple window/Arrange all capability •Open/edit/create scenario
• Cut, Copy & Paste within and between Common •Access support data (World Fact Book, Rendon Group)
scenarios and external documents •Identify Operational Phase (Prehostilities, Lodgment,
• Unlimited Undo/Redo for all text entries Initial = Decisive Combat/Stabilization, Follow-Through,
• Help feature Posthostilities/Redeployment)
• Contextual help Functions •Enter Operational Objectives/SI
• Print capabilities •Enter Tactical Objectives/MOE
• Graceful degradation splits into •Enter Tactical Task/MOP
PSYOP MD OPSEC PA CI EW/NW Instructor

Module Module Module Module Module Module Module
crosses crosses
modules modules
RFI HVT/HPT
Summary Deconfliction Justification
Management Identification
Function Function Function
Function Function
•Provide RFI template •List MAJCOM Region/AOI •Deconflict Tactical Objective •Justify Tactical Objective •Crosscheck modules for
•Accept RFI input •List Country/Locale •Deconflict Tactical Task •Justify Tactical Task common target sets
•Simulate sending RFI •List Operational Phase •Deconflict Discipline-specific •Justify Discipline-specific •Crosscheck modules for
•Store RFI requests •List Operational Objective/SI Supporting Task Supporting Task related target sets
•Track RFI status •List Tactical Objectives/MOE •Deconflict Target Audience •Justify Target Audience •Crosscheck modules for
•Crosscheck RFIs •List Tactical Task/MOP •Deconflict Target Action •Justify Target Action time-critical targets
from other modules •List Discipline-specific •Crosscheck modules for
Supporting Task/MOP established HVTs/HPTs
•List Target Audience
•List Target Action
•List Rationale
Figure 4. IFOTA CSE to SE information transfer.
3.2 IFOTA Knowledge Elicitation

The IFOTA knowledge elicitation was conducted over the course of two trips to the 39th IOS and
was supplemented by e-mail and teleconference. The first trip laid the groundwork for the
training support effort. Instructors explained course objectives and measures of merit and
provided student handbooks, supplementary literature (e.g., AF doctrine documents), sample
course curricula, and course briefings. The 39th IOS instructors conducted tours of the facility
and described typical class activities. Instructors noted the range of student expertise and the
need to challenge class members according to capability. The second trip demonstrated a web-
based version of the IFOTA concept provided by subcontractor Metrica, Inc. The demonstration
and evaluation of the browser-based tool held on-site with the 39th IOS sparked further
requirements specifications that led to the transition of IFOTA from a web-enabled form-based
version to a fat client application with more design flexibility and more capability.
4.0 RESULTS AND DISCUSSION
4.1 Knowledge Elicitation Trip 1

The initial knowledge elicitation trip was hosted by the IOIC instructors at their 39th IOS facility
on Hurlburt AFB. Interviews were arranged with PSYOP, MD, PA, and OPSEC representatives.
As the tool to be developed was to be jointly evaluated on utility and usefulness, the data
collection was organized around these two themes.
At the time of the knowledge elicitation, the IOIC was transitioning from a ten-week to a six-
week initial qualification training course designed to train IO planners assigned to IWFs. The
course focused on the fundamental knowledge required to leverage IO within air operations
planning. It taught the basics of IO, Air Force and Joint doctrine, executing organizations and
8
operational functions through lectures, seminars, participatory planning activities and a capstone
exercise in which student teams planned an integrated IO campaign. At the time data collection
was initiated, the curriculum also included introduction to the Joint Air Operations Center
(JAOC) and Joint Air Operations Planning, air warfare employment and concepts, fundamentals
of IO disciplines, and IO integration into deployed air power structure and processes.
While students represented a breadth of rank and career fields, the majority were either currently
assigned or will receive assignment to slots within the AOCs. Classes of approximately 20
students were split into four teams and practiced interpreting planning guidance, assessing
situations and developing and deconflicting IO planning recommendations in support of the Joint
Force Air Component Commander (JFACC). Emphasis was placed not only on leveraging IO
targeting options but also on plan integration (integrating IO methods to achieve an objective or
objectives) and on plan deconfliction (resolving potential conflicts among component planning
efforts). Several points were raised that were overarching design influences. The first two issues
regarded fostering good planning skills: 1) promoting identification of task terminators and
effectiveness metrics, and 2) promoting probabilistic thinking (i.e., forecasting probability of
success) and exploratory excursions in support of forecasting. The third issue involved ensuring
ability to teach to individual capabilities, challenging a range of student expertise.
The desired system, as described by instructors, would allow students to conduct structured,
collaborative, integrated IO planning—from the identification of operational and tactical
objectives and tactical tasks (with associated success indicators and measures of merit) through
the development of proposed task actions and support requirements. Instructors expressed a
teaching for mastery objective. Their ideal system would permit instructor-supervised students to
build a complete proposed plan and would also capture student rationales, supporting
documentation, instructor comments, and deconfliction actions. It would support forecasting
activities such as ―What if,‖ sensitivity, and impact analyses. Initial requests considered a
feedback function that would identify missteps as they were made and display a comparison of
―right path‖ vs. ―wrong path‖ cascading effects. The system would support in-class instruction,
practice exercises, and testing.
The baseline system concept and tasking was derived from a PSYOP planning tool (PSYOP PT)
developed by Metrica—a browser-based tool with several PSYOP scenarios (e.g., refugee
repatriation, insurgency support, population protest, force surrender) and a subjective rating
method for calculating anticipated change resistance. The IO methods shared a common focus on
identification of target audience (TA) and employment of behavioral shaping methods.
Methodologies, however, were discipline-specific and required considerable adjustment of and
extension to the Metrica PSYOP trainer capabilities. The PSYOP method assessed current vs.
desired TA attitudes to find a behavioral shaping difficulty index; command guidance provided
themes and messages. OPSEC employed its own risk assessment methodology. OPSEC was
noted as having highest potential for inter-discipline conflict, as the other disciplines typically
exploited friendly activity indicators, whereas OPSEC was focused on obscuring those
indicators. MD methods, focused on redirection of adversary attention and perception control,
were highly integrative and frequently required coordination with and active cooperation of sister
services as well as other IO disciplines. Student efforts were to be guided, step-by-step, through
each discipline‘s process. Specific discipline references provided means as well as methodology.
9
Students were to cite both applicable doctrine and the intelligence information used to support
their strategies. Developing student attention to the relationship between objectives/tasks and
measures of merit (e.g., measures of effectiveness and measures of performance), as well as the
identification of termination criteria, were to be emphasized.
The ongoing documentation of the complete student planning effort would allow the instructor to
correct errors and respond to student queries on the fly, understand underlying student thought
processes, and check references for appropriateness. Excellent plans would be archived for future
use in instructional scenarios. Instructors and permitted students would create and archive whole
and partial IO example plans for use in classroom instruction. Desired planning visualizations
included a map-based view for archived plan selection and a holistic hierarchical plan view.
Instructors would manage student log-ins and permissions, plan archives and student records.
Reachback simulation was considered very important. The system, as initially envisioned, would
require a browser capability, connections to Secret Internet Routing Protocol Network
(SIPRNET) and Joint Worldwide Intelligence Communications System (JWICS) as well as to-
be-determined databases (e.g., Sensor Harvest), local area network access (server-based
archives), a recorded instant messaging, and possibly, chat capability, shared document access
and editing management. Figures 5 and 6 illustrate the intended system use, as understood from
the initial data collection. Forecasting and feedback functions, while discussed in the idealized
system description, were not incorporated at this time.
Figure 5. Planned Student Activities within IFOTA as initially described.
10
Figure 6. Planned Instructor Activities within IFOTA as initially described.
As shown above, the knowledge elicitation drew forth an idealized system description that was
identified as a goal to work toward in a spiral design model. Initial funding for the system
covered the basic design of a student module supporting four disciplines (PSYOP, MD, OPSEC,
and PA), a searchable plan archive and the instructor module for managing student log-ins. The
next iteration incorporated a CI component, undo/redo functions, a clickable map view for plan
selection, and extended the instructor module to capture student grades. The next iteration
provided a spell check function and Gantt chart plan timeline display. Neither the feedback
function nor the exploratory excursion or probability of success algorithms were funded.
The following section presents an example of the discussion points that the elicitation raised. A
list of derived system requirements follows.
4.1.1 Elicitation Findings/Discussion Points for Usefulness (Focus on the Task)

Job Requirements
1. Mission-level Expectations:
a. Students will be taking the role of AOC staff and will have to consider how their
input factors into the overall mission plan
Issue: None currently identified
b. Students will take roles of PSYOP, PA, OPSEC, and MD planners. Their plans
should show synergistic effect of integrated IO plan.
Issue: Links (especially dependencies) among plan elements must be manifest. Timing
considerations must be clear; temporal impossibilities should raise flags.
c. Expectations are that students will push to have the training tool made operational.
Issue: The more realistic the training tool is, the more likely students are to push for it;
a very realistic training tool will be easier to operationalize. However, the train as you
fight concept may become an issue, unless this tool is adopted into a system of record.
d. The students must integrate and deconflict their recommendations with other IO
disciplines
Issue: A vision of how the deconfliction aspect will work has not yet been articulated.
11
Trainer Tool Use
1. Tracking:
a. Trainers have not yet considered all they want the tool to track. They exhibited a
positive response to the suggestion that the tool might include a mechanism for
tracking exercise and test performance. System tracking would lighten the trainer
workload.
Issue: Any tracking expectations should be worked out now to aid the designers‘
planning process. Trainers indicate they will be giving individual grades and group
grades for group efforts. How to track that should be thought out in advance as well.
2. Testing:
a. Trainers expect to use the tool in both in class exercises (partial tasks) and the
capstone exercise that will permit students to integrate all they have learned in the
course.
Issue: Trainers indicated a desire to be able to see what students were doing in order to
supervise and aid.
b. Trainers want to integrate students‘ capabilities in team exercises and stretch
everyone. They want to elicit thinking through student identification of options and
variables. Trainers suggest that the tool include an option that allows them to
increase exercise difficulty based on student performance (―teach to each‖ versus
―teach to mean‖). An example is the ability to go from a two-channel ―on/off‖
scenario to a five-channel one, increasing the number of options in the variables
offered. They also suggest adding an assessment method to tell what would have
happened if the student had chosen differently, following the branches, and a
method to anticipate sequels.
Issue: Currently there is no scalability in the training module. Specific requirements for
extension modules are yet to be determined.
3. Feedback:
a. Subjective weightings/rankings are only as good as the student‘s expertise and
information base. The exercise of decomposing the factors that affect the TA and
watching how changing weights for individual factors changes the probability of
success is valuable in itself. Trainers suggested that they would like to see feedback.
They envisioned the following training scenario:
 For a given exercise, the system provides a series of variables that form
three distinct paths to follow (Path A=50% of the solution, Path B=100%,
and Path C=25%).
 System collects data on the students‘ selection of variables and how they
justified them.
 System identifies the incorrect paths and the shows cascading effects from
following the wrong route.
 System shows the correct path and its cascade of effects.
 Trainer tracks student progress; if at any point, the student chooses A, the
trainer can show why that path is not optimal, but if the student chooses C,
the trainer knows to take him/her back to basics.
12
Issue: Hardwiring, as described above, cuts down on options, but the trainers say that is
all right for a training aid. Providing only this option would not necessarily provide a
close match with reality, where there is often no right answer.
b. However, the system could also be designed to allow freedom of
thought/movement, offering a best choice answer and several others that varied in
degree of usefulness, and allowing the student to work out a best possible solution.
In this mode, the system again would show possible outcomes.
Issue: Including both of these modes would allow the student to progress from canned
classroom scenarios to real world scenarios. It would also provide a method for
providing increased difficulty for more able students.
Student Tool Use
1. Student Task:
a. The classes mirror every step of the planning process, taking the student from
―hands-on‖ trainer-supported exercises to a ―hands-off‖ capstone training effort.
Trainers provide the students with a set of Joint Task Force (JTF) objectives and
plug in standardized objectives for the exercise, depending on the scenario (e.g.,
eight objectives for phase one). Influence operations objectives will be the sub-
objectives (influence nation command, influence political structure, etc.) Each
individual discipline can answer the need. Students learn to write their own
objectives and how to modify Air Staff concepts to perception management needs
and integrate counter-intelligence perspectives. Students must learn to support why
a non-kinetic option is preferable to convince the AOC. They must be able to
present their plan, provide appropriate details, make a strong argument, show the
effects and the effects desirability, and defend the plan‘s solution.
Issue: IOTA must be updated to include the entire planning process; the designers
intend for the tool to mirror the language used in AOC planning. As the AOC planning
process is under development, language changes may have to be updated/updatable.
(measures of merit, should be included in the program, but need to be adjustable as
analysis renders them inappropriate.)
b. In the new exercises, all targets go ―on deck‖ no matter how they are to be
prosecuted, only the restricted target list will be retained. Kinetic and non-kinetic
options will be de-conflicted (e.g., will ensure that there is no close air support
activity scheduled for the vicinity of leaflet drops). The point is to integrate the air
picture for the day and deconflict all missions at once.
Issue: How the deconfliction aspect will be managed is not yet articulated.
c. Students will practice assuming different roles in the AOC. Hands-on exercises will
require both individual effort, with each student using different expertise to do
his/her own portion, and group coordination, integrating and deconflicting
individual efforts. Lesson includes teaching students how to present to staff
estimates of non-kinetic actions. In order to accomplish the task, students also must
learn how to manage group dynamics.
Issue: How the students will collaborate is not yet articulated.
2. Task Support:
13
a. Classification: At IOIC, students will stay on JWICS, with SIPRNET and Non-
Secure Internet Protocol Router Network (NIPRNET) for research and reach-back
capabilities. MD will be done at the SECRET/NOFORN level, and will incorporate
national level entities on JWICS. Exercises may require going to a high level
classification.
Issue: Unclassified paradigms for scenarios will need to be built; there will be nothing
classified in the developmental design. For the MD section, the design will need to
separate high and low classification aspects (multi-level security?).
b. MD, OPSEC and PSYOP employ somewhat different terminologies to reflect their
different perspectives. OPSEC is the only track that asks the student to look at how
their plan will both impact US activities (giving Indications and Warnings; I&W)
and US perceptions.
Issue: Language usage will have to be carefully documented and managed.
Additionally, the OPSEC track may pose difficulties for students as they have to focus
their objectives differently than in PSYOP and MD. The OPSEC objective is to remove
I&W, whereas the MD objective is to exploit them.
c. How well the students know where to get data will vary by student; students are
given lists of urls in class that the instructors have compiled.
Issue: The instructor-supplied urls can be integrated into the internet browser as
favorites and the file emailed for importation in the students‘ home systems.
d. Students must factor in cultural analysis issues (e.g., how to communicate with non-
literate populations). Students are taught to leverage preconceived adversarial and
military mindsets.
Issue: PYSOP recommendations are turned over to the Army for implementation. The
actual method of implementation is not determined by the student.
e. In the current version of the tool, the focus is on the factors that influence Target
Audience behavior, the estimated difficulty friendly forces will experience directing
TA behavior toward the goal state.
Issue: The goal state is represented by standard PSYOP objectives; the actual PSYOP
plan is not captured when users project probability of success influencing TA behavior.
f. PSYOP doctrine is in a state of flux. The new JP 2.5.3 draft hasn‘t been signed yet;
neither has the new OPSEC draft.
Issue: The changes in doctrine will probably impact lesson plans and decision support
tool requirements. Additionally, according to the trainers, current AF training focuses
on deliberate and contingency planning for force execution missions. Training doesn‘t
cover how to plan for Humanitarian Assistance (HA), Noncombatant Evacuation
Operations (NEO), and Civil Affairs (CA) outside of hotspots in the Middle East.
Training doesn‘t cover planning for nation building or planning for handing over an
area to the ambassador for reconstruction. Training doesn‘t cover how to redeploy,
reconstitute or employ forces in interim periods and how to get people in and out
safely. PSYOP is concerned with developing ways to endear US forces to the
population to reduce risk and increase cooperation. Any future effort to add in these
training modules will extend required scenarios considerably.
14
4.1.2 Elicitation Findings/Discussion Points for Usability (Focus on the User)
User Characteristics
1. Class Demographics:
a. Joint class members are integrated by service and rank (range from E-2, E3 to Lt
Col). Members exhibit differential levels of expertise; levels of expertise range
from 2 to 3 years (beginner) to 15 years (expert).
Issue: Class tools need to be scalable to teach and test multiple levels of expertise.
b. There are one to two instructors per ~20-person Influence Operations (IO) class.
The class focuses on Falconer AOCs. Class population comes from the nine
Information Warfare Flights (IWFs). Class constitution is governed by the gaining
unit and their needs. Percentages change from class to class.
Issue: Student need for instructor attention will vary. Class tools need to be self-
supporting to some degree to allow students to work independently.
c. Students are taught how to support all IO disciplines used in AOC but when they
report to their IWFs, they will fill whatever slots are open, performing intelligence
preparation of the battlespace (IPB) for deliberate planning and continuous update
functions. During contingencies, approximately ½ the flight will go with the AOC;
the rest will remain with the IWF, supplying reachback.
Issue: There is a concern that students may forget lessons that aren‘t reinforced over
time.
2. Student Computer Expertise:
a. The tool is Hyper Text Markup Language (HTML)-based and will be accessed as a
web page. The web page interface is desirable as all students should have
familiarity with a web environment; students are expected to know how to use
typical internet browser functions.
Issue: The tool needs to incorporate all the capabilities of a web environment
(highlight, copy, paste, save as). Aids should include pop ups, hover, find, and drill
down capabilities. Users should be able to jump to mail to output to other
organizations.
b. Student briefings, which simulate presentations to AOC decision makers, are done
in PowerPoint (however, trainers express a desire for the system to integrate with
all MS Office).
Issue: The tool currently supports copy and paste functions, but automating transfer of
information from the tool to the PowerPoint presentation would save time and effort.
Trainers want the program to integrate with Microsoft Office and be able to ―push‖ to
Theater Battle Management Core Systems (TBMCS).
Task Characteristics
1. Task Overview:
a. Tasks are constrained by class time. In the first part of the course, trainers give an
overview of the different disciplines, the standard measures of behavior, and how to
measure behavior. In the second phase, subject matter experts (SMEs) give units of
instruction on their specific disciplines, use slides accompanied by slide notes. The
course moves from rote memory exercises to demonstrations of subject matter
expertise.
Issue: Currently, students get three weeks of practice in the planning stage. Eventually,
trainers will integrate practice exercises into more of the course. Instructors and
15
students will create new scenarios to add to IOTA‘s existing scenario database. As
more information is acquired, there will be a need to update the influence operations
factors to reflect increased understanding.
b. Using the tool prototype, for a given scenario, students should be able to identify
operational and tactical objectives and associated measures of effectiveness (MOEs),
characterize the target audience and identify opportunities, limiting factors
(LIMFACs) and susceptibilities, and rank and weight the susceptibilities. The
students should be able to give a level of confidence in information and a level of
effectiveness (ability to reach the susceptibility); the student should be able to weight
the likelihood of success.
Issue: Students will have access to SIPRNET, NIPRNET, and JWICS. The user must
be able to integrate database access and exercise activities. The students use IWPC,
InfoWorkspace (IWS), and Information Operations Navigator (ION); some degree of
IOTA integration may be required.
c. To complete the task, students should be able to use available databases to research
culture and leadership aspects to determine how to affect the population and the
leadership.
Issue: Navigation between planning and decision support tools and supporting
databases should require minimal effort and minimal time. No picture of what the
screen will look like while the student moves between application and reachback
capabilities is currently articulated. How the system looks, how the students will keep
track of where they are between applications, how quickly and easily they can navigate
and how quickly and easily the database supports their information quests are all
human factors integration issues.
GUI Environment
1. Common Look and Feel:
a. The IOTA tool, like some other applications students will use, is web-based. Other
applications are MS Office-based or employ the standard Windows work
environment.
Issue: The IOTA tool graphical user interface (GUI) should leverage student familiarity
with the MS Internet Explorer web browser and Office suite GUIs. It should also
leverage all Windows ―Help‖ capabilities and user aids (Help topics, Table of
Contents, Index, Glossary, context-sensitive Help, etc.)
Operational Environment
1. Environmental Characteristics:
a. Students will be working as teams to create their recommendations. Students will
represent the different disciplines/roles found in the AOC.
Issue: Students need to be able to work alone or collaboratively. Students need to be
able to deconflict their respective plans.
16
4.1.3 Requirements
1. Usefulness Criteria (How effective and flexible is IOTA in supporting the work of the
IO instructor and student?):
a. Effectiveness
i. Ensure IOTA supports IO planning for all phases of an OPLAN
ii. Ensure Objectives are entered in correct terminology and structure and can
have associated success indicators and measures of merit inserted
iii. Account for uniqueness of each track (e.g. MD process and target distinctions
from PSYOP process/targets, OPSEC process/targets)
iv. Take advantage of synergies among tracks
v. Account for risk as well as probability of success in presentation of output
vi. Ensure each module (PA, MD, PSYOP, OPSEC) reflects the process for that
track (not all processes are the same)
vii. Ensure IOTA ontology/taxonomy mirrors the language of the course materials
and the relevant discipline
viii. Ensure IOTA reinforces the instructors presentation of the course work
 IOTA presentation mirrors IO planning process taught in lessons
 IOTA provides cues/prompts when reachback is required
 Import methodology and format for reachback simulates process
taught in lessons
ix. Ensure IOTA reinforces student understanding of the course work
 IOTA presentation is familiar to student and mirrors process taught in
lessons
 Understanding of when reachback is needed is clear and
straightforward
 Easy cues/prompts to access needed data sources (reachback)
 Student can import reachback data as required
 Interoperability with other applications – student can provide model
output in required presentation formats
x. Ensure IOTA provides adequate scalability
 IOTA can be used for beginning and challenged students and advanced
students can take advantage of features to push the analysis envelope
and bring in more expertise and sophistication
 Ability to control versions, configuration of tool and data
xi. Ensure IOTA supports student/student and student/instructor collaboration
 Input and results be exchanged, shared
 Framework to support collaboration
 Internal (within schoolhouse) and external (reachback) collaboration
 Ensure ability to integrate IO track (MD, PA, PSYOP, OPSEC) plans
(build supporting objectives and target assessments)
 Ensure ability to de-conflict IO track plans (flag objectives and
analyses that will negatively impact plans for other IO tracks)
 Output directly supports presentation of an integrated, de-conflicted IO
plan for a given scenario, mission objective
17
xii. Ensure IOTA provides adequate extensibility
 Students can use this tool when they report to their assigned units
 IOTA can be implemented in IWPC or Sensor Harvest as a tool to
support deliberate and crisis action IO operational planning
 Compatibility/extensibility to ION (joint community)
xiii. Ensure IOTA provides tracking, both of student rationales and grades
 A way to capture student thought process for each input to the model
(error traceability, rationale, justification, support for end
recommendations and outbrief) – notes pages
 Three-level (red, yellow, green) student grading at completion of
model runs with appropriate feedback and indications of where errors
were made, improvements could be made
 Guided discovery
b. Flexibility
i. Easy to update and expand to advanced versions, new modules, refined
modules
ii. Ability to access pre-canned objectives, modify pre-set objectives, add new
objectives
2. Usability Criteria (How easy is this tool to use?)

a. Communication/Integration
i. Ensure IOTA supports implementation on JWICS
ii. Ensure IOTA can access SIPRNET and NIPRNET source data
b. Situation awareness/Sensemaking
i. Ensure IOTA provides event and change detection
ii. Ensure IOTA provides visualization support
 Graphical display of ―what if‖ and impact analysis
 Progress bar to indicate what steps have been successfully
accomplished
 Buttons to move among track modules (PA, PSYOP, MD, OPSEC)
 Glossary
iii. Ensure IOTA maps output to what‘s needed for target planning presentation
(e.g. targeting sheet)
c. Error detection and recovery (student)
i. Ensure IOTA provides Help functions – useful, comprehensive, clear and easy
to use
ii. Ensure IOTA provides indicators of invalid input (e.g. weights) – ―need to re-
evaluate‖
iii. Ensure IOTA provides indicators of output that does not make sense
d. Predictive capabilities
i. Provide ―What-if‖ analysis
ii. Provide Sensitivity analysis
iii. Provide Impact analysis
e. Interoperability
i. Ensure IOTA search engine integration (reachback)
ii. Ensure IOTA provides pointers, aids to access existing data sources
18
 Databases (various organizations)
 Web sites (instructor bookmarks)
 Documents
 Media
 SMEs
iii. Ensure IOTA has a ―Send to‖ function for checking, collaboration
4.2 Knowledge Elicitation Trip 2

The second knowledge elicitation trip provided new opportunities to flesh out customer
requirements through examination of a proposed system design. The design was originally
intended to undergo user testing in a live classroom demonstration. However, the agreed upon
date for the demonstration occurred during a session break; in consequence, user testing was
done by instructors. A formal evaluation of the proposed system design, specifically directed
under the statement of work, was also conducted and submitted to the government. The customer
demonstration, coupled with the evaluation, illustrated the limitations of the employment of a
browser-based forms approach taken from the PYSOP PT. The user testing opportunity drew
forth more fully defined customer requirements, prompting the proposal of an RCP solution;
requirements definition was immediately initiated to support the design shift. It was during this
requirements collection that, in order to emphasize the Influence Operations nature of the tool
that its title became IFOTA. A partial representation of system requirements is presented in
Table 1. More complete requirements documentation is found in Appendix A.
Table 1. A Partial Representation of IFOTA Requirements.

General
1. The IFOTA shall be able to be installed and run on a JWICS system
2. The IFOTA shall have a Windows look and feel
3. The IFOTA shall have a main menu with submenus and toolbar with icon buttons
4. The IFOTA shall conform to Defense Information Infrastructure Common Operating Environment
(DII COE) and Xerox usability standards
5. The IFOTA shall open to a blank window
6. The IFOTA shall provide a file chooser to display existing files for selection
7. The IFOTA shall provide scenario search capability
8. The IFOTA shall provide a login function
9. The IFOTA shall allow the user to open existing files
10. The IFOTA shall allow the user to create new files
11. The IFOTA shall allow the user to save files
12. The IFOTA shall allow the user to modify files according to permissions
13. The IFOTA shall ensure students can't overwrite scenarios from library
14. The IFOTA shall allow students to modify (add/delete/change) their own work
15. The IFOTA shall allow the user to print whole files
16. The IFOTA shall allow the user to suppress printing Subject Matter Analysis & Research Toolkit
(SMART) input screens
17. The IFOTA shall allow the user to suppress printing SMART results
18. The IFOTA shall allow the user to print the scenario summary
19. The IFOTA shall allow the user to print single/multiple page(s)
20. The IFOTA shall allow cut, copy, and paste between fields, screens, windows and programs
21. The IFOTA shall allow unlimited undo/redo and repeat for all text entries
19
22. The IFOTA shall provide a Help function
23. The IFOTA shall provide contextual help
24. The IFOTA shall provide a glossary encompassing the terms from the Joint Air Estimate Process
(JAEP), IO joint publications (JPs), IO Air Force Doctrine Documents (AFDDs), and IO Air Force
Tactics, Techniques & Procedures (AFTTPs)
25. The IFOTA shall display software version and Program Manager/Developer contact information
under Help:About IFOTA
26. The IFOTA shall display descriptive titles on all windows and dialog boxes
27. The IFOTA shall permit the user to open, manage, and work in multiple windows (up to six?)
28. The IFOTA shall permit the user to open multiple scenario files
29. The IFOTA shall allow the user to open multiple modules in multiple windows
30. The IFOTA shall allow the user to open multiple instances of the same module
31. The IFOTA shall allow the user to open old scenarios concurrent with new scenario
32. The IFOTA shall allow the user to navigate through screens in a maximum of 5 steps
33. The IFOTA shall have PSYOP, MD, OPSEC, and PA modules
34. The IFOTA shall be extensible to include a future CI module
35. The IFOTA shall have a module that accepts/displays electronic warfare (EW) and net warfare
(NW) planning entries
36. The IFOTA shall have an Instructor module
37. The IFOTA shall use terminology that meets 39th IOS approval
38. The IFOTA shall use procedures that meet 39th IOS approval
39. The IFOTA shall identify and keep track of where each planner is within the 5 operational phases
40. The IFOTA shall identify and keep track of where each planner is within the 72--hour planning
cycle
41. The IFOTA shall display plans across operational phases and planning cycles
42. The IFOTA shall accept and maintain integrity of task branches
43. The IFOTA shall have a status screen that summarizes current status for each module
44. The IFOTA shall have a deconfliction/coordination function
45. The IFOTA shall recognize workgroup members
46. The IFOTA shall allow workgroup members to view each others' work
47. The IFOTA shall allow chat-style communication between workgroup members
48. The IFOTA shall capture chat communication between workgroup members
49. The IFOTA shall provide a Request for Information (RFI) management function
50. The IFOTA shall allow students to enter their own decision selections
51. The IFOTA shall provide graceful shutdown
52. The IFOTA shall be designed to be extensible
53. The IFOTA shall be designed to facilitate integration with IOPC-J
Login Function
54. The IFOTA shall prompt the student to login (appropriate permissions will be keyed to login)
55. The IFOTA shall identify types of users and work group members through coded logins
56. The IFOTA shall prompt the student to select a module in the login screen
57. The IFOTA shall use login information to direct file save paths
Search Function
58. The IFOTA shall provide scenario search capability on a single screen through a clickable world
map and a text-based search function
59. The IFOTA shall provide a geographically-based scenario search capability through a Major
Command (MAJCOM) map that permits the user to drill down to specific countries and local areas
to obtain the scenario files for the chosen area.
60. The IFOTA shall provide a text search capability that permits the user to obtain the scenario files
for specific ethnocultural groups, tactical tasks, discipline-specific tasks, or geographic locales
61. The IFOTA shall prompt the scenario creator/modifier to tag the scenario by geographic locale,
ethnocultural group, and tactical/support tasks
20
62. The IFOTA shall permit the scenario file to be opened from the scenario search results display
Menu/Tool Bar
63. The IFOTA shall provide access to all functions through a menu bar with main menus and
submenus
64. The IFOTA shall display keystroke combination shortcuts for actions on the submenus
65. The IFOTA shall identify icon function with hovertext
66. The IFOTA shall provide alternate access to frequently used functions through a tool bar
67. The IFOTA shall include icons to customize the tool bar to include any function
Help Functions
68. The IFOTA shall provide a "WinHelp" or "HTML Help" Help function
69. The IFOTA shall allow Help to remain onscreen while the user is working in the file
70. The IFOTA Help screens shall be dockable/undockable
71. The IFOTA Help screens shall be resizable
72. The IFOTA shall allow the user to print Help entries
73. The IFOTA Help system shall include definitions of terms, directions for procedures, and links to
support material provided by 39th IOS
74. The IFOTA shall provide contextual help at all decision points
75. The IFOTA shall provide contextual help in the form of "on-demand" popups
76. The IFOTA shall access dialog box contextual help using a question mark icon
77. The IFOTA shall provide contextual help in the form of text definitions for course vocabulary items
78. The IFOTA shall highlight text entries that have associated contextual help
79. The IFOTA shall access highlighted contextual help items by doubleclicking on highlighted text
Instructor Module
80. The IFOTA shall allow instructors to view students' work in real time
81. The IFOTA shall associate workgroup and student identifications with each saved file
82. The IFOTA shall capture justifications and references for student's work
83. The IFOTA shall allow instructors to modify (add/delete/change) student decision point selections
and save modifications to a new file
84. The IFOTA shall notify the student the instructor has modified the student's work
85. The IFOTA shall allow the student to transfer to the modified file
86. The IFOTA shall capture grades for student work
87. The IFOTA shall capture student actions in a readable log file
88. The IFOTA shall permit instructors to create scenario templates
89. The IFOTA shall permit instructors to modify scenario templates
90. The IFOTA shall allow instructors to modify scenario data
91. The IFOTA shall allow instructors/staff to create new scenarios
92. The IFOTA shall provide a method for testing students
93. The IFOTA shall provide a method for grading and annotating tests
94. The IFOTA shall provide a method for calculating grades
95. The IFOTA shall capture summary/final grades
Initiation
96. The IFOTA shall open each new work session with the JWICS regional commands map
97. The IFOTA shall display regional command member countries in matrix form
98. The IFOTA shall link to basic political and sociocultural information for each country
99. The IFOTA shall allow the user to select a single country
100. The IFOTA shall display a map for each country
101. The IFOTA shall link to demographic, political and sociocultural information for each distinct region
within the country
102. The IFOTA shall open each scenario with the summary sheet
103. The IFOTA shall provide a list of combined operational tasks organized by service and operational
phase
21
104. The IFOTA shall provide success indicators for each operational task
105. The IFOTA shall allow the user to select operational task(s) and success indicators
106. The IFOTA shall provide an example list of Air Force tactical objectives organized by service it
supports
107. The IFOTA shall provide example measures of effectiveness (MOEs) for each tactical objective
108. The IFOTA shall allow the user to select/write up to 5 tactical objectives
109. The IFOTA shall allow the user to select/write MOEs for each objective
110. The IFOTA shall provide an example list of Air Force tactical tasks organized by service it
supports
111. The IFOTA shall provide example measures of performance (MOPs) for each tactical task
112. The IFOTA shall allow the user to select/write up to 5 tactical tasks
113. The IFOTA shall allow the user to select/write MOPs for each task
114. The IFOTA shall allow the user to enter own tactical tasks
115. The IFOTA shall allow the user to enter own MOPs
116. The IFOTA shall show task branches
117. The IFOTA shall allow the user to create task branches
118. The IFOTA scenario shall identify the current planning stage
119. The IFOTA scenario shall identify the current operational phase
Status/Summary Screen Function
120. The IFOTA shall have a status screen that summarizes current status for each module
121. The IFOTA shall display current information from each module on the summary screen(s)
122. The IFOTA shall display information from each module from the following fields on the summary
screen(s): operational objective, SI, tactical objective, MOE, tactical task, MOP, tactical support
task, MOP, target audience, target action, rationale, link to synchronization matrix
123. The IFOTA shall pull summary information from the corresponding data entry fields in each
individual module
124. The IFOTA shall the status screen will update automatically whenever any data that feed the
status fields change
125. The IFOTA shall have a deconfliction version of the summary screen with checkboxes to indicate
deconfliction has been accomplished
Deconfliction/Coordination Function
126. The IFOTA shall have a deconfliction/coordination feature that prompts the user to
deconflict/coordinate with other disciplines
127. The IFOTA shall display the deconfliction screen whenever the student reaches an identified
deconfliction point in the process
128. The IFOTA shall have a deconfliction button that brings up the summary/deconfliction screen at
user command
129. The IFOTA shall use the status screen for the deconfliction/coordination function
130. The IFOTA shall display checkboxes by each deconfliction action in the deconfliction function
131. The IFOTA shall timestamp each deconfliction/coordination action
132. The IFOTA shall open a popup text field to capture the student's deconfliction action whenever the
student fills in a deconfliction checkbox
133. The IFOTA shall open a popup text field to capture the student's deconfliction rationale whenever
the student fills in a deconfliction checkbox
134. The IFOTA shall not allow the student to proceed until the student has checked each box and
entered text in each action description text field
Multiple Window Capability
135. The IFOTA shall permit the user to manage multiple windows
136. The IFOTA shall allow the user to tile windows horizontally and vertically
137. The IFOTA shall allow the user to resize all windows
138. The IFOTA shall allow the user to move all windows
139. The IFOTA shall allow the user to close all windows
22
140. The IFOTA shall allow the user to minimize all windows
141. The IFOTA shall allow the user to move freely between windows
142. The IFOTA shall include a toggle capability to enlarge window in which student is working
143. The IFOTA shall allow the user to tab between windows
RFI Management Function
144. The IFOTA shall provide a Coliseum RFI template
145. The IFOTA shall provide the means to make other RFI templates
146. The IFOTA shall allow the user to draft RFIs to obtain information necessary to complete scenario
tasks
147. The IFOTA shall capture RFIs for instructor
148. The IFOTA shall simulate tracking RFI status
149. The IFOTA shall allow the user to create assessment collection RFIs
PSYOP Module
150. The IFOTA shall provide example PSYOP-specific tactical support tasks
151. The IFOTA shall allow the user to select up to ? tactical support task(s) for each tactical task
152. The IFOTA shall allow the user to enter own tactical support tasks
153. The IFOTA shall provide space to insert MOPs for each tactical support task
154. The IFOTA shall give an example measure of performance
155. The IFOTA shall capture RFIs needed to perform assessment (in Coliseum format)
156. The IFOTA shall pop up deconfliction screen after tactical support task(s) are selected
157. The IFOTA shall capture/display themes and symbols for each branch
158. The IFOTA shall allow the user to enter own message and theme for each branch
159. The IFOTA shall pop up a deconfliction screen after messages and themes are selected
160. The IFOTA shall capture justification for theme/symbol selection
161. The IFOTA shall list (or link to) target audiences and specific political/sociocultural and
demographic information
162. The IFOTA shall allow the user to select a target audience
163. The IFOTA shall allow the user to enter a target audience
164. The IFOTA shall capture justification for target audience selection
165. The IFOTA shall generate RFIs needed to fill knowledge gap (in Coliseum format)
166. The IFOTA shall pop up deconfliction screen after target audience is selected
167. The IFOTA shall provide a dropdown list of example target actions
168. The IFOTA shall allow the user to enter own target action
169. The IFOTA shall allow the user to select/enter target action
170. The IFOTA shall provide example MOPs/MOEs
171. The IFOTA shall allow the user to enter MOPs/MOEs
172. The IFOTA shall capture collection requests for target action assessment
173. The IFOTA shall capture justification for how target action supports messages/themes/symbols
174. The IFOTA shall pop up deconfliction screen after target action is selected
175. The IFOTA shall list target audience/target action specific situational/cultural factors
176. The IFOTA shall provide default selection of applicable situational/cultural factors (from embedded
knowledge)
177. The IFOTA shall allow the user to modify applicable situational/cultural factors
178. The IFOTA shall allow the user to enter own situational/cultural factors
179. The IFOTA shall list possible situational/cultural conditions (from embedded knowledge)
180. The IFOTA shall allow the user to select applicable conditions
181. The IFOTA shall allow the user to enter new conditions
182. The IFOTA shall capture user's prioritization (ranking) of conditions (vulnerabilities)
183. The IFOTA shall capture user's relative weighting of conditions (susceptibilities)
184. The IFOTA shall capture user's Red/Yellow/Green (stoplight metaphor) assessment
185. The IFOTA shall allow the user to skip SMART model and go directly to delivery method selection
23
186. The IFOTA shall collect SMART model decision criteria
187. The IFOTA shall use scales to capture user assessments required for SMART model
188. The IFOTA shall generate RFIs needed to fill SMART criteria knowledge gap (in Coliseum format)
189. The IFOTA shall display SMART model evaluations
190. The IFOTA shall allow the user to modify SMART model inputs and rerun algorithm
191. The IFOTA shall provide an example list of delivery methods
192. The IFOTA shall allow the user to select/write a delivery method
193. The IFOTA shall pop up deconfliction screen after delivery method is selected
194. The IFOTA shall provide a PSYOP summary relating PSYOP tasks and MOPs to tactical
tasks/MOPs and tactical objectives/MOEs
195. The IFOTA shall capture collection requests for course of action assessment
196. The IFOTA shall permit the student to deconflict across planning cycle and operational phases
Not all of the requirements collected for the system were approved for or intended to be met in
the initial system. The SMART model and associated algorithms were dropped. Many of the
proposed Help, Deconfliction, and Instructor functions were deferred to later iterations or
dropped.
4.2.1 Processes
The following flow diagrams illustrate the understanding of desired system function obtained
during elicitation. The original elicitation did not cover CI, although it was requested for a later
iteration and elicitations were conducted at that time to create a CI process flow. It is included
here for completeness.
Figure 7 describes the login process and opening a scenario. Student planning efforts were tied to
planning scenarios that included situation descriptions and simulated command guidance.
Supplementary materials, such as country reports, the CIA World Fact Book, and bookmarked
web pages of interest were available to simulate planning support documents. Scenarios were
catalogued by type of scenario, region of interest, and sociocultural similarity (at this time,
represented by religious affiliation). Students could look for completed scenarios to study them
and borrow concepts or open an assigned scenario to begin planning efforts. Students were to
begin by examining command guidance identifying operational and success indicators as well as
command directed themes and messages. Figure 8 shows discipline-specific activity sequences.
24
4.2.2 Task Descriptions
Open IFOTA •Doubleclick program icon 1
Assess Plan
Effectiveness
Assumptions: •Login Screen opens
•Student role assigned;
•Identifies User Type, Work Group & Role
student login brings up Login Conduct Termination
•Assigns permissions; links to WG members
student module (Enter Name/Password) •Opens student or instructor module Assessment
•Instructor login brings up
instructor module
•Selection screen opens Provide Feedback
as Required
Find Open
Scenario Assigned Scenario File/Disseminate
•System returns table Lessons Learned
listing scenarios
Click Region Search on Type Search on Name •Identifies title, region,
country, operation Terminating activities
type
Link to CIA WFB •CIA WFB opens in own window
to Get Basic Info •User closes when ready
Doubleclick Doubleclick
Scenario Scenario
•Selection screen closes/minimizes?

•Instructor has filled in •Window opens on Set-up screen tab
or Read •Other tabs are visible behind
•Student fills in Operational Objective,
Group Task--Common Screen
•Shows at top of Set-up screen

Assumptions: SI & Themes, •Not editable
•Instructor has filled in at Op Phase & ATO Cycle
least one Operational
Objective Meet as Group •No System Activity
•Operational Objective to Develop COAs,
displayed in uneditable TOs/MOEs & TTs/MOPs
space.
Enter •Set-up screen has text fields for

Tactical Objective(s) TO and MOE
& MOE(s) •User types; hits OK button. Delete
button clears typing
Enter •Set-up screen has text fields for

Tactical Task(s) TT and MOPs
& MOP(s) •User types; hits OK button
•System builds summary screen from
inputs. User goes to next tab
Initiating activities
Figure 7. Initiating and terminating an IFOTA planning effort.
25
26
Begin CI-specific Process With Respect to IO Plan
PSYOP Receive Concurrent processes O
PS
MD2 Receive
D
Operational Objective tI EC
Operational Objective
ea • Includes Deception Objective
and SI
Identify
PSYOP Target Action
CI Th
r
Identify Potential Assist Identify Critical
Su
pp and SI
Identify
Current Perception
Hostile Threats Information (CI) or
t
Develop/Write Determine Black List: Develop/Write Identify

Tactical Objective(s) MOPs/MOEs Categorize by Threat Assist Identify Possible Individuals who pose a Tactical Objective(s) Desired Perception
• May be group activity • May be group activity
and MOE(s) Immediacy (now/future) Vulnerability Indicators recognized danger whose and MOE(s)
capture and detention are
Identify Relevant a priority. • Identify actions
For each supported tactical task

Influence Factors Develop Storyline adversary would
Develop/Write Identify Specific Assist Identify Develop/Write expect to see
Tactical Task(s) CI Targets in AOI Adversary Threat Gray List:
• May be group activity Tactical Task(s) • May be group activity
and MOP(s) Rank Those individuals whose and MOP(s) • Identify receptor
Influence Factors loyalties and inclinations Determine Means intelligence source
• Key decision makers Justify Selection Assist Justify Selection are currently unknown.
Collect and • Influential groups Unsure which side if any
Weight Collect and • Key decision makers
Analyze Information • Anticipated COAs these individuals support.
Influence Factors Analyze Information • Influential groups Determine MOP/MOEs
about Adversary • Desired COAs Categorize CI Targets in Assist Define Critical about Adversary • Anticipated COAs
White/Gray/Black Lists Information Risk Rating White List:
Individuals believed • Exploitable perceptions
Determine Best (through action or • Undesirable perceptions Develop • Time to receive
Develop Perceptions to Change • Time to respond
otherwise) to be favorable Develop • Desirable misperceptions Event Schedule
PSYOP Justify Categorization Assist Define
to our interest Deception
COAs Vulnerability Risk Rating
COAs
Installations: • When/how to turn it
Determine Develop
Identify Threat Any installation that off; cover story
Delivery Method Termination
Identify PSYOP Installations Assist Define Adversary houses or has housed • Who can authorize
Identify How COAs Plan
Messages/Themes Threat Risk Rating threat individuals (Military, and declassify
Support
Espionage Police, Deception Objective
Identify Threat Research/Tech Centers, • Determine
Obtain Plan Approval Organizations & Teams Review OPSEC Embassies. etc.) Determine
Identify PSYOP Feedback feedback
Risk Algorithm Results
Target Audience Identify Channels requirements
Organizations/Teams: Coordination points
Deception Target • Assess
Identify CI-Valuable Organizations with goals
Documents & Materials Assist Prioritize OPSEC contrary to coalition
Risks goals, potential resistance
centers, covert groups
Justify Selections
PA Coordinate/Deconflict OPSEC
OPSEC only ?
Receive • Proactive/Reactive Receive
• Active/Passive
Consult w/Group • OPSEC measures
Operational Objective Determine Coordinate w/ & Operational Objective reduce ability to
Identify OPSEC
and SI Response Mode Apprise IO Team and SI collect
Measures
• Event Information Document Coordination • OPSEC measures
• True/False reduce ability to
Document Coordination interpret
Develop/Write Develop Situation • Source Develop/Write Identify
Tactical Objective(s) Information Chart • Tactical Objective(s) Potential Problems • Provide
• May be group activity Response • May be group activity
and MOE(s) and MOE(s) alternative
• Press Release analysis
Develop • Press Conference Identify • Prevent
Develop/Write
Response Method • Select Interviews Develop/Write
OPSEC COAs collection
Tactical Task(s) • Morning Talk Show Tactical Task(s) • Attack
• May be group activity • May be group activity collection
and MOP(s) and MOP(s) Determine
Develop • Print Media capabilities
• Radio MOPs/MOEs
Response Means
• Television • Who are adversaries?
Collect and • Internet Collect and • What are their goals?
Analyze Information Analyze Information Identify Threats
Develop • What indicators will
about Adversary about Adversary & Vulnerabilities
Response Timing be created?
• What indicators can
be collected?
Determine • What do they want to know? Identify Indicators • What indicators can
Determine MOPs/MOEs Determine • What can be protected? be used?
Critical Information Critical Information • What is too late to protect?
Document Identify Levels of
Dissemination Plan Threat/Vulnerability
Identify Anticipate /Impact
•What is their strategy?
Target Audience Adversary Collection
•What is their intel capability?
Execute Plan Goals/Capabilities
Perform Risk
Determine Identify Assessment
Coordination points Coordination points
Target Action Target Audience
Assess Plan Success
Figure 8. IO Processes
26
27
5.0 IFOTA DEVELOPMENT
IFOTA 1.0 guided the student through the PSYOP, OPSEC, PA, and MD student
planning capabilities, capturing student rationales and deconfliction efforts. IFOTA 1.0
promoted collaborative work among IO disciplines and allowed instructors to monitor
and communicate with students.
The tasking set forth in the Statement of Work directed the transition of the IFOTA
browser-based prototype from an existing, customer-mandated, planning capability into a
training aid to expedite, enhance, and enrich the training of inexperienced Influence
Operations trainees in the successful planning and integration of Influence Operations
campaigns. Two major tasks were envisioned. The first area focused on developing
scenarios, modules, and exercises resulting in a software package, training on the
software, and a software user‘s manual for IFOTA. The second major task area focused
on an integrated effort to ensure that the IFOTA product, training, and documentation
would be both usable and useful. It directed the empirically based evaluation and
assessment of usability and usefulness through scenario-based testing by subject matter
experts. Specific development goals included the following:
 Transition the existing PSYOP PT into an IFOTA encompassing training in

planning for PSYOP, MD, OPSEC and PA and incorporating software
modifications (e.g. sliding bars and color displays) from review and critique of the
existing PSYOP PT.
 Design, develop, and implement a new module to encompass the planning

component of MD, including OPSEC and allowing deconfliction of MD, PSYOP
and PA mission objectives. Identify a taxonomy of potential objectives/missions,
design an interface, and integrate delivery methods and target audience
vulnerabilities.
 Design, develop, and implement a new module to encompass the planning

component of PA and allowing deconfliction of PA mission, PSYOP, MD, and
OPSEC mission objectives. Identify a taxonomy of potential objectives/missions,
design an interface, and integrate delivery methods and target audience
vulnerabilities.
 Design, develop, and implement a new module to encompass the functional aspect
of identifying and selecting optimum delivery methods. Identify a taxonomy of
delivery methods, design the software interface, and integrate the delivery method
(or methods) that best exploit the vulnerabilities of the target audience.
Additional tasks included development of two IFO scenarios involving one culture,
identifying objectives, target audience, and providing a list of cultural/situational
factors/vulnerabilities. The conduct of a live classroom exercise demonstration, and a
usability/usefulness focused design evaluation and recommendations. The live classroom
exercise was reconfigured as an interactive demonstration using instructors and selected
27
SMEs, due to classroom scheduling difficulties. The two scenarios were delivered to the
government separately, as was the requested software evaluation. Figure 9 shows a
screenshot from IFOTA 1.0.
Figure 9. IFOTA 1.0 multi-tabbed PSYOP scenario showing evaluation of TA resistance

IFOTA 2.0 reorganized the screen real estate to provide multiple dockable/undockable
panes surrounding a main work area, added a CI module and a more fully functional Help
system. Figure 10 shows a screenshot from IFOTA 2.0.
Figure 10. IFOTA 2.0 screenshot illustrating planning template elements and visual checklists to aid
recall (allows users to move among modules in non-linear iterative planning)
28
IFOTA 3.0 added the following functionalities:
 Enhanced Architecture
o Oracle database
o J2EE for component-based multi-tier enterprise
o Eclipse runtime environment provides common interface for extensions to
core IO planning capabilities (enhanced plug-ins)
 Spell Check capability
 Gantt Chart (Time-Series Views) for temporal view of plans
o Visual cue for deconfliction
 Combo Boxes
o Decision aid support
o Include Operational Taxonomy
Figure 11 shows the synchronization matrix (Time-Series View) from IFOTA 3.0.
Each plan level node will ask the operator to input a

time and date at the initial overview screen. The
plans dates and times will be rolled up and
calculated into the scenario level to show the
proposed time constraints of a scenario
Figure 11. IFOTA 3.0 User interface showing addition of Time Series View tab and function
IFOTA 4.0 added the following functionalities:

 Deconfliction Tool
o Decision-Aid for deconfliction of IFO plans
 COA Rating
o PSYOP-specific, cost/benefit-based, post-wargaming COA selection
decision matrix
 PSYOP Estimate Template
o PSYOP Estimate of the Situation template that guides and documents
PSYOP estimate development activities
 Database/Back-end Upgrade
 Additional Scenarios and Data in Database
29
 Worksheets and User Guide updates
Figure 12 shows the deconfliction function in IFOTA 4.0.
Figure 12. IFOTA 4.0 showing deconfliction of MD COA and COA weighting
The final IFOTA task also included development of several IFOTA-compatible scenarios
for use in integrated IO training. The scenarios, which included anti-government and anti-
US protest scenarios in several countries, a multinational peacekeeping scenario, a
Petroleum, Oil and Lubricant (POL) contamination scenario, an ethnic tensions scenario
and an espionage recruiting scenario, were delivered to the government separately.
5.1 IFOTA Technical Architecture

IFOTA technical maturity and enterprise scalability has progressed through releases.
IFOTA 1.0 software used a two tiered client server architecture, with a Java Swing client
and an Oracle Database. Java Data Base Connectivity (JDBC) was used to handle
database transactions between client and database. The architecture‘s technical simplicity
enabled rapid development responsiveness to user requirements. With more mature
requirements, subsequent versions (2.0 through 4.0) utilized a three tiered architecture.
Figure 13 distinguishes the high-level components of the IFOTA architecture within its three-
tiered architecture: a database tier, a business logic tier and a workstation/presentation tier.
IFOTA uses an Oracle database system to handle the data persistence needs. A Java 2
Enterprise Edition (J2EE) middleware solution based on JBoss Application Server version 4
is used for the business logic processing needs. The workstation/presentation tier
representing the user interface is built upon the Eclipse RCP.
30
Figure 13. IFOTA 3-tiered architecture
The communication between the tiers is accomplished through a number of standards.
Remote Method Invocation (RMI) is used as the main information transfer mechanism
between the client and the JBoss server middleware. Java Messaging Service (JMS) is
leveraged for the propagation of influence operation plan updates between the business
logic services and the active listening clients. The persistence of data from the business
logic tier to the database tier uses J2EE connection pooling and JDBC.
Data access/transfer object patterns were used to abstract data persistent implementations
and transfer implementations from the business logic. Enterprise Java Beans (EJB)
version 2.0 was used to define entity relationships and persistent properties to the data
tier communication methods.
A façade design pattern is used to limit coupling between the client system and the
business logic/application services. Stateless session beans are used to limit scalability
barriers in the middle tier. Other J2EE best practices are leveraged throughout the middle
tier, such as restricting direct communication with the file system. Figure 14 shows a
system component view.
Figure 14. IFOTA system component view
31
IFOTA development employed UML for documenting of the IFOTA design. Appendix B
provides key Use Case, Entity Relationship, and Class diagrams for the system. This
documentation has been delivered in electronic format under separate cover.
5.1.1 Advanced Technical Features

The workstation/presentation tier uses the Eclipse RCP. The Eclipse RCP is built on the
extendable Open Services Gateway Initiative (OSGI) service execution framework. The
extendibility of this framework permits the use of extension points to provide a means for
plug-ins/modules to insert capability at application defined points, referred to as
extension points. IFOTA developed a node extension point and an exporter extension
point. The node extension point was used to permit the introduction of new plan types,
such as a refined PYSOP plan type or a custom military deception plan type. All plan
types built within IFOTA use the node extension point to incorporate their plan type
functions into the overarching IFOTA platform. The exporter extension point is used to
incorporate plan product generators. The two plan product generators included in IFOTA
are the PowerPoint presentation generator and the HTML generator. The PowerPoint
presentation product generator (plan exporter) wraps Component Object Model (COM)
functionality exposed by the Microsoft PowerPoint application libraries to create
presentations. Figure 15 illustrates the IFOTA client stack.
Eclipse Provided Plug-ins IFOTA Plug-ins
Microba Deconfliction JUNG

Eclipse Rich Client Platform (Date Picker) (Scenario Editor)
Wizard
Jaret Time Bar Swabunga IFOTA Counter

RCP Optional (Gantt Chart) (SpellChecker) Intelligence Plan
(Help, Forms, Update, etc)
IFOTA Exporters IFOTA Military IFOTA Public

Generic Workbench System (PowerPoint, HTML) Deception Plan Affairs Plan
(Editors, Views, Perspectives) Resources
Jawin IFOTA Operational Security Plan

JFace Platform Runtime (Windows Native
(TableViewer, etc) (System Plug-ins) Interface)
IFOTA
SWT OSGi IFOTA Rich Client Psychological
(On demand classloading) (IFOTA Visualizations) Operations Plan
(button, Table, etc.)
Figure 15. Client stack
IFOTA architecture included an advanced locking mechanism. It enabled users to specify

locks onto planning elements to restrict editing by planning collaboration users, ideally
when they needed to modify the plan. The locking mechanism worked based on a node
level (as contrasted by the node property level or the whole plan locking level). JMS was
used to propagate locking status changes among the collaboration users. J2EE Timers
were used to force lock releases upon client inactivity for an extended period.
32
5.1.2 Rich Client Integration
Since the client leveraged the Eclipse RCP, the features and function of IFOTA can be
integrated into other Eclipse RCP applications fairly easily. This is based on the fact
IFOTA client itself being just a set of plug-ins sitting on the underlying Eclipse RCP. A
proof-of-concept integration effort included a research and analysis toolkit integration
with a 3D visualization application.
5.1.3 Training Environment Configuration

For the support of IFOTA use in training environments, a student number authentication
system was implemented. A role selection mechanism was also used to define the student
accessible aspects of the software, for example a student acting as a PSYOP planner
would select the PSYOP planner role. The system would then restrict the student from
taking part in activities not performed by this role, such as creating military deception
plans. A special, super-user role was given to the authenticated instructor users. This role
permitted instructor plan commenting activities, RFI responding activities, lesson book
management, etc. The IFOTA server based architecture and asynchronous messaging
enabled a distributed user collaboration environment. The Table 2 lists IFOTA software
features.
Table 2. IFOTA Software Features
IFOTA Software Feature List
 Plan Deconfliction
 Threaded Discussions/Instructor Chat
 Discussion integrated into Plan View
 Comments applied onto step
 Wizards Checklists/Step Flags
 Modules
 Drag and Drop Palette
 Spell check capability
 Gantt Chart/Time Series Plan View/Editor
 Hierarchy Plan Relationship View/Editor
 Plan Status Indicators
 Dynamic Overview Reports
 Plan locking
 Plan creation based on plan type wizards
o PSYOP planning
o MD planning
o OPSEC planning
o PA Planning
o CI Planning
33
5.1.4 IFOTA System Requirements
In its IFOTA 4.0 configuration, IFOTA requires Java JRE version 1.5 or greater, an
Oracle 10g database, and a Windows 2000 or XP Operating System.
6.0 DISCUSSION: WARFIGHTER ANALYSIS WORKSHOPS

IFOTA was demonstrated at the 2007 JFCOM Information Operations Planning
Capability-Joint (IOPC-J) Warfighter Analysis Workshop, the 2008 Air Combat
Command Warfighter Analysis of Innovative Technologies and Concepts (WAIT-C)
interactive technology demonstration and at the 2006 and 2007 Phoenix Challenges. The
general response was enthusiastic, as the tool‘s collaborative nature, its structured
planning methodology and deconfliction tool, and its analysis framework and rationale
documentation were all viewed as integral to coordinating joint planning efforts.
At the JFCOM IOPC-J Warfighter Analysis Workshop, IFOTA was reviewed by

representatives from Air Force‘s 7th IOF, the Texas National Guard‘s 49th IO Group, the
Army‘s 1st IO Command Tech Integration, and the Navy Information Operations
Command ‗s (NIOC MD) Information Operations Strategy and Policy group. Capabilities
queries involved addition of a Counterpropaganda module and a multilingual user
interface. The WAIT-C demonstration allowed both AOC strategy planners and IO
specialists to interact with IFOTA. Potential users from both groups were equally
enthusiastic about the structured method and the documentation of the planner‘s
rationale—a critical feature when working collaboratively. Other features that received
positive response were embedded methods for weighting efforts and anticipating
resistance/cooperation. The scenario-based training was considered an effective way to
maintain readiness among teams with differing levels of expertise.
Phoenix Challenge Conferences are DoD-sponsored events that bring government,

industry, academia, and coalition partners together to consider IO challenges and
solutions. IO community representatives share information on and discuss ramifications
of the latest IO policies, strategies, technologies, processes, legal issues, human capital,
force structure, and education and training. The response at Phoenix Challenge 2006 and
2007 was positive. IO professionals expressed concerns with development of MOEs and
MOPs for IO and IFO; tools, such as IFOTA, that prompt MOE and MOP development
are desired. The scenario-based training and checklist guided methodology were well
received.
The desirability of extending IFOTA to incorporate the full range of IO planning was
discussed by IO representatives at both the Warfighter Analysis Workshops and the
Phoenix Challenges. IO tools, such as IOPC-J, are future efforts. While there is a desire
to ―train as we fight‖ (i.e., use deployed tools such as Information Warfare Planning
Capability, IWPC), there is also an acknowledgment that the current tools do not
completely fill IO planner needs, and what will be available in the future cannot be
considered helpful today. The IO community seeks solutions that both support their
unique planning needs and integrate well with traditional planning methods. The 39th
IOS, in its well-considered requirements expression, sought to make IFOTA the bridge.
34
7.0 CONCLUSION/RECOMMENDATIONS
IFOTA 4.0 is a working prototype for planning and documenting IFO in a training
environment. Based on specific requests from the 39th IOS IOIC course instructors,
IFOTA is a scenario-based collaborative training environment featuring drag-and-drop
plan building supplemented by a reconfigurable (data-driven) Visual Checklist that
guides IO students and practitioners through the textbook methodology (including
deconfliction) for PSYOP, MD, OPSEC, PA and CI disciplines. A built-in operational
taxonomy provides decision support for plan development. A dynamically updated Gantt
Chart (Time-Series View) provides a temporal window on plan sequencing. A built-in
dual PowerPoint/HTML briefing generator saves time and effort creating decision briefs.
Instructor features include a Lesson Plan/Course Repository, Maintenance of Acronyms
and Definitions, Links to External Planning Resources, RFI simulation, and printable
Quick Look Books. Table 3 shows the primary requirement to capability mapping for
IFOTA.
Table 3. Requirement to Capability Mapping
Requirement IFOTA Capability

Open architecture Open architecture built around Eclipse RCP, J2EE, JBOSS
Helps planners develop Decision aids and built-in taxonomy supported by data-driven
viable IO options Visual Checklist reinforces strategy-to-task planning
methodology
Collaborative capabilities J2EE with locking mechanism allows multiple clients to work
in the same scenario simultaneously across geographical
locations while enabling real-time data sharing between users
Deconfliction Integrated plans can be deconflicted using IFOTA‘s plug-in
wizard
Plan-to-assessment MOEs and MOPs incorporated into plan; tool allows for
approach / Assessment iterative planning process to allow assessment of plans upon
Planning completion; can annotate intel assessment
Break down objectives IFOTA allows users to break objectives and Commander‘s
intent into tasks, subtasks, targets, target audience analysis,
desired effects, MOPs, MOEs, associated MOE indicators
Provide COCOMS the Built-in PowerPoint generator and HTML export tool for
capability to plan and generating manual documents to enhance communications
assess integrated IO plans
through manual means
COA Development Ability to understand target audience, generate possible
effects-based actions, and select ultimate planning requirement
Visualizations Drag and drop scenario development with associated pull-
down and right-click menus; time-series views, ability to
develop additional visualizations leveraging Eclipse RCP and
IFOTA IFO-specific data
Strategy-to-Task Data-driven Visual Checklist enhances user effectiveness by
Planning allowing non-linear progression while enforcing completion of
strategy-to-task planning
35
Time Synchronization Gantt chart/time-series view built in
Reachback Support Connectivity to CIA World Factbook, Reardon Group (or
current provider), Other External Links
Modular and Scalable All Modules (PSYOP, PA, MD, CI, OPSEC, Instructor) can be
turned on/off; additional modules can be easily plugged in
The uniformly positive responses to IFOTA suggest that the 39th IOS has defined the IO
planning support needs well. Extension of IFOTA to incorporate all of the IO disciplines
is needed to complete it; due to the great interest in and need for effective IO planning
tools, it is highly recommended that IFOTA be reviewed for inclusion in the next IO
system of record. Although DoD software development is moving more toward thin-
client applications, with the advances in support to service-oriented architectures, IFOTA
can be relatively easily rethought to provide a similar level of support in a web-based
application. In a thin client format, the IFOTA functions would fill a gap in cognitive-
based tool support for IO training. It will benefit the IO community if the insights of
those IO experts who contributed to IFOTA‘s requirements development are not lost. It
will benefit the IO community if the collaborative support provided through IFOTA‘s
concept of tracking plan rationale is retained.
36
8.0 REFERENCES
Eggleston, R. (2003). Work Centered Design: A cognitive engineering approach to

system design. Proceedings of the Human Factors and Ergonomics Society 47th
Annual Meeting, 13-17 Oct, 2003 Denver, CO.
Flanagan, J. (1954). The Critical Incident Technique. Psychological Bulletin, 51(4), 327-
359.
Hoffman, R., Crandall, B. & Shadbolt, N. (1998). Use of the Critical Decision Method to
elicit expert knowledge: A case study in the methodology of Cognitive Task Analysis.
Human Factors, 40(2), 254-276.
Militello, L. & Hutton, R. (1998). Applied Cognitive Task Analysis (ACTA): A
practitioner‘s toolkit for understanding cognitive task demands. Ergonomics, 41(11),
1618 – 1641.
Moon, B. (2004). Concept maps and wagon wheels: Merging methods to improve the
understanding of team dynamics. In A. Cañas, J. Novak, and F. González (Eds.),
Concept Maps: Theory, Methodology, Technology. Proceedings. of the First
International Conference on Concept Mapping, Pamplona, Spain.
Zhou, Y. & Burns, C. (2003). A methodology for integrating cognitive engineering into
information system analysis and design. Proceedings of the Human Factors &
Ergonomics Society 47th Annual Meeting, 13-17 Oct, 2003 Denver, CO.
37
APPENDIX A
IFOTA REQUIREMENTS
A-1
The following requirements were derived from discussions with the 39th IOS and selected
subject matter experts and from official training and doctrine documents. Requirements
were prioritized and implemented incrementally as IFOTA was developed. Note that not
all requirements were approved for funding during the period of performance. They are
included here to illustrate the features that were considered desirable.
Requirement
ID Type Requirement Statement
1 Module: Help The Help System shall provide directions on how to use IFOTA
System
2 Module: Help The Help System shall provide links to support material provided by the
System 39th IOS (i.e., URLs on JWICS, SIPRNet, etc.) The instructors will
add/update this list via the Instructor Module.
3 Module: Help The Help System shall provide definitions of all terms used in the
System software. The instructors will add/update the definitions list via the
Instructor Module.
4 Module: Help The Help System shall provide examples of each write-in box (i.e.,
System justification/citation boxes)
5 Module: Help The Help System shall provide contextual help for each user activity (i.e.,
System right-click or click-question-mark-then-click-item-you-want-help-on)
6 Module: Help The Help System shall include explanations for all menu items and
System buttons.
7 Module: Help The Help System shall identify names and functions of all software panes
System and frames. Use title bars on all windows.
8 Module: Help The Help System shall identify how to regain closed software panes and
System frames.
9 Module: Help The Help System shall provide instruction on how to customize the
System toolbar.
10 Module: Help The Help System shall provide instruction on how to revert the toolbar
System back to standard.
11 Module: Help The Help System shall include compilations of all individual contextual
System help entries. (In other words, everything that's included in the contextual
help will also be included in the definitions/acronyms, index, etc. of the
actual full-blown Help system.
12 Module: Help The Help System shall contain explanations for all algorithms.
System
13 Module: Help The Help System shall contain explanations for how to deconflict tasks.
System
14 Module: Help The Help System shall contain explanations for how to use results
System displays.
A-2
15 Module: Help The Help System shall contain explanations for how to alter influence
System factors to change algorithm results.
16 Module: Help The IFOTA shall provide a platform-independent Help System

System
17 Module: Help The IFOTA shall allow Help to remain onscreen while the user is working
System in the IFOTA program. (Perhaps a floating window that can be closed.)
18 Module: Help The IFOTA Help screens shall be dockable/undockable

System
19 Module: Help The IFOTA Help screens shall be resizable

System
20 Module: Help The IFOTA shall allow the user to print Help entries (without having to
System print the entire help system)
21 Module: Help The IFOTA shall provide contextual help at all decision points
System
22 Module: Help The IFOTA shall provide contextual help in the form of "on-demand"
System popups
23 Module: Help The IFOTA shall access dialog box contextual help using a question
System mark icon
24 Module: Help The IFOTA shall provide contextual help in the form of text definitions for
System course vocabulary items
25 Module: Help The IFOTA shall highlight text entries that have associated contextual
System help, if available.
26 Module: Help The IFOTA shall access highlighted contextual help items by
System doubleclicking on highlighted text
27 Module: Help The Help System shall remain open until it is manually closed by the
System user.
28 Module: Help The Help System shall instruct the user how to navigate within a scenario
System
29 Module: Help The Help System shall include selected sections of each instructors'
System lesson notes (to be input by the 39th IOS).
30 Module: Help The Help System shall be navigable by hyperlink to additional help
System topics.
31 Module: Help The Help System shall provide a search feature.

System
A-3
32 Module: The Instructor Module shall allow the instructor to view student activities
Instructor in near real-time as the student's work is saved.
33 Module: An Instructor Module shall have a separate login feature.

Instructor
34 Module: The Instructor Module shall have a separate interface.

Instructor
35 Module: The Instructor Module shall allow the instructor to enter new data into the
Instructor databases.
36 Module: The Instructor Module shall allow the instructor to change data in the
37 Module: The IFOTA shall allow instructors to view students' work in real time
Instructor
38 System: The IFOTA shall associate a workgroup identification and a student

General identification with each saved scenario
39 System: The IFOTA shall capture justifications and references for student's work
General
40 Module: The IFOTA shall allow instructors to modify (add/delete/change) the

Instructor student's plan and save modifications to the database.
41 Module: The IFOTA shall allow the instructor to notify the student that the
Instructor instructor has annotated the student's work
42 Module: The IFOTA shall allow the student to transfer to the modified file
Instructor
43 Module: The IFOTA shall capture grades for student work

Instructor
44 Module: The IFOTA shall capture student actions in a readable log file
Instructor
45 Module: The IFOTA shall permit instructors to create scenario templates

Instructor
46 Module: The IFOTA shall permit instructors to modify scenario templates

Instructor
47 Module: The IFOTA shall allow instructors to modify scenario data

Instructor
48 Module: The IFOTA shall allow instructors/staff to create new scenarios

Instructor
A-4
49 Module: The IFOTA shall provide a method for testing students
Instructor
50 Module: The IFOTA shall provide a method for annotating tests

Instructor
51 Module: The IFOTA shall provide a method for calculating grades for each test or
Instructor exercise
52 Module: The IFOTA shall capture summary/final grades

Instructor
53 Module: The Instructor Module shall allow the instructor to delete data from the
54 Module: MD A module shall be built to encompass the planning aspect of Military

Deception (MD).
55 Module: MD The IFOTA shall provide example MD-specific tactical support tasks
56 Module: MD The IFOTA shall allow the user to select multiple tactical supporting
task(s) for each tactical task
57 Module: MD The IFOTA shall allow the user to enter their own tactical supporting
tasks
58 Module: MD The IFOTA shall provide space to insert measures of performance

(MOPs) for each tactical supporting task
59 Module: MD The IFOTA shall provide example MOPs
60 Module: MD The IFOTA shall link to MD supporting references (simulating reachback

and SIPRNET)
61 Module: RFI The IFOTA shall capture RFIs needed to perform assessment
62 Module: MD The IFOTA shall pop up deconfliction/coordination screen after tactical

support task(s) are selected
63 Module: MD The IFOTA shall allow the user to identify target audience
64 Module: MD The IFOTA shall pop up deconfliction/coordination screen after target

audience is selected
65 Module: MD The IFOTA shall allow the user to input current perception
A-5
66 Module: MD The IFOTA shall prompt the user to select perception management
objective (create/change/maintain)
67 Module: MD The IFOTA shall allow the user to input desired perception (descriptive
action title)
68 Module: MD The IFOTA shall allow the user to input detailed storyline
69 Module: MD The IFOTA shall pop up deconfliction/coordination screen after storyline

is developed
70 Module: MD The IFOTA shall allow the user to select from a dropdown list of means
71 Module: MD The IFOTA shall categorize means as Administrative, Technical, or

Physical
72 Module: MD The IFOTA shall pop up deconfliction/coordination screen after means

are selected
73 Module: MD The IFOTA shall allow the user to input "Special Actions"
74 Module: MD The IFOTA shall capture justification for target audience selection
75 Module: MD The IFOTA shall capture justification for perception management plan
(desired perception, story, and means)
76 Module: MD The IFOTA shall allow the user to describe the action termination plan
77 Module: MD The IFOTA shall allow the user to identify termination cue and
termination cover story (as appropriate)
78 Module: MD The IFOTA shall allow the user to identify termination authority
79 Module: MD The IFOTA shall allow the user to identify what information can be
released/when
80 Module: MD The IFOTA shall allow the user to identify what conduits need to be
terminated/continued
81 Module: MD The IFOTA shall capture justification for action termination plan
82 Module: MD The IFOTA shall display an Event Schedule based on Joint Pub 3-58
plus Location/Target
A-6
83 Module: MD The IFOTA shall pop up deconfliction/coordination screen after the Event
Schedule is created
84 Module: RFI The IFOTA shall capture collection requests (RFIs) for course of action
assessment (feedback)
85 Module: MD The IFOTA shall capture/display feedback
86 Module: MD The IFOTA shall display feedback in a table similar to the Event
Schedule (ID#, Objective, Time, Action/Means, Unit, Location/Target,
feedback)
87 Module: MD The IFOTA shall distinguish feedback as MOP (did the story get out) and
MOE (did the target respond as desired)
88 Module: MD The IFOTA shall provide a MOPs chart listing Event, Unit, Scheduled
DTG, % Completed, Feedback channels
89 Module: MD The IFOTA shall provide a termination assessment
90 Module: MD The IFOTA shall provide an MD summary relating MD tasks and MOPs
to tactical tasks/MOPS and tactical objectives/MOEs
91 Module: MD The IFOTA shall permit the student to deconflict across planning cycle
and operational phases
92 Module: The IFOTA shall provide example OPSEC-specific tactical support tasks
OPSEC
93 Module: The IFOTA shall allow the user to select multiple tactical support task(s)
OPSEC for each tactical task
94 Module: The IFOTA shall allow the user to enter their own tactical support tasks
OPSEC
95 Module: The IFOTA shall provide space to insert MOPs for each tactical support
OPSEC task
96 Module: The IFOTA shall give an example measure of performance (MOP)

OPSEC
97 Module: The IFOTA shall pop up deconfliction/coordination screen after tactical

OPSEC support task(s) are selected
98 Module: The IFOTA shall link to OPSEC supporting references (simulating

OPSEC reachback and SIPRNET)
A-7
100 Module: The IFOTA shall allow the user to identify Critical Information (subset of
OPSEC Essential Element of Friendly Information - EEFIs) from a dropdown list
101 Module: The IFOTA shall allow the user to enter Critical Information items
OPSEC
102 Module: The IFOTA shall capture justification for Critical Information identification
OPSEC
103 Module: The IFOTA shall allow the user to identify target audience
OPSEC
104 Module: The IFOTA shall pop up deconfliction/coordination screen after target
OPSEC audience is selected
105 Module: The IFOTA shall allow the user to identify OPSEC measures from a
OPSEC dropdown list
106 Module: The IFOTA shall allow the user to identify interactions and unintended
OPSEC consequences from employment of OPSEC measures
107 Module: The IFOTA shall allow the user to develop OPSEC primary and
OPSEC secondary countermeasures
108 Module: The IFOTA shall allow the user to identify MOPs and MOEs
OPSEC
110 Module: The IFOTA shall capture justification for the OPSEC plan
OPSEC
111 Module: The IFOTA shall pop up deconfliction/coordination screen after OPSEC
OPSEC COA is selected
112 Module: The IFOTA shall allow the user to identify adversary Threats from a
OPSEC dropdown list
113 Module: The IFOTA shall allow the user to enter Threat types
OPSEC
114 Module: The IFOTA shall allow the user to identify OPSEC Indicators from a
OPSEC dropdown list
115 Module: The IFOTA shall allow the user to enter OPSEC Indicators
OPSEC
116 Module: The IFOTA shall allow the user to identify and analyze Vulnerabilities
OPSEC from a dropdown list
A-8
117 Module: The IFOTA shall allow the user to enter Vulnerabilities
OPSEC
118 Module: The IFOTA shall capture justification of the way and the circumstances in
OPSEC which the Indicator is a Vulnerability
119 Module: The IFOTA shall allow the user to assess risk using an algorithm to factor
OPSEC in levels of Threat, Vulnerability and Impact
120 Module: The IFOTA shall use scales ( e.g., 5-pt scale) to capture user
OPSEC assessments for threat, vulnerability, and impact
121 Module: The IFOTA shall provide a risk summary

OPSEC
122 Module: The IFOTA shall allow the user to provide a cost/benefit analysis
OPSEC
123 Module: The IFOTA shall capture collection requests for course of action
OPSEC assessment (feedback)
124 Module: The IFOTA shall provide an OPSEC summary relating OPSEC tasks and
OPSEC MOPs to tactical tasks/MOPS and tactical objectives/MOEs
125 Module: The IFOTA shall permit the student to deconflict across planning cycle
OPSEC and operational phases
126 Module: PA A module shall be built to encompass the planning component of PA.
127 Module: PA The IFOTA shall provide example PA-specific tactical support tasks
128 Module: PA The IFOTA shall allow the user to select multiple tactical support task(s)
for each tactical task
129 Module: PA The IFOTA shall allow the user to enter own tactical support tasks
130 Module: PA The IFOTA shall provide space to insert MOPs for each tactical support
task
131 Module: PA The IFOTA shall give an example measure of performance (MOP)
133 Module: PA The IFOTA shall pop up deconfliction screen after tactical support task(s)
are selected
A-9
134 Software: The IFOTA shall capture/display unifying themes
General
135 Module: PA The IFOTA shall allow the user to enter own message for each plan
136 Module: PA The IFOTA shall pop up a deconfliction screen after messages and
themes are selected
137 Module: PA The IFOTA shall capture justification for theme/symbol selection
138 Module: PA The IFOTA shall link to PA supporting references
139 Module: PA The IFOTA shall allow the user to identify Critical Information (subset of
EEFIs) from a dropdown list
140 Module: PA The IFOTA shall allow the user to enter Critical Information items
141 Module: PA The IFOTA shall capture justification for selection of Critical Information
items
142 Module: PA The IFOTA shall capture whether the student is in proactive or reactive
mode
143 Module: PA The IFOTA shall capture whether the student is planning a passive or
active information campaign
144 Module: PA The IFOTA shall capture justification for decision to react/not react
145 Module: RFI The IFOTA shall generate RFIs needed to fill knowledge gap
146 Module: PA The IFOTA shall allow the user to select a target audience
147 Module: PA The IFOTA shall allow the user to enter a target audience
148 Module: PA The IFOTA shall capture justification for target audience selection
149 Module: PA The IFOTA shall pop up deconfliction screen after target audience is
selected
150 Module: PA The IFOTA shall provide a dropdown list of example target actions
A-10
151 Module: PA The IFOTA shall allow the user to enter own target action
152 Module: PA The IFOTA shall allow the user to select/enter target action
153 Module: PA The IFOTA shall capture Situation Description and response justification
(Information, T/F, Source, Response, Rationale)
154 Module: PA The IFOTA shall pop up deconfliction screen after response is selected
155 Module: PA The IFOTA shall capture Dissemination Plan (Response, Means,
Methods, Timing)
156 Module: PA The IFOTA shall pop up deconfliction screen after response plan is
delineated
157 Module: PA The IFOTA shall capture MOPs and MOEs
159 Module: PA The IFOTA shall capture simulated response effectiveness (Response,
Measures of Effectiveness)
160 Module: PA The IFOTA shall provide a PA summary relating PA tasks and MOPs to
tactical tasks/MOPS and tactical objectives/MOEs
161 Module: PA The IFOTA shall permit the student to deconflict across planning cycle
and operational phases
162 Module: The IFOTA shall provide example PSYOP-specific tactical support tasks
PSYOP
163 Module: The IFOTA shall allow the user to select multiple tactical support task(s)
PSYOP for each tactical task
164 Module: The IFOTA shall allow the user to enter own tactical support tasks
PSYOP
165 Module: The IFOTA shall provide space to insert MOPs for each tactical support
PSYOP task
166 Module: The IFOTA shall give an example measure of performance (MOP)
PSYOP
A-11
168 Module: The IFOTA shall pop up deconfliction screen after tactical support task(s)
PSYOP are selected
169 Module: The IFOTA shall capture/display themes and symbols for each branch
PSYOP
170 Module: The IFOTA shall allow the user to enter own message and theme for
PSYOP each plan
171 Module: The IFOTA shall pop up a deconfliction screen after messages and
PSYOP themes are selected
172 Module: The IFOTA shall capture justification for theme/symbol selection
PSYOP
173 Module: The IFOTA shall list (or link to) target audiences and specific
PSYOP political/sociocultural and demographic information
174 Module: The IFOTA shall allow the user to select a target audience
PSYOP
175 Module: The IFOTA shall allow the user to enter a target audience
PSYOP
176 Module: The IFOTA shall capture justification for target audience selection
PSYOP
177 Module: RFI The IFOTA shall generate RFIs needed to fill knowledge gap
178 Module: The IFOTA shall pop up deconfliction screen after target audience is
PSYOP selected
179 Module: The IFOTA shall provide a dropdown list of example target actions
PSYOP
180 Module: The IFOTA shall allow the user to enter own target action
PSYOP
181 Module: The IFOTA shall allow the user to select/enter target action
PSYOP
182 Module: Help The IFOTA shall provide example MOPs/MOEs

System
183 Module: The IFOTA shall allow the user to enter MOEs
PSYOP
184 Module: The IFOTA shall capture collection requests for target action assessment
PSYOP
A-12
185 Module: The IFOTA shall capture justification for how target action supports
PSYOP messages/themes/symbols
186 Module: The IFOTA shall pop up deconfliction screen after target action is
PSYOP selected
187 Module: The IFOTA shall list target audience/target action specific
PSYOP situational/cultural factors
188 Module: The IFOTA shall provide default selection of applicable

PSYOP situational/cultural factors (from embedded knowledge)
189 Module: The IFOTA shall allow the user to modify applicable situational/cultural
PSYOP factors
190 Module: The IFOTA shall allow the user to enter own situational/cultural factors
PSYOP
191 Module: The IFOTA shall list possible situational/cultural conditions (from
PSYOP embedded knowledge)
192 Module: The IFOTA shall allow the user to select applicable conditions
PSYOP
193 Module: The IFOTA shall allow the user to enter new conditions
PSYOP
194 Module: The IFOTA shall capture user's prioritization (ranking) of conditions
PSYOP (vulnerabilities)
195 Module: The IFOTA shall capture user's relative weighting of conditions
PSYOP (susceptibilities)
196 Module: The IFOTA shall capture user's Red/Yellow/Green (stoplight metaphor)
PSYOP assessment
197 Module: The IFOTA shall allow the user to skip SMART model and go directly to
PSYOP delivery method selection
198 Module: The IFOTA shall collect SMART model decision criteria
PSYOP
199 Module: The IFOTA shall use scales to capture user assessments required for
PSYOP SMART model
200 Module: RFI The IFOTA shall generate RFIs needed to fill SMART criteria knowledge
gap
201 Module: The IFOTA shall display SMART model evaluations

PSYOP
A-13
202 Module: The IFOTA shall allow the user to modify SMART model inputs and rerun
PSYOP algorithm
203 Module: The IFOTA shall provide an example list of delivery methods
PSYOP
204 Module: The IFOTA shall allow the user to select/write a delivery method
PSYOP
205 Module: The IFOTA shall pop up deconfliction screen after delivery method is
PSYOP selected
206 Module: The IFOTA shall provide a PSYOP summary relating PSYOP tasks and
PSYOP MOPs to tactical tasks/MOPs and tactical objectives/MOEs
207 Module: The IFOTA shall capture collection requests for course of action
PSYOP assessment
208 Module: The IFOTA shall permit the student to deconflict across planning cycle
PSYOP and operational phases
209 Software: The IFOTA shall include icons to customize the tool bar to include any
General function
210 Software: The IFOTA shall open each new work session with the JWICS regional
General commands map
211 Software: The IFOTA shall display the scenarios by region (and country) when you
General click on the map
212 Software: The IFOTA shall link to basic political and sociocultural information for
General each country
213 Software: The IFOTA shall allow the user to select the scenarios associated with a
General single country
214 Software: The IFOTA shall display a map for each country
General
215 Software: The IFOTA shall link to demographic, political and sociocultural
General information for each distinct region within the country
216 Software: The IFOTA shall open each scenario and immediately display the
General summary sheet
217 Software: The IFOTA shall provide a list of combined operational tasks organized
General by service and operational phase
218 Software: The IFOTA shall provide example success indicators for
General each operational objective
A-14
219 Software: The IFOTA shall allow the user to select/write multiple
General operational objective(s) and success indicators
220 Software: The IFOTA shall provide an example list of Air Force tactical objectives
General organized by service it supports
221 Software: The IFOTA shall provide example measures of effectiveness (MOEs) for
General each tactical objective
222 Software: The IFOTA shall allow the user to select/write multiple tactical objectives
General
223 Software: The IFOTA shall allow the user to select/write MOEs for each objective
General
224 Software: The IFOTA shall provide an example list of Air Force tactical tasks
General organized by service it supports
225 Software: The IFOTA shall provide example measures of performance (MOPs) for
General each tactical task
226 Software: The IFOTA shall allow the user to select/write multiple tactical tasks
General
227 Software: The IFOTA shall allow the user to select/write MOPs for each task
General
228 Software: The IFOTA shall allow the user to enter own tactical tasks
General
229 Software: The IFOTA shall allow the user to enter own MOPs
General
230 Software: The IFOTA shall show task branches

General
231 Software: The IFOTA shall allow the user to create task branches
General
232 Software: The IFOTA scenario shall identify the current planning stage
General
233 Software: The IFOTA scenario shall identify the current operational phase
General
234 Software: The IFOTA shall have a status screen that summarizes current status for
General each module
235 Software: The IFOTA shall display current information from each module on the
General summary screen(s)
A-15
236 Software: The IFOTA shall display information from each module from the following
General fields on the summary screen(s): operational objective, SI, tactical
objective, MOE, tactical task, MOP, tactical support task, MOP, target
audience, target action, rationale, link to synchronization matrix
237 Software: The IFOTA shall pull summary information from the corresponding data
General entry fields in each individual module
238 Software: The IFOTA shall update the summary plan automatically whenever any
General data that feed the summary fields change
239 Software: The IFOTA shall have a deconfliction version of the summary screen with
General checkboxes to indicate deconfliction has been accomplished
240 Module: The IFOTA shall have a deconfliction/coordination feature that prompts
Deconfliction the user to deconflict/coordinate with other disciplines
241 Module: The IFOTA shall display the deconfliction screen whenever the student
Deconfliction reaches an identified deconfliction point in the process
242 Module: The IFOTA shall have a deconfliction button that brings up the
Deconfliction summary/deconfliction screen at user command
243 Module: The IFOTA shall use the status screen for the deconfliction/coordination
Deconfliction function
244 Module: The IFOTA shall display checkboxes by each deconfliction action in the
Deconfliction deconfliction function
245 Module: The IFOTA shall timestamp each deconfliction/coordination action

Deconfliction
246 Module: The IFOTA shall allow the student to enter the deconfliction action
Deconfliction whenever the student fills in a deconfliction checkbox
247 Module: The IFOTA shall allow the student to enter the deconfliction rationale
Deconfliction whenever the student fills in a deconfliction checkbox
248 Module: The IFOTA shall not allow the student to proceed until the student has
Deconfliction checked each box and entered text in each action description text field
249 Software: The IFOTA shall permit the user to manage multiple windows
General
250 Software: The IFOTA shall allow the user to tile windows horizontally and vertically
General
251 Software: The IFOTA shall allow the user to resize all windows
General
252 Software: The IFOTA shall allow the user to move all windows
General
A-16
253 Software: The IFOTA shall allow the user to close all windows
General
254 Software: The IFOTA shall allow the user to minimize all windows
General
255 Software: The IFOTA shall allow the user to move freely between windows
General
256 Software: The IFOTA shall include a toggle capability to enlarge window in which
General student is working
257 Software: The IFOTA shall allow the user to tab between windows
General
258 Module: RFI The IFOTA shall provide a Coliseum RFI template
259 Module: RFI The IFOTA shall provide the means to make other RFI templates
260 Module: RFI The IFOTA shall allow the user to draft RFIs to obtain information
necessary to complete scenario tasks
261 Module: RFI The IFOTA shall capture RFIs for instructor
262 Module: RFI The IFOTA shall simulate tracking RFI status
263 Module: RFI The IFOTA shall allow the user to create assessment collection RFIs
264 System: IFOTA shall be designed to work in a secure environment.

General
265 System: IFOTA shall be designed to work in a secure environment.

General
270 System: The IFOTA shall store login information.

General
271 Software: All text boxes shall have an auto-wrap feature.

General
272 Software: All text boxes shall have a scroll-bar feature that becomes active when
General necessary.
273 Software: The IFOTA shall have a Windows look and feel
General
A-17
274 Software: The IFOTA shall have a main menu with submenus and toolbar with icon
General buttons
275 Software: The IFOTA shall use portions of the DIICOE and Xerox usability
General standards as guidelines for software development.
276 Software: The IFOTA shall open to a blank window

General
277 Software: The IFOTA shall provide a scenario chooser to display existing scenarios
General for selection
278 Software: The IFOTA shall provide scenario search capability

General
279 Software: The IFOTA shall provide a login function

General
280 Software: The IFOTA shall allow the user to open existing scenarios
General
281 Software: The IFOTA shall allow the user to create new scenarios
General
282 Software: The IFOTA shall allow the user to save their work to the database
General
283 Software: The IFOTA shall allow the user to modify their work according to
General permissions
284 Software: The IFOTA shall ensure students can't overwrite scenarios from library
General
285 Software: The IFOTA shall allow students to modify (add/delete/change) their own
General work
286 Functionality: The IFOTA shall allow the user to print whole scenarios
Print
287 Functionality: The IFOTA shall allow the user to suppress printing SMART input
Print screens
288 Functionality: The IFOTA shall allow the user to suppress printing SMART results
Print
289 Functionality: The IFOTA shall allow the user to print the scenario summary
Print
290 Functionality: The IFOTA shall allow the user to print single/multiple page(s)
Print
A-18
291 Functionality: The IFOTA shall allow cut, copy, and paste between fields, screens,
General windows and programs
292 Functionality: The IFOTA shall allow unlimited undo/redo for all text entries
General
293 Module: Help The IFOTA shall provide contextual help

System
294 Module: Help The IFOTA shall provide a preliminary glossary that the instructor can
System add to at any time.
295 Module: Help The IFOTA shall display software version and PM/Developer contact
System information under Help:About IFOTA
296 Functionality: The IFOTA shall display descriptive titles on all windows and dialog
General boxes
297 Functionality: The IFOTA shall permit the user to open, manage, and work in multiple
Navigation windows
298 System: The IFOTA shall permit the user to open multiple scenarios
General simultaneously
299 Software: The IFOTA shall allow the user to open multiple modules in multiple
General windows
300 Software: The IFOTA shall allow the user to open multiple screens of the same
General module
301 Software: The IFOTA shall allow the user to open old scenarios concurrent with
General new scenario
302 Functionality: The IFOTA shall allow the user to navigate through screens in a
Navigation maximum of 5 steps
303 Module: Help The IFOTA shall use terminology that meets 39th IOS approval
System
304 Module: Help The IFOTA shall use procedures that meet 39th IOS approval
System
305 Software: The IFOTA shall identify and keep track of where each planner is within
General the 5 operational phases
306 Software: The IFOTA shall identify and keep track of where each planner is within
General the 72--hour planning cycle
307 Software: The IFOTA shall display plans across operational phases and planning
General cycles
A-19
308 Software: The IFOTA shall accept and maintain integrity of task branches
General
309 Software: The IFOTA shall have a summary screen for each module
General
310 Module: The IFOTA shall have a deconfliction/coordination function

Deconfliction
311 Software: The IFOTA shall recognize workgroup members

General
312 Software: The IFOTA shall allow workgroup members to view each others' work
General
313 Functionality: The IFOTA shall allow chat-style communication between workgroup
Chat members
314 Functionality: The IFOTA shall capture chat communication between workgroup
Chat members
315 Software: The IFOTA shall allow students to enter their own decision selections
General
316 System: The IFOTA shall provide graceful degradation

General
317 System: The IFOTA shall be designed to be extensible

General
318 Functionality: The system shall provide a print-preview function.

Print
319 Functionality: The system shall allow the user to save a scenario as a new name, at
General any point.
320 Functionality: The system shall allow the user to save their scenario and continue
General working on it.
321 Functionality: The IFOTA shall prompt the student to login (appropriate permissions will
General be keyed to login)
322 Functionality: The IFOTA shall identify types of users and work group members
General through coded logins
323 System: The IFOTA shall prompt the student to select a module in the login
General screen
324 System: The IFOTA shall use login information to direct file save paths
General
A-20
325 System: The IFOTA shall provide scenario search capability on a single screen
General through a clickable world map and a text-based search function
326 System: The IFOTA shall provide a geographically-based scenario search

General capability through a MAJCOM map that permits the user to drill down to
specific countries and local areas to obtain the scenario files for the
chosen area.
327 System: The IFOTA shall provide a text search capability that permits the user to
General obtain the scenarios for specific ethnocultural groups, tactical tasks,
discipline-specific tasks, or geographic locales
328 System: The IFOTA shall prompt the scenario creator/modifier to tag the scenario
General by geographic locale, ethnocultural group, and tactical/support tasks
329 System: The IFOTA shall permit the scenario to be opened from the scenario
General search results display
330 Software: The IFOTA shall provide access to all functions through a menu bar with
General main menus and submenus
331 Software: The IFOTA shall display keystroke combination shortcuts for actions on
General the submenus
332 Module: Help The IFOTA shall identify icon function with hovertext
System
333 Software: The IFOTA shall provide alternate access to frequently used functions
General through a tool bar
334 System: The IFOTA shall be able to be installed and run on a JWICS system
General
335 Module: Help The IFOTA shall provide a Help function

System
336 System: The IFOTA shall have PSYOP, MD, OPSEC, and PA modules
General
337 System: The IFOTA shall include a CI module

General
338 System: The IFOTA shall have a module that accepts/displays EW and NW
General planning entries
339 Module: The IFOTA shall have an Instructor module

Instructor
340 Module: RFI The IFOTA shall provide an RFI management function
341 System: The IFOTA shall be designed to facilitate integration with IOPC-J
General
A-21
342 Software: The system shall support a mult-user environment.
General
343 Software: The system shall support an individual user environment.

General
344 Software: The system shall support a concurrent user environment.

General
345 Software: The IFOTA shall have a graceful shutdown process.

General
346 Software: Entrance into the IFOTA software shall be gained by double-clicking on
General an IFOTA icon.
347 Software: The initial IFOTA screen shall display a splash screen.
General
348 Software: The IFOTA shall have an autosave function.

General
349 Software: The IFOTA shall provide meaningful error messages with instructions.
General
350 Software: The IFOTA shall permit simultaneous access by multiple users to one
General scenario.
351 Software: The IFOTA shall have a login feature.

General
352 Software: The IFOTA shall have a 'student' permissions level.

General
353 Software: The IFOTA shall have an 'instructor' permissions level.

General
354 Software: The IFOTA shall have an 'admin' permissions level.

General
355 Software: The IFOTA shall allow the user to save his work in a directory specified
General by the user.
356 Software: The IFOTA shall be platform independent.

General
357 Software: The IFOTA shall provide a backup feature.

General
358 Functionality: The system shall have a print function.

Print
A-22
359 System: The system shall allow the user to generate a new scenario.
General
360 System: The system shall allow the user to open existing scenarios.
General
361 System: The sytem shall have a spell check feature for all user-entered text
General boxes.
362 System: The system shall allow the user an unlimited number of login attempts
General
363 System: The IFOTA shall be fully functional for one user only.
General
364 System: The IFOTA shall be fully functional for a team of users, each working on
General different modules.
365 Module: RFI IFOTA shall provide a Request for Information (RFI) module.
366 System: IFOTA shall permit users to access multiple scenarios simultaneously
General
367 System: IFOTA shall display a summary of the justification text entered. May be
General the same screen it was entered in.
368 System: IFOTA shall display a summary of the deconfliction text entered. May be
General the same screen it was entered in.
369 System: IFOTA shall capture plan sequels

General
370 System: IFOTA shall use the FM 3-05.301 as a guide to developing the PSYOP
General planning module.
371 System: IFOTA shall provide a means to capture Target Audience Analysis
General planning (ref. FM 3-05.301)
372 System: IFOTA shall use the USAF Operational Military Deception Planners
General Handbook as a guide to developing the MD planning module.
373 Software: The IFOTA shall provide an example list of Air Force operational
General objectives organized by service supported
374 Functionality: The IFOTA shall allow users to print MD, PSYOP, OPSEC and/or PA
Print plan summaries contained within a scenario
375 Functionality: The IFOTA shall allow users to print complete set of MD, PSYOP,
Print OPSEC and/or PA supporting tasks (with associated decision criteria)
contained within a scenario (complete IO discipline plan)
A-23
376 Functionality: The IFOTA shall allow users to print MD, PSYOP, OPSEC and/or PA
Print COAs (with associated decision criteria) for individual tactical tasks
(portions of the IO discipline plan)
377 Functionality: The IFOTA shall allow users to inputs to the Commander's Briefing
Print
378 Functionality: The IFOTA shall allow users to print the Commander's Briefing
Print
379 Functionality: The IFOTA shall allow users to print the target list
Print
380 Functionality: The IFOTA shall allow users to print the event schedule
Print
381 Software: The IFOTA shall capture user-identified high priority targets
General
382 Software: The IFOTA shall capture user-identified high payoff targets
General
383 Software: The IFOTA shall capture user-identified common targets

General
384 Software: The IFOTA shall capture user-identified prioritization for the combined IO
General COA recommendations in the Commander's Briefing
385 Module: MD The IFOTA shall capture user-generated probability of success estimates
for MD supporting tasks
386 Module: The IFOTA shall capture user-generated probability of success estimates
PSYOP for PSYOP supporting tasks
387 Module: The IFOTA shall capture user-generated probability of success estimates
OPSEC for OPSEC supporting tasks
388 Module: PA The IFOTA shall capture user-generated probability of success estimates
for PA supporting tasks
389 Module: MD The IFOTA shall capture user-generated rankings for MD supporting
tasks
390 Module: The IFOTA shall capture user-generated rankings for PSYOP supporting
PSYOP tasks
391 Module: The IFOTA shall capture user-generated rankings for OPSEC supporting
OPSEC tasks
392 Module: PA The IFOTA shall capture user-generated rankings for PA supporting
tasks
A-24
393 Module: MD The IFOTA shall capture user-identified MD supporting tasks and include
in them in the Commander's Briefing
394 Module: The IFOTA shall capture user-identified PSYOP supporting tasks and
PSYOP include in them in the Commander's Briefing
395 Module: The IFOTA shall capture user-identified OPSEC supporting tasks and
OPSEC include in them in the Commander's Briefing
396 Module: PA The IFOTA shall capture user-identified PA supporting tasks and include
in them in the Commander's Briefing
397 Module: MD The IFOTA shall capture user-identified justifications for MD supporting
tasks in the Commander's Briefing
398 Module: The IFOTA shall capture user-identified justifications for PSYOP
PSYOP supporting tasks in the Commander's Briefing
399 Module: The IFOTA shall capture user-identified justifications for OPSEC
OPSEC supporting tasks in the Commander's Briefing
400 Module: PA The IFOTA shall capture user-identified justifications for PA supporting
tasks in the Commander's Briefing
401 Module: MD The IFOTA shall capture user-provided cost/benefit assessment or other
cost-based assessment or cost documentation for each MD supporting
task
402 Module: The IFOTA shall capture user-provided cost/benefit assessment or other
PSYOP cost-based assessment or cost documentation for each PSYOP
supporting task
403 Module: PA The IFOTA shall capture user-provided cost/benefit assessment or other
cost-based assessment or cost documentation for each PA supporting
task
404 Module: MD The IFOTA shall capture user-identified cost information for MD
supporting tasks in the Commander's Briefing
405 Module: The IFOTA shall capture user-identified cost information for PSYOP
PSYOP supporting tasks in the Commander's Briefing
406 Module: The IFOTA shall capture user-identified cost information for OPSEC
OPSEC supporting tasks in the Commander's Briefing
407 Module: PA The IFOTA shall capture user-identified cost information for PA
supporting tasks in the Commander's Briefing
408 Module: MD The IFOTA system shall capture user justification for MD support task
and associated MOE/MOP recommendations
409 Module: MD The IFOTA system shall capture user justification for MD story
development
A-25
410 Module: MD The IFOTA system shall capture user justification for MD story delivery
means
411 Module: MD The IFOTA system shall capture user justification for MD Event Schedule
entries
412 Module: MD The IFOTA system shall capture the user's target audience analysis
413 Module: MD The IFOTA shall provide space for the user to insert measures of
effectiveness (MOEs) for each MD supporting task (aka MD tactical
supporting task)
414 Module: MD The IFOTA shall provide example MD MOEs
415 Module: MD The IFOTA shall allow the user to input MD means
416 Module: MD The IFOTA shall allow the user to select multiple MD means
417 Module: The IFOTA shall link to PSYOP supporting references (simulating
PSYOP reachback and SIPRNET)
418 Module: The IFOTA system shall capture the user's PSYOP target audience
PSYOP analysis
419 Module: The IFOTA system shall capture the user's likelihood of change estimate
PSYOP
420 Module: The IFOTA system shall capture a description of the user-developed
PSYOP influence COA
421 Module: The IFOTA system shall capture the user's scheduling/timing
PSYOP recommendations
422 Module: The IFOTA system shall display the PSYOP schedule of events
PSYOP
423 Module: The IFOTA system shall capture operational feedback (simulated mission
PSYOP results)
424 Module: The IFOTA system shall display operational feedback

PSYOP
425 Module: The IFOTA system shall distinguish between MOE and MOP feedback
PSYOP
426 Module: The IFOTA system shall capture user justification for target action and
PSYOP MOE/MOP selection
A-26
427 Module: The IFOTA system shall capture user justification for selection of best
PSYOP changes to influence factors
428 Module: The IFOTA system shall capture user justification for influence COA
PSYOP development
429 Module: The IFOTA system shall capture user justification for delivery method
PSYOP and time inputs
430 Module: PA The IFOTA system shall permit the user to capture MOEs for PA-specific
tactical support tasks
431 Module: PA The IFOTA system shall capture user justification for MOEs and MOPs
432 Module: PA The IFOTA system shall capture the PA desired target opinion
433 Module: PA The IFOTA system shall capture the PA "worst case scenario"
assessment and associated requirements
434 Module: PA The IFOTA system shall capture the user's PA target audience analysis
435 Module: PA The IFOTA system shall capture operational feedback (simulated mission
results)
436 Module: PA The IFOTA system shall display operational feedback
437 Module: PA The IFOTA system shall distinguish between MOE and MOP feedback
438 Module: The IFOTA system shall capture the OPSEC target audience analysis
OPSEC
439 Module: The IFOTA system shall capture operational feedback (simulated mission
OPSEC results)
440 Module: The IFOTA system shall display operational feedback

OPSEC
441 Module: The IFOTA system shall distinguish between MOE and MOP feedback
OPSEC
442 Module: The IFOTA system shall capture user justification for MOEs and MOPs
OPSEC
443 Module: The IFOTA system shall capture impact in the range of 1-100.
OPSEC
A-27
APPENDIX B
USE CASES & UML DOCUMENTATION
B-1
Figures B-1 through B-4 illustrate UML modeling for IFOTA.
Figure B - 1. Truncated Entity-Relationship Diagram (based on Version 2)
B-2
Scenario Each node has a planning process that
describes the steps needed to make a valid
-nodeList:Node[] node
-title:String
A node has a number of

ModuleNodeController which controls
0..*
the Node and provides a uniqueness Cr iter ia
Node of the node.
-annotations:Comment[]
-comments:Comment[]
id:ID
name:String
Measur eOfEffectiveness
Measur eOfPer formance
+MeasureOfEffectiveness SuccessIndicator
AreaOfInter est +MeasureOfPerformance
criteria:Criteria -criteria:Criteria
status:Status criteria:Criteria
qualitative:boolean qualitative:boolean
status:Status
0..*
0..*
Effect 0..*
#significant:boolean
+toString:String
description:String
contexts:ContextList
resourcesStatus:Status
effectiveness:Status
performance:Status
confidence:Confidence
Objective
0..* 0..*
Comment
Task enabling:boolean
contributory:boolean
contents:String
userId:int
assets:Assets
contexts:ContextList
name:String
description:String 0..* 0..*
TacticalObjective OperationalObjective
Plan
-moe:MeasureOfEffectiveness[] -successIndicator:SuccessIndicator[]
0..*
tacticalTaskIds:IDList tacticalObjectiveIdsList:IDList
TacticalTask
-plans:Plan[]
-mop:MeasureOfPerformance[]
-desc:String Module Node Controller tells the viewwhat to
Deconfliction
displayand bridges the view to the data store.
PysopPlan PlanningProcess
CounterIntelligencePlan MilitaryDeceptionPlan
Gr oup
-targetAction:String
-supportingTasks:String -influenceFactors:InfluenceFactors
-analysis:Analysis
OpSecPlan sdPercep:int interface

PublicAffairsPlan
sdActions:String 1..* ModuleN odeC ontroller
taMOP:String List
-targetAudience:PubAffTargetAudience perception:MilDecPercep taMOE:String ProcessStep
methodMeans:MilDecMethMeans interface +processStep:ProcessStep
targetAudience:PysopTargetAudience QueryableList User
event:EventSchedule +node:Node
currentCond:Object -comments:Comment[]
criticalInfo:String feedback:MilDecFeedback targetCond:Object -annotations:Comment[]
CIVuln:String ciSituation:CounterIntelSituation deliveryMethod:String[]
adverThreat:String schedule:EventSchedule
riskLevel:int
primaryCounterMeasure:String elementType:Class leaf:boolean
secondaryCounterMeasure:String name:String
id:ID
PubAffTargetAudience
PysopTargetAudience
-desc:String
-cultrualAffl:CulturalAffl
MilD ecPercep
-currentPercep:String ObjectiveModule
infoSource:String PerceptionModule
-desiredPercep:String location:String Tar getModule
messageTopic:String InfluenceModule
goal:String ethnicity:String
currentOpinion:int countryOfOrigion:String
targetOpinion:String language:String
occupation:String description:String
desiredPerception:Perception
literacyRate:int
method:String
property:int
CounterIntelSituation
MilD ecMethMeans
-method:String
-means:String Cultur alAffl
information:String
accuracy:int
source:String 0..* GeoLocation
credibility:String religion:String
responseType:String variants:String
responseAction:int leadership:String
responseMethod:String EventSchedule tribe:String
codeOfConduct:String
-methodMeans:MilDecMethMeans[] values:String
-beginDate:Date politicalAffl:int
-endDate:Date
-event:String
InfluenceFactor s
MilD ecFeedback
-factor:String
-operationalFeedback:String -description:String
-analyticalFeedback:String
Analysis
-imValues:int[]
-likehoodChange:int
weight:int
Figure B - 2. General Class Diagram of Main Planning Elements (based on Version 2)
B-3
B-4
IFOTA System boundary JComponent LeanSparseVertex interface ...renderer.NodeRendererFactor y
This diagram shows all of the ScenarioGraph ...common.CommonVer tex ...graph.renderer.INodeRenderer
-single:NodeRendererFactory
user (student) case cases for #prePainters:Vector #tooltip:String
IFOTA. #postPainters:Vector #decisionTooltip:String +getFactory:NodeRendererFactory
UE8 Save Scenario UE10 Create an OO +paint:void
#scaleDate:long -NodeRendererFactory
+getPreferredSize:Point
U1 Open an Existing Scenario Since the Administrator
#mouseDown:boolean -cleanupEffort:void +getNodeRender:INodeRenderer
#startScale:double
<<include>> UE11 Create a TO (instructor) can do anything a #mousePoint:Point name:String
dnd:DND toolTip:String
<<extend>> user can do, it is also shown on
decisionToolTip:String
this diagram. +addDropTarget:void startDate:long
UE12 Create a TT
+ScenarioGraph endDate:long
interface interface
U2 Create a NewIFOTA Scenario <<extend>> <<extend>> The Administrator-specific use
+cleanup:void percentComplete:double
...graph.renderer.IPostPainter ...graph.renderer.IPrePainter
#resizeLayout:void effortLength:int
<<extend>> cases are shown on the +doLayout:void enabled:boolean
UE7 Comment Plan +paint:void effortEstimate:double[]
<<extend>> diagram IFOTA Administrator
#renderEdges:void effortActual:double[] +paintLast:void +paintFirst:void
<<extend>> Use Cases. #renderGraph:void
<<include>> <<extend>> #paintEdges:void
<<extend>> +addPrePainter:void
+removePrePainter:void Renderer Layout
<<include>> UE1 Complete the MD Module +addPostPainter:void ...renderer.ScenarioR enderer LayoutManager
<<extend>> +removePostPainter:void
U3 Modify an IFOTA Scenario <<include>>
...graph.layout.Scenar ioLayout
<<extend>> +getToolTipText:String +MINUSICON:ImageIcon
+getEdgeAtPoint:Object +PLUSICON:ImageIcon -viewSize:Dimension
UE2 Complete the PSYOP Module <<extend>> #getTreeNodeAtPoint:Node
<<include>> <<extend>> -armSpace:int -viewKey:Pair
User -findNode:Node -progress:mil.af.ifota.graph.common.indicators.SandFillProgressBar
<<include>> <<extend>> #getTreeNodeAtPointUsingRange:Node +ViewKey:Pair +ScenarioLayout
-findNodeFromRange:Node -finalizePaintObjs:Vector +cleanup:void
<<extend>> <<extend>>
<<include>> +layoutContainer:void
UE3 Complete the OPSEC Module -TargetListener +ScenarioRenderer +advancePositions:void
-DND +paintVertex:void #layoutGraph:void
+ScenarioViewport +paintEdge:void #layoutVertex:void
<<extend>> <<extend>> +addFinalizePaintObject:void -hideVertex:void
<<extend>> UE4 Complete the PA Module viewKey:Pair
U8 Print IFOTA Plan UE6 Deconflict +finalizePaint:void +initialize:void
renderer:Renderer
<<extend>> -contains:boolean +getX:double
model:ScenarioModel +getY:double
scale:double pickedKey:PickedInfo +applyFilter:void
UE5 Complete the CI Module
<<extend>> +restart:void
+getVertex:Vertex
<<extend>> +getVertex:Vertex
<<extend>> +resize:void
+incrementsAreDone:boolean
interface interface AbstractSparseGraph ...af.ifota.gr aph.common.N ode Rectangle
+lockVertex:void
U9 Export Plan to Powerpoint ...graph.renderer.IFinalizePainter ...graph.renderer.IEdgeRender er ...ifota.model.ScenarioModel INodeRenderer
<<extend>><<extend>> -CREATED:Integer ...ifota.graph.views.NodeView
+unlockVertex:void
+forceMove:void
-orderedIds:Vector
#changeEvent:ChangeEvent +Node #expandedSequal:boolean +addLayoutComponent:void
+finishPainting:void +paint:void +removeLayoutComponent:void
#listenerList:EventListenerList +addChild:void #gravity:boolean
+accepts:boolean #taskcycle:boolean +preferredLayoutSize:Dimension
U4 Access External Research Links +ScenarioModel +transfer:NodeAndEdge #border:boolean +minimumLayoutSize:Dimension
+cleanup:void dash1:float[]
+getNodeById:Node +NodeAndEdge dashed:BasicStroke status:String
graph:Graph
+addNode:Edge +totalWidth:int
U5 Send an RFI #fireStateChanged:void model:ScenarioModel +totalHeight:int incremental:boolean
visibleEdges:Set
parent:Node -joint:Point
RFI Collecting visibleVertices:Set
startDate:long children:Vector
Administrator U6 Chat with Other IFOTA Users currentSize:Dimension
Agency endDate:long ID:Integer +NodeView
root:Node id:Integer +NodeView
changeListeners:ChangeListener[] description:String +NodeView
+NodeView
DirectedSparseEdge
U7 ViewStatus of Other Users' change +NodeView
+NodeView ...af.ifota.gr aph.common.Edge
Plans Within Own Group
+NodeView
#bar:JProgressBar
+setParentNodeJoint:void
#tooltip:String
+paint:void
+getPreferredSize:Point
U10 Access IFOTA Help +Edge
+isMouseOver:boolean
visible:boolean
visibility:boolean
toolTip:String
U11 ViewLesson Plan visiblity:boolean
collapsable:boolean
filtered:boolean
expandedSubset:boolean
paintGravity:boolean
paintTaskCycle:boolean
U12 Export Workto File or Disk paintBorder:boolean
estimateColor:Color
actualColor:Color
U13 Provide Feedback on Class icon:Icon
expanderCoordinates:Rectangle
controlRange:Rectangle
selected:boolean
U14 ViewAll RFIs and Responses
U15 ViewQuickLook Book

IEdgeRenderer mil.af.ifota.graph.views.TOView mil.af.ifota.graph.views.OOView mil.af.ifota.graph.views.MDView ...ifota.graph.views.ScenarioView mil.af.ifota.graph.views.PlanView
IFinalizePainter
...ifota.graph.views.EdgeView -label:JLabel -label:JLabel -label:JLabel
U16 Complete Coursework +paint:void +PlanView
+NO_ARROW:int +paint:void +paint:void +paint:void
+getPreferredSize:Point +paint:void
+ANGEL_ARROW:int +getPreferredSize:Point +getPreferredSize:Point +getPreferredSize:Point
+WEDGE_ARROW:int
U17 Access Acronyms and Definitions -hasChildren:boolean
-childrenExpanded:boolean
-jointX:int
U18 Access Context Sensitive Help -jointY:int
-armSpace:int
-end:Node
-childView:NodeView
U19 DisplayIFOTA Version Info
+EdgeView
+initialize:void
+paint:void
+finishPainting:void
U20 Exit IFOTA +isMouseOver:boolean
+mouseClick:void
UE9 Print Preview color:Color

stroke:Stroke
fromArrow:int
toArrow:int
visible:boolean
...af.ifota.gr aph.views.OpsecView
Figure B - 3. Use Case Diagram (based on Version 2) Figure B - 4. View Model Class Diagram (based on Version 2 - Jung)
B-5
B-6
APPENDIX C
TRIP REPORTS
C-1
MEMORANDUM FOR RECORD
SUBJECT: IWE DO-0008 Trip to Hurlburt Field, FL (39th IOS Schoolhouse)
FROM: Elisabeth Fitzhugh, Human Factors Lead, SRA International
1. Introduction. Notes below are captured in terms of utility and usability issues and
requirements identified during the trip.
IOTA, a Psychological Operations (PSYOP)-oriented planning tool, is intended to be an

influence operations training aid that walks analysts through the PSYOP planning process
and prompts analysts to evaluate potential courses of action. It uses standardized military
objectives based on tenets of air and space employment. COA evaluations are based on
1) subjective weights and ranks assigned to critical cultural factors associated with the
target audience (TA) that impact achieving the desired effect and 2) the anticipated
probability of modifying those factors to induce the desired effect. The evaluation is a
risk assessment for the projected course of action (COA).
The current version was developed for operational use. Future plans call for updating the
PYSOP component and integrating Military Deception (MD), Public Affairs (PA), and
Operations Security (OPSEC) planning components using the same or similar algorithms
to assess COAs.
The trainers‘ goal is for the system to support student acquisition of an integrated
multidisciplinary perspective capability as well as specific AOC targeting and planning
capabilities. IOTA should support students as they learn to organize a body of
knowledge, plan and execute a strategy across all influence operations disciplines.
AF Influence Operations (IO) are based on exploitation of the adversary‘s mental state.
The choice between media-based and leaflet-based campaigns or other non-kinetic
methods are choices between delivery mechanisms. In determining methods, students
must bear in mind where information comes from and its probable validity, maintain an
appropriate cultural mindset, understand the ―why‖ behind the information, and form
appropriate mental models. They must be able to weight TA fears, understand how those
fears influence behavior, and understand the ―why‖ behind behavior.
2. Usability Issues (Focus on the User)
User Characteristics
2. Class Demographics:
a. Joint class members are integrated by service and rank (range from E-2,
E3 to Lt Col). Members exhibit differential levels of expertise; levels
of expertise range from 2 to 3 years (beginner) to 15 years (expert).
Issue: Class tools need to be scalable to teach and test multiple levels of
expertise.
b. There are one to two instructors per ~20-person Influence Operations
(IO) class. The class focuses on Falconer Aerospace Operations Centers
C-2
(AOCs). Class population comes from the nine Information Warfare
Flights (IWFs) Class constitution is governed by the gaining unit and
their needs. Percentages change from class to class.
Issue: Student need for instructor attention will vary. Class tools need to be
self-supporting to some degree to allow students to work independently.
c. Students are taught how to support all IO disciplines used in AOC but
when they report to their IWFs, they will fill whatever slots are open,
performing IPB for deliberate planning and continuous update functions.
During contingencies, approximately ½ the flight will go with the AOC;
the rest will remain with the IWF, supplying reachback.
Issue: There is a concern that students may forget lessons that aren‘t
reinforced over time.
3. Student Computer Expertise:
a. The tool is HTML-based and will be accessed as a web page. The web
page interface is desirable as all students should have familiarity with a
web environment; students are expected to know how to use typical
internet browser functions.
Issue: The tool needs to incorporate all the capabilities of a web
environment (highlight, copy, paste, save as). Aids should include pop ups,
hover, find, and drill down capabilities. Users should be able to jump to
mail to output to other organizations.
b. Student briefings, which simulate presentations to AOC decision
makers, are done in PowerPoint (however, trainers express a desire for
the system to integrate with all MS Office).
Issue: The tool currently supports copy and paste functions, but automating
transfer of information from the tool to the PowerPoint presentation would
save time and effort. Trainers want the program to integrate with Microsoft
Office and be able to ―push‖ to TBMCS.
Task Characteristics
2. Task Overview:
a. Tasks are constrained by class time. In the first part of the course,
trainers give an overview of the different disciplines, the standard
measures of behavior, and how to measure behavior. In the second
phase, SMEs give units of instruction on their specific disciplines, use
slides accompanied by slide notes. The course moves from rote memory
exercises to demonstrations of subject matter expertise.
Issue: Currently, students get three weeks of practice in the planning stage.
Eventually, trainers will integrate practice exercises into more of the course.
Instructors and students will create new scenarios to add to IOTA‘s existing
scenario database. As more information is acquired, there will be a need to
update the influence operations factors to reflect increased understanding.
b. Using the tool prototype, for a given scenario, students should be able to
identify operational and tactical objectives and associated measures of
effectiveness (MOEs), characterize the target audience and identify
opportunities, limiting factors (LIMFACs) and susceptibilities, and rank
C-3
and weight the susceptibilities. The students should be able to give a
level of confidence in information and a level of effectiveness (ability to
reach the susceptibility); the student should be able to weight the
likelihood of success.
Issue: Students will have access to Secure Internet Protocol Router Network
(SIPRNET), Non-Secure Internet Protocol Router Network (NIPRNET),
and the Joint Worldwide Intelligence Communications System (JWICS).
The user must be able integrate database access and exercise activities. The
students use IWPC, IWS, and ION; some degree of IOTA integration may
be required.
c. To complete the task, students should be able to use available databases
to research culture and leadership aspects to determine how to affect the
population and the leadership.
Issue: Navigation between planning and decision support tools and
supporting databases should require minimal effort and minimal time. No
picture of what the screen will look like while the student moves between
application and reachback capabilities is currently articulated. How the
system looks, how the students will keep track of where they are between
applications, how quickly and easily they can navigate and how quickly and
easily the database supports their information quests are all human factors
integration issues.
GUI Environment
2. Common Look and Feel:
b. The IOTA tool, like some other applications students will use, is web-
based. Other applications are MS Office-based or employ the standard
Windows work environment.
Issue: The IOTA tool GUI should leverage student familiarity with the MS
Internet Explorer web browser and Office suite GUIs. It should also
leverage all Windows ―Help‖ capabilities and user aids (Help topics, Table
of Contents, Index, Glossary, context-sensitive Help, etc.)
Operational Environment
2. Environmental Characteristics:
b. Students will be working as teams to create their recommendations.
Students will represent the different disciplines/roles found in the AOC.
Issue: Students need to be able to work alone or collaboratively. Students
need to be able to deconflict their respective plans.
3. Utility Issues (Focus on the Task)
Job Requirements
2. Mission-level Expectations:
a. Students will be taking the role of AOC staff and will have to consider how
their input factors into the overall mission plan
Issue: None currently identified
C-4
b. Expectations are that students will push to have the training tool made
operational.
Issue: The more realistic the training tool is, the more likely students are to
push for it; a very realistic training tool will be easier to operationalize.
c. The students must integrate and deconflict their recommendations with other
IO disciplines
Issue: A vision of how the deconfliction aspect will work has not yet been
articulated.
Trainer Tool Use
4. Tracking:
a. Trainers have not yet considered all they want the tool to track. They
exhibited a positive response to the suggestion that the tool might include a
mechanism for tracking exercise and test performance. System tracking
would lighten the trainer workload.
Issue: Any tracking expectations should be worked out now to aid the
designers‘ planning process. Trainers indicate they will be giving individual
grades and group grades for group efforts. How to track that should be thought
out in advance as well.
5. Testing:
a. Trainers expect to use the tool in both in class exercises (partial tasks) and
the capstone exercise that will permit students to integrate all they have
learned in the course.
Issue: Trainers indicated a desire to be able to see what students were doing in
order to supervise and aid.
b. Trainers want to integrate students‘ capabilities in team exercises and stretch
everyone. They want to elicit thinking through student identification of
options and variables. Trainers suggest that the tool include an option that
allows them to increase exercise difficulty based on student performance
(―teach to each‖ versus ―teach to mean‖). An example is the ability to go
from a two-channel ―on/off‖ scenario to a five-channel one, increasing the
number of options in the variables offered. They also suggest adding an
assessment method to tell what would have happened if the student had
chosen differently, following the branches, and a method to anticipate
sequels.
Issue: Currently there is no scalability in the training module. Specific
requirements for extension modules are yet to be determined.
6. Feedback:
a. Subjective weightings/rankings are only as good as the student‘s expertise
and information base. The exercise of decomposing the factors that affect
the TA and watching how changing weights for individual factors changes
the probability of success is valuable in itself. Trainers suggested that they
would like to see feedback. They envisioned the following training
scenario:
C-5
 For a given exercise, the system provides a series of variables that
form three distinct paths to follow (Path A=50% of the solution,
Path B=100%, and Path C=25%).
 System collects data on the students‘ selection of variables and
how they justified them.
 System identifies the incorrect paths and the shows cascading
effects from following the wrong route.
 System shows the correct path and its cascade of effects.
 Trainer tracks student progress; if at any point, the student chooses
A, the trainer can show why that path is not optimal, but if the
student chooses C, the trainer knows to take him/her back to
basics.
Issue: Hardwiring, as described above, cuts down on options, but the trainers
say that is all right for a training aid. Providing only this option would not
necessarily provide a close match with reality, where there is often no right
answer.
b. However, the system could also be designed to allow freedom of
thought/movement, offering a best choice answer and several others that
varied in degree of usefulness, and allowing the student to work out a best
possible solution. In this mode, the system again would show possible
outcomes.
Issue: Including both of these modes would allow the student to progress from
canned classroom scenarios to real world scenarios. It would also provide a
method for providing increased difficulty for more able students.
Student Tool Use
3. Student Task:
a. The classes mirror every step of the planning process, taking the student
from ―hands-on‖ trainer-supported exercises to a ―hands-off‖ capstone
training effort. Trainers provide the students with a set of JTF objectives
and plug in standardized objectives for the exercise, depending on the
scenario (e.g., eight objectives for phase one). Influence operations
objectives will be the sub-objectives (influence nation command, influence
political structure, etc.) Each individual discipline can answer the need.
Students learn to write their own objectives and how to modify Air Staff
concepts to perception management needs and integrate counter-intelligence
perspectives. Students must learn to support why a non-kinetic option is
preferable to convince the AOC. They must be able to present their plan,
provide appropriate details, make a strong argument, show the effects and
the effects desirability, and defend the plan‘s solution.
Issue: IOTA must be updated to include the entire planning process; the
designers intend for the tool to mirror the language used in AOC planning. As
the AOC planning process is under development, language changes may have to
C-6
be updated/updatable. (MOEs should be included in the program, but need to
be adjustable as analysis renders them inappropriate.)
b. In the new exercises, all targets go ―on deck‖ no matter how they are to be
prosecuted, only the restricted target list will be retained. Kinetic and non-
kinetic options will be de-conflicted (e.g., will ensure that there is no close
air support activity scheduled for the vicinity of leaflet drops). The point is
to integrate the air picture for the day and deconflict all missions at once.
Issue: How the deconfliction aspect will be managed is not yet articulated.
c. Students will practice assuming different roles in the AOC. Hands-on
exercises will be require both individual effort, with each student using
different expertise to do his/her own portion, and group coordination,
integrating and deconflicting individual efforts. Lesson includes teaching
students how to present to staff estimates of non-kinetic actions. In order to
accomplish the task, students also must learn how to manage group
dynamics.
Issue: How the students will collaborate is not yet articulated.
4. Task Support:
a. Classification: At IOIC, students will stay on JWICS, with SIPRNET and
NIPRNET for research and reach-back capabilities. MD will be done at the
SECRET/NOFORN level, and will incorporate national level entities on
JWICS. Exercises may require going to a high level classification.
Issue: Unclassified paradigms for scenarios will need to be built; there will be
nothing classified in the developmental design. For the MD section, the design
will need to separate high and low classification aspects (multi-level security?).
b. MD, OPSEC and PSYOP employ somewhat different terminologies to
reflect their different perspectives. OPSEC is the only track that asks the
student to look at how their plan will both impact US activities (giving
Indications and Warnings; I&W) and US perceptions.
Issue: Language usage will have to be carefully documented and managed.
Additionally, the OPSEC track may pose difficulties for students as they have to
focus their objectives differently than in PSYOP and MD. The OPSEC
objective is to remove I&W, whereas the MD objective is to exploit them.
c. How well the students know where to get data will vary by student; students
are given lists of urls in class that the instructors have compiled.
Issue: The instructor-supplied urls can be integrated into the internet browser as
favorites and the file emailed for importation in the students‘ home systems.
d. Students must factor in cultural analysis issues (e.g., how to communicate
with non-literate populations). Students are taught to leverage preconceived
adversarial and military mindsets.
Issue: PYSOP recommendations are turned over to the Army for
implementation. The actual method of implementation is not determined by the
student.
C-7
e. In the current version of the tool, the focus is on the factors that influence
TA behavior, the estimated difficulty friendly forces will experience
directing TA behavior toward the goal state.
Issue: The goal state is represented by standard PSYOP objectives; the actual
PSYOP plan is not captured when users project probability of success
influencing TA behavior.
f. PSYOP doctrine is in a state of flux. The new JP 2.5.3 draft hasn‘t been
signed yet; neither has the new OPSEC draft.
Issue: The changes in doctrine will probably impact lesson plans and decision
support tool requirements. Additionally, according to the trainers, current AF
training focuses on deliberate and contingency planning for force execution
missions. Training doesn‘t cover how to plan for Humanitarian Assistance
(HA), Noncombatant Evacuation Operations (NEO), and Civil Affairs (CA)
outside of hotspots in the Middle East. Training doesn‘t cover planning for
nation building or planning for handing over an area to the ambassador for
reconstruction. Training doesn‘t cover how to redeploy, reconstitute or employ
forces in interim periods and how to get people in and out safely. PSYOP is
concerned with developing ways to endear US forces to the population to
reduce risk and increase cooperation. Any future effort to add in these training
modules will extend required scenarios considerably.
4. System Requirements
1. Modify current version to show military objectives at three levels:

 Operational air objectives
 Tactical objectives
 Tactical tasks
2. Modify current version to include success indicators (measures of merit) at each
level of objective.
3. Modify current version to allow the operator to modify operational objectives,
sub-objectives and success indicators.
4. Update current version to reflect new PSYOP-related behavioral information.
5. Modify current version to reflect language used in course/work area.
6. Integrate the work domain language of all SME tracks into the tool.
7. Develop a glossary for planning language.
8. Develop interoperability with Sensor Harvest, IWPC, IWS, ION
9. Redesign current tool to take the trainee from planning to outbrief. Modify the
current tool to export the objectives, measures of merit, suggested COAs (in rank
order), COA risk assessment/rationales, and anticipated end states to a
PowerPoint slide show suitable for briefing decision makers.
10. Include a capability to track student progress, give feedback, show alternative
paths and outcomes, and capture student performance.
11. Include a capability to show branches and sequels for planning over time.
12. Include a capability to update scenarios based on target audience response.
13. Integrate the tool with MD (uses MIDB) and OPSEC data sources and planning
tools. (Currently, PA has only been discussed as an adjunct to each of the other
C-8
disciplines.) Integration should include deconfliction of PSYOP, MD and OPSEC
COAs.
14. Integrate the tool with Secure Internet Protocol Router Network (SIPRNET),
Non-Secure Internet Protocol Router Network (NIPRNET), and the Joint
Worldwide Intelligence Communications System (JWICS)
15. Develop ability to capture information in different databases and integrate access
to database system. In PSYOP and MD, need to be able to populate the databases
with new information as it is learned.
5. Collection/Testing Suggestions
1. Need to perform cognitive walk-throughs with several trainers (optimally, with

students, too) to observe and analyze tool use behaviors.
2. Need to perform experiments to differentiate between ―aided‖ versus ―unaided‖
performance. Need to collect baseline performance data.
3. Need to perform usability tests (includes collection of error behaviors, system
response to errors, hesitations, system aid needs, performance times, etc.)
6. MD & OPSEC
 The MD and OPSEC processes model the basic IO process; some terminology
differences were noted and will have to be incorporated in design planning.
 IO (especially in MD) identifies the primary decision maker and leverages
his/her perceptions to US advantage. Whenever possible, it seeks the path of
least resistance, using adversary opinion rather than changing it.
 MD‘s twin goals are to increase adversary ambiguity to slow correct decision
making, and conversely, to decrease adversary ambiguity to speed incorrect
decision making. OPSEC goals are to maximize our information protection
and minimize our information leaks. In contrast, MD leverages information
leaks.
 Trainers indicate MD and OPSEC options can be broken out as variables and
weighted as is done for PSYOP in IOTA. The trainers anticipate the IOTA
algorithms will work with minimal adjustment. The OPSEC focus is internal.
It includes internally-directed vulnerability assessment and situational risk
assessment elements that must be factored into its track design.
 MD and OPSEC use PA extensively and ideally are never isolated from PA
planning. However, no PA representative was available to discuss PA track
requirements.
 Although the major emphasis was on deconfliction of different tracks; trainers
also mentioned cooperative efforts across tracks. In the future, cooperative
planning capabilities may have to be added to IOTA.
 MD and OPSEC requirements were in synchrony with PSYOP requirements.
With the exception of PSYOP-specific comments, system requirements can be
assumed to apply to MD and OPSEC tracks.
C-9
FROM: Mike Zywien, Project Lead, SRA International
3. Notes below are captured in terms of the ―usability‖ and ―usefulness‖ criteria SRA is
developing for the IOTA project.
4. Usefulness Criteria (How effective and flexible is IOTA in supporting the work of the
IO instructor and student?):
a. Effectiveness
i. Support IO planning for all phases of an OPLAN
ii. Ensure Objectives get entered in correct terminology and structure and
can have associated success indicators and measures of merit inserted
iii. Account for uniqueness of each track (e.g. MD process and target
distinctions from PSYOP process/targets, OPSEC process/targets)
iv. Take advantage of synergies among tracks
v. Account for risk as well as probability of success in presentation of
output
vi. Ensure each module (PA, MD, PSYOP, OPSEC) reflects the process
for that track (not all processes are the same)
vii. Does IOTA ontology/taxonomy mirror the language of the course
materials and the relevant discipline
viii. Does IOTA reinforce the instructors presentation of the course work
1. IOTA presentation mirrors IO planning process taught in
lessons
2. IOTA provides cues/prompts when reachback is required
3. Import methodology and format for reachback simulates
process taught in lessons
ix. Does IOTA reinforce student understanding of the course work
1. IOTA presentation is familiar to student and mirrors process
taught in lessons
2. Understanding of when reachback is needed is clear and
straightforward
3. Easy cues/prompts to access needed data sources (reachback)
4. Student can import reachback data as required
5. Interoperability with other applications – student can provide
model output in required presentation formats
x. Scaleability
1. IOTA can be used for beginning and challenged students and
advanced students can take advantage of features to push the
analysis envelope and bring in more expertise and
sophistication
C-10
2. Ability to control versions, configuration of tool and data
xi. Collaboration
1. Input and results be exchanged, shared
2. Framework to support collaboration
3. Internal (within schoolhouse) and external (reachback)
collaboration
4. Ensure ability to integrate IO track (MD, PA, PSYOP, OPSEC)
plans (build supporting objectives and target assessments)
5. Ensure ability to de-conflict IO track plans (flag objectives and
analyses that will negatively impact plans for other IO tracks)
6. Output directly supports presentation of an integrated, de-
conflicted IO plan for a given scenario, mission objective
xii. Extensibility
1. Students can use this tool when they report to their assigned
units
2. IOTA can be implemented in IWPC or Sensor Harvest as a tool
to support deliberate and crisis action IO operational planning
3. Compatibility/extensibility to ION (joint community)
xiii. Tracking
1. A way to capture student thought process for each input to the
model (error traceability, rationale, justification, support for
end recommendations and outbrief) – notes pages
2. R/Y/G student grading at completion of model runs with
appropriate feedback and indications of where errors were
made, improvements could be made
3. Guided discovery
b. Flexibility
i. Easy to update and expand to advanced versions, new modules, refined
modules
ii. Ability to access pre-canned objectives, modify pre-set objectives, add
new objectives
5. Usability Criteria (how easy is this tool to use)

a. Implementation on JWICS (access SIPRNET, NIPRNET source data)
b. Event and change detection
c. Representation aiding
i. Graphical display of ―what if‖ and impact analysis
ii. Progress bar to indicate what steps have been successfully
accomplished
iii. Buttons to move among track modules (PA, PSYOP, MD, OPSEC)
iv. Glossary
d. Error detection and recovery
i. Help functions – how useful, how comprehensive, how clear and easy
to use
ii. Indicators of invalid input (e.g. weights) – ―need to re-evaluate‖
iii. Indicators of output that does not make sense
C-11
e. Make coherent, relevant information out of data
i. Map IOTA output to what‘s needed for target planning presentation
(e.g. targeting sheet)
f. Predictive capabilities
i. ―What-if‖ analysis
ii. Sensitivity analysis
iii. Impact analysis
g. Interoperability
i. Search engine integration (reachback)
ii. Pointers, aids to access existing data sources
1. Databases (various organizations)
2. Web sites (instructor bookmarks)
3. Documents
4. Media
5. SMEs
iii. ―Send to‖ button for checking, collaboration
6. Other general observations:

a. IOS focus is on INTEGRATED IO Planning at Operational and Tactical
levels in support of JFC, JFACC campaign objectives
b. Schoolhouse sends students to all 9 IWFs (USAFE, CENTAF, Davis-
Monthan, PACAF, USFK, AFSPACE, Weapons School, TRANSCOM, and
NORTHCOM)
c. IOTA can support both instruction and testing
d. Output probabilities may help student adjust measures of merit and Objectives
e. MD and OPSEC processes are different from PSYOP process, however all
students will be trained as planners, and all are interested in target
vulnerabilities and capabilities (targets will be somewhat different for each
track)
f. Reachback is very important and needs to be integrated into the IOTA
g. Sensor Harvest data will be very useful as a reachback capability for IOTA
h. IWPC is being considered as the ―future Joint planning suite.‖ VPT lessons
learned may aid IOTA integration into IWPC environment
i. OPSEC risk assessment methodology may be useful for other tracks, too
j. OPSEC track can have great potential for conflict with other tracks in that
other tracks (PA, MD, PSYOP) are interested in exploiting our indicators,
whereas OPSEC is interested in removing indicators
7. Plan is to target an interim demonstration of the revised IOTA in the November 2004
timeframe. This was an extremely valuable collection trip. Team will document
observations, share them with other participants and the trainers, and use as a basis to
begin design phase of project.
MICHAEL L. ZYWIEN
SRA Project Lead
C-12
FROM: Pat Ryan, Consultant, SRA International
1. Notes appearing after this page were captured during interviews with Subject Matter
Experts and System Administration personnel.
PATRICK H. RYAN
SRA Project Consultant
C-13
Notes by Topic
May 12-13, 2004 Page 1 of 7
Topic/Role Who Comments
IOTA
Metrica (Gave PPT presentation on IOTA)
Metrica Intends to create a paradigm that can be copied and
customized to a specific scenario.
Metrica want to be able to create a scenario for any country.
(country map (image map?) needs to define region for each
Metrica SMART model accounts for variability in confidence levels
Metrica IOTA is written in C++
Metrica Database is current Access. Future version will be SQL
Server
System Admin (SA 3C) Info Workspace (IWS) requires Oracle server. They may be
installing IWS soon, and if so, they will stand up an Oracle
server.
System Admin (SA 3C) They run Windows2000 on clients, Windows 2000 Server
on servers. Moving everything to Gigabit Ethernet. Clients
are Dell slim profile PCs, servers are Compaq Proliant.
They've got huge budget for equipment so they get pretty
much anything they want. Micro
Admin (SA 3C) Leah talked to me about their in-house configuration. They
want to document it in accordance with STEMB (SA
civilians that do CM for all AF bases), but simply don't have
time because they are expanding so fast. They use KVM
switches on all their Dell PC c
System Admin (SA 3C) Currently have 7 servers dedicated to single functions: Print
Server, File server, media server, Veritas backup server,
web server (Jmeasle, Cold Fusion)
System Admin (SA 3C) Would like IOTA to have a nice setup.exe that presents a
wizard which allows them to choose install directory, drives,
etc. Central installation would be best (server side vs.
client side). Their servers located underneath classroom
seating (amphitheatre
C-14
May 12-13, 2004 Page 2 of 7
System Admin (SA 3C) They have 5 networks: NSA (going away soon), SIPRNET,
NIPRNET, JWICS (most robust, where they see IOTA
installed on)
System Admin (SA 3C) Classes typically 25-60 people at a time. Can 60 use the
tool at the same time? Multiple classes at the same time?
IE is the std browser. Prefer not Netscape. Microsoft is
implied std within IO School. Training 3C's on how to
administer IOTA. IIS is their
System Admin (SA 3C) Jmeasle simulates an AOC
PSYOP Instructor The Rendon Group is the subscriptions database that is
used by IO Planners.
PSYOP Instructor Tool should mirror every step of planning process
PSYOP Instructor Provide models as a zip file on a web site so it can be
grabbed before deploying. NASIC does this for one of their
other tools. Plenty of feedback when updating files (show
what is new, allow to choose what is updated, etc.).
PSYOP Instructor Col. Durham (sp?) of PA center of excellence (Maxwell AFB)
could use data from IOTA for their purpose.
PSYOP Instructor Wants to be able to "hand-jam" data into IOTA. (via
notepad, excel, etc.) Quick and easy way to get data in
PSYOP Instructor Would like to be able to disable options via a tool. (For
example, vulnerabilities). Selectively hide some of the intel
data to make the task more difficult.
PSYOP Instructor Capture experts knowledge. NASIC needs to analyze where
they collect info from and why the info states what it does.
How to pull data from disparate db's into IOTA?
PSYOPS="mental state". How do I get to his "melon".
What do I do to his "melon". Do2= AFI2
PSYOP Instructor For novices (aka "rocks"), the scenarios would get
progressively easier. For experts, it would get progressively
harder.
PSYOP Instructor Export to IWPC is the number 1 destination for output of
IOTA. Excel is backup plan. Powerpoint would also be good
for briefing JFACC.
PSYOP Instructor Individual grading system required (vice team based)
because entire team won't deploy together to same area.
C-15
May 12-13, 2004 Page 3 of 7
PSYOP Instructor PSYOP Instructor talked again about capturing and sharing IOTA data
with other IOTA users.
PSYOP Instructor Would like to see wildcard capability in keyword searches
PSYOP Instructor Need to add MOEs MOPS to the tool.
PSYOP Instructor Wants to edit, add, delete nodes in tool (Objective, Task, MOE, etc.)
PSYOP Instructor Need to justify the final plan coming out of IOTA: Answer
the question: "How did I get here?"
Note
SRA Looks like they might benefit by using Microsoft's TreeView
in the left pane. Might simplify things a bit.
SRA IOTA Data Collection. Hurlburt AFB, Ft Walton Beach.
Information Operations School. Staff Sgt. Spike Szeredy,
Mike Zywien, Elisabeth Fitzhugh, Pat Ryan, Rosie
Vasquez (Metrica), Dr. Brice Stone (Metrica), Capt. Tim
Gameros (AFRL-HE WPAFB), Major Janelle Viera
SRA All classrooms have 2 plasma display hung in the back of
the room so the instructor can see what is being displayed
as well. 1 classroom has about 100 small cubicles with low
walls so students can see the instructor, but get privacy
between themselves.
SRA "Show best changes" link in right pane shows top 3 to
impact objective. What if it is determined that #2 is not
feasible given the assets available. Can we see option #4?
(Provide checkboxes?)
SRA Is there an editor for adding, modifying, deleting pre-set
cultural/situational factors that show under each objective?
(This came up early on in SKOPE development)
SRA Required fields not obvious until button pressed and
message window pops up indicating which field was missed.
SRA Collection and dissemination of data. Taxonomy
development. Finite/well defined scales for assigning values
such as weightings, etc. RFIs for DB data?
C-16
May 12-13, 2004, 2004 Page 4 of 7
SME
PSYOP Instructor New curriculum being developed. Feels IOTA will fit in well.
PSYOP Instructor Students come up with COAs
PSYOP Instructor PM=Propaganda management
PSYOP Instructor SIPRNET and NIPRNET used for research. JWICS will be
used for IOTA.
PSYOP Instructor The justification column (in Excel) contains why, what other
targets are required in conjunction with this one
PSYOP Instructor JTF objectives given to students
PSYOP Instructor All objectives should be broad enough to allow any of the
disciplines to be worked.
PSYOP Instructor Complexity levels of scenarios. As students get better,
scenarios should get more complex, answers become more
ambiguous, giving student more flexibility in analysis (not
hard wired)
PSYOP Instructor Primary and secondary objectives provided to students.
PSYOP Instructor Students are taught to justify PSYOP target
recommendations
PSYOP Instructor PSYOP Instructor currently selects zip files representing scenarios and
expands them to set up for a class
PSYOP Instructor IOS class course content: Part1: Objectives, samples of
behavior. Part2: Details of Objectives.
PSYOP Instructor Air Force has a 1 page doc which describes competence
levels for students (2B, 3C, etc. where D=Expert). PSYOP Instructor
will send out in package. We (SRA and Metrica) will tell
AFRL what docs we want and they will request them from
PSYOP Instructor Data Weighting: SIGINT report or debrief often gives weighted
value. Credibility rating given to data entered by a particular
type of person. Short experience = lower confidence.
Longer experience = higher confidence.
PSYOP Instructor Terminal Velocity Exercise: All targets will be put on the
C-17
May 12-13, 2004, 2004 Page 5 of 7
target list. (including PSYOP). That way, leaflet drop won't
be undermined by a bombing.
PSYOP Instructor During assessment: best guess applies. In school environment, a right,
wrong and almost right answers are available to choose from.
PSYOP Instructor Also need discipline specific objectives (CI, PM, etc.)
PSYOP Instructor PSYOP Instructor presented the IWPC PowerPoint presentation.
PSYOP Instructor IOTA data should be made available from a web site the
way that Sensor Harvest data is, so that data can be
PSYOP Instructor Media Mapping Tool=world wide list of subscriptions
(magazines, newspapers, etc.)
PSYOP Instructor We teach (????), crisis planning, force execution
PSYOP Instructor Phase 4 and 5 of a war (aka post-war Iraq) need heavy
Information Ops planning
PSYOP Instructor IOS produces students destined for the AOC
PSYOP Instructor Guidance and Objectives from JFC remain largely
unchanged through JFACC guidance and objectives.
PSYOP Instructor Powerpoint presentation briefly describes IW Vis, Tel
Scope, Esync Matrix, ACE _Team Management - manage
documents, query them.
PSYOP Instructor Targeting and Guidance Interface Facility (TGIF) interfaces
IWPC to TBMCS
PSYOP Instructor IWPC 4.0 lecture brief should be ready soon. (Weeks?) We
can request it in our package request (via AFRL)
PSYOP Instructor IWPC 4.0 going to Operational Task, Tactical Task, etc.
See PSYOP Instructor's handout
PSYOP Instructor Priority of targets (GAT) is based on commonality. If the
Navy and the Army also want the target struck, it is raised
in priority on the nomination list. Geo location, assets
available to conduct the attack are also considered.
PSYOP Instructor IWPC will be a joint tool
PSYOP Instructor Confusion was shared about entering the 2nd objective. It
was not clear if it was going to be a sub-objective or what.
This later turned out to be mostly terminology issue, which
PSYOP Instructor later resolved for us. Metrica to change. We should
put screen labels
C-18
May 12-13, 2004, 2004 Page 6 of 7
PSYOP Instructor During the GAT meeting (Guidance and Targeting) a
PowerPoint slideshow of maps showing the targets in
different colors representing target type (naval, SAM, etc.) is used
PSYOP Instructor DIA target intel is imported into the MIDB, where it is used
by IO Planners using IWPC or Excel, and then it is
imported into TBMCS
PSYOP Instructor When viewing the target deck in TBMCS, they found that
many targets are marked as inactive, simply because they
don't have recent intel on them. But this doesn't mean they
aren't a target anymore (absence of evidence is not
evidence of absence). They get
PSYOP Instructor For moving targets, BE# of facility they are based out of is
used. Notes section used to reflect actual current latitude
and longitude
PSYOP Instructor Code words are used in the target deck to relate to
classified targets behind the green door.
PSYOP Instructor IO Planners spend 50% of their time in the STO (green
door), and 505 outside
PSYOP Instructor PSYOP Instructor talked about an AF std worksheet for defining
objective-task-moe-mop, etc. Said he would send it to us. (I
gave him my business card, but it might come in the
package we request via AFRL).
PSYOP Instructor IWST is now called IWT (??)
SME MD
MD Instructor "Spin Control" = PA term for SNOWBALL effect.
MD Instructor "Consequence Management" = MD term for SNOWBALL
effect.
MD Instructors (2) Human Factors database at NASIC is another tool used
MD Instructors (2) Six stages of MD? (Situation=Military situation you're
involved in, and what the desired situation is;
Objective=Military and deception objective;
Perception=Current enemy perception, desired enemy
perception; Story=?; means=?, Moe, Mom Mop are the
MD Instructors (2) Approx 70 core IO planners were involved in Desert Storm
MD Instructors (2) Deception has a snowball effect (just like EBO does)
C-19
May 12-13, 2004, 2004 Page 7 of 7
MD Instructors (2) Army deception constrained to their area (5KM x 5KM area
for example). The point is that they don't look at the big
picture and how everything is related.
MD Instructors (2) Joint Universal Lessons Learned database is a tool that is
used
MD Instructors (2) When students leave, they will know how to Plan and
interact with other Influence Operations
MD Instructors (2) We use reachback to MAJCOMS for advice, help.
SME OPSEC
OPSEC Instructor OPSEC plays in every objective
OPSEC Instructor 3 Questions to ask: Can enemy collect on indicators that
I've put out there?; Can he analyze it?; Can he act on it?; If
he can, then what is the impact?
OPSEC Instructor MD enjoys indicators, OPSEC wants to get rid of them
OPSEC Instructor OPSEC Product is OPSEC Annex
OPSEC Instructor Only tool in use is the OPSEC Survey Tool
OPSEC Instructor OPSEC course teaches JOPES, Crisis Action Planning
OPSEC Instructor 5 step process
OPSEC Instructor OPSEC guys ensure PA and MD are not revealing anything
sensitive.
OPSEC Instructor OPSEC monitors our vulnerabilities (not enemy's)
C-20
APPENDIX D
BIBLIOGRAPHY
The following bibliography lists primary source materials for IFOTA development. Other
sources were also reviewed, including several versions of curricula for the IOIC course.
Supplementary and detailed information was obtained from SME interviews.
D-1
Central Intelligence Agency. (2006). CIA World Factbook. Accessible online at:
https://www.cia.gov/library/publications/the-world-factbook/
Joint Chiefs of Staff. (1996). JP 3-58, Joint Doctrine for Military Deception. Washington,
DC: Joint Chiefs of Staff.
Joint Chiefs of Staff. (1997) JP 3-61, Joint Doctrine for Public Affairs. Washington, DC:
Joint Chiefs of Staff.
Joint Chiefs of Staff. (1997). JP 3-54, Joint Doctrine for Operations Security.
Washington, DC: Joint Chiefs of Staff.
Joint Chiefs of Staff. (1998). JP 3-13, Joint Doctrine for Information Operations.
Joint Chiefs of Staff. (2003). JP 3-53, Doctrine for Joint Psychological Operations.
Joint Chiefs of Staff. (2004). JP 3-0, Joint Doctrine for Operations Revision. [1st Draft.]
Joint Force Command. (2003). Joint Information Operations Planning Handbook.
Norfolk, VA: Joint Command, Control & Information Warfare School.
Lord, W. (2004). Concept of Operations for Information Operations. Langley AFB, VA:
Air Combat Command.
United States Air Force. (2001). AFI 35-101, Public Affairs–Public Affairs Policies and
Procedures. Washington, DC: United States Air Force Headquarters.
United States Air Force. (1997). AFI 10-704, Operations–Military Deception Program.
Washington, DC: United States Air Force Headquarters.
United States Air Force. (2001). AFI 10-1101 31 Operations–Operations Security.
Washington, DC: United States Air Force Headquarters.
United States Air Force. (2000). AFI 71-101, Vol. 4, Special Investigations–
Counterintelligence. Washington, DC: United States Air Force Headquarters.
United States Air Force. (2002). AFI 13-1AOC, Vol. 3 1, Operational Procedures–
Aerospace Operations Center. Washington, DC: United States Air Force Headquarters.
United States Air Force. (1999). AFDD 2-5.3 27 Psychological Operations. Washington,
DC: United States Air Force Headquarters.
United States Air Force. (1999). AFDD 2-54, Public Affairs Operations. Washington,
DC: United States Air Force Headquarters.
United States Air Force. (2002). AFDD 2-5, Information Operations. Washington, DC:
United States Air Force Headquarters.
United States Air Force. (2004). Operational Military Deception Planner‘s Handbook,
Vol. 1, Iss. 1. Washington, DC: USAF/XOIWS.
United States Air Force. (2005). Joint Air Estimate Planning Handbook (Version 5.
Maxwell AFB, AL: Center for Aerospace Doctrine Warfare Studies Institute.
D-2
United States Army. (2003). FM 3-05.301 Psychological Operations Tactics, Techniques,
and Procedures. Washington, DC: United States Army Headquarters.
United States Army. (2004). FM 3-05.30, Psychological Operations. [Final Draft.]
Washington, DC: United States Army Headquarters.
United States Army. (1995). FM 34-60, Counterintelligence. Washington, DC: United
States Army Headquarters.
D-3
APPENDIX E
ACRONYM LIST
39th IOS 39th Information Operations Squadron

711th HPW 711th Human Performance Wing
ACTA Applied Cognitive Task Analysis
ADV IOIC Advanced Information Operations Integration Course
AFCERT Air Force Computer Emergency Response Team
AFDD Air Force Doctrine Document
AFI Air Force Instruction
AFRL Air Force Research Laboratory
AFTTP Air Force Tactics, Techniques & Procedures
AOC Air Operations Center
BPR Business Process Reengineering
CA Civil Affairs
CI Counterintelligence
CIA Central Intelligence Agency
COA Course of Action
COM Component Object Model
CSE/SE Cognitive Systems Engineering and Software Engineering
CTA Cognitive Task Analysis
DII COE Defense Information Infrastructure Common Operating Environment
EJB Enterprise Java Beans
EW Electronic Warfare
HA Humanitarian Assistance
HTML Hyper Text Markup Language
I&W Indications and Warnings
IDEF0 Integrated Definition for Function Modeling
IFO Influence Operations
IFOTA Influence Operations Training Aid
INOSC Integrated Network Operations and Security Center
INTRO IOIC Introductory Information Operations Integration Course
IO Information Operations
ION Information Operations Navigator
IOPC-J Information Operations Planning Capability - Joint
IOTA Information Operations Training Aid
IOTT Information Operations Team Training
IW Information Warfare
IWAS Information Warfare Aggressor Squadron
IWE Information Warfare Effectiveness
IWF Information Warfare Flight
IWPC Information Warfare Planning Capability
IWS InfoWorkspace
JAEP Joint Air Estimate Process
E-1
JAOC Joint Air Operations Center
JAOP Joint Air Operations Plan
JCS Joint Chiefs of Staff
JDBC Java Data Base Connectivity
JFACC Joint Force Air Component Commander
JMS Java Messaging System
JP Joint Publication
JTF Joint Task Force
JWICS Joint Worldwide Intelligence Communications System
LIMFACs Limiting Factors
MAJCOM Major Command
MD Military Deception
MEC Mission Essential Competency
MOE Measure of Effectiveness
MOP Measure of Performance
NEO Non-Combatant Evacuation Operations
NIOC-MD Navy Information Operations Command-Maryland
NIPRNET Non-Secure Internet Protocol Router Network
NOD Network Operations Division
NW Net Warfare
OPSEC Operations Security
OSGI Open Systems Gateway Initiative
PA Public Affairs
POL Petroleum, Oil, & Lubricants
PSYOP Psychological Operations
PSYOP PT Psychological Operations Planning Tool
RCP Rich Client Platform
RFI Request for Information
RHA Warfighter Readiness Research Division
RHC Warfighter Interface Division
RMI Remote Method Invocation
SIPRNET Secret Internet Routing Protocol Network
SMART Subject Matter Analysis & Research Toolkit
SMC Signature Management Course
SME Subject Matter Expert
TA Target Audience
TBMCS Theater Battle Management Core Systems
UML Unified Modeling Language
USA United States Army
USAF United States Air Force
WAIT-C Warfighter Analysis of Innovative Technologies and Concepts
WCD Work-Centered Design
E-2

Information Operations Team Training & Information Operations Training Aid, Information Warfare ... (PDFDrive)

Uploaded by

Copyright:

Available Formats

Information Operations Team Training & Information Operations Training Aid, Information Warfare ... (PDFDrive)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Operations Team Training & Information Operations Training Aid, Information Warfare ... (PDFDrive)

Uploaded by

Copyright:

Available Formats

AFRL-RH-AZ-TR-2010-0023

Information Operations Team Training & Information

SRA International, Inc.

Distribution A. Approved for public release, distribution unlimited. (Approval given

AIR FORCE RESEARCH LABORATORY

AFRL-RH-AZ-TR-2010-0023 HAS BEEN REVIEWED AND IS APPROVED FOR PUBLICATION

SARAH FOCKEL HERBERT H. BELL

JOEL BOSWELL, LtCol, USAF

6. AUTHOR(S) 5d. PROJECT NUMBER

15. SUBJECT TERMS

Standard Form 298 (Rev. 8-98)

Approved for public release; distribution unlimited.

Figure B - 1. Truncated Entity-Relationship Diagram (based on Version 2) ............................. B-2

Approved for public release; distribution unlimited.

Approved for public release; distribution unlimited.

Approved for public release; distribution unlimited.

2.1 Task One: Mission Essential Competencies (MECs)

2.2 Task Two: Information Operations Training Aid (IOTA)

Figure 1. IFOTA opening interface and example plan tree view

2.3 IOTT/IOTA Accomplishments

3.1 Cognitive Work Analysis

Figure 2. Concept map of Capstone Exercise from IOIC instructor interview.

3.1.2 Work-Centered Design (WCD).

Identify Specific Assist Identify

3.1.3 CTA Artifacts, WCD and Software Requirements Specification

Other General Capability Requirements

PSYOP MD OPSEC PA CI EW/NW Instructor

Figure 4. IFOTA CSE to SE information transfer.

3.2 IFOTA Knowledge Elicitation

4.0 RESULTS AND DISCUSSION

4.1 Knowledge Elicitation Trip 1

Figure 5. Planned Student Activities within IFOTA as initially described.

4.1.1 Elicitation Findings/Discussion Points for Usefulness (Focus on the Task)

2. Usability Criteria (How easy is this tool to use?)

4.2 Knowledge Elicitation Trip 2

Table 1. A Partial Representation of IFOTA Requirements.

•Selection screen closes/minimizes?

•Shows at top of Set-up screen

Enter •Set-up screen has text fields for

Enter •Set-up screen has text fields for

Figure 7. Initiating and terminating an IFOTA planning effort.

Develop/Write Determine Black List: Develop/Write Identify

For each supported tactical task

 Transition the existing PSYOP PT into an IFOTA encompassing training in

 Design, develop, and implement a new module to encompass the planning

 Design, develop, and implement a new module to encompass the planning

Figure 9. IFOTA 1.0 multi-tabbed PSYOP scenario showing evaluation of TA resistance

Each plan level node will ask the operator to input a

IFOTA 4.0 added the following functionalities:

Figure 12 shows the deconfliction function in IFOTA 4.0.

5.1 IFOTA Technical Architecture

Figure 14. IFOTA system component view

5.1.1 Advanced Technical Features

Eclipse Provided Plug-ins IFOTA Plug-ins

Microba Deconfliction JUNG

Jaret Time Bar Swabunga IFOTA Counter

IFOTA Exporters IFOTA Military IFOTA Public

Jawin IFOTA Operational Security Plan