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	5	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	5	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 5 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 15 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 5 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 30 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 event 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 25 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. Glossory 5 This is section 6 of the document and is not numbered. It provides an alphabetical list of technical terms used in this document.