CISC 498 Information Technology Project
School of Computing		Requirements Document

Overview

The purpose of a requirements document is to capture the needs of your sytsem's users and the context of the system's use. A requirements document is distinct from a user interface design document: requirements specify what needs the system must fulfil; user interface describes the mechanisms that are presented to a user.

Your requirements specification should be created in cooperation with your customer. You should interview the customer to find out the details of his/her problem, to find out how the problem is currently solved, and to understand shortcomings in the problem. Low-fidelity prototypes can be particularly helpful in eliciting requirements since they give the customer something to react to. Requirements elicitation is iterative; you should not expect to fully understand the customer's requirements from a single interview. Furthermore, you should expect your understanding of the requirements to evolve as you proceed to later phases of the project.

The following is an outline of the expected contents of a requirements document and presentation. Good example presentations from past years can be found below.

Structure

Your requirements document should contain the following sections:

Introduction	Give a high-level description of the problem that your software is meant to solve.
User Group	Describe the people who will be using the system. What is their level of technical sophistication? Are they frequent or infrequent computer users? What other kinds of software packages do they use? Might users have special needs (e.g., physical, mental disability)?
Context of Operation	Describe the location of use. Is it busy? Noisy? Are the users free to work for large blocks of time, or are they constantly being interrupted? Is it an office environment? A shop floor? Outdoors? Do users work from home as well as the office? Are the users' workspaces private? What kind of computers and network connections are there?
Current Processes	How do the users currently solve their problem? Describe the full process, not just parts that have software support. Use English text as well as supporting diagrams - screen shots of software, photographs of users performing their work (if helpful and appropriate), formal description of processes using activity diagrams, use case diagrams and/or statechart diagrams. Adapt your presentation to best suit the process you are describing.
Roles	List and describe the roles users might take on while interacting with the system. E.g., WebCT has roles of student, designer, TA and administrator.
Functional Requirements	Provide a prioritized list of functional requirements (see below for more information.)
Non-Functional Requirements	Provide a prioritized list of non-functional requirements (see below for more information.)
Glossary	Provide a glossary of domain-specific terms used in this document.

Functional Requirements

Functional requirements list the functions that the software system should provide in order to meet users' needs. Normally, functional requirements do not specify the user interface mechanisms by which these functions are achieved or the algorithms used to implement them. (Exceptions could include situations where a regulator requires a particular user interface style or particular hardware environment.)

Requirements are prioritized using the following scale:

• Critical: The requirement must be met in order for the system to be acceptable for production deployment
• Important: Failing to meet this requirement would significantly impact the usefulness of the system, but it is not essential. Failure to meet several "important" requirements may render the system unusable.
• Optional: Users would appreciate it if this requirement were met, but the system will still be useful if the requirement is not satisfied.

Functional requirements should be formatted as a table based on the following template. If you wish, you may use several tables each addressing a set of related requirements. Example requirements for a photo-sharing site might include:

Id	Priority	Requirement	Description
R1	Critical	New users can create an account	Anyone accessing the photo sharing service over the Internet can create an account giving them privileges as a photo owner.
R2	Critical	Photo owners can upload photographs to the site	People signed in as a photo owner can upload photographs to the site. Users are restricted to 1 MB of photo data uploaded per day.
R3	Important	Photo owners can sort photos	Photo owners can easily change the order in which photos appear on their site.
R4	Optional	Photo owners can remove red-eye from photographs	Photo owners can easily modify photos where the subject has "red eyes" so that the red eyes are muted to a less noticeable colour.

It is not uncommon for systems to have hundreds of functional requirements. You should expect to list 30-40 of your system's more crucial requirements.

Non-Functional Requirements

List requirements that address quality attributes that are important to this project. Examples of quality attributes that may be important include security, availability, usability, performance, maintainability and accessibility. Consult your notes from CISC 322 and CISC 327 for more information on quality attributes.

Discuss any technological requirements related to this project. Are there specific hardware or software requirements?

Examples

Here is a high-quality example presentation for the Requirements phase. (Used with permission.)

Generic Example Requirements (2007)                 CSL Team Requirements (2008)