Hostel Management System

Project Documentation

Muhammad Ammar

IU16M2MB137

MCS(2016-2018)

Department of Computer Science & IT

The Islamia University of Bahawalpur

 ACKNOWLEDGEMENT
All praise is to ALLAH, who created the universe and appointed the man as His vicegerent. I offer my
humble thanks to ALLAH who blessed and enabled me to complete this dissertation in the
predetermined time frame. All respects for the Holly Prophet (Peace Be upon Him) who recognized us
to our creator.

No volume of words is enough to my deep and sincere gratitude to my project Supervisor

MsAfsahImtiazElahi, Asst. Professor, DCS & IT, The Islamia University of Bahawalpur, who has
been helpful me to explore this vast topic in an organized manner and provided me with all the ideas
on Hostel Management System. He encouragesme how to work towards a project.without his devoted
interest, valuable attention and continuous encouragement it is not possible for me to complete work in
time. He gave positive approach in every matter even in unfavorable and odd situations shaped
patience in me.
.
Most importantly, I would oblige a great depth of thankfulness to my loving parents for their prayers,
love, care and continuous encouragement. Their realistic love shows me right direction out of blue. I
must also thanks to all my family members and friends for their prayers and moral support which
enable me to achieve the desired destination.

Muhammad Ammar
 TABLE OF CONTENTS

Chapter 1 ................................................................................................................................1
Introduction............................................................................................................................1
1.1Purpose ............................................................................................................................1
1.2Scope ...............................................................................................................................1
1.3Overview .........................................................................................................................2
1.4The Overall Description ..................................................................................................2
1.5Product Perspective ........................................................................................................2
1.6Types of Users this System Supports ..............................................................................3
1.6.1 The Administrator ...................................................................................................3
1.7Operations .......................................................................................................................3
Administrator’s Operations ..............................................................................................3
1.8User Characteristics ........................................................................................................3
1.9Types of Users ................................................................................................................3
1.9.1 The Administrator ...................................................................................................3
1.9.2 The Cashier..............................................................................................................4
1.10 General Constraints ...................................................................................................4
1.11 Assumptions and Dependencies................................................................................5
Chapter 2 ................................................................................................................................6
Software Requirements Specification ..................................................................................6
2.1 Specific Requirements ...................................................................................................6
2.1.1 Correct .....................................................................................................................6
2.1.2 Traceable .................................................................................................................6
2.1.3 Unambiguous...........................................................................................................6
2.1.4 Verifiable .................................................................................................................6
2.1.5 Prioritized ................................................................................................................6
2.1.6 Complete .................................................................................................................6
2.1.7 Consistent ................................................................................................................6
2.2 External Interface Requirements ....................................................................................7
2.2.1 System Interfaces ....................................................................................................7
2.2.2 Interfaces .................................................................................................................7
2.2.2.1 Desktop GUI .....................................................................................................7
2.2.2.2 Web page GUI ..................................................................................................7
 2.2.3 Hardware Interfaces ................................................................................................7
2.2.3.1 Minimum Configuration ................................................................................7
2.2.3.2Recommended Configuration ............................................................................8
2.2.4 Software Interfaces ..................................................................................................8
2.2.4.1Operating system ...............................................................................................8
2.2.4.2 Microsoft SQL Server.......................................................................................9
2.3 Functional Requirements ...............................................................................................9
2.3.1 Administrator...........................................................................................................9
2.3.2 Cashier ...................................................................................................................10
2.3.2.1 Introduction.....................................................................................................10
2.3.2.2 Inputs ..............................................................................................................10
2.3.2.3 Processing .......................................................................................................10
2.3.2.4 Outputs ............................................................................................................10
2.3.2.5 Error Handling ................................................................................................10
2.3.3 Generate mess bill .................................................................................................10
2.3.3.1 Introduction.....................................................................................................10
2.3.3.2 Inputs ..............................................................................................................10
2.3.3.3 Processing .......................................................................................................10
2.3.3.4 Outputs ............................................................................................................11
2.3.3.5 Error Handling ................................................................................................12
2.3.4 Expenses report .....................................................................................................12
2.3.4.1 Introduction....................................................................................................12
2.3.4.2 Inputs ..............................................................................................................12
2.3.4.3 Processing .......................................................................................................12
2.3.4.4 Outputs ............................................................................................................12
2.3.4.5 Error Handling ................................................................................................12
2.3.5 Mess report ............................................................................................................12
2.3.5.1 Introduction.....................................................................................................12
2.3.5.2 Inputs ..............................................................................................................13
2.3.5.3 Processing ......................................................................................................13
2.3.5.4 Outputs ...........................................................................................................13
2.3.5.5 Error Handling ...............................................................................................13
2.3.6 Hostel Employees ................................................................................................13
2.3.6.1 Introduction.....................................................................................................13
 2.3.6.2 Inputs .............................................................................................................13
