Requirements should be stated as complete sentences containing words like "should" and "will" for strict requirements that must be met for the project to be considered successful. In addition to those strict requirements, which define the project's basic scope, additional optional requirements may be defined. Optional requirements should state any nessary preconditions using words like "if", "in case", "under the condition that", etc., and should use words like "may" or "could" to indicate that while the project would be enhanced by meeting the requirement, it still can be judged a success without doing so.
Especially in the second project cycle, the strict requirements for the project should be complete enough that even if none of the optional requirements are met, a complete and high quality high level design, low level design, implementation, and evaluation can be achieved without significant revision or expansion of the set of strict requirements for the project. This is very important, as the set of strict requirements defines the final scope of the project, and in that sense establishes expectations for the amount and kind of effort required to complete the project by the end of the course.
All requirements for the project should be detailed enough that they can be followed into the selection of appropriate design patterns. That is, the document should adequately describe the design forces for each requirement, so that design pattern problem and context descriptions can be compared against the design forces arising from each requirement. In your requirements document, you should list the relevant design forces pertaining to each stated requirement, as explicitly as possible.
In practice it is sometimes difficult to anticipate all of the considerations that will come up during design and implementation up front, and it is sometimes necessary and beneficial to revisit requirements during later stages. Beware, however, of letting the scope of the project change (sometimes known as "scope creep") as that can put the timeline and quality of the project in jeopardy. In general, your experience with the requirements and their effects on later project stages during the first project cycle should help build your intuition in how to avoid these kinds of problems.
The cost (in this course mainly in terms of time, but in real-world projects also often in terms of money and in some cases in terms of health and safety risks) of revisiting requirements increases non-trivially as a function of the number and scope of subsequent design and implementation decisions that themselves must then be revisited. Therefore, it is again important to look ahead at least to the high level design stage (and if possible even farther), and to try to anticipate whether the set of requirements stated will be sufficient and appropriate looking ahead. One suggestion is again to skim the brief pattern summaries on the inside cover of the GoF book and see if any of them seem to have bearing on the requirements you are generating. You can then review those patterns that appear possibly relevant in more detail as you write your requirements, and focus on whether those patterns may suggest other requirements that have not been captured.
This suggested approach can also result in development of a partial skeleton for your high level design while you complete your requirements definition, and can help you both to evaluate your second set of requirements and to get a head start on transitioning from requirements into the second high level design stage. Whether a given set of requirements is complete is ultimately a matter for you to judge, and building your experience in making such judgements is an important part of the design experience in this course. Because this is the second cycle of the projects, your experience in the previous cycle should help you evaluate the completeness of your requirements.
For a review of examples of requirements, please see the Requirements I web page from the first project cycle.
Participation: every member of your team should be significantly involved in the production of this document, though how you structure the interactions within the team is up to you. For example, it's fine for one person to capture notes from a group discussion of the requirements document and write it up as long as the other team members contributed materially to the discussion that is captured.
Deadline: by 11:59pm on Friday, June 19, 2009, please e-mail your team's second requirements document to Prof. Gill at cdgill@cse.wustl.edu.
Your team should again treat this document as a "work in progress", evolving it appropriately throughout the second development cycle, and by the evaluation stage it should constitute most of your final project report, other than the evaluation results and analysis which you will add in that last stage of the cycle.