THE INTELLIGENCE REQUIREMENTS PROCESS

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP79M00098A000300020035-9
• Release Decision: RIPPUB
• Original Classification: T
• Document Page Count: 7
• Document Creation Date: December 20, 2016
• Document Release Date: November 3, 2006
• Sequence Number: 35
• Content Type: PAPER

Approved For Release 2006/11/07: CIA-RDP79M00098A000300020035-9
Q
Approved For Release 2006/11/07: CIA-RDP79M00098A000300020035-9
 Approved For Release 2006/11/07: CIA-RDP79M00098A0003(Y0D2O035-1,:)
The Intelligence Requirements Process
Introduction
3 w .v1 1:.: "'a
ence requirements" is perhaps the most frequently
The term "intellig
CD1
used and also the most frequently misused term in the lexicon of the intelligence
community. "Requirements" can cover the spectrum from broad statements
of intelligence production needs to the specific information sought in the tasking
of an individual collector or technical sensor.. In every instance, a stated
requirement is used as the basis for creating or operating a collection resource;
for processing, analyzing or exploiting the collected data; and for synthesizing,
evaluating and reporting single or multiple source information in a product
which can range from a spot report to an in-depth study or a national estimate.
The full range of requirements reflect the insatiable- appetites of the
intelligence consumers, the intelligence managers and the intelligence analysts.
Most, if not all, requirements are stated without regard for satisfaction capa-
bility, feasibility, complexity or cost. Few, if any, stated requirements
are ever fully satisfied; those which may be satisfied usually give rise to
further and more detailed statements of need or desire or to regeneration of
the requirement for up-dating purposes. Thus, the volume of requirements
continues to multiply in proportion to the satisfaction achieved.
Apart from relatively superficial "validation" procedures, no particular
effort is made to challenge or reject requirements statements, nor is the
originator ever informed of the feasibility, complexity or cost of meeting a
stated requirement. In this aspect, the requirements process can be.viewed
as a huge juggernaut with no brakes and few effective control mechanisms.
Prioritizing or priordering of requirements is another imponderable
which detracts from the effectiveness of the process in most instances. The
plethora of requirements originators and the wide range of responsibilities
they represent adds confusion and conflict to judgments of priority.
Process versus System
So far, I have referred to the requirements "Process". It would be
n referable to refer to it as the "system". however, a system by definition
~~ ii .'i _l .. -?.'. ~'.; ,~ _t2 1
is a r_ca-,tuisuils/ or rou o _~ a url?'u~
whole" with the connotation of an organization serving a common purpose and
under specific leadership. Except for small segments of the present process
which are systematized, the total process does not appear to meet the "system"
criteria. To make the process a system should perhaps be one of our basic
objectives .25X1
Approved or Release 2006/11/07: CIA-RDP79M00098A000300020035-9
 Approved For Release 2006/11/07: CIA-RDP79M00098AO00300020035-9
Elements of the Process
The requirements process can best be understood'rhen viewed in
terms of sequential steps which become separable elements in the process.
In broad terms these are:
Objectives -or Goals -- general statements, usually reflecting end
results; relatively few in number and preferably in some order of priority
or emphasis; correspond to what are otherwise described as First Order
Requirements. Existing example is DCID 1/2 and corresponding JCS JSOP
Annex A.
Statements of Requirements or Information Needs -- Expansion of
general objectives into more specific descriptions of information needed to
support intelligence analysis and product; not directed at any specific
collection, processing or analysis discipline; not in priority order except
as derived from general objectives; correspond to Second Order Requirements.
Existing examples are Key Intelligence Questions, Defense Intelligence
Requirements, Essential Elements of Information (EEI) stated in Unified
Command war and contingency plans.
Guidance (to collectors, processors, analysts) -- probably the least-
defined element of the process; involves directing requirements or information
needs to one or more collection disciplines based on judgment of most likely
sources to provide data in timely and useable form; also serves as manage-
ment mechanism for processors and analysts; determination of essentiality
of one collection source over others is part of guidance. Existing examples
are SORS mission guidance to Directors, NRO and NSA; COMIREX guidance
to NRO, Intelligence Guidance for COMINT Programming (IGCP).
Tasking -- A further detailing of requirements or information need
statements into specific tasks to be performed by individual collectors or
sensors in consideration of guidance provided; equates to Third Order
Requirements in detail of observables, circuits to be covered or targets
to be photographed. This element is best carried out by the collection
resource manager who can marry the data needs with the technical or
access capability of the collector or sensor. Examples are NSA SIGINT
system tasking, technical tasking of overhead systems, or specific intelligence
tasks l:. `pied on HU,'TIN1 collet`ors .
Interrelationships of the Process
In an ideal world, the elements of the process identified above
should provide for requirements development to flow in an orderly pro-
gression of sequential steps, each detailed statement or action at any level
Approved For Release 2006/11/07: CIA-RDP79M00098AO00300020035-9
 Approved For Release 2006/11/07 :tTA'-RDP79M00098A000300020035-9