2.3.6.3 Processing .......................................................................................................13
2.3.6.4 Outputs ...........................................................................................................13
2.3.6.5 Error Handling ................................................................................................14
2.3.7 Mess security card .................................................................................................14
2.3.7.1 Introduction.....................................................................................................14
2.3.7.2 Inputs .............................................................................................................14
2.3.7.3 Processing .......................................................................................................14
2.3.7.4 Outputs ............................................................................................................14
2.3.7.5 Error Handling ................................................................................................14
2.3.8 Purchases ...............................................................................................................14
2.3.8.1 Introduction.....................................................................................................14
2.3.8.2 Inputs ..............................................................................................................14
2.3.8.3 Processing .......................................................................................................15
2.3.8.4 Outputs ............................................................................................................15
2.3.8.5 Error Handling ................................................................................................15
2.3 Use Case Diagram ...................................................................................................15
2.4.1 Use Case of mess system.......................................................................................15
2.5 Use cases ......................................................................................................................16
2.5.1 Use case to add employee information .....................................................................16
2.5.2 Use case for new mess bill ...................................................................................17
2.6 Classes / Objects ..........................................................................................................18
2.6.1 Class / Object 1.....................................................................................................18
2.6.1.1 Attributes ........................................................................................................18
2.5.1.2 Functions.........................................................................................................19
2.7 Non-Functional Requirements .....................................................................................19
2.7.1 Performance...........................................................................................................19
2.7.2 Reliability ..............................................................................................................19
2.7.3 Availability ............................................................................................................19
2.7.4 Security ..................................................................................................................19
2.7.5 Maintainability ......................................................................................................19
2.7.6 Portability ..............................................................................................................20
Chapter 3 ..............................................................................................................................21
Software Design Description ...............................................................................................21
3.1 System Overview .........................................................................................................21
3.1.1 Types of users this system supports ......................................................................21
3.1.1.1 The Administrator ...........................................................................................21
3.1.1.2 The Cashier .....................................................................................................22
3.2 System Architecture .....................................................................................................22
3.2.1 Architectural Design..............................................................................................22
3.3 Decomposition Description..........................................................................................23
3.3.1 Activity diagram ....................................................................................................23
3.3.2 Data Flow Diagram ...............................................................................................23
3.3.3 State Transition Diagram.......................................................................................24
3.3.4 Sequence diagram.................................................................................................25
3.4 Design Rationale ..........................................................................................................26
3.5 Data Design ..................................................................................................................26
3.5.1 Data Description ....................................................................................................27
3.5.1.1 Login table ...................................................................................................27
3.3.1.2 Mess security card Table ...............................................................................27
3.3.1.3 Mess bill Generation ......................................................................................28
3.3.1.4 Purchases items table .....................................................................................28
3.3.1.5 Hostel Employee table ...................................................................................28
3.6 Data Dictionary ............................................................................................................29
3.6.1 Information for Student .........................................................................................29
3.6.2 Room Information .................................................................................................30
3.6.3 Allotment Information ...........................................................................................30
Chapter 4 ..............................................................................................................................31
Implementation And Testing ..............................................................................................31
4.1 Overview of User Interface ..........................................................................................31
4.2 Implementation of Hostel management system ...........................................................31
4.2.1 login page ..............................................................................................................31
4.2.2 Main Page ..............................................................................................................31
4.2.3 Employee information ...........................................................................................32
4.2.4 Mess Information Page ..........................................................................................33
4.2.5 Expenses Information ............................................................................................33
 4.2.6 Webpage ................................................................................................................34
4.2.7 News and Services.................................................................................................34
4.3 Implementation ............................................................................................................35
4.4 Testing ..........................................................................................................................35
4.4.1 Testing Strategy .....................................................................................................35
4.2.2 Testing Strategy that I used ...................................................................................35
4.4.2.1Black box Testing ............................................................................................36
4.4.2.2 White Box Testing ..........................................................................................36
4.4.2.3 Unit Testing ....................................................................................................36
4.4.2.4 System Testing................................................................................................36
4.4.2.5 Acceptance Testing .........................................................................................36
4.4.3 Debugging .............................................................................................................36
4.4.3.1 Syntax Errors ..................................................................................................37
4.4.3.2 Logic Errors ....................................................................................................37
4.4 Test Cases ....................................................................................................................37
4.4.1 Test Case: 1. Login Module Testing .....................................................................37
4.4.2 Test Case: 2. New Allocation Module Testing .....................................................37
4.4.3 Test Case: 3. Add new Rooms .............................................................................38
4.5 Testing summary ..........................................................................................................38
Plagiarism Report ................................................................................................................39
References .............................................................................................................................40
 List of Figures

Figure 2.1 Use Case of student and cashier in mess ..............................................................15

Figure 2.2 Use Case add employee Information ...................................................................16
Figure 2.3 Use Case New Mess bill......................................................................................17
Figure 2.4 Class diagram for mess bill ..................................................................................18
Figure 3.1 Architectural Diagram Of Hostel Management System ......................................22
Figure 3.2 Activity Diagram for adding employee and allotment .........................................23
Figure 3.3 Data Flow Diagram Hostel Employee .................................................................24
Figure 3.4 State Transition diagram .....................................................................................24
Figure 3.5 State Transition diagram .....................................................................................25
Figure 3.6 Sequence diagram ...............................................................................................25
Figure 3.7 ERD Diagram ......................................................................................................26
Figure 3.8 Login Table .........................................................................................................27
Figure 3.9 Mess security card Table Definition ...................................................................27
Figure 3.10 Mess bill Definition ...........................................................................................28
Figure 3.11 Employee Table Definition ...............................................................................28
Figure 3.12 Hostel Employee table ......................................................................................29
Figure 4.1 Login Page...........................................................................................................31
Figure 4.2 Main Page ............................................................................................................32
Figure 4.3 Hostel Employee Page ........................................................................................32
Figure 4.4 Mess bill information ..........................................................................................33
Figure 4.5 Expenses information ..........................................................................................33
Figure 4.6 Al-Barq Hostel Website ......................................................................................34
Figure 4.7 Al-Barq website...................................................................................................34
 CHAPTER 1
INTRODUCTION

The system we are going to design is useful to manage the overall activities of hostel. This
system will help the management to manage the student record about their room allocation
and all about mess information. This system is computer desktop app to manage all record
i.e. (insert, delete update or search) regarding the students through computer. This will help
the management to manage record quickly with accuracy and consistency. This system will
also help the management to resolve the problem regarding old manual system.
The simple graphical user interface will help the user and the administrator to manage the
record easily. This will reduce the dependency on single person as in manual system.
This is also an online application that will disperse the information among the students
regarding their activities and the room status.
The system will also maintain different type of managerial reports and room bill receipts.
This system will also provide the biometric verification facility for a secured record
management regarding students in the hostel.

1.1 Purpose
This is software requirements for the hostel management system. The main purpose of our
system is to provide fully computerize record management facilities. In the existing manual
system all the records about the student were managed on register, which takes too much
time in processing records. By using this proposed system the administrator can manage all
the student record through computer. The system will reduce the time consumption for the
required activities in an efficient manner.
The document is written for:
 Owner / Administrator of the hostel.
 The owner or the Administrator will be the person, who will purchase this system. He
/She could be the owner or Manager of the business i.e. hostel.

