Your goal is to do the initial brainstorming in pairs during the lab period (Wednesday, February 13th), and then working individually finalize a requirements document by the due date (February 19th). In your individual 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.
Addendum (clarification): First off, I am altering this assignment to allow you to hand in a team requirements document, should you wish to do so. Therefore, be sure that the person you are working with is in agreement on whether you will be turning in a team document.
Secondly, 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, I would ideally like at least some of them to be elaborated, with at least one briefly elaborated, one casually elaborated and (hopefully) one fully dressed. I initially said I want them all at least briefly elaborated, but I am backing off on that in case that should be too long. However, you should try to elaborate as many as you are able to do in the given time.
By the way, I linked in UseCases.org on the course web page (as well as here, of course).
Instructor: Karl Knight