INFORMATION REQUIREMENTS

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP84-00780R001300060030-1
• Release Decision: RIPPUB
• Original Classification: C
• Document Page Count: 2
• Document Creation Date: December 14, 2016
• Document Release Date: September 17, 2002
• Sequence Number: 30
• Publication Date: May 19, 1966
• Content Type: MFR

~4TT1~!- gg~ G I S~ R ~`
Approved For Release 20 84-00780&da1f30~060030;1 _; ~ a 7 /~ /7L'i
1 9 MAY 1966
SUBJECT: Information Requirements
1. On Wednesday, 11 May 1966, I met with Emmett Echols,
and o discuss the need to develop and define requirements for
managemen i ormation which they would like to have satisfied by new systems
we are in the process of developing. The problem of defining what is meant by
"requirements definition" is almost as difficult as defining the requirements
themselves. All of the teachers, all of the lecturers, and all of the literature
advocate definition of requirements as among the first steps in the conduct of
any system study and they all insist that this must be done by the highest
levels of management. Apparently this has never been done successfully and
I have been able to find no guidance for setting about it systematically. I
have attended two seminars at the Civil Service Commission recently which
were described as intending to deal with the development of managemen[.
reporting systems, the definition of organizational objectives, and the deter-
mination of requirements. These were reiterations of the need to define
requirements but none of the speakers had any specifically useful suggestions
about how the problem of getting .it done should be approached.
2. I explained these problems as background for the discussion and
hopefully leading to the point that we are trying now to define our requirements
for information in a way which has never been done before. We know what the
requirements for computer output are now in the existing systems and we are
not seeking at this time a redefinition or validation of those. Very often people
who are asked to define requirements tend to think .in terms of particular out-
put formats for presentation of data or they tend to try to frame their statement
of requirements in terms of what they believe the computer may be capable of
producing. It is extremely difficult to avoid these tendencies and the difficulties
were evident during this discussion. We are interested in requirements for
information which will permit the Offices to develop their programs, ply ns,
and forecasts; measure their accomplishments toward the achievement of
their plans and objectives; project trends; surface problems; anticipate back-
logs; as well as provide for feedback, evaluation, and control of resources.
Approved For Release 2003/04/29 :CIA-RDP84-00780
25X1
~QWr~~~~ Ezciuded tram au~amattc
If.ll datrnCr~ding and
_ _ declassttisatioo _
 Approved For Release 2~~/~~~-RDP84-007808001300060030-1
3. Mr. Echols asked how I thought they should go about this and I
suggested that they might begin with the statements of their objectives as
set forth in the combined progxam call. In most cases these are very broad
and general, and sometimes platitudinous. To begin with, the statements of
objectives will require that they be brought much. more sharply into focus and
brought into the form of some precise statements of specific goals capat~le of
achievement within a limited measureable time frame. In addition, I suggested
that they might review their statements of mission and functions as included in
the Agency regulations and as.k themselves what :management information they
need to fulfill their responsibilities. I also suggested that they try to think in
terms of the performance criteria for subordinate levels in their organization,
not in the fitness reporting sense, but in terms by which the success or failure
of subordinate operations may be measured. For example, the success or
failure of the recruitment effort may be measured in terms of the number of
people interviewed, the number put in process, the number entered on duty,
or some combination or comparison of these and other elements. We need to
know the .k.inds of information they want the system to produce in order to make
these evaluations and it may be useful for them to think about their requirements
in these terms. I emphasized that they should not attempt to phrase their
requirements definition in terms of what they may think the computer can or
cannot do but should simply say what they want the system to produce, then we
will assume the responsibility for recommending whether or not the require-
ments can be satisfied manually or automatically. Mr. agreed to
produce some requirements at least as a first cut as soon as he can.
Special Assistant to the
Deputy Director for Support
SA-DD/S:RHW:de.k (19 May 66)
Distribution:
Orig - DD/S Subject
1 - DD/S Chrono
25X1
25X1
Approved For Release 2003/~4~~~~~ 007808001300060030-1