The Requirements Document
Deadline: Midnight September 29, 1997
 
  1. There will be one requirements document generated by each group.

    2.  
  2. The purpose of this document is to specify the requirements for the system to be built. This document will be provided to the customer for approval.

    3.  
  3. The approved document will serve as a contract between the customer and the developer. Any changes to the requirements, during the course of the project, will be reflected in this document. It is expected that the system will conform to the specifications in the most recent version of this document.

    4.  
  4. The document should be in HTML  and linked to the Group homepage by the deadline given above. 

    5.  
  5. Click here for a suggested format for the requirements document.
  
 BACK TO EVALUATION
 BACK TO CS406 HOMEPAGE

 
 
Suggested Format for the
Requirements Document
 
  1. General format: All text and graphics are contained within: width: 6", height: 9"; font size: 10pt or 11pt; font type: your choice (Times New Roman preferred); number all pages except the title page, starting with 2.

    2.  
  2. Title page: This 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.

    3.  
  3. Table of Contents:  This may require more than 1 page. 

    4.  
  4. Main body: The Table of Contents page is followed by the main body of the requirements document. The body is divided into the following sections.

    5. 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. 

    System models: This is section 2 of the document. It describes and shows the relationships amongst different components of the system you will build. 

    Functional requirements definition: This is section 3 of the document. It lists the services to be provide by the system. The services should be formulated in terms of use-cases. Each use-case should be listed and briefly explained in a separate numbered subsection. One or more use-case diagrams should be provided to help in the understanding of the relationships amongth the use-cases. The format for these diagrams must be as in Martins' UML text. 

    Non-functional requirements: This is section 4 of the document. Any constraints imposed on the system you will build are listed and explained here. In case you do not have any constraints, say so in this section; do not omit the section. 

    Glossory: This is section 5 of the document. It provides an alphabetical list of technical terms used in this document.  

    A separate format for recording any changes in the requirements document will be provided after the deadline for this document.