Criteria	Points	Description
General format:	5	All text and graphics are contained within: width: 6" X 9".  Font size: 10pt or 11pt; font type: your choice (Times New Roman preferred).   Number all pages except the title page, starting with 2.  All text is full-justified.  Page breaks are in apropriate places.
Title page	*	This is page 1; unnumbered.  Contains the project title, list of team members, team and group leaders, date on which the report was prepared and the version number.  The report submitted by the deadline above will be considered version 1.
Table of Contents	*	Lists all sections and subsections in the standard indented manner.  Names of the sections do not include the word "Section" -- e.g. "Section 1: Introduction" should simply be: "1 Introduction".   This may occupy more than 1 page.
Main body	85	The Table of Contents page is followed by the main body of the requirements document. The body is divided into the following numbered sections.   Section Points Description Introduction * This is  section 1 of the requirements document. It is titled Introduction. It describes the need for the system, its function and how it will work with other systems (if any). The description must be kept brief, preferably to one page.  The description should be put in Layman's terms, and you should not assume that the reader of this section is at all familiar with the project. System Functions * This is section 2.  Here you will lay out the basic functions that compose the system.  These functions should be arranged into logical groupings, and may be divided into subsections of the document as in Larman, pp.42-44.  Be sure to include a brief description of your function categories before using them, and be sure to include reference numbers for each Function. System Attributes * Section 3.  Any non-functional system requirements (constraints that are not part of system functionality) should be listed here, in the manner described in Larman, p.45.   If there are no non-functional requirements, say so here -- do not omit this section. Description of Functionality * This is section 4 of the document. One or more use-case diagrams must be provided to help in the understanding of the relationships amongst the use-cases.  Make use of real use cases (page 59 of Larman) to explain actor actions and system response (you will most likely make changes to section 2 during this process). Each use-case should be listed and explained in a separate numbered subsection.  Do not make the mistake that each system function should be a use case.  A single use case will most likely cause the invocation of several System functions -- that is to say that a Use Case is a more High-Level process than a System Function. (see 6.5, p53; Larman) (25 pts) Rank use cases by their importance to the system (e.g. see Section 7.3 of Larman's text).  (This will help you to identify the features you will include in your prototype, and thus it is important that your sponsor shares your opinion on what is important). (5 pts) Conceptual Model * Section 5: Note that you are doing an OO analysis of Requirements. Show a conceptual model of the system to be built (see pages 87 to 102 of Larman's text). The format of all diagrams must be as in Larman's UML text , particularly Figure 9.1.  Be sure to clearly understand what a concept is, and the common mistakes as pointed out in Larman section 9.6.3.  Be sure to include the appropriate associations. System Behavior 30 Section 6: This is where you describe how the system concepts handle the use cases.  You should include system sequence diagrams (Larman ch. 13) or collaboration diagrams (Larman ch.17) for all "interesting" use cases (those that are not overly redundant, and particularly those that give a good overview of how the concepts interact).  Chapters 18,19 and 20 of Larman's book will be helpful for deciding on how parts of the system should work together.  For complex use cases, or those that are absolutely critical to the system, you should also include System Operation Contracts (Larman chapter 14).  Each team should include at least a few Contracts in their documents. Division of Reposnsibilities 30 Section 7:  In this section describe the classes that exist in the system (through a Design Class Diagram), as well as the role or responsibility that each class plays(in numbered subsections).  The description may include references to the concepts that a class may implement, as well as reference numbers of the use cases it participates in.  This is not a complete list -- include anything here that helps to describe what each class does.  If you will be using exceptions to handle errors in your system, it would be a good idea to list the exceptions that a class's methods may throw, as well as ones thrown from methods it calls.  As an introduction to this section, discuss the process you used to determine the classes that are present in your design.  Larman chapters 21 and possibly 22 will help with this section. Overview of System Architecture 15 Section 8: Larman section 22.4.1 (pp. 275-280) describes packaging.  This can be viewed as an extention of the Class discussion from the previous section in that it helps to lay out the high level architecture of your system as it will be built.  Figure 22.5 (p. 277) is a good example of a packaging diagram.   Notice that it illustrates the interaction on a high-level basis using groups of functionality as the objects of the diagram.  You should also show which classes belong to which packages (Larman, Figure 22.7, p.280) Member Responsibilities/ Contributions & Administrative info 5 In this section (#9) describe in tabular format which team members participated or contributed to the design, implementation, testing or documentation (or whatever else you've done).  What I'm looking for is a list of things (classes, document sections, use case descriptions, investigations into unknown technologies, etc.) with the name(s) of the member(s) who worked on them.  Also, you may include any other information you feel is important here. Problems, Conflicts, and Resolutions 5 This section (#10) is for you to list any problems you ran across during this project (be they communication problems, design problems, problems finding time to meet, etc.) and hopefully the solutions you came up with to solve them.   (This is used as an information source so that you will not have to re-invent the wheel whenever the same problem re-surfaces) Glossory * This section of the document and is not numbered. It provides an alphabetical list of technical terms used in this document.
Consistency	10	By "consistency" I mean that when ever you have made changes, you have made the changes throughout the entire document.  e.g. You will lose points if you have diagrams listing methods which no longer exist on the corresponding class or concept.

* Since these were graded as the requirements document, I'll only look to see that they have been kept up to date with any changes made.  (Unless there have been major changes) (See Consistency above).