CS 49000-020 Software Testing
Fall 2009

(Interim Report 1) Requirements Document Guidelines: Format and Grading Criteria
Note: There is lots of material on the internet on requirements documentation using UML.
Please follow the section outline below and draw the diagrams as many as you can.
Click here for some help.

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 spevified deadline 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.  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.   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 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.

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. The format of all diagrams must be as in UML. Be sure to clearly understand what a concept is. 
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.  [Include this section only if you have the time.]