non-computerese. We should be using as much as is 
possible, terminologu from established literature rather 
than words invented bu programmers. 
à 2: ON-LINE HELP 
All system functions should have sufficient on-line help to 
allow the analyst to come to the work station with only his 
data tapes and professional literature. This means that ALL 
user-level system documentation should be on-line. Getting 
it on-line is easy. Making it especially readable is a 
different story. The user/analyst should be able to enter 
further documentation, especially if he has written local 
procedural command sets for himself (or his colleagues). 
This documentation should be stored, accessed and displayed 
in a manner that appears identical to the documentation 
supplied with the sustem. 
5. 3: COMMAND PROTOCOL 
Assuming manual keyboard control entry, all commands should 
be constructed From a uwell-formed suntax. You should be 
able to write, for example, a Backus-Naur form syntax 
description for the full set of commands. Extra points are 
awarded if the syntax fits on two pages; points are lost 
for syntax exceptions — which probably won’t be used anyway. 
6.4: PROGRAM CONTROL ACCESS 
You should be able to set up ALL program control vivia 
COMMANDS and MENUS. 
COMMANDS must be provided allowing the analyst to examine 
and change the state (value) of ANY control parameter for 
ANY program in the system without actually running the 
application programs. As much as is feasible, the interface 
should check user input for validity while s/he is setting 
them. rather than during execution of the application 
program. 
All programs should have MENUS. Menus should be invoked, 
formatted and manipulated in a single, consistent manner. 
Dense menus should have two {not more) states: one that 
provides access to the basic functions for that capability, 
and another that provides advanced options. Nesting menus 
more than two levels deep is for the computer-literate, 
hence this should be avoided.