(Sanitized)DRAFT - SAFE SYSTEM REQUIREMENTS SPECIFICATION

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP84-00933R000500070037-2
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 5
• Document Creation Date: December 12, 2016
• Document Release Date: May 8, 2002
• Sequence Number: 37
• Publication Date: January 16, 1980
• Content Type: MF

0b 6
Approved For RelQase 2002/06/18: CIA-RDP84 00933R00W00700 -
IAI IN I L
16 January 1980 1'~)
f,Z5 p)g
MEMORANDUM FOR: Director, Consolidated SAFE Project Office
Deputy Director, Consolidated SAFE Project Office
FROM: Director, Information Resources Office
SUBJECT: I I- SAFE System Requirements
Specification
1. In the time available, we have reviewed the subject
documents and offer the following comments and observations for
your consideration:
a. In view of the statement found on p. 4 of Book I
that: "In the event of conflict between the documents
referenced herein and the contents of this specification,
the contents of this specification shall be considered a
superseding requirement, except in the case of the SAFE
Contract," it is our opinion that this set of documents
will become part of the contract and will henceforth
govern and determine the actual configuration of the
systems and the capabilities that both SAFE systems will
consist of at IOC. The CSRD documents will have validity
only to the extent that this specification is silent or
the wording of the Systems Requirements Specification
can be harmonized with the CSRD. We have not been able to
make a detailed comparison between the two sets of docu-
ments to ascertain the exact extent that changes have been
made. We know that the staff of the CSPO is engaged in such
a study. We feel that the results of such a study should
be incorporated in a written memorandum which summarizes
all significant changes which 0 has made, which the CSP -Ai-NTL
prepared to accept, the rationale therefor, together with an
analysis of the overall significance of these changes. This
memorandum should then be provided to the members of the
Steering Committee for their review prior to government
acceptance of the Systems Requirements Specification.
b. In general, the statement of the general system
requirements and the requirements for SAFE-C seem to provide
a reasonable set of'criteria for directing the detailed
system design and its evaluation. However, there seem
to be a large number of items which are designated to be
implemented "in a simplified manner." Some of these appear
The contents of this
memo A pro ffc,2 g19gW2002/06/18 : CIA-RDP84-00933R000500070037-2
 Approved For Releaseok02/06/18 : CIA-RDP84-00933R0005WO70037-2
to be relatively critical elements of the system, so that a
written explication of what is meant by a "simplified manner"
should be required, either as to specific items or a
general formula, or both.
c. The SAFE-D specifications, on the other hand, appear
to us to be too incomplete, even for this stage of the
project. Given the fact that in its present form these
documents become the operative part of the contract itself
insofar as defining the deliverable, the government should
certainly not approve this portion of the system requirements
specification until many of the items listed as "TBD" have
been determined.
d. I have previously noted the fact that there is no
electrical interface specified between the SAFE-C and SAFE-D
systems. In addition to the electrical interface specifi-
cation, we believe that the ability to implement certain
functions, such as the capability for analyst-to-analyst
communication between SAFE-C and SAFE-D terminals and the
capability for SAFE-C terminals to access data bases resident
on SAFE-D and vice-versa, should be stated explicitly, even
though the specification of an electrical interface might
imply such a capability. The need for this is, in my
opinion, supported by the results of the IHC Analysts Support
Study.
e. Even though SAFE-C, and possibly SAFE-D, are to be
initially implemented in a system high operational mode,
both from the aspect of being able to impose the "need-to-
know" and being able to implement compartmentation controls,
it is desirable that the system have the capability
of imposing access controls down to the record level and
possibly to. the sub-element level. It is not clear to me
from my review that this is provided for, either at IOC
or beyond. If it is, I would appreciate being informed of
the specific provision therefor. If not, I would appreciate
being informed of your estimate of the resource implications
of including this as a requirement, either for IOC or
post-IOC implementation.
f. In dealing with the ADSTAR interface, paragraph
10.3.7.12.3.1 provides that a SAFE user can request "a print
of an ADSTAR document" or "the display of an ADSTAR document"
on an ADSTAR terminal. It was my understaT ing of the
original concept that when, through an index search, a SAFE
user had identified a series of documents resident on ADSTAR
which met the criteria of his search strategy, he would then
be able to have the system execute a command. which would
permit him to browse the complete list of documents on his
Approved For Release 2002/06/18 : CIA-RDP84-00933R000500070037-2
 Approved For Relea%W2002/06/18 : CIA-RDP84-00933R0005 O70037-2
