April 17, 1967




Author: Lee A. Friedman
System Development Corporation
Santa Monica, California



Table of Contents



 1. Defining The Man/Computer Interface Design Problem


 1.1 The Information Gap


 1.2 The Information Gap In Man/Computer Interface Design

 1.3 The Information Gap In Current Man/Machine Design


 2. Why This Book Is Needed

 3. Purposes of This Book

 4. Sources of Information

 5. Audience For the Book

 6. Present Statue and Schedule

 7. Author's Background


 8. Annotated Outline of Chapters







April 17, 1967


1. Defining The Man/Computer Interface Design Problem

1.1 The Information Gap

A phenomenal number of computerbased information systems have been designed and installed during the past two decades. All of these ubiquitous systems use man in some capacity as master or servomechanism, as manager or operator, but not always in a manner that benefits man, the computer or the system.

Concern for man was not omitted by system designers, although it does seem man was taken for granted in many situations. The fault for any of man's interface problems did not lie exclusively with the system designer. More to the point, it seems that information (standards and criteria) may not have been available to designers on the range and limits of man's abilities and job functions as could be applied to computer systems; information that would have helped to improve the utilization of man and of the computer programs and equipment with which he had to interface.

The consequences of this situation, of course, led to the misuse of man and the computer, the mixallocation of jobs, to the detriment of efficient system operations. This information gap resulted in conditions that placed greater constraints on, and required more of, man than on the computer programs and equipment.

1.2 The Information Gap In Man/Computer Interface Design

System design technology has been notably concerned with the correct blending of machine-with-machine with operational requirements with man, who usually ends up just hanging on. This latter condition is probably based on designers' intuition, culled from inspirational literature, that that adaptable animal man can easily (or should easily) adjust to the demands of the machine to which he is assigned. Man becomes the distressed partner a fault in the system, when he cannot adjust to a constraining and demanding machine whose method of operation might contradict the problemsolving procedures to which he is accustomed.

Absent from system design technology, then, is information (standards and criteria) that will help to mitigate man/computer incompatibilities, and that will prescribe to designers ways to better apportion system operation tasks between man and computer. The following statements describe the three major man/computer information gaps that have engendered design faults (and the basic subject matter for the proposed book).

1. Computer system designers (and human factors engineers, too) lack structured technical information on how a computer's information processing function the computer program, augments man's own information processing, decisionmaking, problemsolving faculties. The computer program's



purpose is to extend and complement man's mental (data transformation) faculties. As such, program design must be scrutinized and evaluated in terms of man's mental limitations and capabilities. The computer program designers, for example, should ask the generic questions: "What are man's mental processes?" "Which part of man's mental processes and activities should be apportioned to computer programs because of man's limitations or because the computer can do a better job?"

2. Computer system designers also lack sufficient information that prescribes how and when specific computer components and peripheral gear (typewriters, card readers, tapes, core) can best be used to supplement man's information processing activities. Equipment utilization and allocation, too, must be scrutinized in terms of man's information processing and transfer function limitations and capabilities. Thus, the designer should ask himself such questions as, "How and when should man and/or the typewriter be used for information transmission? How and when should the card reader and/or typewriter be used to facilitate man's (input) dialogue? How and when should man and/or computer core be used for sorting data?"

3. Finally, computer system designers lack information on how and when to design computer system operational requirements (input, output, sorting, merging, etc.) according to system functions (manage, control, operate, maintain, use). Insufficient standards and criteria can cause the allocations of data processing jobs or tasks to positions (whithin a functional area) that are not within the scope of their responsibilities or training experiences. The levels of job performance and data requirements for a computer system manager, for example, are distinctly different from that of a scientist-user or a computer operator.


As a result of these information inadequacies (but primarily the first one) many computer systems place untold constraints on man's abilities, thereby causing man often to err, and consequently, systems often to fail. To the designer, some troublesome interfaces may seem on the surface to be trivial. But it is fact, not hypothesis, that the cumulation of these so-called trivia actually hinders and degrades the accomplishment of even simple jobs.


