The Requirements Document
Deadline: Version 0.9 September13 and Version 1.0 20, 1999
  1. There will be one requirements document generated by each team.

    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. Note that this document goes beyond a simple textual description of the requirements. It also includes the outcome of your OO analysis of the requirements as stated by the sponsor. 

    3.  
  3. The approved document will serve as a contract between the sponsor and you. 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 Team, 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 numbered 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.

    Functional requirements definition: This is section 2 of the document. It lists the services to be provided by the system. The services should be formulated in terms of use-cases. Each use-case should be listed and explained in a separate numbered subsection. 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. Rank use cases (e.g. see Section 7.3 of Larman's text). Note that you are doing an OO analysis of REquirements. Show a conceptual model of the system to be built (see Figure 9.1 on page 88 of Larman's text). The format of all diagrams must be as in Larman's UML text.

    It is suggested that you organize section 2 into several subsections.

    Non-functional requirements: This is section 3 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 4 of the document and is not numbered. 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.