Rooms Project Requirements

Introduction

• Purpose : The purpose of this program is to provide a way for people in the computer sciences department to reserve rooms for their use.
• Document Conventions and Definitions :
  1. Terms used in this document are defined in the companion glossary document.
• Users : The users of this program are people in the CS department (anybody with a CS login).
• References :
  1. This is a group project for computer science 706, Fall 2001.
  2. Email: rooms_cs706@cs.wisc.edu
  3. Group Web Page: http://www.cs.wisc.edu/~minyi/room.html
  4. Group Members: Brian Bowers (blbowers@cs.wisc.edu), Andrew Palmer (palmeran@biostat.wisc.edu), Hongwei Zhu (hzhu@cs.wisc.edu), Ming Li (mingl@cs.wisc.edu), Minyi Xu (minyi@cs.wisc.edu), Naijun Zhou (naijun@cs.wisc.edu), Keith Noto (noto@cs.wisc.edu)
  5. Group Mentors: Will Benton (willb@cs.wisc.edu), Jerry Tutsch
  6. Class Professor: Somesh Jha (jha@cs.wisc.edu)

Program Requirements

• This program will provide
  1. A web-based (HTML) user interface. This interface will be accessable via (at least) Lynx and Netscape browsers. The web-based interface will not include frames. The web-based interface will conform to W3C's Web Content Accessibility Guidelines 1.0 (link as of October 8, 2001). (User(s): All Users)
  2. An interface with the colloq program. (User(s): N/A)
• Viewing
  1. View the current room reservations by {room/time/contact/purpose} (time includes date). (User(s) Visitors)
  2. View the attributes of a room (i.e. seating capacity) (User(s): AcctUsers)
• Reservation
  1. Reserve a given room (identified by room number) for a specified time range. Each reservation must be associated with a contact (whomever makes the reservation) and a purpose (a brief piece of text). (User(s): AcctUsers)
  2. Reserve a given room (identified by room number) for a specified recurring time range (i.e. weekly), and this recurrence for a specified time range (i.e. the next 6 weeks). (User(s): AcctUsers)
  3. Edit a given reservation that they have made (location, date/time, purpose, recurrence). If a reservation is a recurring reservation, the user will be able to edit the recurrence itself, as opposed to editing each instance of the reservation. Editing a recurrence includes the ability to cancel single instances of reservations in a recurring pattern of reservations. (User(s): AcctUsers)
  4. Cancel a reservation that they have made. (User(s): AcctUsers)
• Administration
  1. Cancel a reservation that any user has made, and send an email to that informing that user of the situation. (User(s): Room Czar)
  2. Edit a given reservation that any user has made (location, date/time, purpose, recurrence) and inform the user of the situation. User(s): Room Czar)
  3. Add new rooms to the system. (User(s): Room Czar)
  4. Remove existing rooms from the system. (User(s): Room Czar)
  5. Edit the attributes of an existing room. (User(s): Room Czar)
• Security
  1. Provide authentication for users. (User(s): AcctUsers)
  2. Provide a way to cancel a reservation transaction. Between defining and committing a room reservation, an acctuser will be able to cancel the reservation without needing to re-authenticate herself/himself before making new reservations. (User(s): AcctUsers)
  3. Provide a way to retrieve a forgotten password. (User(s): AcctUsers)
  4. Correctly handle the case where two users reserve the same room for the same time. (User(s): N/A)

Secondary Requirements

• This program will provide
  1. A Java Applet interface (highly desired) (User(s): All users)
  2. A way to easily inforce a reservation validation policy. That is, if it is decided that reservations should be removed/reviewed each semester, or that long-term reservations be allowed to last forever, a policy can be agreed upon, and it is possible to set the rooms project up to enforce it.
• Reservation
  1. The ability to express interest in a reservation, without committing to the reservation (to "pencil-in" a reservation). (User(s): AcctUsers)
  2. The ability to search for rooms based on room attributes and availability. It should be easy to see a list of potential reservations by entering time and room attribute constraints. (User(s): AcctUsers)
  3. The ability to search for reservations with text matching the text in the reservation's purpose.
  4. The ability to create recurring reservations that recurr up until a fixed time: The end of the current semester, the end of the current summer session.
  5. The ability to enforce a policy which limits reservations to within a certain time period. For instance, no reservation can be made for later than one year after the time the reservation is made (calendar or academic year).
  6. A record of a "reason" (text) associated with each reservation cancellation.
  7. For each reservation, A list of alternate contacts, separate from the person who makes the reservation, who are the people to be contacted to request that the reservation be changed or revoked.
  8. A list of world wide web URLs associated with each reservation. (For example, these can be used to link users to home pages associated with the event for which the room is reserved.)

Documentation Requirements (these may be integrated into the user interface)

• First-level help
  1. Overview of which functionality the program has, and how to accomplish each.
• Low-level help
  1. Explanation of each part of the user interface.