being relatable to something at the next higher level. Unfortunately, this
.does not now occur, and it is difficult if not impossible in many cases to
trace tasks, guidance and information needs back to requirements and broad
objectives. This is true for two principal reasons:
- many originators of requirements have direct access to collection
and processing systems without review by any central authority, and
- there is no central authority or structured mechanism through
which requirements can pass for validation, association and the provision
of guidance.
25X1
In the imagery collection and exploitation endeavor, the requirement
and guidance procedure is much more orderly as the result of a central
authority (COMIREX) which receives all requirements, prioritizes them,
and provides for collection and processing action in accordance with system
capabilities. In a sense, the comparison of the SIGINT system to the imagery
system is unfair and unrealistic. Imagery acquisition involves a relatively 25X1
few systems constrained only by vehicle availability and weather. Success
(reouirement satisfaction) is a "yes" or "no" nronofiitinn _ Tar of ti.- ,iaT nn
It is reasonable to conclude, therefore, that the major problems
confronting the intelligence community in requirements management pertain
to the SIGINT system.
Approved For Release 2006/11/07: CIA-RDP79M00098A000300020035-9
 Approved For Release 2006/11/07: ClAtRbP79 tOCd98A000300020035-9
When is a Requirement not a Requirement?
S
There is one school of thought in the intelligence community that
a stated requirement which exc:eds our technical or human capability to
satisfy should not be "validated'' and levied for collection or processing
action. I reject this view. Any requirement for substantive response
should be stated and accepted whether or not a capability exists to operate
against it. The lack of a current capability could, for example, cause
necessary research and development to be undertaken toward creation of
a capability. At the same time, we should recognize that some of our most
pressing requirements are not likely to ever be satisfied. That fact, however,
is not sufficient to deny that the requirement exists.
This brings into play the need for prioritizing and the careful
provision of guidance in the application of resources toward requirements
satisfaction. The objectives or goals element of the requirements process
provides a general priority framework within which second and third order
requirements can and should be fit. To do so effectively requires, among
other things, that all stated requirements (second order) be reviewed by a
central authority who is able to associate and priorder all statements. This
having been done, the further provision of guidance incident to conveying
the requirements into particular discipline areas can include recommendations
on the emphasis of resource application consistent with overall priorities
and essentiality of the source. This procedure would recognize that some
lower priority requirements would receive no effort in order that appropriate
effort is applied to higher priority needs. These determinations should
be made by the central authority responsible for providing guidance in
each discipline area. Such a procedure is already in effect for the relatively
simple imagery discipline and needs to be developed for the SIGINT discipline.
To Make the Process a System
An analysis of the requirements process and its application to the
principal disciplines of imagery, SIGINT and HUMINT indicates that the
process lacks systematic organizational structure in the first two elements--
objectives or goals and requirements or information needs. The statements
in both of these elements need to be associated, the second being derivative
from and an expansion on the first. Both sets of statements need to be
tl ,G1 ^~11 to ..1 .~~ -.6 or+ it i , 0 '.1
r c to -.. C.~1?
It is suggested that there should be a USIB Requirements Committee
established for these purposes.
The application of stated requirements to particular collection and
processing disciplines should be accomplished by the respective committees
of USIB--COMIREX, SIGINT and HUMINT--in the form of guidance to be
Approved For Release 2006/11/07: CIA-R?P79M00098A000300020035-9
 Approved For Release 2006/11/07: CIA-RDP79M00098A000300020035-9
utilized by appropriate program managers in the allocation of resources
and the assignment of operational tasking. Obviously, these pi ocedures
v. ill take differing forms depending on the detail and nature, of guidance
to be provided for tasking purposes.
It seems clear that the SIGINT guidance area is the most complex.
Past efforts to systematize this area have been hampered by two major
shortcomings:
- a lack of detailed knowledge on the part of the SIGINT
Committee concerning resources allocated and capabilities existing within
the SIGINT system to respond to requirements and guidance;
- , a lack of centralized access to all requirements levied on the
SIGINT systems by various originators.
The "other requirements" problem is a USIB and SIGINT Committee
matter involving all members, but particularly the DIA, Military Service
and Treasury members. While substantial progress can be made on this
problem within the SIGINT Committee, an even more effective system could
evolve with the assistance of a USIB Requirements Committee.
Recommendations
It is recommended that:
- serious consideration be given to forming a USIB Requirements
Committee to fulfill the functions discussed above;
- the SIGINT Committee Ad Hoc Review Group give particular
attention to a Committee structure or sub-structure which will move toward
more effective systematization of r eciuirements for -which SICIT"N' is jud -ed
to bo an ess'antial source, ti-_ pl'iord r1a of the ie r Cii r r eats, and
ti a
provision of guidance to the SIGINT program manager.
Approved se 2006/11/07: CIA-RDP79M00098A000300020035-9
 Approved For Release 2006/11/07: CIA DF3,791 I00t79bA000300020035-9
There is an obvious interface necessary between action recommended
for the SIGINT Committee and the National SIGINT Plan under development by
Director, NSA. Requirements for which SIGINT contributions are essential,
resources allocated, system capabilities and an assessment of responsiveness
and satisfaction are all ingredients to be considered in the Plan.