1.2 Scope
A biometric hostel management system is in progress to producing an efficient system that
helps administrator and students. The software system will lead the record of the students
who occupied the rooms and empty rooms with also record of their mess system and
biometric verification of students will be saved. We are developing the system application
in C# language, web designing and MYSQL server as database. Because it is easy and
efficient in developing the application and encrypts the record and prevent system easily.
Attractive graphic user interface with login and password, insert, delete, update and search

1|Page
record on button click, biometric verification in mess system and attendance system. Printed
challan will be print out and pay to continue the room allocation process.

1.3 Overview
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the functional and
data requirements of the product. General description of the project is discussed in section
2 of this document. Section 3 gives the functional requirements, data requirements and
constraints and assumptions made while designing the Hostel Management System. It also
gives the user viewpoint of product. Section 3 also gives the specific requirements of the
product. Section 3 also discusses the external interface requirements and gives detailed
description of functional requirements. Section 4 is for supporting information.

1.4 The Overall Description

This software product the hostel management to improve their services for allthe students of
the hostel. This also reduce the manual work of the persons inadmin penal and the bundle of
registers that were search when to find theinformation of a previous student, because
through this system you can store thedata of those students who had leaved the hostel three
years ago. Through this youcan check the personal profile of all the current students within
few minutes thedata base of the system will help you to check a particular one. You can
select thetime of the student to use the internet by allocating the specific time to
everystudent. The system will help you to check the mess bills of every student and
thestudent’s hostel dues. The students of the hostel will be recognized from the IDnumber
allocated at the room rental time. This system also attach to the systemof the library and the
departments, so that they can access the data of the particular student. In the last this system
will improve the management work in the hostel.

1.5 Product Perspective

 The “Hostel Management System” have only admin side user does not interact with this
system new student registered here for fee challan and room allocation system.
 This system have two aspects of GUI (graphical user interface) in two different
languages.
 This first aspect is in the C# language and only administrator or warden can use delete
and update record.
 Second Graphical user interface is in the Web (PHP) .Only students will interact with
that system to see their accounts and record.
 Print out challans will be ensure to continue the process of room allocation system.
 The mess bills of students will be available on the web GUI page.
 Only admin or warden can insert, delete and update the record.
 Only students can view their records and mess bills.
 They will not allow to changes any type of record in the system.

2|Page
1.6 Types of Users this System Supports

1.6.1 The Administrator

The administrator maintain all activities occurring at hostel management. Administrator
manages employees’ detail in the system. He is authorized to give an account access to the
Employee person. He has the authority to update or change the details as required. He can
also view the reports generated by the system. He is also responsible to add or delete some
employee from the system.
He manages all the activities regarding Mess sales, purchase and stock. He is responsible
for all tasks performed by system. He is responsible to Mess sales and purchase orders. He
can add items to stock from a particular purchase order and may sale out items from stock
by finding in stock whether the particular items is present in stock or not in greater than or
equal quantity.

1.7 Operations
The administrator login in the system to manage the system all operations provided in Al-
Barq Hostel Management System.

Administrator’s Operations
 He/she manages the employee record.
 Overlook and manages the purchase and stock operations.
 Overlook the sales and stock operations.
 Generates and examine the different reports obtained from the system.
1.8 User Characteristics
The system is developed for the user who is employee or the owner of the Hostel and wish
to have a system that fulfill the requirements regarding Hostel. This system is supported by
the following users.
1.9 Types of Users
1.Administrator.
2.Cashier.

1.9.1 The Administrator

The administrator maintain all activities occurring at Hostel. Administrator manages
employees’ detail in the system. He is authorized to give an account access to the new
Cashier . He too must have some specific username and password. He has the authority to
update or change the items details as required. He can also view the reports generated by the
system. He is also responsible to add or delete some employee from the system.
He manages all the activities regarding Mess sales, purchase and stock. He is responsible
for all tasks performed by system. He is responsible to sales and purchase orders. He can
add items to stock from a particular purchase order and may sale out items from stock by
finding in stock whether the particular items is present in stock or not in greater than or
equal quantity.

3|Page
1.9.2 The Cashier
The Cashier or the computer operator is the person at the Hostel Management, which
directly communicate with Students and take Mess orders. He must have an account on the
system to utilize it according to the features provided by the administrator. Like he should
be able to make Mess transactions, search items to check whether the corresponding item
has enough quantity in to be sold.After a Mess order has confirmed. He should be able to
print a bill receipt for that order. He should also have an authority to view Mess reports.

1.10 General Constraints

General description of other items that can limit the developer’s options. These can include:
 Regulatory Policies
To understand what rules, regulations and obligations are applicable to the companies. The
companies use Regulatory policies. Administrator of the Hostel develops these policies. He
can change his policies according to his own requirements.
 Hardware limitations
The required minimum hardware for the system should be 1 GB ram and 80 GB hard drive
and processing capacity should be 2.4 core duo.
 Parallel operation
The developing system will be able to handle multiple operations at the same time.
The system and SQL server will work in synchronized way.
The system is capable of printing report of different types.
 Reliability requirements
System is reliable because several recovery procedures will be maintained from the back up
storage.
 Safety and security considerations
Safety is maintained by using the login mechanism and the security will be maintained
according to the standard of the shop.
 Others
The application is being developed by using C# window form tool which will be initially
accessible using Microsoft visual studio.
 Audit functions
Provide the forms for adding new employee, Student, Room, Mess purchase, and Mess
information. And information about these events and actors is provided by system.

4|Page
 Control functions
It handles the control functions of the Hostel like adding new employee, Student, Mess
purchase, and sale information. And information about these events and actors is provided
by system. It enables administrator to generate different reports according to needs.
 Higher-order language requirements:
 The application is being developed by using C# window form tool which will be
initially accessible using Microsoft visual studio.
 The software is being developed by using English American or British language.
 Reliability requirements
 System is reliable because several recovery procedures will be maintained from the back
up storage.
 Safety and security considerations
 Safety is maintained by using the login mechanism and the security will be maintained