Each system component-programs, equipment and man- has its known functions, limits and capacities. The data on man must be considered in conjunction with computer capabilities to hopefully achieve a more effective system. Human performance is the least reliable in computer systems operations, and until system designers learn how and when to use man in conjunction with the computer, the problem will persist.


1.3. The Information Gap In Current Man/Machine Design


The paucity of information on man/computer interface requirement and criteria within the general field of man/machine system design poses a peculiar



April 17, 1967

problem, viz., the design criteria and standards that should be derived from man/computer interface requirements are absent. Consequently, there are design criteria,standards and specifications that cannot be considered during system planning and advanced system design.

Much of the available man/machine literature that bears some relationship to the problem of man/computer task allocation or apportionment deals exclusively with the criteria for man's information requirements and display formats. There are few studies dealing with pertinent man/computer decision allocation, the use of natural languages, and how man's information processing capabilities should be fully or semiautomatically accomplished.This still leaves a large chasm to be covered.

There is no literature or data that tackles the practical job of prescribing what criteria to use to allocate man/computer program tasks at the design implementation level. The pertinent literature on man/machine design that currently exists only provides gross design axioms concerned with machines other than computers. Any suppositions about computers have merely been generalized from these constructions.

For example, it is stated in human engineering literature that: man is good at detection, sensing, perception,judgment, induction, long term memory; machines are good at speed, power,simultaneous operations, computations, repetition. Most of these constructions become moot points when applied to man/computer task allocations and they are ineffectual when used as guides for programming a computer to augment man's mental faculties.They easily direct attention away from the theme of allocating portions of tasks woman and to the computer.

The impression given is that man is good at one thing and the machine isn't. Presumably, this is not what is intended. But the impression is given, for example, that man is good at sensing and detection within the scope of his capabilities and that the machine surely cannot compete with this.

Man can sense an approaching ship at sea, but so can a radar antenna. The antenna and man can calculate speed and direction, but the antenna (its computer) can do it faster and more accurately. The task elements here are: to sense/detect, calculate, decide,act (report). The problem is to apportion the task elements according tothe capabilities of each and according to the environment. Both man and the antenna can perform a sensing and reporting task, but what part of the sensing task should man be apportioned? (Man can look for a ship and then point the antenna.)

Human factors engineersfor their part, by following the man/machine literature have the task of assisting in the design of those components of the machine that man will see, touch and sense "knob and dial" design some



April 17, 1967

call it. Their expertise lies in this area - making the marriage more palatable by "fixing up" the machine's components and facade so that man and machine are more psychophysiologically compatible; so that man will make fewer errors when reading a dial or manipulating a manual control.

What happens when this type of design and its related criteria are applied to the design of a man/computer system? It seems that when system designers, in conjunction with human factors engineers, concern themselves with man/computer interfaces they direct their attention to the equipment that man will see and touch, or which requires man's services. This, of course, means the design of consoles, CRT displays, the switches man will handle and the registers he will see. The interior of that calculating "black box" is of little concern.

Similar information gaps exist for the computer program designer and design implementer, viz., the lack of information on computer system user/operator limitations, capabilities and design criteria. Computer program design books and manuals usually stipulate people functions in such gross generalities as, "Simplify operator actions where decision-making is required," that they become meaningless as design guidelines. Hence, the implementation of human interface design will be left solely up to the programmer. Programming manuals sorely lack explications of man/computer interface requirements, tradeoffs and capabilities.

By no means is what the programmer decides unusable, although in this writer's experience there have been several such programs designed and delivered (and eventually some were ignored by the customer). Rather, what the programmer does produce frequently spawns operating difficulties for the user. Some customers get used to clumsy operating requirements, and then system reliability is correlatively reduced.

The proposed book is therefore needed by various computer system designers to cover the man/computer information gap, and to provide additional design criteria.



