CINF4324_Chapter 11

• ○ Command line
• ○ Menu
• ○ Form
• ○ Object-based
• ○ Natural language

Pro = good for experienced users, for systems with a limited command set, and for rapid interaction with the system.

Con = places a substantial burden on the user to remember names, syntax, and operations.

Dara Error	Description
Appending	Adding additional characters to a field
Truncating	Losing characters from a field
Transcripting	Entering invalid data into a field
Transposing	Reversing the sequence of one or more characters in a field

• Pro = ...
• Con =provide little guidance beyond invoking the command.

Pro =is effective for both the input and presentation of information.

Con =...

Pro =take up little screen space and can be quickly understood by most users.

Con =...

Pro = Inputs to and outputs from a computer-based application are in a conventional spoken language

Con =Implementations can be tedious, frustrating, and time-consuming for the user and are often built to accept input in narrowly constrained domain.

Validation Test	Description
Class or Composition	Test to ensure that data are of proper type (e.g., all numeric, all alphabetic, all alphanumeric)
Combinations	Test to see if the value combinations of two or more data fields are appropriate or make sense (Does the quantity sold make sense given the type of product?)
Expected Values	Test to see if data are what is expected (e.g., match with existing customer names, payment amount, etc.)
Missing Data	Test for existence of data items in all fields of a record (Is there a quantity field on each line item of a customer order?)
Pictures/Templates	Test to ensure that data conform to a standard format (e.g., Are hyphens in the right places for a student ID number?)
Range	Test to ensure data are within proper range of values (e.g., Is a student’s grade point average between 0 and 4.0?)
Reasonableness	Test to ensure data are reasonable for situation (e.g., pay rate for a specific type of employee)
Self-Checking Digits	Test where an extra digit is added to a numeric field in which its value is derived using a standard formula
Size	Test for too few or too many characters (e.g., Is social security number exactly nine digits?)
Values	Test to make sure values come from set of standard values (e.g., two-letter state codes)

Guideline	Explanation
Consistency	Dialogues should be consistent in sequence of actions, keystrokes, and terminology (e.g., the same labels should be used for the same operations on all screens, and the location of the same information should be the same on all displays).
Shortcuts and Sequence	Allow advanced users to take shortcuts using special keys (e.g., CTRL-C to copy highlighted text). A natural sequence of steps should be followed (e.g., enter first name before last name, if appropriate).
Feedback	Feedback should be provided for every user action (e.g., confirm that a record has been added, rather than simply putting another blank form on the screen).
Closure	Dialogues should be logically grouped and have a beginning, middle, and end (e.g., the last in the sequence of screens should indicate that there are no more screens).
Error Handling	All errors should be detected and reported; suggestions on how to proceed should be made (e.g., suggest why such errors occur and what user can do to correct the error). Synonyms for certain responses should be accepted (e.g., accept either “t,” “T,” or “TRUE”).
Reversal	Dialogues should, when possible, allow the user to reverse actions (e.g., undo a deletion); data should not be deleted without confirmation (e.g., display all the data for a record the user has indicated is to be deleted).
Control	Dialogues should make the user (especially an experienced user) feel in control of the system (e.g., provide a consistent response time at a pace acceptable to the user).
Ease	It should be a simple process for users to enter information and navigate between screens (e.g., provide means to move forward, backward, and to specific screens, such as first and last).