The idea is that you should not yet use the requirements tests from A1 to test your code, rather just design it and get it working for at least a few test inputs. You'll run the tests from A1, and fix all indicated bugs, in Assignment #3.
You can assume that it is provided, and that it is correctly formatted. You don't have to check for errors in it. An incorrectly formatted VSL is one of the (few) circumstances in which it's okay for the Front End to stop with a fatal error.
Your Front End should take two arguments: the name of a Valid Services List file, and the name of a Transaction Summary file.
The Front End also reads input from standard input, which can either be typed in (in "production") or redirected from a file (test input when testing). In the first case:
frontend validservices.txt transactionsummary.txt
That should read validservices.txt, and write transactionsummary.txt (upon logout, as specified by the requirements).
When testing, use redirection to feed in the "user" input, say testinput.txt, without typing it on the keyboard:
qies validservices.txt transactionsummary.txt < testinput.txt
You may also want to save the terminal output created by the test:
qies validservices.txt transactionsummary.txt < testinput.txt > testoutput.txt
This seems to be an issue with some Java installations, where typing things into the shell somehow behaves differently from redirected input. If you can't easily fix this, it's okay to change your qies to take three arguments. (If you also want to implement a command-line option to support terminal input for casual testing, you can do that—but you must support terminal input from a file, so you can automate testing on A3.)
What I have in mind is a description of the architecture of your solution, showing the parts (classes, methods, major data structures) and their relationships (which uses which, which calls which, etc.). For an object-oriented implementation, this could be a UML Class diagram or something similar. Or you could make a structured spreadsheet-like table of the major parts, the parts inside them, and which parts each calls or uses.
That's not the Front End's problem. The Front End doesn't have access to the number of tickets sold, because that's not in the Valid Services List.
You can assume there's only one login-logout session per run of the Front End, representing one "day" of transactions. Don't try to generate multiple files—it's extra work that falls outside the requirements.