April 17, 1967

2. Why Thie Book Is Needed

It is indeed unfortunate that in these past two decades no book on man/computer task allocation or apportionment as the one being proposed hasbeen produced. To cover this hiatus in computer system design philosophy a book is required that will express methods for improving task allocation or apportionment between man andcomputers, based on a disclosure of man's mental and psychologicall imitatione vis-a-vis the computer and its programs, and that will serve as practical counsel for the integration of man into the computer system.

Such a book should supply case histories to illustrate concrete examples ofthese actions. In addition, such a book should supply methods for testing the computer system to insure the optimization of human reliability. Finally, such a book should provide guidelines for information flow and communciation among the various system designers and the customer. The proposed book will provide much of this material.



April 17, 1967

3. Purposes Of The Book

The following statements summarize the mayor purposes of the book:

1. To supply necessary and sufficient information to computer system designers on the vital functions, capabilities and limitations of man as they should be applied to computer system design, to optimize human and system reliability;

2. To indicate effective methods and salient criteria for allocating or apportioning information processing, decision-making, problem-solving task elements between man and computer components; and to provide criteria that can be used to effectively determine levels of automation, standardization, system control and tradeoffs;

3. To illustrate, via the case history method, how ineffective computer system and computer program designs have degraded system operations and impaired human performance; to describe the consequences of such design;

4. To provide guidelines on required system design interfaces (communication, information) among system planners, designers, computer programmers, human factors engineers and the customer;

5. To provide rules and guidelines for testing computer systems to insure the optimization of human reliability and reduce human errors; and,

6. To provide general standards and conventions that can be used for man/computer task allocation/apportionment according to stipulated system functions (such as management, professional,operator).



April 17, 1967

4. Source of Information

The information base for this book will be derived from several sources.

1. From the practical (design and production) experiences of knowledgeable computer program designers and human factors engineers.

2. From verbal and written reports made by users and operators of information systems (e.g., error rate and human performance reports).

3. From pertinent research on man/computer program interfaces conducted by various organizations: SDC, Mitre, RAND, and Army Personnel Research Office.

4. Other research reports on material tangential to man/computer interface will be reviewed for pertinency. This usually includes other research in engineering psychology and experimental psychology.

5. From data collected by this writer during the past five years pertaining to computer system design.

Human performance standards will be based on generalizations made from psychological research that can be applied to man in information systems. Justifications or reasons for certain task allocations between man and computer program will be based mostly on the practical experiences of human factors engineers, programmers and systemusers. It is certainly hoped that most of the material presented (e. g.,task allocations and performance limitations) will become hypotheses for further research in order to refine such statements.

This author believes that most of the standards, guidelines and objectives presented will be applicable to information system design for at least 5 to7 years. Some of the criteria and performance standards should be longer lasting. If current practices persist, though, the material will be good for at least 25 years. But as programming technology and information on man's capabilities becomes more sophisticated, there is no question that some, or even much,of the contents will eventually be obsolete. Because of the limited scope of the book, the author will not deal with man and computer program design in future systems, viz., artificial intelligence or heuristic programming.



April 17, 1967

5. Audience For The Book

1. This book can provide simple, commonsense guidelines to computer programmers* when they are faced with the job of deciding what elements of information processing tasks can be effectively allocated to man and to computer systemcomponents (e.g., computer programs, displays, console). They will be provided with criteria for judging the extent or level of tradeoffs that can be permitted without degrading design or potential use. Information on human performance limitations will enable them to quickly judge whether they are designing for or around the human beings in the systems. The book does not tell programmers how to program; it does, however, suggest ways that computers and programs could be more efficiently utilized.

2. The information in this book can supply an understanding of computer program design for the human factors engineer who has spent most of his career designing machine components. The information can provide him a means for judging computer system design efficiency and adequacy from the human point of view that will enable him to better ensure human reliability. In addition, much of the material can provide hypotheses for research in this area.