according to the standard of the shop.
1.11 Assumptions and Dependencies
 This desktop application must run on any operating system, no specific operating
system is required.
 This desktop application must support any type of hardware, no specific hardware is
required.
 This desktop application must have any specific user name and password to use.
 For this desktop application no need of internet.
 In the system website is connected with MYSQL server for sorting the record in the
database.
 Desktop application must depend on operating system, because application cannot runs
directly on the hardware.

5|Page
 CHAPTER 2
SOFTWARE REQUIREMENTS SPECIFICATION

This will be the largest and most important section of the SRS. The customer requirements
will be embodied within Section 2, but this section will give the D-requirements that are
used to guide the project’s software design, implementation, and testing.
2.1 Specific Requirements
The developed system require the characteristics to be full to function properly.

2.1.1 Correct
 The requirement must be correct and understandable.
 The requirement is without errors.

2.1.2 Traceable
 System fulfill both forward and backward of the requirement.
 Accept the changes according to future requirement.

2.1.3 Unambiguous
 All the data is in clear.
 Whole requirement are understandable.

2.1.4 Verifiable
 Pass in test able condition.
 Requirements are according to desire.

2.1.5 Prioritized
 With the respect to importance and stability.

2.1.6 Complete
 Requirement should be complete.

2.1.7 Consistent
 Accuracy of the requirement.

6|Page
2.2 External Interface Requirements
The external interface are the interfaces which are directly interacted by the end user, some
of them are discussed below:

2.2.1 System Interfaces

The system interface is like forms which are to be filled to enter data into the
system. The employee interact with the system through system interfaces

2.2.2 Interfaces
Interfaces in the system are as follows:

2.2.2.1 Desktop GUI

 System will display the graphical user interface with including the user name and
password.
 System will offer to admin menus buttons and many options to configure the system.
 Students can choose their room numbers and mess accounts by admin not directly.
 Printout Challans will be Ensure to complete the process.
 Biometric verification will ensure.

2.2.2.2 Web page GUI

 This user interface is only for students use.
 Students can view their hostel room information and about all information of facilities
in this hostel.
 Students can view their accounts and mess bills of all meals have eaten in this hostel.
 Admin side GUI and student side GUI have the same records, no inconsistency.

2.2.3 Hardware Interfaces

The system that going to developed is requires some hardware specifications so that it can
be utilized efficiently. The computer on which this system is going to be used must have the
specified hardware components. All the hardware needed here are generally the basic
configuration of a typical office computer. A list of the hardware requirement used in the
system given below:

2.2.3.1 Minimum Configuration

Minimum configuration for the system is described below:
 Keyboard.
 Mouse.
 A printer.
 2.5 Hz Pentium processor.

7|Page
 500 MB SD RAM.
 Minimum 80 GB Hard Drive.
 Monitor Display. Or LCD or LED.
 Bio-Metric device

2.2.3.2Recommended Configuration
The configuration mention above is to use the system just effectively. The configuration
described below can be used to have better and optimum result during the working of the
system.
 2GHz core 2 duo.
 Keyboard.
 Mouse.
 Laser printers.
 2GB or more SD RAM.
 Minimum 80 or more GB Hard drive.
 Color Monitor.
 500 V. UPS .(can be used in case of power failure)

2.2.4 Software Interfaces

 The hostel management system shall communicate with the Configuration to identify all
the available components to configure the product.
 The hostel management system shall communicate with the admin to get the product
specifications, offerings and promotions.
 The hostel management system shall communicate with bills Pay system to identify
available payment methods, validate the payments and process payment.
 The hostel management system shall communicate to allocate room to complete all the
process.
 The hostel management system shall communicate with students to provide support.
 The hostel management system shall communicate with student to show the information
of students.
 The hostel management system shall communicate with students to show mess bills of
the students.
 The hostel management system shall communicate with student to show the information
of all rooms and empty rooms.
 The system will interact with admin to verify the thumb impressions of the students foe
secure database.

2.2.4.1Operating system
 Window 10 (32 or 64 bit).
 Visual studio 2015 Enterprise.
 .Net Framework 4.5 or higher.

8|Page
 Notepad or MS word installed.

2.2.4.2 Microsoft SQL Server

SQL server is used to connect with the database using OLEDB and ODBC data connection.
Many backend software are available for data storage such as MS access, Sybase, oracle
and my SQL. Here we are choosing Microsoft SQL Server as database for the system. It has
best features supporting the .net framework. Some features are:
1. Most popular open source database system.
2. It works on many different system platforms.
3. My SQL does not support DDL transactions.
4. It is database for PHP or any desktop application and it is large and useful and great too
speed.
5. It is developed under the GLU license, not for profit open license.
6. It is very powerful, cross platform and is used by many web servers.
7. It is a database engine to interpret SQL.
8. It is the software of the Swedish company.

2.3 Functional Requirements

This section describes specific features of the system. If desired, some requirements may
be specified in the use-case format and listed in the Use Cases Section:

2.3.1 Administrator

2.3.1.1 Introduction
This module is used to record the information about all functions in the hostel and it is
managed by the administrator. Admin is responsible for all record management.

2.3.1.2 Inputs
Some necessary parameters that are required to maintain the record e.g. User name which is
assigned to admin, Meal time and quantity also enter by administrator to fulfill Mess Order.

2.3.1.3 Processing
The data processed in it can be in the form of adding records, information and search a
particular Mess order.

2.3.1.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the mess information Different type of reports
can be produced by the administrator.

9|Page
2.3.1.5 Error Handling
If some information regarding a hostel student is inserted incorrectly then it can be updated
by administrator. Only the administrator have authority to maintain employee record.

2.3.2 Cashier

2.3.2.1Introduction
This module is used to record the information about Mess in the hostel and it is managed by
the cashier. Cashier is responsible for the mess record management.

2.3.2.2 Inputs
Some necessary parameters that are required to maintain the mess record e.g. Mess ID
which is assigned to each order, Meal time and quantity also enter by Cahier to fulfill Mess
Order.

2.3.2.3 Processing
The data processed in it can be in the form of adding records, information and search a
particular Mess order.