ADSTAR terminal or to execute a command to print all of the
referenced documents without having to re-enter the document
numbers of each of the references. It appears to us that if
this is the case, this language should be amended to so
specify.
S TATIN T L g. While the requirements appear to be quite adequate
regarding responsibilities to develop and carry out
a quality assurance program, the documents seem to imply
that the CSPO will only be involved in reviewing the
documentation up to the point of system demonstration
testing. We believe it advisable to include language which
indicates that government personnel will be afforded the
opportunity to monitor all phases of test and evaluation and
making provision for additional review and testing if the
original results are unsatisfactory.
h. In paragraph 10.3.2.5.4 of the system requirement
specifications the following statement appears: "The system
shall mishandle no more than 0.1 percent of transactions
(user requests for service)." This was derived from CSRD
V. 5, paragraph 4.2.3.2.2. We interpret this from its STATINTL
context in the CSRD to represent an attempt to define a
a measurable degree of software reliability. IIattempts
to postpone the attainment of this standard un 1 OC as
regards SAFE-C. However, a similar requirement as to SAFE-D
which prescribes a much more stringent standard is found
in paragraph 20.3.2.5.4 where it is indicated that this is to
be "implemented in a simplified manner." If there is to be
such a specification, it seems to us that it should be
required to be attained, either at IOC or within a reasonable
stated time after IOC. Also, there is no specification of
the manner in which the fulfillment of the requirement is to
be judged. For it to have real validity, it would seem to us
that it could only be deemed to have been satisfied following
a period of full-scale operational experience, with a
reasonable opportunity for the contractor to correct some of
the error in coding which will necessarily escape the most
stringent test and evaluation program. Regardless of the
above suggestions, it appears that it would be preferable
to eliminate the requirement entirely rather than include it
as a standard to be attained only at FOC.
i. We are concerned about the statement found in
paragraph 20.3.2.1.1 that: "The response time requirements
are only applicable for the current active highest priority
users." This appears to be an attempt to restate the
language in CSRD, Vol. V, p. 4-1, where it is stated:
Approved For Release 2002/06/18 : CIA-RDP84-00933R000500070037-2
 Approved For Releaj 2002/06/18 : CIA-RDP84-00933R000pO70037-2
"the objective of the DIA SAFE system is to provide the
lowest possible response times for those activities which
support the on-line user activities, and reasonable response
times for all other system activities, depending on their
criticality to the intelligence processing mission." If so,
it is ambiguously worded and much more restrictive than
necessary.
STATINTL
STATINTL
j. Section 10.3.1.2 of the system requirements
specification states: "The mission of the CIA SAFE
system is to improve support to intelligence production
analysts by providing indirect access to other intelli-
gence community and commercial computer systems." We are
unable to interpret any of the substantive requirements to
provide for such access. We would appreciate being advised
as to whether or not the requirements as presented permit
the fulfillment of this portion of the stated mission, and
if so, how this is to be implemented. STATINTL
2. When we reviewed the pro osal, we were concerned
with the manpower loading propose by over the course of the
project since it did not appear to con orm with models in the
literature. There did not appear to be sufficient manpower
remaining to do error correction coding which is generally
required after IOC in the case of SAFE-D. We had thought this
might be addressed in the management plan. Since it is not, we
take this opportunity to call it to our attention and ask if
there has been any modification ins plans in this regard
subsequent to their proposal?
3. The DIA portion of the CSRD in Vol. V, Section 3.3, it
was provided that: "To avoid the current difficulties in multiple
query language (AIRES, COINS, DIAOLS), the SAFE system should be
implemented with a common standard language for all subsystems. A
language interpreter which converts user input commands to the
form acceptable by the queried system should be developed for
systems external to SAFE which users wish to access. At IOC this
capability should be provided for AIRES and selected COINS systems
to be specified by the government at a later date. Post IOC
development should aim towards expanding this capability to other
systems." In the matrix, this provision of the CSRD is described
as "N/A," but Section 20.3.1.5.1.2.2 provides: "The system shall
provide the capability for transparent access to other systems in
the Washington Area Local Communications Network. This
transparent access will initially be provided only to the SOLIS
and AIRES systems." Presumably the requirement to provide a
"transparent access" implies a language interpreter be built for
these two external systems. (Perhaps this should be more
specific.) It is common knowledge, confirmed by the results of
the IHC Analyst Support Study, that one of the principal barriers
to more widespread use by the analytical community of automated
Approved For Release 2002/06/18 : CIA-RDP84-00933R000500070037-2
 Approved For Releac2002/06/18 : CIA-RDP84-00933R000SWO70037-2
data bases is the difficulty of being forced to use a bewildering
variety of complex retreival languages. The differences among
these languages are often arbitrary. There are two possible
approaches to solving this problem. One is the development of
language translation facilities such as proposed by the above
quoted CSRD requirement and the COINS ADAPT project, and the
establishment of a standard user language for the implementation
of functions which are common to all or most information retrieval
systems. With the advent of SAFE, a large portion of the
Community's data bases will be accessible to a very large
proportion of the Community's analysts, either through SAFE or
COINS. If the development of the SAFE user language and the
development of the mechanisms to provide transparent access
therefrom to the AIRES and the data bases from SAFE-D were
properly coordinated with the COINS ADAPT project, the result
would naturally be the establ ishment of a de facto community
standard user language. The development of such a standard to
which future community systems could be adapted is a very
substantial contribution to the improvement of information
handling throughout the Community which SAFE could make. I would
appreciate discussing this with you in some depth. I sugges tt hat
uirement stated for the coordination of iI
there should be a re
q
work on the SAFE user language and the transparent access to AIRES
and SOLIS with the COINS PMO. STATINTL
4. I appreciate the opportunity to comment on the
requirements documents. I hope they will be helpful to you.
cc: D/DCI/RM
D/ODP
DIA
STATINTL
STATINTL
Approved For Release 2002/06/18 : CIA-RDP84-00933R000500070037-2