1.

Introduction
This section gives a scope description and overview of everything included in this SRS
document. Also, the purpose for this document is described and a list of abbreviations
and definitions is provided.

1.1.Purpose
The purpose of this Software Requirements Specifications (SRS) is to fully document
the specifications and requirements for the Online Hostel Management System. The
audience of this SRS will be the clients who want the software to be built and the
technical professionals developing the software.

1.2.Scope
The objective of this project is to create and implement a website that will be used to
get the information from the students and then storing the data for future use.The
current system is a paper based system. It is too slow and cannot provide updated list
of room allotment to students within a reasonable timeframe. The intentions of the
system are to overcome the loopholes in the existing system and increase the number
of students that can be treated accurately.

1.3.Definitions, Acronyms, and Abbreviations

Term Definition

User Someone who interacts with the mobile phone application

Admin/Administrator System administrator who is given specific permission for

managing and controlling the system

1.4.References
The following material was used in creating this document: IEEE Std 830-1998, IEEE
Recommended Practice for Software Requirements Specifications.

1.5.Overview
The rest of the SRS is organized as follows:
Section 2 is an overall description of the project.
Section 3 cites the specific requirements
2. The Overall Description
This Hostel Management System is a self contained system that manages activities of
the hostel as student information, room allotment reports, mess information, staff
details and payment options.

2.1.Product Perspective
This product is unique as the offline system is now being held up online for easy
access and maintenance of information and schedule.
The online Hostel Management system will interact with the database, which records
the number of rooms available, student details and payment details.

Online Hostel Management

System Hostel Database

2.1.1. System Interfaces:

The system will interface with the following two systems:
1. A payment processing system: The system will access the credit
card/debit card through the payment processing system via its web services
API.
2. The Hostel Database: The system will interact with the database to get all
the information related to students who are allotted rooms and the availability
of rooms.

2.1.2. Interfaces:
The system will provide students and warden the ability to access the Online
Hospital System via the Internet. There will be two different user interfaces that
will accompany this website: one will be the common users(students) and other
will be the administrators.

Users will be allowed to search room availability in database without having

to login, however, they must login in order to perform any other action. These
other action will include after allotment formalities, payment, mess details using
their online account.
Administrators will be required to login at all times to access the site and to
check the status.

2.1.3. Hardware Interfaces:

There are no special hardware interface requirements.
 2.1.4. Software Interfaces:
There are no special software interface requirements.

2.1.5. Communication Interfaces:

There are no special communication interfaces requirements.

2.1.6. Memory Constraints

There is no memory constraints for the above system.

2.1.7. Operations
The different operations of user are:-
1. Sign up
2. LogIn.
3. Search for Room Availabilty
4. Allotment Process
5. Mess Details Report

2.1.8. Site Adaption Requirements

There are no special communication Site Adaption Requirements only a device
with working internet is required.

2.2.Product Functions
The following list of function descriptions explains the major features of the Online
Hospital Management system.

2.2.1. Sign up
The sign up function shall allow users to create secure accounts. The account
will track the users name, permanent address, phone number, username, user
id, branch and password.

2.2.2. Login
The login function shall allow users to use already created account. Users can
update their attributes as well.

2.2.3. Search for Room Availability

In user search for room availability function users can check the room
availability in Hostel .

2.2.4. Allotment Process

The allotment function shall offer users to go for payment after the room is
allotted to them by their respective accounts giving their information to
database.

2.2.5. Mess Details Report

The mess details report function shall allow the users to see their standard
mess bill reports and they can view their monthly mess bill online as well.
 2.3.User Characteristics
Users of the website must know how to access a computer and how to navigate in a
website.

2.4.Constraints
The constraints on the services and functions of the system are as follows.
The software product must confirm to disclaimer policy.

2.5.Assumptions and Dependencies

Since the Online Hospital Management system is only accessible through the
Internet, it is assumed that the end user has a connection to the Internet. It is also
assumed that the user has a web browser able to display the website.

2.6.Apportioning of Requirements
There are no requirements that may be delayed until future versions of the system.

3. Specific requirements
This section contains all of the functional and quality requirements of the system. It gives a
detailed description of the system and all its features.

3.1.External Interface
This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication
interfaces and provides basic prototypes of the user interface.

3.2.Functional Requirements

3.2.1. Stimulus: Click "Sign up" Button

1. The system shall allow a non-registered user to create a secure account.
2. The system shall require the following information from the user: Name,
Address, phone number, branch, user id.
3. The system shall ask the user for a username and password.
4. The system shall confirm the username and password are acceptable.
5. The system shall store the information in the database.

3.2.2. Stimulus: Click "Login" Button

1. The system shall allow a registered user to log-in to their account.
2. The system shall require a username and password from the user.
3. The system will verify the username and password, and the user will be
considered logged-in.

3.2.3. Stimulus: Click "Search Room Availability" Button

1. The system will get information about the room availability from the
database.
 2. The Availability Report should be seen to the user without mandatory login.

3.2.4. Stimulus: Click "Allotment" Button

1. The system shall allow a registered and logged-in user to make payment and
update details.
2. It should enter all the details to the database with the allotted room details
too.

3.2.5. Stimulus: Click "Mess Details Report Generation" Button

1. The system shall allow a registered and logged-in user to request for their
mess bill reports.
2. The system shall give complete information about mess reports.
3. If reports will be displayed to the screen.

3.4.Logical Structure of the Data

The two sections below show the different types of information used by various
functions and the overall data model, respectively. SRS for BSU Online Bookstore

3.4.1. Types of Information Used

The types of information used by various functions of the website:

Function Types of Information Used

Account Signup User information (name, mailing

address, residential address, number,
and user name, and password)

Account login User information (user name, and

password)

Room Allotment Student information (name, address,

number, branch, user id), Alloted
room information (room number)

3.5.Design Constraints
The Online Hostel Management System shall conform to the following design
constraints:
Able to support PC, Mac platforms.
System logs out user after a ten minute inactivity period.
System supports all web browsers.

3.5.1. Standards Compliance

The Online Hostel Management System will follow existing standards and
regulations, which are stated in the disclaimer policy.
3.6.Software System Attributes

3.6.1. Reliability
The average time to failure shall be 30 days. In the event that a server does
crash, a backup server will be up and running within the hour.

3.6.2. Availability
The Online Hostel Management System shall be available to users 24 hours a
day, 7 days a week, with the exception of being down for maintenance no more
than one hour a week. If the system crashes, it should be back up within one
hour.

3.6.3. Security
Users will be able to access only their own personal information and not that of
other users. Purchases will be handled through a secure server to ensure the
protection of users credit card and personal information.

3.6.4. Maintainability
Any updates or defect fixes shall be able to be made on server-side computers
only without any patches required by the user.

3.6.5. Portability
Nothing required.