Your goal is to do the initial brainstorming in pairs during the lab period, and then working individually or as a pair, finalize a requirements document by the due date. In your work, you will round out the list of requirements with any additional ones you think of, polish the ones you already have, and, most importantly, organize and clearly communicate the requirements, so that the requirements document has structure, rather than being a unorganized hodge-podge of assorted ideas.
You can use whatever format makes your requirements document clear: you need not stick religiously to the textbook's example format. You might want to illustrate your requirements with some use cases (sample scenarios of usage), which gets into our next textbook topic, but can be a powerful tool for elucidating the visible functional requirements. You might even want to sketch a provisional user interface, not because this is an appropriate time in the system-development process to be seriously addressing the user interface details, but rather because it can help tell the use-case stories and thus help you find functional requirements.
Let me make some comments as to what I am expecting in your document. Generally, I would like you to apply the strategies that the textbook's author outlines, in particular in chapter 6, about writing a requirements document. Since this is "learning by doing", I feel that this is best done by teams uncovering the goals and methods, and applying them to the project at hand.
In particular, I recommend that work through the 4-step process described in section 6.9. In particular, you should choose the system boundary, uncover actors, categorizing them as primary or supporting, identify goals, and name your use cases. For the use cases, at least should be briefly elaborated, one should be casually elaborated and one should be (reasonably) fully dressed.