HOSTELMANAGEMENTSYSTEM

HOSTEL MANAGEMENT SYSTEM(HMS)

Software Requirements Specification

Version 1.0
03-02-2012
PRATHIBHA.T
Lead Software Engineer

SoftwareRequirementsSpecification

Pagei

HOSTELMANAGEMENTSYSTEM

Table of Contents

1. INTRODUCTION....................................................................................................................................................1
1.1 . PURPOSE............................................................................................................................................................1
1.2 . SCOPE..................................................................................................................................................................1
1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS...............................................................................................1
1.4 REFERENCES.........................................................................................................................................................2
1.5 OVERVIEW.............................................................................................................................................................2
2.1 PRODUCT PERSPECTIVE........................................................................................................................................3
2.2 PRODUCT FUNCTIONS...........................................................................................................................................3
This software includes Details of hostel such as -...............................................................................................3
2.4 GENERAL CONSTRAINTS.......................................................................................................................................4
TIME CONSTRAINT.............................................................................................................................................4
2.5 ASSUMPTIONS AND DEPENDENCIES.....................................................................................................................4
THE FOLLOWING DETAILS ANY HIGH LEVEL ASSUMPTIONS REGARDING THE PROPOSED
CHANGES INCLUDING ANY RESTRICTIONS REGARDING SCOPE OF THE PROJECT. IT ALSO
DETAILS ANY FUNCTIONALITY LIMITATIONS OR ENVIRONMENT OR DESIGN LIMITATION
THAT MAY IMPACT THE DESIGN OR DELIVERY OF THE CHANGE. DETAILS ARE ALSO
PROVIDED ON ANY ASSUMPTIONS THAT MAY IMPACT THE REQUESTOR/CUSTOMER/USER ......5
3. SPECIFIC REQUIREMENTS...............................................................................................................................5
3.1 EXTERNAL INTERFACE REQUIREMENTS................................................................................................................5
3.1.1 User Interfaces.............................................................................................................................................5
3.1.2 Hardware Interfaces.....................................................................................................................................5
3.1.3 Software Interfaces.......................................................................................................................................5
3.1.4 Communications Interfaces..........................................................................................................................6
3.2 FUNCTIONAL REQUIREMENTS...............................................................................................................................6
3.2.1 <Functional Requirement or Feature #1>..................................................................................................6
3.2.2 <Functional Requirement or Feature #2>..................................................................................................6
3.3 USE CASES............................................................................................................................................................6
3.3.1 Use Case #1..................................................................................................................................................6
3.3.2 Use Case #2..................................................................................................................................................6
3.4 CLASSES / OBJECTS..............................................................................................................................................6
3.4.1 <Class / Object #1>.....................................................................................................................................6
3.4.2 <Class / Object #2>.....................................................................................................................................6
3.5 NON-FUNCTIONAL REQUIREMENTS......................................................................................................................6
3.6 INVERSE REQUIREMENTS......................................................................................................................................8
3.7 DESIGN CONSTRAINTS..........................................................................................................................................8
3.8 LOGICAL DATABASE REQUIREMENTS...................................................................................................................8
3.9 OTHER REQUIREMENT..........................................................................................................................................8
4. ANALYSIS MODELS.................................................................................................................................................8
4.1 SEQUENCE DIAGRAMS..........................................................................................................................................8
4.3 DATA FLOW DIAGRAMS (DFD)............................................................................................................................8
4.3.1 SYMBOLS USED IN DFD..............................................................................................................................8

SoftwareRequirementsSpecification

Pageii

HOSTELMANAGEMENTSYSTEM

SoftwareRequirementsSpecification

Pageiii

HOSTELMANAGEMENTSYSTEM

1. Introduction
1.1 . Purpose
In this system, we can easily manage the hostel details, room details, student records, mess
expenditure, mess bill calculation, easy way of room allocation and hostel attendance.
The main feature of this project is easy to allocate for the student and also easy to calculate
mess bill.

