Room Reservation System Documentation: Release 1.0.0
Room Reservation System Documentation: Release 1.0.0
Documentation
Release 1.0.0
1 Introduction 1
1.1 System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 User Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 System Administrators Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Technical Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Overall Description 17
2.1 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Project Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 User Classes and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Operating Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Search 19
i
ii
CHAPTER 1
Introduction
The DCS Room Reservation Service (RRS) is an online platform for reserving rooms in the Department
of Computer Science (DCS). It aims to provide an efficient and convenient way of reserving rooms for
all the individuals involved. By hosting the service online, the entire flow of the reservation system will
not be greatly affected by the absence of important individuals. (Example: Suppose that the building
administrator or the Department Chair of the building, whose approval is needed for the room reservation,
is out of the country then they can still fulfil their duties online.)
It also aims to to prevent issues caused by human error can easily be avoided by the RRS, like preventing
conflicting reservations.
This project also aims to be extended to a bigger scope being deployed throughout the College of Engi-
neering and providing a uniform reservation system for the entire college.
Contents:
Add User
Edit User
1
Room Reservation System Documentation, Release 1.0.0
This is a medium priority feature which allows the system administrators or users to edit user infor-
mation.
Step User Input Response
1 System Admin RRS shows Edit User Form for Admins
opens Edit User
Form
2 System Admin RRS asks for confirmation and informs that the System Admin that t
Stimulus/Response Sequences
presses Delete cannot be undone.
User
3 System Admin RRS marks that user deleted and can no longer be used. Also deletes
confirms future room reservations that the user has made. Note: User account
since past reservations are associated with the user.
Search Users
2 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
Add Room
Edit Room
Remove Room
Search Room
1.2.1 Introduction
This user manual is the how-to guide for guests, student organizations, advisers, faculty, and department chairpersons.
4 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
6 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
1.3.1 Introduction
The system admin has the ability to make new users, edit their information and to delete user accounts.
2. Provide the necessary information along with choosing the type of user.
3. Submit information to create new user.
2. Provide the necessary information along with choosing the type of user.
3. Submit information to create new room.
8 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
1.4.1 Introduction
The room reservation system is composed of different modules, classes, and tools for the software itself to become
fully functional. Its components, their relationships, and their features are described in this portion as well as the
dependencies used for optimal end-product utilization.
The database schema of the software presents the relationships between the classes (relations) involved in the systems
backend part. It also includes the fields of each classes and how they are used to interact with other classes.
The following figures show the initial and future database schemas of the room reservation system.
Figure 1 basically shows the allowable instances of users to reserve a room. It also shows how a reservation is
created and how it is approved by the Building Administrator and later by the Department Chair. For a reservation
to be instantiated, the reservation class needs the list of pre-added rooms, events, and schedules by the users. System
Administrator creates the user profiles according to their types and hierarchy. This is the current database schema of
10 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
1.4.3 Modules
Current:
users
forms.py
user registration form
views.py
add user(s)
12 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
view user(s)
models.py
user attributes reflected in database
urls.py
reference for user navigation on the website
reservations
forms.py
reservation form
views.py
add reservation(s)
view reservation(s)
show reservation(s) status
pending
approved
disapproved
show reservation(s) timestamp
change reservation(s) status
approved
disapproved
models.py
reservation attributes reflected in database
urls.py
reference for user navigation on the website
rooms
forms.py
room (registration) form
views.py
add room(s)
models.py
room attribute reflected in database
urls.py
reference for user navigation on the website
To follow:
users
edit user settings
delete user
reservations
Adviser for organization(s)
filter reservations
reservation history
rooms
delete room(s)
1.4.4 Dependencies
Database
Django-crispy-forms
A Django application that let developers easily customize forms using a CSS framework without writing custom
form templates
It provides a (|crispy) filter and ({%crispy%}) tag that controls the rendering behavior of Django forms.
Django-braces
1.5 Testing
Use Case Testing is a functional black box testing technique that helps testers to identify test scenarios that exercise
the whole system on each transaction basis from start to finish.
The RRS has the following use cases:
login
home page/dashboard
logout
addition of users
addition of rooms
viewing of rooms
addition of reservations
viewing of reservations
14 Chapter 1. Introduction
Room Reservation System Documentation, Release 1.0.0
approval of reservations
status of reservation
Test Tools
Selenium WebDriver
The primary new feature in Selenium 2.0 is the integration of the WebDriver API. WebDriver is designed to provide
a simpler, more concise programming interface in addition to addressing some limitations in the Selenium-RC API.
Selenium-WebDriver was developed to better support dynamic web pages where elements of a page may change
without the page itself being reloaded. WebDrivers goal is to supply a well-designed object-oriented API that provides
improved support for modern advanced web-app testing problems.
Test Method
The alpha version of the RRS was deployed in Heroku and can be seen here:
http://r2e2.herokuapp.com/users/login
Test Method
RRS was officially introduced to potential users using Social Media accounts (i.e Facebook). They were
asked to try the system for the first time using accounts the System Admin had initially created. The
following instructions were given to the users:
1. Visit this page: http://r2e2.herokuapp.com/users/login
2. Login using: Username: <username>, PW: <password>
3. Click reserve rooms.
4. Fill up the form.
5. Wait for your request to be approved.
After trying the system, the users were asked to answer a survey powered by GoogleDocs, through this
link: http://bit.ly/r2e2_survey
A total of 15 users were able to use the system properly and were able to reserve rooms. The following
table displays the questions asked in the survey and the average score of the participants. A score of 1
means the user Agrees with the statement, and a score of 5 means the user Disagrees with the statement.
1.5. Testing 15
Room Reservation System Documentation, Release 1.0.0
16 Chapter 1. Introduction
CHAPTER 2
Overall Description
There are no information systems that are currently being implemented and the RRS is a project will be replacing the
reservation system of the DCS, which is currently being implemented manually by people, building admins.
The RRS will aim to be self-contained, meaning that it will have no dependencies to other existing information system.
It is expected that more functionalities will be included, or that this system might be extended. The RRS will be
implemented and tested in DCS however, if successful, it will be done be deployed in the entire college.
The RRS will have two general roles, the users and the administrators, and the basic functionalities that each of these
roles have are shown below.
Feature Description
View Room Users can check the availability of a particular room for some chosen date. Admins can
Availability check the availability of a particular room for some chosen date along with all the names
of the events that will occur.
Request for Room Users can make requests for reservations where they provide necessary information
Reservation including the date and time that they want to use the room.
Track Room Users can check the status of their requests to know whether or not their requests have
Reservation been approved.
Requests
Manage Users Admins can create and delete the users, and also edit their privileges.
Manage Rooms Admins can create, edit, and delete the rooms that are available for reservation.
Approve / Admins can approve or disapprove room requests and also keep track of all approved
Disapprove Room room reservations.
Requests
Make Room Admins can reserve rooms without the need of making a request.
Reservations
These are the main functionalities that must be implemented. However, there are some functionalities that may be
implemented but are not as important as the ones listed above: a billing system for the fees and an activity approval
system.
17
Room Reservation System Documentation, Release 1.0.0
As mentioned in the Product Features, there are two main roles in the RRS, the users and the admins. The table below
described the specific roles.
Role Description
Student Or- An org is a type of user. For a request made by an org to be approved, it must be approved by
ganizations the orgs adviser, the building admin and also the Department Chair of the building.
Faculty A faculty is type of user. For a request made by a faculty, it must be approved by the building
admin and also the Department Chair. Faculties generally have a higher priority over orgs and
they can also have roles as an advisor for multiple orgs.
Guests A guest is a temporary user that is given to individuals or organisations that are from outside UP.
For a request made by a guest, it must be approved by the building admin and the Department
Chair of the building. Guests will have a special tag on their requests to indicate and remind the
building admin and the Department Chair that these are special users.
Advisor An advisor approves or disapproves requests made by the orgs they handle.
Building Ad- Building administrators have the ability manage the rooms of their respective buildings and all
ministrators requests for reservations for rooms in their building has to be approved by them.
Department The Department Chair or the dean of a building has the final say on whether or not an event will
Chair be approved. The dean is also considered to be a special type of faculty.
System Ad- System administrators has the ability to manage the users. Building administrators will usually
ministrators be also system administrators.
Search
search
19