2.3.2.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the mess information Different type of reports
can be produced by the cashier.

2.3.2.5 Error Handling

If some information regarding a hostel student is inserted incorrectly then it can be updated
by administrator. Only the administrator have authority to maintain employee record.

2.3.3 Generate mess bill

2.3.3.1 Introduction
This module is used to record the information about mess in the hostel and it is managed by
the administrator. Administrator is responsible for the mess record management.

2.3.3.2 Inputs
Some necessary parameters that are required to maintain the mess record e.g. Allotment No
which is assigned to each student, meal time, meal quantity, meal items, Total cash, given
change etc. the administrator also sets the Allotment No of each student and then stores the
record of every student in the database.

2.3.3.3 Processing

10 | P a g e
The data processed in it can be in the form of adding records, updating student’s mess
information and search a particular student mess bill which is living in hostel.

2.3.3.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the Allotment no their mess bill information and
maintaining their status whether the students are paying or not by giving remarks to each.
Different type of reports can be produced by the administrator of the HMS.

11 | P a g e
2.3.3.5Error Handling
If some information regarding a hostel student mess bill is inserted incorrectly then it can be
updated by administrator. Only the administrator have authority to maintain mess bill
record.

2.3.4 Expenses report

2.3.4.1 Introduction
Reports can be calculated by administrator of expenses as and when required. The reports of
expenses determine the daily and monthly expenses of our hostel.

2.3.4.2 Inputs
The Administrator will check report of daily or monthly expenses. The expense name,
expense date, expense cost, allocation order date, allotment no etc. of adding record are the
basic inputs.

2.3.4.3 Processing
The data processed in it can be in the form of adding date order in calculating report from
date and to date Changing expenses dates, report dates by updating of records are common
processing elements of the module.

2.3.4.4 Outputs
The data is organized in well and efficient format. The output can be generated in different
formats i.e. checking whether an date order is given by the administrator to calculate report
or not. Different type of reports can be produced by the staff and the administrator of the
hostel management system for checking their purchase room to maintain rooms.

2.3.4.5 Error Handling

If some record is inserted incorrectly then it can be updated by administrator. The records
that contains some errors can be resolve by the update operation which is the authority of
HMS administrator to maintain data accuracy and consistency.

2.3.5 Mess report

2.3.5.1 Introduction
Reports can be calculated by administrator of mess as and when required. The reports of
mess determine the daily and monthly income of our hostel. The administrator is
responsible for the maintained the mess report system.

12 | P a g e
2.3.5.2 Inputs
Some necessary parameters that are required to maintain the hostel mess report e.g. daily
mess, monthly mess, date to date mess report.the administrator stores the record of every
mess in the database.

2.3.5.3 Processing
The data processed in it can be in the form of Searching records, updating record of mess
and search a particular date mess report.

2.3.5.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the report date order and maintaining the status
of hostel income and expenses. Different type of reports can be produced by the
administrator of the HMS.

2.3.5.5 Error Handling

If some information regarding a hostel student is inserted incorrectly then it can be updated
by administrator. Only the administrator have authority to maintain employee record.

2.3.6 Hostel Employees

2.3.6.1 Introduction
This module is used to record the information about employees working athostel and it is
managed by the administrator. Administrator is responsible for the staff record
management.

2.3.6.2 Inputs
Some necessary parameters that are required to maintain the employee record e.g. employee
ID which is assigned to each employee, employee name, email address, residential address,
CNIC, job designation, salary, salary type, mobile# etc. the administrator also sets the salary
of each employee and then stores the record of every employee in the database.

2.3.6.3 Processing
The data processed in it can be in the form of adding records, updating employee’s
information and search a particular employee which is working in the system.

2.3.6.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the working employees their salary information
and maintaining their status whether the employees are working or not by giving remarks to
each. Different type of reports can be produced by the administrator of the hostel.

13 | P a g e
2.3.6.5 Error Handling
If some information regarding a staff member is inserted incorrectly then it can be updated
by administrator. Only the administrator have authority to maintain employee record.

2.3.7 Mess security card

2.3.7.1 Introduction
This module is used to record the information about total issued mess security cards in the
hostel and it is determine the total received amount for mess cards. Administrator is
responsible for the other person record management.

2.3.7.2 Inputs
Some necessary parameters that are required to maintain the record e.g. Allotment nowhich
is assigned to each student, Student name, allowed meals, security amount, issue date,
remaining meals etc. the administrator also sets the record of every card issued in the
database.

2.3.7.3 Processing
The data processed in it can be in the form of adding card records, updating student’s
information and search a particular student which is using the mess card.

2.3.7.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the living student their allotment information
and maintaining their mess card status whether the persons is using or not by giving remarks
to each. Different type of reports can be produced by the administrator of the hostel.

2.3.7.5 Error Handling

If some information regarding a person is inserted incorrectly then it can be updated by
administrator. Only the administrator have authority to maintain person record.

2.3.8 Purchases

2.3.8.1 Introduction
This module is used to store the record of different type of purchases items for the mess of
hostel. This determines the total things used in mess system of hostel and also determines
expenses.

2.3.8.2 Inputs
Some necessary parameters that are required to maintain the purchases items record e.g.
Item name, purchaser name, purchase date, purchase amount etc. the administrator also sets
the record of every item in the database.

14 | P a g e
2.3.8.3 Processing
The data processed in it can be in the form of adding items records, updating items
information and search a particular purchase item recordand date of purchase item in the
system.

2.3.8.4 Outputs
The data is organized in an understandable and efficient format. The outputs can be
generated in different formats i.e. checking the purchases records. And maintain their
amount different type of items can be add by the administrator of the hostel.

2.3.8.5 Error Handling

If some information regarding a shop is inserted incorrectly then it can be updated by
administrator. Only the administrator have authority to maintain shop record.

2.3 Use Case Diagram

The use cases describes that to activities or actions an actor is associated. And what are the
process through which the actor has to pass to complete an action.

2.4.1 Use Case of mess system

The use case is for cashier and new student in hostel mess system. The admin can access all
of the function of the system. Student will view meal items and select meal and meal time,
quantity and total amount of mess bill.