1.2 . Scope
This particular project deals with the problems on managing a hostel and avoids the problems
which occur when carried manually.
Identification of the drawbacks of the existing system leads to the designing of computerized
system that will be compatible to the existing system with the system which is more user
friendly and more GUI oriented. We can improve the efficiency of the system, thus
overcome the drawbacks of the existing system.
The features of this software are
1. Hostel Information panel
2. Hostel Account panel
3. Student panel
4. Hostel Food panel

1.3. Definitions, Acronyms, and Abbreviations

HMS
User
Administrator
ID card

Hotel management system

The student who lived in the hostel.
The warden of the hostel who manage all the things.
The card issued by the hotel which contains the information of the
student.
Database
The records of every current and old students is saved here.
Account number The issued by the HMS when the new students becomes the part of
the hostel. This number is on the ID card of the student.
Mess status
It tells the mess information of the students.
Users profile It contain the students personal information. e.g.. his name, fathers
name, his full address etc.

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

1.4 References
[1]. DFD link from
http://nptel.iitm.ac.in/courses/Webcourse-contents/IIScBANG/System%20Analysis%20and%20Design/pdf/Lecture_Notes/LNm5.pdf
[2]. SRS material link from
http://www.kassoftindia.com/Product/GeniusAcademic/hostelmgt.htm
We take the material from the sites and follow the pattern you have given in the example.

1.5 Overview
Project statement
The hostel management needs to create the hostel management system (HMS) to
organize the rooms, mess, students record and the other information about the
students. how many students can live in a room, and the students of the hostel can
be recognized from their ID card number.

Registration flow

To take the membership of the hostel the students should tell the departments
name to the hostel management system. He/she should fill his/her personal
profile on the profile page. After this the warden issued ID # to him/her
Mess Flow

At the end of the month the hard copy of mess details issued to the students
room, which shows the detailed of his/her messes and all the dues of the mess
The student should pay the dues within 10 days after the issued of mess bill.
Room process flow

A room will be allocated when a student is registered in the hostel. The

allocation will be on the basis of the department, semester and the session of
the student. A room is only for the three students.
Database flow
When the new student is arrived then the administrator easily enter a new entry
in the database of the system. All the information about mess and other facilities is
updated easily. This database should save the record of all the current users and
old students.

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

2. General Description
The system is desired to handle all the activities of the students as well as the
administrative level. The system will have the ability to search the students information
about his/her room mess and all the other things. Once the current and previous record is
entered then the database will be updated for the new students automatically. This system is
for hostel so that the primary users of the system is administrative panel.

2.1 Product Perspective

Hostel management by manual way is tedious process, since it involves
work load and time consumption. In this system, we can easily manage the
hostel details, room details, student records, mess expenditure, mess bill
calculation, easy way of room allocation and hostel attendance.
The HMS is an independent standalone system. It is totally self contained.

2.2 Product Functions

This software includes Details of hostel such as
Building Information.
Room Information.
Student Information.
Room Allocation And Availability Management
Allot the room and provide a hostel ID number.
Keep track of Shifting and Exchange of rooms .
Displays the available rooms.
Attendance and Visitor Record
Records student's in and out attendance.
Store information about visitors.
Expense Calculation
Daily expense calculation.
Monthly expense calculation.
Mess Bill Calculation
Effective days calculation.
Rate per day calculation.
Total mess amount per student calculation.

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM
Income And Expenditure Calculation
Stock details (food, gas , milk etc).
Other expenses.

2.3 User Characteristics

The user must have basic knowledge of computer.
User must be aware of hostel management.
User must be able handle mess panel.

2.4 General Constraints

