Quantitative Requirements

This section describes the performance and behavior requirements for the Zurk software suite.

1. All programs MUST NOT crash, core dump, dump a stack trace, or throw an exception on any input.
2. In the case of a RECOVERABLE ERROR, a program MUST issue a warning statement and continue processing. All PLAYER-consumable ERROR or WARNING statements MUST be issued to STDERR. Any other ERROR or WARNING statements (e.g., parse errors or internal Zurk errors) MAY be issued to a log file or to STDERR. If an internal error is issued to STDERR, it must be made interoperable to a general human PLAYER and not simply to the developer.
3. In the case of an UNRECOVERABLE ERROR, a program MUST issue an error statement and terminate with a non-zero error condition. The program MAY use different exit codes to indicate different error conditions, but such codes MUST be documented in the user manual. The error message MUST be logged to the same destination that warning messages (from RECOVERABLE ERRORS) are.
4. In the case of any ERROR, a program MUST NOT delete, corrupt, or damage existing GAME FILEs or any other ``stateful'' files employed by the Zurk program suite.
5. The entire program suite MUST NOT employ or refer to the StreamTokenizer, StringTokenizer class or any element of java.util.regex, including indirect references to it via, e.g., String.split(). The developer MUST provide her or his own implementation of a lexer to handle lexical analysis. That lexer MAY be an extension of Dr. Lane's MiniLexer class, presented in lecture, or MAY be a from-scratch implementation.
6. The suite MUST NOT use an auto-generated lexer or parser (e.g., from lex/yacc/flex/bison/pccts/antlr/etc.) Both lexer and parser MUST be written by the developer.
7. The programs MAY provide additional output for debugging purposes, but such output must be disabled by default. Any program MAY provide a command-line switch or a user-interface configuration utility to enable debugging support when desired.
8. The Zurk suite MAY employ any class in java.util (including HashMap, etc.) not otherwise covered by the above.
9. The Zurk suite MAY use the gnu.getopt.Getopt and gnu.getopt.LongOpt classes to assist in handling command-line options.
10. The designer MAY ask permission of the instructor or the TA to use any classes outside the JDK that have not already been mentioned. The final programs MUST NOT use any class outside the JDK that have not been explicitly allowed.
11. The Zurk suite MAY assume that all valid GAME FILE and PLAYER input is standard ASCII text in the range (char)0-(char)127, inclusive. If a program encounters a character outside this range, it MAY treat it it as a RECOVERABLE or UNRECOVERABLE ERROR or silently ignore it. If such characters are treated as RECOVERABLE or ignored, they MUST NOT disrupt the otherwise normal functioning of the program.
12. All programs MUST NOT assume that all PLAYER input is validly structured. If a program encounters syntactically erroneous input (e.g., punctuation, too many or too few arguments, etc.) it MAY produce a RECOVERABLE or UNRECOVERABLE ERROR, but it MUST NOT crash, corrupt any files, etc.
13. All user documentation MUST be grammatically correct and include correct spelling and usage. (You will be graded, in part, on the quality of your writing.)
14. The designer MUST document any areas in which her or his software suite does not meet this specification. WARNING! The grade penalty will be higher if the instructors discover an undocumented program shortcoming or bug than if it is documented up front.