Figure 2.1Use Case of student and cashier in mess

15 | P a g e
Actor:Administrator

Pre-condition
 Administrator must open Login form to have access to system
 Then he/she has to select or choose the above mentioned any action that he want to
perform
 Fulfill the required criteria for the action
Primary Scenario
 He will run application and login to the system.
 He will enter required fields.
 Choose an appropriate action he want to perform.
 Fulfill the action’s requirement according to the constraints on it.
 And commit confirm command.
 This use case ends.
Exceptions
 Invalid form filling.
Post Condition
 The Data will be saved successfully.

2.5 Use cases

Some use cases about particular actions that can an employee or admin can perform are
given below:

2.5.1Use case to add employee information

In this use case the admin the can add new staff. The admin open add new employee form
and fill all the required data in the fields and save to the database.

Figure 2.2Use Case add employee Information

16 | P a g e
Actor:Administrator
Pre-condition
 Administrator must open add staff Form
Primary Scenario
 He will run application and open add staff form.
 He will enter required fields.
 He will click the Add Button.
 Data for the new staff member will be saved
 This use case ends.
Exceptions
 Invalid form filling.
Post Condition
 The Data will be saved successfully.

2.5.2 Use case for new mess bill

In this use case the admin can give print bill of mess to student. The admin open menu items
for mess first fill the meal information and then fill the meal type, quantity and total amount
of mess bill then save the mess record into the database and generate mess bill.

Figure 2.3Use Case New Mess bill

Actor: Administrator
Pre-condition
 Administrator open New mess bill Form
Primary Scenario
 Administrator will run application and open New bill of mess.
 Administrator will enter required fields.
 Administrator will click the print bill Button.
 Data for the new mess bill will be save, and record will be updated.
 This use case ends.

17 | P a g e
Exceptions
 Invalid form filling
Post Condition
 The Data will saved successfully.

2.6 Classes / Objects

Major classes of the system are:

2.6.1 Class / Object 1

This is class diagram in this In this diagram there are 5 classes. in the first student class
have 2 variables for ordering the mess system. The Food item class contain three
variableitem no, cost and ingredients. Purchase class have list of items, amount and date.
Student will select items and admin generate mess bill.

Figure 2.4Class diagram for mess bill

2.6.1.1 Attributes
The system includes following attributes:
 Meal Number
 List of item

18 | P a g e
 Mess Type
 price
 Date
 Ingredients

2.5.1.2 Functions
 Administrator manages information for mess
 Manages the Mess purchases
 Make product sale to the student
 View mess report
 Manages the information of debit Student
 Total bill of the Student Mess purchases.

2.7 Non-Functional Requirements

The non-functional requirements are more critical than functional requirements, because if
these are missing the system is useless.
Non-Functional requirements are stated here:

2.7.1 Performance
System should run fast more than one user can access the system simultaneously on the
other side. So the system performance should not be affected. Fast and better performance
should be ensured.

2.7.2 Reliability
Data validation and verification should be done at any stage of activity.System should not
failure in any case. This software system should be reliability.

2.7.3 Availability
The availability of this system must be ensured.This system will available at all the time
and functioning and running all the time where and when required. The services of this
system should be provided always.

2.7.4 Security
The biometric verification is used in this application to keep data secure and encrypt all the
database from failure. The antivirus of good quality should be used in the operating system
to keep database secure from the malwares.

2.7.5 Maintainability
The system should be able to enhance and maintain the quality of software where and when
required. If any error and failure is occurred so the application maintainability should be
easy.

19 | P a g e
2.7.6 Portability
This desktop application will runs on any hardware and operating system. It does not have
required any specific hardware and operating system.This desktop application is platform
independent it does not depend on any platform.

20 | P a g e
 CHAPTER 3
SOFTWARE DESIGN DESCRIPTION

3.1 System Overview

This software product the hostel management to improve their services for allthe students of
the hostel. This also reduce the manual work of the persons inadmin penal and the bundle of
registers that were search when to find theinformation of a previous student, because
through this system you can store thedata of those students who had leaved the hostel three
years ago.
Through this youcan check the personal profile of all the current students within few
minutes thedata base of the system will help you to check a particular one. You can select
thetime of the student to use the internet by allocating the specific time to everystudent. The
system will help you to check the mess bills of every student and thestudent’s hostel dues.
The students of the hostel will be recognized from the IDnumber allocated at the room
rental time.
This system also attach to the systemof the library and the departments, so that they can
access the data of the particular student. In the last this system will improve the
management work in the hostel.

3.1.1 Types of users this system supports

The system is a stand-alone desktop application, it supports these two types of users.

 Administrator.
 Salesman.
These are explained below :

3.1.1.1 The Administrator

The administrator maintain all activities occurring at Hostel. Administrator manages
employees’ detail in the system. He is authorized to give an account access to the new
Cashier . He too must have some specific username and password. He has the authority to
update or change the items details as required. He can also view the reports generated by the
system. He is also responsible to add or delete some employee from the system.
He manages all the activities regarding Mess sales, purchase and stock. He is responsible
for all tasks performed by system. He is responsible to sales and purchase orders. He can
add items to stock from a particular purchase order and may sale out items from stock by
finding in stock whether the particular items is present in stock or not in greater than or
equal quantity.

21 | P a g e
3.1.1.2 The Cashier
The Cashier or the computer operator is the person at the Hostel Management, which
directly communicate with Students and take Mess orders. He must have an account on the
system to utilize it according to the features provided by the administrator. Like he should
be able to make Mess transactions, search items to check whether the corresponding item
has enough quantity in to be sold.After a Mess order has confirmed. He should be able to
print a bill receipt for that order. He should also have an authority to view Mess reports

3.2System Architecture
This is the architecture that what type of information is going into the system, where the
will get saved. It describes who will interact with the system and flow of the information
and factors that affect the system or affected by the system.