The system is desired to handle all the activities of the students as well as the administrative
level. The system will have the ability to search the students information about his/her room
mess and all the other things. Once the current and previous record is entered then the database
will be updated for the new students automatically. .
The constrains are the amount of the hostel dues and the mess dues that are calculated in the
system. These dues should be paid within 10 days. If anyone could not do the payment for some
reason the system will notify the name of the student.
o System will uses warden of the hostel.
o The Hostel id card is necessary to use mess.
o Time constraint
o GUI is only in English.

o Login and password is used for identification of user and there is no facility for guest.

2.5 Assumptions and Dependencies

The following details any high level assumptions regarding the proposed changes
including any restrictions regarding scope of the project. It also details any functionality
limitations or environment or design limitation that may impact the design or delivery of the
change. Details are also provided on any assumptions that may impact the
requestor/customer/user .

Area
Hostel Processes

Database
Administrator

SoftwareRequirementsSpecification

Descriptions
All other hostel related functionality and/or
process and logic the system executes to
manage the hostel user accounts will remain
the same as the process before automation.
The underlying database to be used for this
system is already in place as part of the
standard infrastructure.
Only the warden will administer the system.
All other hostel employees will only have
access permissions like any other users.
Page

HOSTELMANAGEMENTSYSTEM

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
o This software starts with a login form.
o There are many pop - up menus in the main form which are enabled only after
the proper login.
o Each pop - up menu contains sub menus which will enable easy interaction.
3.1.2 Hardware Interfaces
Processor
:
Process speed :
Memory
:
Hard drive
:
Keyboard
:
Mouse
:
3.1.3 Software Interfaces
Operating system
Development
Front End
Back End

Pentium IV
1.6 GHz
512MB
80
107keys
Microsoft
: Microsoft windows 2000,windows XP
: Netbeans 7.0.1
: Java
: MYSQL

3.1.4 Communications Interfaces

The only communication interface used here is a printer ,
which is used to print the monthly bill payments for the students.

3.2 Functional Requirements

This system contains 6 modules in it. They are given below :
1. Details of Rooms & Students.
2. Room Allocation & Availability.
3. Attendance calculation.
4. Total Expense calculation.
5. Mess bill calculation.
6. Mess income and expenditure calculation.
From the above 6 modules, we divide it into 3 parts and assign each part to each group
member. My modules are
Details of Rooms & Students.
Mess bill calculation.
3.2.1. Details of Rooms & Students
This module will display details such as Number of rooms
The capacity of each room
Total number of students in the hostel
SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM
Information about the hostel (Hostel name, Building information etc.)
3.2.2.Mess bill calculation
In this module, the mess item expenditure for each student in the hostel is
calculated for each month and the mess bill for each student in calculated and
displayed.
USE CASE DIAGRAM:
Use case diagram is a diagram that shows the interaction between user and
System to capture the users goals.

enter mess expenditure

calculate expenditure for veg

DBmanager
ADMINISTRATOR

calculate expenditure for non-veg

calculate mess expenditure details per day

per day

calculate mess expenditure details per month

mess bill calculation

acknowledgement for messbill

request for messbill report

display mess bill report

student

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

3.3 Use Cases

Use case diagram is a diagram that shows the interaction between user and system to
capture the users goals.
The use case diagram for the entire system is given below .

collect&store the student details

store the availability of hostel&room details

DBmanager
ADMINISTRATOR

generate & update the attendance details

calculate& generate report for mess expenditure ...per day

mess bill calculation

calculate& generate report for mess expenditure ...per month

Payment of messbill
request for mess bill report

display mess bill report

check and verify mess bill report

update the payment details

student

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

3.4 Classes / Objects

Class diagram is a collection of static elements such as classes and their
relationships connected as a graph to each other.
3.4.1 . Class Diagram :

3.5 Non-Functional Requirements

