The documentation will be in a software requirements specification. This specification is at the level a customer should set down when contracting for a piece of software. Your specification will be based on customer interviews, with your instructor and teaching assistants in the role of customers. When developing this specification, your team will play the role of system analysts.

You should be creative and ambitious with your specifications. In particular, do not worry about specifying a project that will be too hard to implement. Your job in the fifth week of the quarter will be to prioritize the requirements into a subset of features that can be implemented in the second half of the quarter.

The core features of the TestTool are:

• A question bank
  • this contains all the different kinds of questions that can be on a test
  • the TestTool provides a convenient set of interfaces for users to enter new questions, change or delete existing questions, and search for questions
  • questions in the bank have a number of attributes, such as what class the question is for, the type of question, how hard it is, how long it takes to answer, and other attributes you can help the customers figure out
  • we'd like to have all the standard types of questions, such as true/false, multiple choice, fill-in, matching, short-answer, long-answer, and others you may find when you look at related tools
  • we also need to have questions that contain graphics
  • and very important, we want questions that have program code; we're not sure exactly what the details are with this type of question, so you're going to have to help us figure it out

• Semi-automated test generation
  • the simplest form of generation could display a dialog with a few test features, and use the filled-in values to generate a test
    • for example, a user could enter the class a test is for, how many questions are on the test, how long the test should take, and roughly how difficult it should be
    • with this information, the generator produces a test which can be edited to further refine the questions
  • a more advanced form of generation allows the user to enter details for each specific question to be on the test
    • the user interface for this kind of test generation could be some form of table with each table row being a set of pattern values that could be matched by one or more questions in the bank
    • the table column headings would be question attributes, such as class, type of question, difficulty, time it takes to answer, last time it was used on a test, etc.
    • the TestTool would then generate a test to meet these more precise specifications

• Electronic test taking
  • the taking interface allows students to take a test electronically
  • the test taker should have convenient features such as a timer, an indication of which questions have been answered, and an option to allow students to use an IDE during test taking to answer code questions
  • the taker should operate in one of three modes -- (1) in-class proctored, (2) out of class take-home, and (3) out of class practice exam

• Semi-automated test grading
  • all types of questions can be graded automatically, at least partially
  • once auto-graded, the user can look at the tests and change or refine an auto- graded score
  • the user can also put comments next to student answers, in the form of, say, electronic post-it notes; these simulate the normal kind of pen-based mark-up that instructors do on paper tests

• The TestTool is not an AI program
  • it uses some basic rules for test generation, nothing super fancy
  • once a test is generated, the user can edit it manually, or change some of the input parameters and have the test re-generated
  • the same goes for test grading; it will use some basic grading rules, and if necessary the instructor can change graded scores manually

• The primary setting for the TestTool is the computer science department
  • if some aspects of the TestTool are useful for other departments on campus, or even off campus, that's fine
  • however the focus is on features that computer science faculty and students need

• In the beginning, we won't worry about whether the TestTool is a desktop app or browser-based app
  • your initial requirements scenarios should have user interface pictures with useful features, independent of whether the program is running on a desktop or in a browser
  • we'll determine the actual deployment platform in a few weeks
  • there are in fact tool kits that can take a single program interface design and have it deploy transparently to either a desktop or browser; (one such tool is JavaFX, which you may choose to use in 307 if you like)