3.2.1Architectural Design
This system will maintain and records all the transactions such as allotment and storing the
record of employees and Students. There is also the facility of checking record. Basic
interface through which the user will interact with the system are the different screens with
multiple items having the facility of adding, deleting, updating and searching of records
facility with different aspects. The system will be efficient and compatible with other
system working in the environment.
This hostel management system application will be run on windows operating system.
How things are used together to complete the implementation.you see the architecture in the
following. How user will interact with this application via operating system and hardware

Figure 3.1Architectural Diagram Of Hostel Management System

22 | P a g e
3.3 Decomposition Description
Different diagrams including state transition diagram/ Activity diagram, DFDs, ERD,
Sequence diagram are given below:

3.3.1 Activity diagram

In the activity diagram first login page is occur. After login the main is loaded. From main
form the admin can add new staff record through opening new employee form. Admin can
also allot the room to the student after filling the required student information and allotment
details.

Figure 3.3.1Activity Diagram for Mess System

3.3.2 Data Flow Diagram

Data flow diagrams describes the flow of data from user to system, and from system to the
users. Some of the DFDs are given and described below

23 | P a g e
 Figure 3.2Data Flow Diagram Hostel Employee

3.3.3 State Transition Diagram

The state transition diagram describes the state of the user after performing an activity, e.g.
after completing login process the state of the user is logged in and he might be on the main
page of the system. If the user commit information about an object, then he / she is in a
committed state. If the user logged out from the system the he in logged out state.

Figure 3.3 State Transition diagram

24 | P a g e
 Figure 3.4State Transition diagram

3.3.4 Sequence diagram

Sequence of the system that, what is the efficient way of sequence to use the system is given
below:

Figure 3.5Sequence diagram

25 | P a g e
3.4 Design Rationale
A design rationale is an explicit documentation of the reasons behind decisions made
when designing a system or artifact. design rationale seeks to provide argumentation-based
structure to the political, collaborative process of addressing wicked problems.

ERD of the system

An entity relationship model is also called an entity-relationship (ER) diagram it is a
graphical representation of entities and their relationships to each other, typically used in
computing in regard to the organization of data within databases or information systems.

Figure 3.6ERD Diagram

3.5 Data Design

The data is stored in relational database. The relations are described by the database
administrator of the Hostel Management System. The fields are transmitting to and from the
database are given in the following table.

26 | P a g e
3.5.1 Data Description
Here are some data base table with their definitions and some explanation:

3.5.1.1 Login table

In this Database table the admin id and Cashier id is stored. Which is used to login to Hostel
Management system

Figure 3.7Login Table

3.3.1.2 Mess security card Table

In this table the basic information of mess card is stored. Allotment no, name, allowed
meals, remaining meals, date and amount.

Figure 3.8Mess security card Table Definition

27 | P a g e
3.3.1.3 Mess bill Generation
In this table mess bill information is saved. What is date, what is the meal, what is the
quantity, what is amount of total bill.

Figure 3.9Mess bill Definition

3.3.1.4 Purchases items table

In this table the information about different item is stored. What is purchase date, item
name, quantity, amount, purchaser name is stored in this table

Figure 3.10Employee Table Definition

3.3.1.5 Hostel Employee table

28 | P a g e
In this table the information about hostel employees is stored. Employee id is primary key.
Table contains the employee id, employee name, employee cnic, employee mobile, address,
date and salary.

Figure 3.11Hostel Employee table

3.6 Data Dictionary

A data dictionary contains metadata i.e. the information about the information. The
important information about the fields of different tables used in the system are given
below. These describes which field contain what kind of data and for what purpose with a
short description below.

3.6.1 Information for Student

Attribute Name Attribute Type Attribute Size
Student Id Varchar 20
Student Name String 20
Student F Name String 20
Student Mobile Int 20
Email Address String 20
City String 20

29 | P a g e
3.6.2 Room Information
Attribute Name Attribute Type Attribute Size
Room Id Varchar 20
Room beds String 20
Room beds available String 20
Room dues String 20
Allotno String 20

3.6.3 Allotment Information

Attribute Name Attribute Type Attribute Size
Allotment Id Varchar 20
Allotment type String 20
Allotment Date String 20
De allotment date String 20
Dues String 20

30 | P a g e
 CHAPTER 4
IMPLEMENTATION AND TESTING

4.1 Overview of User Interface

After log in to the system the user or the admin has home page or main page, where he or
she can choose the option according to the requirement and the according to the access
permission granted by the admin. The only admin can use full fledge options of the system,
rest of members can use as access provided by the admin

4.2 Implementation of Hostel management system

Some of the important images that can help in the efficient usage of the system are given
below:

4.2.1 login page

This image show main page of Al-barq hostel management System. The admin and cashier
login to the system through this page. If the admin is forget his password they can reset
through button.

Figure 4.1Login Page

4.2.2 Main Page

This picture is the main page of hostel management system. After login from admin id this
page is loaded. From this page the admin perform multiple Operation which is necessary to
maintain Hostel System record.

31 | P a g e
 Figure 4.2Main Page

4.2.3 Employee information

The staff information is done through this page. Thispage contains employee’s basic
information to store the record of employee in database. Such as employee id, employee
name, employee position, employee address and date.

Figure 4.3Hostel Employee Page

32 | P a g e
4.2.4 Mess Information Page
In this page the record of the mess bill will be done. Record is find through the allotment
no. it stores the student mess information such as Meal type, meal quantity, total cash and
given change information.

Figure 4.4Mess bill information

4.2.5 Expenses Information

In this page expenses will be maintained to meet the hostel income and expenses such as
expense name, expense cost, expense date etc will be manage.

Figure 4.5Expenses information

33 | P a g e
4.2.6 Webpage
In this website all hostel information related to student allocation will be provide. This
website willbe control by administrator. All information on this page will be updated.

Figure 4.6Al-Barq Hostel Website

4.2.7 News and Services

In this page the administrator will update hostel services and latest news of hostel related to
students will be update that motivate students. Student will be able to know latest news
about new rooms, services, and latest news.

Figure 4.7Al-Barq website