3. The data in this book can also be used as a computer program quality control medium by system design managers, to ensure that the computer programs meet with system operational requirements from the customer's point of view, and insure that man/computer criteria are included in design specifications.


* A generic term used throughout the book to depict computer systems advanced designers, operational designers and design implementers (e.g., coders); i.e., those disciplines responsible for the design of computer programs and equipment utilization.



April 17, 1967

6. Present Status and Schedule

1. Status

Almost all required data has been collected and filed. Only a small portion of the raw data on human errors, reliability and uses of natural language have yet to be obtained. These are available locally, and will be obtained shortly.

2. Schedule

April, 1967 : Complete data collection.

September, 1967: Complete first draft. Various chapters will be completed before this data and will be reviewed internally.

October, 1967 : First draft of book for external and internal review.

November, 1967: Second draft of book for external review.



April 17, 1967

7. Author's Background

Current - Human Factors Scientist, Assoc. System Development Corporation.

Responsibility: Writing the book: HUMAN FACTORS IN COMPUTER SYSTEM DESIGN on a corporate grant (Class I)

1964-1967- Human Factors Scientist, Assoc., Member, Personnel Subsystem Analysis and Requirements Design Staff, Personnel Subsystem Group, Space Programs Department, System Development Corporation, Santa Monica, California.


--Human Factors engineering consultation on computer program and information system design for the Space System Division's (AFSC) Satellite Control Facilities contract. Worked on computer program design teams and was responsible for man/computer program function allocation and human interface requirements (e.g., designing a radio frequency interference prediction program). Developed user's manuals and procedures. Designed training programs and conducted exercises. Worked on a teamresponsible for designing future Satellite Control Facilities (SCF) information subsystem, operational control system philosophy and configuration, operating requirements and personnel requirements.

--Organizational and personnel subsystem design for future Satellite Test Center (at Sunnyvale) configuration. Responsible for the design of personnel and organizational requirements, information subsystem operating requirements and philosophy, workspace and equipment allocation.

--Human factors consultant to joint SSD/Aerospace Corporation committee on future STC configuration design. Consulted on facilities design (with architectural contractor), organizational and personnel requirements design, and equipment allocation.

--Human factors member, joint SSD/Philco/Lockheed committee on human engineering equipment design criteria for SCF systems.

--Developed design requirements and methodology for computer program operational procedures; developed human engineering requirements for computer program design.

--Performed liaison work with SSD personnel on information system procedure document requirements and production.

--Responsible for group internal training on satellite and ground support system telemetry, tracking and command functions.



April 17, 1967

1963-1964 - Technical Ass't. to Group Head, Operations and Training Group, Space Programs Department, System Development Corporation, Santa Monica, California


--Responsible for group administrative/technical matters. Developed work plans, design documents, work schedules and manpower costing.

--Human factors engineering consultation on computer program design. Designed, developed and produced various computer program operational procedures documentation for use by STC operations personnel. Directed projects in these areas.

--Organizational and personnel subsystem design for the STC information system. Performed task analyses, link analyses, function analyses and developed STC personnel planning information (QQPRI) reports on required organization and personnel configurations within the information subsystem, based on new system design specifications.

--Human factors member, joint SSD/Aerospace/Philco/Lockheed/SDC Human Engineering Committee. Performed several "troubleshooting" analyses of system operations to ascertain operating faults and constraints. Performed liaison work with SSD on product requirements.

1962-1963 - Human Factors Scientist, Assoc., Operationa and Training Group, Space ProgramsDepartment, System Development, Santa Monica, California.


--Developed work plans, design methodologies and production schedules for SCF computer-based information system organizational and personnel requirements documentation, operational procedures documentation, and system task analyses. Produced organizational and personnel requirements documents (personnel planning information) and operational procedures for the computerbased system.

1960-1962 - Control Section Head, Personnel Subsystem Group, Strategic Air Command ControlDepartment, System Development Corporation, Paramus, New Jersey.


