Software Requirements
Specification
for
HOSTEL ROOM ALLOCATION
AND MAINTENANCE SYSTEM
Version: 1.0
Prepared by
Group Number: 19
Mohammed Ismail C B180437CS
Fadi Noushad P B180492CS
Muhammed Shifan P B180501CS
Abid Ali Karuvally Pathikkal B180466CS
Indrajith T S B180486CS
Instructor: Dr. Abdul Nazeer K A
Course: Database Management System
Date: 19-10-2020
1
TABLE OF
1 INTRODUCTION 3
1.1 DOCUMENT PURPOSE 3
1.2 PRODUCT SCOPE 3
1.3 OBJECTIVE 4
1.4 DOCUMENT CONVENTIONS 4
2 OVERALL DESCRIPTION 5
2.1 PROJECT OVERVIEW 5
2.2 PRODUCT FUNCTIONALITY 5
3 USE CASE MODEL 6
3.1 APPOINT MANAGER 6
3.2 REMOVE MANAGER 6
3.3 VIEW STUDENTS 6
3.4 ALLOT STUDENTS 7
3.5 VACATE ROOMS 7
3.6 EDIT RECORDS OF STUDENTS 8
3.7 SUBMISSION OF APPLICATION 8
3.8 VIEWING OF NOTICE BOARD 8
3.9 SUBMISSION OF VACATING FORM 9
4 SYSTEM REQUIREMENT SPECIFICATION 9
4.1 FUNCTIONAL SYSTEM REQUIREMENT 9
4.1.1 ADMINISTRATOR MODULE 9
4.1.2 HOSTEL MANAGER MODULE 10
4.1.3 STUDENT MODULE 10
4.1.4 APPLICATION MODULE 10
4.2 NON FUNCTIONAL SYSTEM REQUIREMENTS 10
4.2.1 PERFORMANCE REQUIREMENTS 10
4.2.2 SAFETY REQUIREMENTS 11
4.2.3 SECURITY REQUIREMENTS 11
4.2.4 SOFTWARE QUALITY ATTRIBUTES 11
5 HARDWARE REQUIREMENT 12
2
1. Introduction
1.1 Document Purpose
The Software Requirements Specification (SRS) provides a complete description
of the requirements needed for the Hostel Management System (HMS) Project. It
provides an understanding into the framework of the Hostel Management System.
This SRS is the basic foundation for the project. It is used by the project team for
the future stages of the project.
Also the end users can know whether this project is going to build a system that
fulfills their requirements.
1.2 Product Scope
The Hostel Management System software will automate the current working of
the hostels in NITC. It allows the students to enrol and reserve their rooms. The
hostel administrators can allot rooms to the eligible students. The students can
inform the hostel authorities about any complaints regarding the [Link] end
users for the system are hostel administrators and [Link] administrators can
have access to all
3
system functionalities without any [Link] students will access the system
with limited restriction. To keep restrictions for different end user levels, HMS will
create different login functions.
1.3 Objective
The main objective of the HMS is to simplify the day to day processes of the
[Link] reduces data redundancy and human error to some [Link] software
can provide a solution for the large amount of file handling happening in the
[Link], easiness of using and most importantly the efficiency of
information retrieval are some benefits that the project team puts forward with this
system. The system will be
user appropriate, easy to use and have an overall end user high subjective
satisfaction.
1.4 Document Conventions
The document is prepared using Google docs and has used the font type 'Arial'.
The fixed font size that has been used to type this document is 14pt with 1.5 line
spacing. It has used the bold property to set the headings of the document.
Standard IEEE template is the template used to organize the appearance of the
document and its flow.
4
2. Overall Description
2.1 Project Overview
Hostel Management System is a web application which mainly aims for
automating the hostel room allocation and also provides other features such as
informing hostel authorities about any complaints. Currently our students are
filling up forms and submitting in the respective hostel offices which involves a
lot of paperwork and is less efficient.
2.2 Product Functionality
The Web Application has two main parts :
1. Administrators.
2. Hostel Managers.
3. Students.
Students can select their room from the allocated hostel for each batch and the
hostel Manager will verify and approve their request. Hostel managers are
appointed by the Administrator.
5
3. Use Case Model
3.1 Appoint Manager
Brief description
This use case demonstrates the appointment of a hostel manager
Precondition
The appointed manager should not be in charge of any other hostel.
End-User
Administrator
3.2 Remove Manager
Brief description
This use case deals with removing a previously appointed manager.
Precondition
The manager that is being removed should be previously appointed.
End-user
Administrator
3.3 View Students
Brief description
This use case show that the End-User can view all the allotted students
6
Precondition
No specific precondition
End-User
Administrator
3.4 Allot students
Brief description
This use case deals with the allotment of students to different hostels as
specified by the end-user.
Precondition
Students should be of that specific Institute
End-User
Hostel Manager
3.5 Vacate rooms
Brief description
This use case deals with vacating the students from the hostel as
specified by the end-user.
Precondition
Students should be initially allocated in any one of the hostels.
End-User
Administrator
7
3.6 Edit Records of student
Brief description
This use case deals with the provision to edit and modify the details of
students.
Precondition
Students should be initially allocated in any one of the hostels.
End-User
Administrator
3.7 Submission of application
Brief description
This use case deals with the provision that allows the end-user to
submit the hostel allocation application.
Precondition
Students should be initially allocated in any one of the hostels.
End-User
User
3.8 Viewing of Notice Board
Brief description
This use case deals with the provision that allows the user to view the
notice board of the corresponding hostel.
Precondition
Students should be initially allocated in the respective hostel.
8
End-User
User
3.9 Submission of Vacating form
Brief description
This use case deals with the provision that allows users to submit the
Vacating form.
Precondition
Students should be initially allocated in any one of the hostels.
End-User
User
4. System Requirement Specification
4.1 Functional System Requirement
This section gives the functional requirements that are applicable to the HMS.
These are sub modules in this phase.
4.1.1 Administrator module:
The administrator can:
1. Appoint the Hostel Manager
[Link] a Hostel Manager.
9
[Link] the details of the student.
4.1.2 Hostel Manager module:
The Hostel Manager can :
1. Allot different students to the different hostels.
2. Vacate the students from the hostels.
3. Edit the details of the students & modify the student records.
4.1.3 Student module:
The options given to the student are:
1. Submission of the application form.
2. Viewing the notice board.
3. Submission of the vacating form.
4.1.4 Application module:
This section provides an application form which can be filled by the
students and can take a print out. It is submitted to the hostel
authorities which will be verified by them and allot rooms.
4.2 Non-Functional System Requirements:
4.2.1 Performance Requirements
Some performance requirements needed are listed below:
10
● The database should be capable of storing around more than 6000
records.
● The software should support multiple users at a time.
4.2.2 Safety Requirements
There are chances of crashes in a database at any time due to malware
attacks or system failure. So it is necessary to backup the database.
4.2.3 Security Requirements
Some of the factors that are identified to protect the software from accidental
or malicious access, use, modification, destruction, or disclosure are described
below.
1. Assign certain functions to different modules
2. Restrict communications between some areas of the program
3. Check data integrity for critical variables
4. Later version of the software will incorporate encryption
5. Techniques in the user/license authentication process.
6. Keep specific log or history data sets.
4.2.4 Software Quality Attributes
● Less human error.
● Strength and strain of manual labour can be reduced.
11
● High security.
● Data redundancy can be avoided to some extent.
● Data consistency.
● Easy to handle.
● Easy data updating.
● Easy record keeping.
5. Hardware Requirements
● Processor : 1GHz
● RAM : 512 MB
● Storage: 1 GB
12