34 | P a g e
4.3 Implementation
A crucial phase in the system life cycle is the successful implementation of the new system
design, Implementation simply means conveying a new system design into operation. This
involves creating computer-compatible files, training the operating staff and installing
hardware, terminals before the system is up and running.
In system implementation, user training is very difficult for minimizing resistance to change
and giving the new system a chance to prove its worth. Training aids, such as user friendly,
manuals, a data dictionary, job performance aids that communicate information about the
new system and “help” screens helps the user to work efficiently on the new system.
There are three types of implementation
Implementation of a computer system to replace a manual system. The problems encounter
are converting files, training users, creating accurate files and verifying printouts for
integrity.
Implementing of a new computer system to replace an existing one. This is usually a
difficult conversion. If not properly planned there can be many problems. Some large
computer system has taken as long as a year to convert.
Implementation of a modified application to replace an existing one using the same
computer. This type of conversion is relatively easy to handle, provided there are no major
changes in the files

4.4 Testing
Testing is the phase in which different module of the system are tested using different
testing techniques like black box testing, white box and unit testing etc.

4.4.1 Testing Strategy

The errors may occur at a very inception of the process where the objectives may be
erroneously or imperfectly specified. Because of human inability to perform and
communicate with perfection, software development is accompanied by a quality assurance
activity.

4.2.2 Testing Strategy that I used

The basic Strategies that are used for testing are following.
 Black box testing
 White box Testing
 Unit Testing
 System Testing
 Acceptance Testing

35 | P a g e
4.4.2.1Black box Testing
In Black Box testing only the functionality was tested without any regard to the code
written. If the functionality, which was expected from a component, is provided then black
box testing is completed. Black Box testing is also called as Behavioral testing because it
tests the functional requirements of the software. Black Box testing enables to derive sets of
input conditions that will fully exercise all functional requirements for a program. Black
Box testing is not an alternative to white-box techniques. Rather it is complementary
approach that is likely to uncover a different class of errors than white-box methods.

4.4.2.2 White Box Testing

In white Box testing internal code written in every component was tested and it was
checked that the code written is efficient in utilizing various resources of the system like
memory or the utilizing of input/output. White Box testing is a test case design method that
uses the control structure of the procedural design to derive test cases. Logical errors and
incorrect assumptions are inversely proportional to the probability that a program path will
be executed.

4.4.2.3 Unit Testing

In Unit testing I checked that the entire individual component is working properly. Before
integration of the entire component unit testing is essential because it gives a confidence
that all the component individually are working fine and ready to be integrated with the
other one.

4.4.2.4 System Testing

When all the units are working properly and unit testing was performed then the time for
system testing arrives, where I checked all the integrated components as a whole and looked
for possible discrepancies, which could have arisen after the integration.

4.4.2.5 Acceptance Testing

In acceptance testing the software was checked for completeness that it is ready. Normally
the quality assurance department performs the acceptance testing that the software is ready
and can be exported.

4.4.3 Debugging
Debugging is not testing but it occurs always as a consequence of testing. It begins with
execution of a test case. Results are assessed and lack of correspondence between expected
and actual performance is encountered. Debugging is one of the more frustrating parts of
programming. It has elements of problem solving or brainteasers coupled with the annoying
recognition that you have made a mistake. While testing my software I found some errors,
which I corrected in debugging modes. I found Syntax errors in Black box testing and
Logical errors in white-box testing.

36 | P a g e
4.4.3.1 Syntax Errors
These are caused by typographical errors & incorrect use of the Programming language.

4.4.3.2Logic Errors
These are caused by the incorrect use of the control structure. These errors were identified
while testing procedure and were corrected in debugging mode.

4.4 Test Cases

Following modules are tested using different testing strategies.

4.4.1 Test Case: 1. Login Module Testing

System: Al-Barq Hostel Management System.
Test:
Login form is opened and login and password is entered.
Instructions
1. Open the Login Form
2. Enter user name and password.
Expected Result
Message will appear that please enter correct user name and password.
Actual Result
The entered user name and password is correct, hence you can manage your software
system to make changes into the data and also can get the expected result you desire.

4.4.2 Test Case: 2. New Allocation Module Testing

System:Al-Barq Hostel Management System.
Test:
The New Allocation testing actually a testing in which it is notifiesthe Student that if the
new Student has unique id it will become a new registered Student .
Instructions
1. You can select the option for add new Allocation to add a new Student
2. Against the option you may find any more options.
Expected Result
The “New Allocation” form with its all basic information.
The testing will occur consequently on the selected option.

37 | P a g e
Actual Result
Result was as per expected on the behalf of the menu and the Room Is allocated

4.4.3 Test Case: 3. Add new Rooms

System:Al-Barq Hostel Management System.
Test
The insertion record testing module shows the information of the Room is provided
correctly. It needs some basic information like Id, Beds etc.
Instructions
1. Select add new room form from the main page and provide the required information.
2. Add new Room.
3. Update.
Expected Result
1. Errors may occur in a case if aproduct with duplicate id is added.
Actual Result
Confirmation of the Hostel of the new Room.

4.5 Testing summary

Testing of every module fulfils the requirement of user to check into the system that either
all the options are working correctly or not. To check and test a module it must get the
knowledge of the working type it holds. Many checking techniques are gathered to make
sure the testing criteria but it is the suitable option for the testing authority to attempt the
best one so that the testing technique make sure itself the working of the system.
In the above testing of Hostel Management it is confirmed the correct working of system
from every module contains this project.

38 | P a g e
 Plagiarism Report
This documentation contains original data it’s the combination of two parts SRS and SDD.
The SRS Part-I just 5% plagiaries and SDD Part -II just 21% plagiaries, Turnitin Plagiarism
report screen shorts are listed below.

39 | P a g e
 References

1 This document used following references:.

2 Admin of Bilal manzal hostel management system guides us about a lot of things
and points of Hostel management system and all students requirement.
3 Wikipedia
4 Internet
5 We also include friends suggestions in the software requirements specifications.
6 We also discuss all the contents, languages and further processes we are going to
include in the software requirements specifications documents to our supervisor
ma’am AfsahImtiazEllahi.
7 Supervisor also guides us about several things in Software requirements
specifications.
8 IEEE SRS Format.

40 | P a g e