--Supervised the design and development of SAC control system organizational and personnel requirements, and information system utilization procedures. Directed initial work on system task and functions analysis. Performed liaison work with SAC personnel in the development of personnel requirements and procedure design.



April 17, 1967

1956-1960 - Instructor in Sociology, Long Island University, College of Liberal Arts and Sciences, Brooklyn #1, New York.


--Taught all undergraduate and graduate courses in sociology, social research and social psychology. Member graduate thesis committee in sociology and psychology. Directed various social research projects and was undergraduate student advisor in sociology. (I also attended graduate school at this time).

1955-1956 - Consultant, Motivation Research, Benton and Bowles Advertising Agency, NewYork City.


--Performed psychological analyses on attitude and opinion surveys for large oil company client.

1951-1955 - Attended undergraduate and graduate school.

1951-1953 - News Correspondent, Fairchild Newspapers, Akron (Ohio) News Bureau.


--Wrote news articles and represented the Fairchild News staff in the Akron, Ohio area.

1949-1951 - Chief Copy "Boy", Fairchild Publications, East 12th Street, New York City.


--Supervised copy staff and trained new copy personnel in Fairchild "style".

1946-1949 USAF service


B. A., Exper. Psychology, Kent StateUniversity, Ohio 1954

M. A., Sociology, Kent State University, Ohio 1956

Ph.D candidate, Columbia University, N.Y.C., 1955-1958 with all course work completed in sociology.


1. "Use of Comic Effect to Control Dysfunctional Behavior in Outer Space", Human Factors, August, 1963

2. "The Space Jester," FM & Fine Arts magazine, December, 1964.



April 17, 1967

3. "The Design and Production of SystemProcedures", in The Design and Production of Computer-Based-Information Systems, ed. by P. E. Rosove (to be published by Wiley, 1967). Included section on human factors engineering of computer program design.

4. System Development Corporation publications: authored approximately 60 technical publications.



April 17, 1967

Annotated Outline of Chapters*


Table of Contents


Chapter 1. Introduction

Chapter 2. How is Human Factors Engineering Related to Computer System and Computer Program Design?


Chapter 3. Capacities and Capabilities

Chapter 4. Human Reliability

Chapter 5. The Proper Use of Man: Allocating Task Elements

Chapter 6. The Misuses of Man: Case Histories


Chapter 7. Human Performance Guidelines

Chapter 8. Testing the Computer Program for Human Use

Chapter 9. Standards and Conventions for Task Allocation


*Book will contain approximately 200 pages



April 17, 1967


Chapter 1. Introduction

The purpose of this chapter will be to increase the computer system designer's and computer programmer's awareness of the importance of computer operator/ user's capabilities, capacities, limitations and operating requirements.

Section 1

1. A discussion of the consequences of a lack of understanding and implementation of man's capabilities and capacities. How such a gap in knowledge and technique can lead to increased costs, extended personnel training time, system degradation, design retrofits, and cause a standstill in the stateoftheart and the business of designing computer programs.

2. A discussion of the role of various system designers; that is, the participation in the design and development process with discussion and contributions and nominal limitations of each group: top management, user technical specialists, system analysts, computer programmers, human factors specialists, etc.

3. A discussion of some of the major causes of ineffective design, such as poor design management, insufficient design analyses prior to design commitments, inadequate "system" orientation leading to an improper blending of man/machine/computer program; the egoinvolvement of computer programmers with their offspring; the inadequate interactions and information flow among designers, and between top level customer management and designers.

Section 2

3. Definitions of basic terminology used in this book and types of systems that will be considered and their definitions.

4. The purposes of this book and why it is needed.

5. Ways in which to use this book.



April 17, 1967

Chapter 2. How is Human Factors Engineering Related to Computer System and Program Design?

The purpose of this chapter is to describe how human factors engineering should be used for the design, development, and validation testing of various types of information systems components (programs, equipment usage).

