CMPS183, Fall 2011, Section 01: Requirements - Template

Title Page:

Project Name

Group Name


Change Record:

Date Version Changes/Additions Responsible Person


For every modification to this document (including the first time it was handed in), an entry must be made in this field. This way, others reading the document can tell what modifications have been made, and when. Document modifications must be indicated within the document using some form of highlighting, such as change bars.

Table of Contents:

A listing of the contents of the document. It must be detailed enough to show the organization of requirements in the requirements specification section.


A high-level overview of the Web application you are developing. It should describe the project, as well as its purpose. This section provides the reader with a broad understanding of the project, which is then filled-in by the more detailed requirements in later sections.

Reference Documents:

Documents and Web sites that are useful in understanding the current document. For example, if you're developing a Web application for a specific organization, list its current Web site. Provide full bibliographic citations. For Web sites, it is not sufficient to just provide its URL - you must also give the title of the site, and a brief description of its contents is also necessary.

Classes of Users:

A list enumerating all of the possible classes of users of the system, along with a brief description of each kind of user. For example: "Volunteer administrators: these are members of the organization who have volunteered to perform mailing list administration. These people are expected to be geographically distributed, and be generally familiar with the use of computers and the Web."


Definitions of important and specialized terms and acronyms used throughout the remainer of the specification.

Scenarios Document Feedback:

This section has two parts:

1. A printout of an email message from your project customer stating:

"I have read the project scenarios document produced by {your team name} and have discussed its contents with them. I am satisfied that the team understands the problem well enough to proceed with writing a detailed requirements document."

2. A written summary of any changes in understanding or functionality that resulted from reviewing the project scenarios document with your customer. This might involve changes in functionality, improved understanding of the classes of users of the system and their respective needs, expansions or reductions in scope, new content that needs to appear on the site, and additions to the application's architecture, such as additional integration with other systems.


A detailed specification of the requirements for the Web application you are developing. Requirements need to be organized into meaningful groupings. A brief introduction to the organization of the requirements, at the beginning of the section, might be useful. When requirements apply only to specific classes of users, this should be explicitly stated.

Requirements specification are often (but not always) written as "musts" or "shalls". For example, "the system must provide a mechanism for immediately exiting the system, without data loss."

Refined Paper Prototype/Storyboard:

Revised versions of your paper prototype and/or storyboard produced in the scenarios document. The revised figures should clearly indicate what changes have been made, such as by highlighting these changes in a different color, or having a page that describes the changes in text.