3.5.1 Performance
The system shall support up to 3 students per room.
3.5.2.Reliability
The two aspects are primary concerns of the reliability requirement:
System
The system should be fully operational at any given time. In case of faults, the
system should degenerate slowly and gracefully.
Content
Content reliability is an important issue. Not only the content should be
accurate and safe, it also has to be reliable.
3.5.3 Availability
The system shall be available 99.9% of the time.
SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM
3.5.4.Security
The system requires the user to identify by using an ID card number at the checkout
point.
The HMS shall have several types of access permissions. For instance, the warden is
recognized as the systems administrator, thus, the warden shall be able to perform any type
of activities on the system and both the users and student profiles. At the same time, the
other hostel staff members shall have restricted access to both the users and student profiles.
The public in general shall be restricted from accessing any user profile. However, they shall
be granted a read access on the student profile.
3.5.5. Maintainability
The system shall provide the capability to backup the database.
3.5.6.Portability
The HMS shall be flexible and adaptable due to future plans of expanding the system.

3.6 Inverse Requirements

3.7 Design Constraints
The Hostel Management System shall be a stand-alone system running in a Windows
environment. The system shall be developed using Java and MYSQL database.

3.8 Logical Database Requirements

The database is normalized up to third level . The failures of system during any database
access or any other operations can be handled by rollback to its previous state.

3.9 Other Requirement

Need a printer for providing ID card and bills.

4. Analysis Models
4.1 Sequence Diagrams
Sequence diagram shows an interaction arranged in a time sequence . it is an
alternate way to understand the overall flow of the control of the system program.

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

student

Administrator

DB manager

give details

enter student details

update

enter mess item & eexpenditure

details
update

calculate(total mess expenditure)

enter attedance details

update
request for mess bill expenditure

calculate(total mess item expenditure/total

no.of students
publish

pay the fees

mess fees details

enter the payment details

update

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

4.2 Data Flow Diagrams (DFD)

4.2.1 Symbols Used In DFD
PROCESS

A circle represents a process

Straight lines with incoming arrows are input data flows Straight lines with outgoing
arrows are output data flows Processes are given serial numbers for easy reference
Labels are assigned to Data flow. These aid documentation
EXTERNAL ENTITIES

A Rectangle represents an external entity . They either supply data or receive

data. They do not process data
DATA STORS

A Data Store is a repository of data . Data can be written into the data store and this is
depicted by an incoming arrow.
Data can be read from a data store and this is depicted by an outgoing arrow.
External entity cannot read or write to the data store. Two data stores cannot be connected by
SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM
a data flow
RULES OF DATA FLOW
Data can flow from
-external entity to process
-process to external entity
Context Diagram of Registration in Hostel

Context Diagramof Mess in Hostel

SoftwareRequirementsSpecification

Page

HOSTELMANAGEMENTSYSTEM

EXPANDED DFD FOR HOSTEL MESS MANAGEMENT

Students

Mess Secretary

Chief Warden

Update
daily rate

Payments

Itemized bills at
end of month

1
Billing
system

Unpaid
bills

Items used each day

Extras/Rebates
Expenses
Mess manager
No of meals(today +3)

Vendor
supplies

Vendors
Order nonperishable

Student
billingInformation +
bills
2
Stores
issues&
Control
system

Items to be
ssued(today
+2)

Menu(today +2)

Stores inventory

Orders
(perishable)

SoftwareRequirementsSpecification

Mess Manager

Items used
to day

Vendor data

Perishable order

Low stock
(today+2)

3
Perishable
ordering

Mess Secretary
Order data

Vegetables and perishable requisition

Vendor data
(perishable)

Page

HOSTELMANAGEMENTSYSTEM

EXPANDED DFD-BILLING SYSTEM

Payments

Itemized bills

Mess Secretary

1.2
Calculate
Students
bills

Extras/Rebates

Unpaid
bills

Bills

Chief warden
1.3
Reconcile
payments

Students
data
Students data

Daily rate average

(upto date)

No of meals
(today + 2)

1.4
Find noOf
meals to
cook

1.1
Calculate
Daily rate

Students data
Items rate data
Mess Manager

SoftwareRequirementsSpecification

Expenses data

Page