1. A discussion of the ways in which the human factors engineer can assist the designer and programmer during system planning, advanced design, operational design, and implementations and testing. And, how the designer and computer programmer can use the expertise of the human factors engineer during all stages of design and production.

2. A discussion of the various tools and methods used by the human factors engineer and how he uses them. For example, there will be a discussion of functions and tasks analyses, human interface requirements analysis, tradeoff and link analyses, personnel and organizational requirements, etc., and their particular role in information system design. For the human factors engineer, there will be an explanation of how to apply these techniques to information system design.

3. A discussion of the types of information needed from the computer programmer by the human factors engineer to adequately perform his several design tasks, and the types of information the human factors engineer can supply to the program designer for each type of information system being designed.


17 - Blank



April 17, 1967


Chapter 3. Capacities and Capabilities

The purpose of this chapter will be to provide specific data to computer system designers and programmers (and human factors engineers) on man's limitations and capabilities as applied to the design of computer program and information system operations.

1. Data will be provided on the limits and ranges of man's abilities, skills, aptitudes, and qualifications for consideration when designing the man/computer interface. (There will be no discussion, however, of the psychophysiological rudiments of man/machine interfaces; e.g., the limits of psycho/motor/capabilities or vigilance in a tracking task. Vigilance will be discussed, though, in terms of monitoring program operations.)

2. The data in this chapter will be arranged into two general categories, and each factor discussed will be strictly related to man/computer tasks only.

Section 1. Mental Senses/Capacities

1) Perception

2) Memory/Storage/Retention

3) Vigilance

4) Fatigue

5) Sensing

6) Attention

7) Identifying

8) Detecting/Discriminating

9) Interpretation

10) Speed

Section 2. Problem-Solving Capabilities

1) Goal-Setting

2) Judgment

3) Fallibility

4) Certitude

5) Control

6) Ambiguity

7) Flexibility

8) Motivation

9) Decisionmaking

10) Information processing

11) Feedback/feedforward

12) Coding



April 17, 1967

3. With these concepts and variables in mind, the chapter will be concerned with how man can be expected to perform within various system contexts according to his functions and capabilities. The types of users, their skills, job requirements, etc., capacities and capabilities will be defined. (For example, the subject of "Feedback" material will be concerned with the need for feedback, reasons for feedback and consequences of lack of feedback.)

4. Some discussion will be presented on the consequences to system operations when specified human capability standards are ignored.



April 17, 1967

Chapter 4. Human Reliability

The purpose of this chapter is to identify and explain human performance standards, requirements, conventions, and limitations within the context of computer system operations. Included will be a discussion of ways of optimizing human reliability, and the problems encountered when human performance limitations are exceeded. The discussion will also illustrate how these standards, etc., should be applied to various system functions(e.g., the allocation of decisionmaking functions to man and to computer) within various types of information systems; (e.g., timesharing, military command/control, document retrieval, scientific, engineering, education, etc.). Much of the data will be derived from actual design and operational experiences.

Section 1. Human Reliability

1) Performance Standards (workload, pacing)

2) Human Errors and Error Rates (human induced errors)

3) Design induced Errors (lack of information and other sins of omission and commission)

4) Effects of Human Error on System

5) Error Recovery Techniques

Section 2. System Functions

1) Operate

2) Maintain

3) Control

4) Monitor

5) Use or Manage

Section 3. Human Attitudes, Skills and Requirements

1) Language (dialogue that should be used in various system contents)

2) Decisions (that man makes and that computers can make)

3) Transfer Function

4) Actuating/Amplifying

5) Manpower and Other Personnel Requirements

6) Skills (related to computer functions such as editing, computations, storage, sorting, etc.)



April 17, 1967

Chapter 5. The Proper Use of Man: Allocating Task Elements

The purpose of this chapter is to introduce the "principle of complementary allocation* of task elements." As complex as it may sound, this principle merely purports to answer the question, "What portions of a single information processing task should be "justly" allocated to man and what portions to the computer?"

