(Alternative question: an older version of the requirements document has YYYYMMDD.hhmm, but the newer one has YYYYMMDD.)
I decided to drop the hour and minute—not for realism (a real system would need the time, not only the date) but because it wouldn't teach you anything you won't already learn by handling YYYYMMDD.
Not on this assignment, but your test plan should explain what you intend to do later on, e.g. which scripting language (bash, Windows batch, etc.) you'll use, or whether you plan to compare test results manually.
(Windows batch files are strange and I don't recommend them if you have any reasonable alternative. Cygwin may allow you to run bash scripts on Windows without doing a full Linux installation, but I haven't personally used it because I don't use Windows.)
They should include the same information as that example, but you're encouraged to present it more concisely. For example, many failure tests (like "can't create service in agent mode") will result in an "empty" Daily Transaction File (actually one containing just an EOS transaction). You can refer to that file by name in the test case; you don't need to show its contents.
Similarly, if you find that all your test cases may print "possibly information messages in response to commands", you can add a note above the list of test cases saying that every test case may print that. You don't need to repeat it.
You still need to include information that's specific to the test case: for example, you shouldn't leave out "Purpose: check that creating service in agent mode is disallowed".
Assignment 1 asks you to write requirements tests for the Front End. Writing a program to check validity of the Daily Transaction File is separate from that. Each test case should check that the session produces a specific, valid Daily Transaction File, because that's part of the expected output of the Front End. But you don't need to think about the entire "space" of possible Daily Transaction Files, just the ones produced by your test cases.
(In a real-world system, you might want a separate program to "double-check" validity of the DTF. Then you'd need to write test cases for that program. Such a program is not part of this assignment, and may not be part of the project at all.)
Also, you don't need to write any tests for the Back Office. A1 is for the Front End, only.
(By the way, there is a systematic testing method called output coverage testing where you would design tests that can produce every "kind" of DTF. That is not what we're asking you to do in Assignment 1, but we will cover it in lecture.)
Either is acceptable, as long as the invalid input is ignored.
You need to make test inputs by hand. You can, for example, make a Valid Services file using a text editor. Your tests can then use that file as part of their input. It could have no services in it, or a couple of made-up service numbers for the purpose of testing.
Failed or invalid transactions must have no effect on the Transaction Summary File. An error message on the terminal would be appropriate for failed or invalid transactions.
All logins are assumed valid. We are not implementing a security component, so if a login says either "agent" or "planner", you should consider it valid.
This is different from the question above (about testing the Daily Transaction File). First, the Valid Services List is an input, not an output. Second, it is not user input; in an actual system, it would be generated by the Back Office. You can assume that the Valid Services List is correctly formatted.
Put another way, you do not have to write robustness tests to check whether the Front End can handle a corrupt or incorrectly formatted Valid Services List.
If you already interpreted "The Front End should never crash...The Front End cannot depend on valid input" to mean that you needed to test that the Front End doesn't crash even when given a garbage Valid Services List, and wrote up test cases accordingly, we will not deduct marks.
You can assume the Front End is started, gets a single login as either Agent or Planner, and is shut down after logout. Three subsequent sessions within one run wouldn't be consistent with the setup described in the specs (though you have to read all the way through the end, about the Back Office, for that to make sense), which means