1. "Task" is defined as it should be applied to information systems in particular. Explains how the traditional use of task (as in "task analysis") can hinder the proper allocation of task elements to man and computer programs.

2. Various data processing logical functions and operating methods will be identified and discussed in terms of man's own processing capabilities, and then recommendations will be made for allocating task elements. Logical functions are those computer program operations that augment man's capabilities. Operating methods are concerned with the proper utilization of input/output and processing equipment according to man's capabilities and his job requirements.

3. The discussion will, for each concept, indicate the criteria and rationale for applying the principle of complementary allocation. Thus, we could ask such questions as: how should a data sorting task be allocated? Should data be first provided on a punched card? If yes, should these cards be hand sorted? machine (EAM) sorted? or sorted by both man the computer? How? What are man's limitations in terms of requirements and criteria for sorting? What types of constant or variable errors can he make? And their consequences. What are the allowable tradeoffs? When should man be allocated a complete sorting task that could be more easily accomplished by a computer? And vice versa.

4. The criteria for judging the effectiveness of task element allocation will include: (a) criticality (of task, mission), (b) time factors, (c) accuracy, (d) cost (manpower, training, etc.), (e) operating efficiency (or automation), (f) standardization, and (g) control (types, centralized, decentralized, etc.).

5. The basic discussions will be arranged in the following manner and will include the following concepts:

*Although the term "allocations," meaning to distribute or assign, has traditionally been accepted and will probably remain so; the term "apportionment," used frequently in this proposal has a meaning closer to what is meant here: "to divide and assign in just proportion."



April 17, 1967

Section 1. Logical Operations and Functions

1) Inputs

a. Sorting data*

b. Merging data

c. Coding Information (cards, messages, mnemonics, etc.)

d. Language (dialogue)

e. Information Retrieval (data request techniques)

f. Editing (conversions)

g. Verification


2) Information Processing

a. Utility

(1) Merging (files, data)

(2) Sorting(data)

(3) Memory Storage

(4) Subroutines: buffering, indexing, queuing, table lookup, etc.

(5) Control (executive)

(6) Validation (e.g., data limits)

(7) Diagnostics

[handwritten] (8) File Maintenance

b. Operational

(1) Decision Algorithms

(2) Error Detection

(3) Error Recovery

(4) Updating

(5) Data Reduction

(6) Data Arrangement

(7) Data Processing Control

(8) Data Computations


3) Outputs

a. Language

b. Format

c. Contents/Mnemonics/Codes

d. Data Transmission and Distribution

e. Information Retrieval

f. Dynamic/Static Displays

g. Editing


*For example, will discuss the techniques man and computers use for sorting; and will be related to Chapter 3's discussion on man's "identifying," "attention," and "interpretation" capabilities.



April 17, 1967

Section 2. Method of Operations

1) Inputs

a. Cards (format, content, usage, sorting)

b. Tapes (usage, merging)

c. Console (switches, data inputs)

d. Typewriter/Flexowriter/Keyboards

e. CRT, (uses, formats)

f. Disks, Drums (data storage, format)


2) Information Processing

a. Disks (use during processing)

b. Drums (format, contents, usage)

c. Tapes (format, contents, usage)

d. Core/Memory (multiprocessing/multiprogramming)


3) Outputs

a. Cards

b. Tape

c. Typewriter

d. Printers

e. Plotters

f. Displays



April 17, 1967

Chapter 6. The Misuses of Man: Case Histories

The purpose of this chapter is to illustrate the consequences of "poor" allocation of task elements between man and computer program.

1. The case history method will be used to provide examples of imperfect computer system designs and its effect on computer system operations. Various examples will be chosen to illustrate how a pertinent human performance deficiency was engendered.

2 After each case, a discussion will be presented on how these particular computer programs significantly degraded information system operations, increased human error, overloaded users, increased manpower requirements and hindered the achievement of tasks and objectives.



April 17, 1967


Chapter 7. Human Performance Guidelines

A short chapter that outlines, probably in chart form, man's capabilities, capacities and limitations according to:

1. The type of information system being designed (document retrieval, scientific, timesharing, command and control, educational, etc.) and,

2. The type of human functions to be performedcontrol, use, operation, maintenance, etc.



April 17, 1967

Chapter 8. Testing the Computer Programs for Human Usage

The purpose of this chapter is to indicate the importance of validation-testing of computer systems and programs to insure optimum human reliability and reduce potential human errors, before program delivery to a customer.

1. A discussion of the reasons for exercise/testing computer programs in a simulated mode (near-real operating conditions) to further insure that computer system operating requirements are compatible with potential user operational requirements and personnel requirements.

2. A description of test design methods and principles that will allow the programmer to integrate human reliability testing with his program validation. The following test procedures will be discussed.

a. Designing the test exerciseparticipants, materials, reports, rules.

b. Setting up test criteria and standards.

c. Testing all human interfaces and operating instructions.

d. Stressing the program according to human performance limitations.

e. Checking adequacy of feedback and feedforward mechanisms, and recovery procedures.

f. Evaluating the exercise run, evaluating human performance and reliability, and making design changes (including discussion of allowable tradeoffs).



April 17, 1967

Chapter 9. Standards and Conventions

1. The purpose of this chapter is to provide simple guidelines for indicating what, when and how task elements should be allocated to either programs and/or man. This chapter is a working summary of Chapters 3, 4, and 5. It will provide easy access to relevant design arguments in those cases where man is a component of an information system. There will be no discussions of human performance limitations, but standards will be derived from them.

2. The data will be arranged in a format illustrated in the attached table. An example of table contents is also supplied.

Explanation of Table:

Column 1. System Functions: These represent the major functions (not people) that are involved with computer system operations. Each function has some purpose for which information processing tasks must be allocated in a certain way. Thus, what can be required of a professional/technical function may not always be required of management functions for each has peculiar job and data requirements.

Column 2. This column will include indications of computer logical operations (computer program functions) and operating method (equipment utilization).

Column 3. Standards: These are standards that will be based on man's limitations and capabilities as well as the capabilities of the computer system component. Thus, for each logical operation specified there will be indicated the performance limitations of man, and the operating capabilities/ limits of the computer.

Column 4. Conventions: These are the normally accepted ways of performing some task and is based on such things (for man) as "population stereotypes" or general procedures for doing a job to which man is accustomed; and the most efficient way for a computer component to perform some task that requires a human interface.



April 17, 1967

3. Examples of Table Contents

Logic Operations: Input

Computer Operator: Sorting Data


    • Operator level personnel who are required to sort data input by users will usually evidence high error rates. The larger the number of keys on which to sort, the higher the expected error rate. (Examples of keys: by alphabetic sequence, and height, weight, length of service, grades, etc)
    • Computer program sort routines can save time and reduce human errors. Program sorts can standardize procedures.
    • (Sorts on EAM equipment. See: Operating Methods: Inputs)
    • Program should provide sequence list for quality control and information feedback for users.


    • If key sorts are a mixture of alphanumerics, high error rate will occur. (See: Keypunch errors on Card inputs; Operating Methods: Input section.)
    • Can sort input data if sort is required only on a master key.
    • Feedback (listing) of sorted data should be provided if others are to use data on tape.
    • Operating instructions are an inefficient way to reduce sort errors.
    • If keys are alphanumeric the computer is best. For automatic sort it is not necessary to provide feedback to operators on outofsort data.
    • Program should sort in core. Direct card to tape will not provide adequate feedback on input errors, if feedback is desired. Partial sort on tape first is OK if tapeto coreto tape technique is used.
    • Master file order should also be close to required final order to minimize sorting if only master key is used.
    • Program should provide option to operator for a listing of final sort sequence.


Page 29 Figure 1: