SlideShare ist ein Scribd-Unternehmen logo
1 von 78
Downloaden Sie, um offline zu lesen
HOSTEL MANAGEMENT SYSTEM
Submitted in partial fulfilment of the requirements
for the award of the degree of
Computer Science
Year, th
Sem
To
Submitted To: Prepared By:
Mr/Mrs
1
ACKNOWLEDGEMENT
The project work in this report is an outcome of continual work and intellectual
support from various sources. It is almost impossible to express adequately the debts
owed to many persons who have been instrumental in imparting this work a successful
status. It is however a matter of great pleasure to express my gratitude and
appreciation to all those people who had helped in completion of this project.
We would like to take the opportunity to thank Mrs/Mr for giving us an opportunity
to work on this project, which not only has increased our awareness but also has
taught the importance of teamwork, it is because of her guidance, constant
encouragement and inspiration that we have been able to accomplish the task of
completing this project.
We express our sincere thanks to our project mentor.Mr/Mrs for their invaluable
guidance and frequent suggestions during the course of the project. Their suggestions
helped us to maintain a good quality of work. We express our deep gratitude to them.
Our special cordial thanks to Computer Science Department, INSTITUE NAME,
Location for its earnest efforts and guidance throughout out project work.
We also thank our lab assistants for allowing us to work in lab as need and for their
readiness to help us in all our difficulties.
name (roll no)
2
Institue name
location
Batch (20XX-20XX)
CERTIFICATE
This is to certify that this is a record of the project work on Hostel Management
System done sincerely and satisfactorily NAME .
This report has not been submitted for any other examination and does not form part
of any other course undergone by candidate and qualifies for submission of project
evaluation purpose.
Signature of candidate
name
Signature of project guide
name
3
LIST OF CONTENTS
I PROBLEM STATEMENT 6
II SOFTWARE REQUIREMENT SPECIFICATION (SRS) 7
1. Introduction 8
1.1 Purpose 8
1.2 Scope 8
1.3 Abbreviations & Acronyms 8
1.4 Objectives & Goals 9
1.5 References 9
1.6 Overview 10
2. Overall Description 11
2.1 Product Perspective 11
2.2 Product Functions 12
2.3 User Characteristics 12
2.4 Constraints 13
2.5 Assumptions & Dependencies 13
3. Specific Requirements 14
3.1 External Interfaces 14
3.2 Software Product Features 29
3.3 Performance Requirements 36
3.4 Design Constraints 37
3.5 Software System Attributes 37
3.6 Logical Databases 37
3.7 Other requirements 39
III SOFTWARE DESIGN DOCUMENTATION (SDD) 40
1. Introduction 41
1.1 Introduction (of the document) 41
1.2 Scope 41
4
2. Data Design 42
2.1 Introduction 42
2.2 Data Modelling 42
ER Diagram 42
Data Dictionary 46
3. Architectural Design 56
3.1 Introduction 56
3.2 Data flow Diagrams (DFDs) 56
4. Testing 62
4.1 Testing 62
4.2 Testing Procedures 62
4.3 Objectives of System Testing 62
4.4 Test Cases 64
5. Feasibility Study 67
5.1 Financial & Economic Feasibility 67
5.2 Technical Feasibility 67
5.3 Legal Feasibility 68
5.4 Schedule Feasibility 68
IV FUTURE EXTENSIONS 69
V CONCLUSION 69
VI BIBLIOGRAPHY 70
5
PROBLEM STATEMENT
The Hostel Management System is developed for automating the activities of hostel.
The software will be great relief to the employees. This software will help user in case
of reporting, registration and searching the information about residents and rooms.
The aim of the Hostel Management System is to carry out the activities of Hostel in an
efficient way. It will take the operations of Hostel to an upper level by providing faster
access to data and allowing addition, upgradation, modification, and deletion of data
in a very systematic and reliable manner.
EXISTING SCENARIO:
• All the work is done manually. Different copies of the student information are
kept for different departments.
• Room is allotted according to the room requirements and other special
facilities demanded by the student.
• Room categories: Single, Double, Air-Conditioned and Corner.
• Payment modes: Cash, Cheque and Draft.
• Hostel facilities and charges and other information are all kept in a booklet.
• Student’s information, staff information, fee records, student check-in and
check-out, room status, staff’s salary all these information are kept in
registers.
• All calculations relating to students’s fees, staff salary, fines and penalties,
hostel funds are done manually.
DRAWBACKS:
• The existing system is highly manual involving a lot of paper work and
calculation and therefore may be erroneous. This has lead to inconsistency and
inaccuracy in the maintenance of data.
• The data, which is stored on the paper only, may be lost, stolen or destroyed
due to natural calamity like fire and water.
• The existing system is sluggish and consumes a lot of time causing
inconvenience to students and the employees.
• Due to manual nature, it is difficult to update, delete, add or view the data.
• Since the number of students have drastically increased therefore maintaining
and retrieving detailed record of every student is extremely difficult.
FEATURES OF THE PROPOSED SYSTEM
• Long-term storage of records.
• High accuracy in calculations.
• Efficiency in modification, sorting and retrieval of data.
• Inexpensive updations in facilities and terms of organization.
• Utilization of time and workforce.
6
• Storage space for bulky record books can be ignored.
• Upgrades the level of working and presentation.
SOFTWARE REQUIREMENT
SPECIFICATION
1. INTRODUCTION
1.1. PURPOSE
The purpose is to make an automated system to carry out the various operation of
a Hostel. The system will provide the ease of use to the staff of the hostel by
performing all the work on a computer system rather than following a paper pen
approach. This approach helps improving the reliability of the data maintained and
provides a fast and efficient interface for the users of the software.
1.2. SCOPE
The software product “Hostel Management System” will be an application that
will be used for maintaining the records in an organized manner and to replace old
paper work system. This project aims at automating the hostel management for
smooth working of the hostel by automating almost all the activities. Updations
and modifications will be easily achievable and all the calculations and accounting
work would be accurate.
OUT OF SCOPE
The following features will not be delivered by the system:
• Employee Payroll
• Inventory Management
• Resident attendance
• Accounting Details except Hosteller’s Fee details
1.3. ABBREVATIONS AND ACRONYMS
7
DFD :- Data Flow Diagram
SRS :- Software Requirements Specification
ERD :- Entity Relationship Diagram
8
1.4. OBJECTIVES AND GOALS
 OBJECTIVE:
Automating basic hostel management activities.
The basic hostel management activities comprise of activities like:
• Room Allotment
• Bill Generation
• Maintaining Student’s Records
• Catering to Student’s Complaints
• Maintaining Employee Records
In course, they may face problems like:
• Data Redundancy
• Problems due to Human errors
• Tedious Maintenance of data
• Manually answering queries like: Residents with due fees, Facilities
availed by the resident, Number of empty rooms etc.
 GOAL
The goal of the system is to tackle these problems in an effective and optimal
manner by:
• Centralizing the database and thus providing consistent data to all the
employees in the hostel.
• Make the system more user friendly by providing an intensive user
interface.
• Easy access through queries and reports.
• Restricted data access to employees thus providing additional security
to data.
1.5. REFRENCES
9
 www.iitm.ipu.ac.in
 www.du.ac.in
 http://en.wikipedia.org/wiki/hostel_facilities
 http://en.wikipedia.org/wiki/seondary_data
1.6. OVERVIEW
The aim of the Hostel Management System is to carry out the activities of Hostel
in an efficient way. It will take the operations of Hostel to an upper level by
providing faster access to data and allowing addition, upgradation, modification,
and deletion of data in a very systematic and reliable manner.
10
2. OVERALL DESCRIPTION
2.1. PRODUCT PERSPECTIVE
 SYSTEM INTERFACES
Null.
 USER INTERFACES
• At the start, there will be a login screen where the user have to enter its
login name and password to authenticate himself.
• After the login, a homepage will be displayed showing all the
information and operations provided by the Hostel Management
System.
• All the operations available at the homepage will have a specific
routine that will be followed up in order to complete that operation. For
each operation, a different screen will be displayed demanding and
providing the information regarding the operation.
• A report will be generated for each student containing fee information,
fines dues and penalties, check-in and check-out information.
 HARDWARE INTERFACES
11
• Screen resolution: 800X600 or Higher.
• Support for printer that is, appropriate devices are installed and
connected printer will be required for printing of the reports.
• Desktop system, Handheld system-not a concern, as it will be possible
to run the application on any of these.
 SOFTWARE INTERFACES
• Operating System: Windows 95/98/XP or higher.
• Oracle as DBMS for database. Future release of the application will
aim at upgrading Oracle 8i as the DBMS.
• C++ for coding, developing the software.
 COMMUNICATION INTERFACES
Null.
 MEMORY CONSTRAINTS
• Min. 128 MB RAM.
• Min. 1 GB of Hard-disk space.
 SITE ADAPTATION REQUIREMENTS
All the hardware and software requirements should be fulfilled at the client’s
system.
2.2. PRODUCT FUNCTIONS
"Hostel Management System” is an attempt to simulate the basic management
system. The system enables to perform the following functions:
12
 Maintaining Resident Information
 Maintaining Room Information
 Maintaining Fee Information
 Maintaining Employee Information
 Searching, Sorting and Retrieval of the data
2.3. USER CHARACTERSTICS
 EDUCATIONAL LEVEL: At least user of the system should be
comfortable with English language.
 TECHNICAL EXPERTISE: User should be comfortable using general
purpose applications on the system.
13
2.4. CONSTRAINTS
 SOFTWARE CONSTRAINTS:
1. The system will run under windows 98 or above operating system.
2. the system must have word processor.
 HARDWARE CONSTRAINTS:
1. Minimum 128 MB RAM
2. Pentium III or above processor
3. Minimum 500 MB of Hard disk space
2.5. ASSUMPTIONS AND DEPENDENCIES
 Extensive documentation is available with the client
 Users will be having a valid user name an password to access the software
 Complete training is provided to all end users to handle the product
 The software would not take into account the business impact i.e. the risks
associated with constraints imposed by the management or the market
place.
14
15
3. SPECIFIC REQUIREMENTS
This section contains the software requirements to a level of detail sufficient to enable
designers to design the system and the tester to test that system.
3.1 EXTERNAL INTERFACES
This interface will be the actual interface through which the user will
communicate with the application and perform the desired tasks. The following
screens will be provided:
1.
Use case ID: - Manager wishes to login to the system.
Primary actor: - Manager
Pre-condition: - Usernames and passwords must be available beforehand.
Success End condition: - The main options screen is displayed.
Failed end condition: - User has entered incorrect username or password or both.
Main success scenario description
1. Select the “Log In” option from the desktop.
2. The following screen is displayed
16
3. Enter your username and password in the given spaces.
4. Click the “OK” button.
5. The main screen is displayed.
Scenario extension description
1. Click the “Cancel” option.
2. Desktop screen is displayed
3. Entered username or password or both are incorrect.
4. System asks to input again correctly, maximum up to 3 times, after which the
system is blocked.
17
2.
Use case ID: - Add new records
Goal in context: - Manager adds new record
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the main options screen.
Success end condition: - A room is available and the new record is added.
Failed end condition: - No room is available and new record cannot be inserted.
Main success scenario description
1. On the ‘Residents’ menu, and click ‘Resident Details’. The window titled
‘Resident Details’ will open.
2. The window will be displaying the first record of the database on opening.
Click the ‘Add’ button on the right of the screen.
3. All the entries of the fields will be cleared. You will see a number that’s been
randomly generated in the ‘Registration Number’ field.
4. Fill in the rest of the fields of the resident details i.e. the name, date of birth,
Category etc.
5. Make sure that certain fields such as ‘Facilities availed’ are checked
appropriately, and the dates are correct.
6. Click on “Save” button to save it in database.
18
Scenario extension description
1. Select the “Exit” button
2. It will return to the main screen
NOTE: Do not forget to click on the ‘Save’ button when you have filled up all
the fields and checked the details. Clicking on any other button will also erase
all the details filled up by you and not save the record. The record will not be
saved until you do so.
19
3.
Use case ID: - Selecting an existing room by registration no.
Goal In context: - Manager wishes to select a particular room from the list
displayed.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - All the rooms and fair details are presented.
Failed end condition: - No room and fair details are presented.
Main success scenario description
1. In the ‘Residents’ menu, and click ‘Resident Details’. The window titled
‘Resident Details’ will open.
The window will be displaying the first record of the database on opening.
20
1. In order to search a record by its registration number, select the ‘Registration
number’ from the drop down list of ‘Search records by’ in the window.
2. On doing so, you will get a list of all the saved registration numbers in the
database in the adjacent drop down list named ‘Select records to view details’.
3. From the list select the required registration number by clicking on it.
4. All details related to the particular registration number will be displayed in the
window.
5. You can scroll through the records preceding and following the particular
record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button
respectively at the bottom of the screen.
6. The first record and the last record of the database can be viewed by clicking
on the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the
records at the beginning and the end of the database.
21
4.
Use case ID: - Selecting existing resident details by resident name.
Goal In context: - Manager wishes to select particular resident details from the
list displayed.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - All the rooms and fair details are presented.
Failed end condition: - No room and fair details are presented.
1. In the menu of the main window, select the resident tab, and click ‘Resident
Details’. The main window titled ‘Resident Details will open:
The window will be displaying the first record of the database on opening.
22
2. In order to search a record by its registration number, select the ‘Resident
name’ from the drop down list of ‘Search records by’ in the window.
3. On doing so, you will get a list of all the saved resident names in the database
in the adjacent drop down list named ‘Select records to view details’.
4. From the list select the required resident name by clicking on it.
5. All details related to the particular resident name will be displayed in the
window.
6. You can scroll through the records preceding and following the particular
record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button
respectively at the bottom of the screen.
7. The first record and the last record of the database can be viewed by clicking on
the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the
records at the beginning and the end of the database.
23
5.
Use case ID: - Selecting existing resident details by setting options.
Goal In context: - Manager wishes to select a particular room from the list
displayed.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - All the rooms and fair details are presented.
Failed end condition: - No room and fair details are presented.
You can select certain options for searching records in the database. For this you
need to click on the ‘Set options’ button at the right hand side of the ‘Resident
Details’ window.
You will have the option of setting the search option of searching the records of
existing i.e. the presently residing hostel residents and/or the records of previous
residents of the hostel in the following window:
24
6.
Use case ID: - Editing an existing room.
Goal In context: - Manager wishes to edit a particular room.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - All the rooms and fair details are presented.
Failed end condition: - No room and fair details are presented.
To edit existing resident records in the database, first search the record you want to
edit. Then click the ‘Edit’ button on the right hand side of the ‘Resident Details’
window:
This will allow you to edit the currently displayed resident record. You can edit
each of the fields of the record and finally after reviewing the changes, save the
record by pressing the ‘Save’ button
NOTE: Do not forget to click on the ‘Save’ button when you have edited all
the required fields and checked the details. Clicking on any other button will
erase all the details filled up by you and not save the record.
NOTE: You may not be allowed to edit records depending on the privileges
assigned to you by the system administrator.
25
7.
Use case ID: - Deleting existing resident details.
Goal In context: - Manager wishes to delete a particular resident details .
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - Actor has successfully deleted the details.
Failed end condition: - No details are presented.
In order to delete a resident record in the database, first search the desired record
from the database that you want to delete. Then click the ‘Delete’ button on the
right hand side of the ‘Resident Details’ window:
You will get a warning from the system confirming your will to delete a record.
Click yes to ‘Delete’ the record or ‘Cancel’ to abort deletion.
NOTE: Be careful about deleting records from the database as such changes
cannot be reverted.
NOTE: You may not be allowed to delete records depending on the privileges
assigned to you by the system administrator.
26
8.
Use case ID: - Searching existing room details.
Goal In context: - Manager wishes to search particular room detail .
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - Actor has successfully searched the details.
Failed end condition: - No details presented.
To search a room record, follow these steps:
4. In the main window of HMS, select the ‘Rooms’ tab and click on the ‘Room
Allotment Details’.
5. A screen on ‘Room Allotment’ will open. Now select the room number of the
room whose details you intend to view from the list of room numbers displayed.
6. The details of the particular room will be displayed.
7. The details of the resident(s) residing in the particular room can be viewed by
clicking on the ‘Resident Details’ tab on the right hand side of the ‘Room Details’
window.
8. You can scroll through the records preceding and following the particular
record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button
respectively at the bottom of the screen.
9. The first record and the last record of the database can be viewed by clicking
on the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the
records at the beginning and the end of the database.
27
9.
Use case ID: - Adding room details.
Goal In context: - Manager wishes to add new room detail.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - Actor has successfully added the details.
Failed end condition: - No room is empty.
To add a new room and its details in the database follow these steps:
1. In the ‘Room Details’ window click on the ‘Add’ button.
2. Fills the details in the fields with the correct values and select the ‘Vacancy’
field value from the list according to the following convention:
a. ‘X’ (where x is the full capacity of the room e.g. 3): If a particular
room is completely occupied.
b. 0: If the room is empty i.e. no one is residing in that room.
c. -1: If the room is under repair/ not available for allotment.
3. After you have filled up all the details, click on the ‘Save’ button to save the
record of that room.
NOTE: Do not forget to click on the ‘Save’ button after you filled up all the
fields and checked the details. Clicking on any other button will erase all the
details filled up by you and not save the record.
28
10.
Use case ID: - Editing room details.
Goal In context: - Manager wishes to edit a room detail.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - Actor has successfully made the changes.
Failed end condition: - No room detail is available.
1. To edit existing room records in the database, first search the record you
want to edit. Then click the ‘Edit’ button on the right hand side of the ‘Room
Details’ window:
2. Edit the particulars of the room that you wish to change. .
3. Click on the ‘Save’ button after you have edited all the required fields.
NOTE: Do not forget to click on the ‘Save’ button when you have edited all
the required fields and checked the details. Clicking on any other button will
erase all the details filled up by you and not save the record.
NOTE: You may not be allowed to edit records depending on the privileges
assigned to you by the system administrator.
29
11.
Use case ID: - Deleting room details.
Goal In context: - Manager wishes to delete a room detail.
Primary actor: - Manager
Pre-condition:- Actor has successfully navigated to the search results.
Success end condition: - Actor has successfully made the changes.
Failed end condition: - No room detail is available.
In order to delete a room record in the database, first search the desired record
from the database that you want to delete. (Refer Section 5a.) Then click the
‘Delete’ button on the right hand side of the ‘Room Details’ window:
You will get a warning from the system confirming your will to delete a record.
Click yes to ‘Delete’ the record or ‘Cancel’ to abort deletion.
NOTE: Be careful about deleting records from the database as such changes
cannot be reverted.
NOTE: You may not be allowed to delete records depending on the privileges
assigned to you by the system administrator.
30
3.2 SOFTWARE PRODUCT FEATURES
Hostel Management System
3.2.1 Login Information Maintenance
 Description
The system will maintain the login information of its user.
 Validity checks:
• Administrator needs to login with a unique id and password.
• Only authorized user distinguished by the password can make
modifications to the system.
• The login id should be a string of alphanumerics of length not
exceeding 30 characters.
• The password should be a string of alphanumerics of minimum
length of 8 characters and maximum of 20 characters.
• Login id cannot be NULL.
• Password cannot be NULL.
 Sequencing information
Login information has to be filled in before the user is allowed to choose
from the options such as Menu Item Details, Facilities and Room Details
and Payment Details.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.2 Resident Information Maintenance
 Description
The system will maintain the resident information regarding the personal
details of the customer. It contains the name, code, address and phone no.
of each resident that can be added/modified/deleted.
 Validity checks:
• Only the administrator can modify/delete the room and resident
details.
31
• The resident name should be a string of alphanumeric with length
upto 20 characters.
• The registration ID is auto generated and should be a number of 6
digits.
• The resident address contains city information that should be a
string of alpha numeric of length upto 40 characters.
• The resident phone no. should a number of minimum length of 8
digits and maximum of 10 digits.
• The resident code cannot be NULL.
• The resident name cannot be NULL.
 Sequencing information
Resident information has to be filled in before the user is allowed choose
from the options such as Menu Item Details, Facilities, Room details and
Payment Details.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.3 Employee Information Maintenance
 Description
The system will maintain the employee information including an
employee’s personal and professional details being needed by the
organization. It contains the employee name, id no., address, phone no.,
department, designation, basic salary of each that can be
added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the employee
details.
• The employee name should be a string of alphanumeric with
length upto 20 characters.
• The employee id no. should be a number of 6 digits which is
unique for each employee.
• The employee designation should be a string of alphabets of
length upto 15 characters.
32
• The employee address should be a string of alphanumerics of
length upto 40 characters.
• The employee phone no. should be a number with minimum
length of 8 digits and maximum of 10 digits.
• Employee basic salary should be a number in the range 0-50,000.
• Employee id cannot be NULL.
• Employee basic salary cannot be NULL.
 Sequencing information
Employee information has to be filled in every month for proper
increments to be added to the employee salary.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.4 Local Guardian Information Maintenance
 Description
The system will maintain the resident’s local guardian information being
needed by the organization. It contains the local guardian name, address,
phone no. that can be added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the local guardian
details.
• The local guardian name should be a string of alphanumeric with
length upto 20 characters.
• The local guardian address should be a string of alphanumerics of
length upto 40 characters.
• The local guardian phone no. should be a number with minimum
length of 8 digits and maximum of 10 digits.
 Sequencing information
Local guardian information has to be filled at the same time when the
resident information has been filled.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
33
3.2.5 Relative Information Maintenance
 Description
The system will maintain the resident’s relative information being
needed by the organization. It contains the relative name, address, phone
no. that can be added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the relative details.
• The relative name should be a string of alphanumeric with length
upto 20 characters.
• The relative address should be a string of alphanumerics of length
upto 40 characters.
• The relative phone no. should be a number with minimum length
of 8 digits and maximum of 10 digits.
 Sequencing information
Relative information has to be filled at the same time when the resident
information has been filled.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.6 Room Information Maintenance
 Description
The system will maintain the room information including room no, type,
vacancy and phone num. being needed by the organization. The
information can be added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the room details.
• The room no should be a number of 3 digits.
• The room type should be a string of alphanumeric of length upto
15 characters.
• The room vacancy should be a number of 2 digits.
34
• The room phone no. should be a number with minimum length of
8 digits and maximum of 10 digits.
• Room no cannot be NULL.
• Room type cannot be NULL.
 Sequencing information
Room information has to be filled in before the user is allowed to choose
that room from the options displayed for his desired facilities.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.7 Fees Information Maintenance
 Description
The system will maintain the fee information of all its residents. It
contains the fee amount, type and frequency each resident that can be
added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the fee details.
• The fee amount should be a number in the range 0-30000.
• The fee type should be a string of alphanumeric of length upto 15
characters.
• The fee frequency should be a string of alphanumeric of length
upto 15 characters.
• Fee amount cannot be NULL.
 Sequencing information
Fee information is filled in after the resident has chosen his required
room and facilities.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
35
3.2.8 Complaint Information Maintenance
 Description
The system will maintain the complaint information for all of its
residents. It contains the complaint details, ID, reg no, room no, status,
complaint date for each resident that can be added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the complaint
details.
• The room no should be a number of 3 digits.
• The complaint details should be a string of alphanumeric of
length upto 15 characters.
• The complaint ID should be a number of 5 digits.
• The reg no. should be a number of 6 digits.
• The complaint status should be a string of alphanumeric of length
upto 10 characters.
• Room no cannot be NULL.
• Reg no. cannot be NULL.
• Complaint ID cannot be NULL.
 Sequencing information
Complaint information has to be filled in before the processing of the
complaint.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.9 Organization Information Maintenance
 Description
The system will maintain the organization information for all of its
residents. It contains the organization name, email ID, reg no, phone no
and address for each resident that can be added/modified/deleted.
36
 Validity checks:
• Only the administrator can add/modify/delete the organization
details.
• The organization name should be a string of alphanumeric with
length upto 20 characters.
• The organization address should be a string of alphanumerics of
length upto 40 characters.
• The organization phone no. should be a number with minimum
length of 8 digits and maximum of 10 digits.
• The reg no. should be a number of 6 digits.
• Reg no. no cannot be NULL.
 Sequencing information
Relative information has to be filled at the same time when the resident
information has been filled.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.2.10 Payment Information Maintenance
 Description
The system will maintain the payment information for all of its residents.
It contains the payment type, transaction ID, due date, date of payment
and receipt no for each resident that can be added/modified/deleted.
 Validity checks:
• Only the administrator can add/modify/delete the payment details.
• The reg no. should be a number of 6 digits.
• The payment type should be a string of alphanumeric with length
upto 15 characters.
• The payment date should be a string of alphanumerics of length
upto 10 characters.
• The payment due date should be a string of alphanumerics of
length upto 10 characters.
37
• The payment transaction ID should be a number of 10 digits.
• The payment receipt no should be a number of 10 digits.
• Reg no. no cannot be NULL.
• Payment transaction ID cannot be NULL.
• Payment receipt no. cannot be NULL.
 Sequencing information
Fee information should be calculated every month or every two months
or quarterly as chosen by the resident in his fee frequency.
 Error Handling
If any of the validations/sequencing flow does not hold true system will
display proper error messages for the user to do the needful.
3.3 PERFORMANCE REQUIREMENTS
 USER FRIENDLY:
The system should be user friendly so that it can easily be understand by the
user without any difficulty.
 EASE OF MAINTENANCE:
The system should be easy to maintain and use.
 LESS TIME CONSUMING:
The system should be less time consuming which could be achieved by
good programming.
 ERROR FREE:
The system should easily handle the user error in any case.
 STATIC:
Software runs on standalone machine. Support only single user.
38
3.4 DESIGN CONSTRAINTS
None.
3.5 SOFTWARE SYSTEM ATTRIBUTES
 SECURITY:
The system should be secure from the unauthorized access and should be
password protected so that no other user can access it.
 PORTABILITY:
The system should be machine independent.
 MAINTAINABILITY:
The system will be designed in a maintainable order. The system can be easily
modified and renewed according to the need of the organization.
3.6 LOGICAL DATABASES
S.no. Entity Attributes
1. Log In Log in ID
Password
39
2. Resident Registration No.
First name
Last name
Date of birth
Local address
State
Pin code
Country
Telephone no.
Occupation
Email ID
Gender
3. Fees Fees type
Charges
Frequency
4. Room Room no.
Room type
Vacancy
5. Employee Employee ID
First name
Last name
Designation
Email
Address
Telephone no.
Date of birth
Salary
6. Complaint Complaint ID
Complaint date
Particulars
Status
Registration no.
Room no.
7. Local guardian Registration no.
First name
Last name
Email
Address
State
Telephone no
8. Relative Registration no.
First name
Last name
Email
Address
State
Telephone no
Relation
40
9. organization Registration no.
Name
Email
Address
Telephone no.
10. payments Registration no.
Type
Transaction ID
Due date
Date of payment
Receipt no.
3.7 OTHER REQUIREMENTS
 CORRECTNESS:
It is defined as the extent to which program satisfies specifications, fulfils
user’s requirements.
 EFFICIENCY:
It is defined as the extent to which the amount of computing resources and
code required to perform function.
 FLEXIBILITY:
It is defined as the extent to which effort needed to modify operational
programs.
 TESTABILITY:
It is defined as the extent to which effort needed to test to ensure performance
as intended.
 REUSABILITY:
It is defined as the extent to which effort it can be reused in another
application.
41
SOFTWARE
DESIGN
DOCUMENTATION
42
1. INTRODUCTION
1.1 INTRODUCTION (of the document)
Software Design sits at the kernel of software engineering and is applied
regardless 7of the software process model that is used. Beginning once software
requirements have been analyzed and specified, software design is the first of three
technical activities- designs, code, generation and test- that are required to build
and verify the software. Each activity transforms information in a manner that
ultimately results in validated computer software.
Software design is more creative process rather than analysis coz it deals with the
development of the actual mechanics for a new workable system. While analyzing,
it is possible to produce the correct model of an existing system. However, there
is, no such thing a correct design. Good design is always system dependent and
what is good design for one system may be bad for another.
A SRS document tells us what a system does, and becomes input to the design
process, which tells us how a software system works. Designing software system
means determining how requirements are realized and result is a software design
document (SDD). Thus the purpose of the design phase is to produce a solution to
a problem given in SRS document.
The flow of information during software design is illustrated in fig1. Software
requirements, manifested by the data, functional and behavioral models feed the
design tasks. Using number of design methods the design tasks produces a data
design, an architectural design, an interface design and a component design.
1.2 SCOPE
The most challenging and creative phase of the system life cycle is SYSTEM
DESIGN. It shows how the software system will be structured to satisfy the
requirements identified in the SRS. It refers to the technical specifications that will
meet the stated requirements. The design specifications that get generated at the
end of this phase are technical in nature and are the blueprint for the
implementation activity.
Thus the scope of SDD encompasses:-
 User interface
 Manual procedure
 Data base design
43
 Program structure
44
2. DATA DESIGN
2.1 INTRODUCTION
The data design transforms the information domain model created during analysis
into the data structures that will be required to implement the software. The data
object and relationships defined in the entity relationship diagram and the detailed
data content depicted in the data dictionary provides the basis for the data design
of software architecture.
Data design also referred as data architecting creates a model of data that is
represented at a high level of abstraction. This data model is then refined into
progressively more implementation specific representation that can be processed
by the computer- based system. The data object defined during software
requirement analysis is modeled using ERD. The data design translates these
elements of the requirements model into data structures at the software component
level and, when necessary, a database architecture at the application level.
2.2 DATA MODELING
Data modeling is a well-established pseudo-discipline. Most people in the
information technology field are familiar with some kind of data structure diagram
(sometimes referred to more specifically as entity relationship diagrams. There are
innumerable software products each of which supports the preparation of one or
more variants of data modelling and sometimes additionally some other kind of
modelling, such as data flow diagrams.
The term "data modelling" is usually interpreted as implying a diagramming
technique. There are many such diagramming techniques in use worldwide.
ER DIAGRAM
 Cardinality
Cardinality is the specification of the number of occurrences of one [object]
that can be related to the number of occurrences of another [object].
Cardinality is usually expressed as simply 'one' or 'many.' For example, a
husband can have only one wife (in most cultures), while a parent can have
many children. Taking into consideration all combinations of 'one' and 'many,'
two [objects] can be related as
45
• One-to-one (l:l): An occurrence of [object] 'A' can relate to one and only one
occurrence of [object] 'B,' and an occurrence of 'B' can relate to only one
occurrence of 'A.'
• One-to-many (l:N): One occurrence of [object] 'A' can relate to one or many
occurrences of [object] 'B,' but an occurrence of 'B' can relate to only one
occurrence of 'A. 'For example, a mother can have many children, but a child
can have only one mother.
• Many-to-many (M:N): An occurrence of [object] 'A' can relate to one or
more occurrences of 'B,' while an occurrence of 'B' can relate to one or more
occurrences of 'A. 'For example, an uncle can have many nephews, while a
nephew can have many uncles.
 Modality
The modality of a relationship is 0 if there is no explicit need for the
relationship to occur or the relationship is optional. The modality is 1 if an
occurrence of the relationship is mandatory. To illustrate, consider software
that is used by a local telephone company to process requests for field service.
A customer indicates that there is a problem. If the problem is diagnosed as
relatively simple, a single repair action occurs. However, if the problem is
complex, multiple repair actions may be required.
It represents Cardinality N(more than one data objects) and
Modality 0.
It represents Cardinality N(more than one data objects) and
Modality 1.
It represents Cardinality 1(one data object) and Modality 0.
It represents cardinality 1(one data object) and Modality 1.
The relationships that exist between the data objects are:-
46
S. No. RELATIONSHIP PARTICIPATING ENTITIES
1. Belongs To Resident, Organization
2. Has A Resident, Local Guardian
3. Has A Resident, Relative
4. Pays Resident, Fees
5. Files Resident, Complaints
6. Is Allotted Resident, Room
7. Are Handled By Complaints, Warden
47
48
DATA DICTIONARY
1.
Name:-Login
Aliases:-None
Where used / how used:-Administrator wants to login
Description:-Stores the login ID and Password.
S. no Field name Data type Description
1. Login ID Characters (30) Login Name of the
Administrator
2. Password Characters (20) Password of the
Administrator
49
2.
Name:-Resident
Aliases:-None
Where used / how used:-A resident wants to take a room.
Description:-Stores the details of all residents of the hostel including past
residents
S. no Field name Data type Description
1. First name Characters (20) First name of the
resident
2. Last name Characters (20) Last name of the resident
3. Address Both characters and
numbers. (40)
Residential address of
the resident
4. Phone no. Integer (10) Phone number of
resident
5. Email ID Characters, numbers and
symbols (30)
e-mail id of the resident
6. Gender One character long (1) Sex of the resident
7. Registration no. Integer (6) Registration no. of the
resident
8. Date of birth Both characters and
numbers ((10)
Date of birth of the
resident
9. State Characters (10) State of the resident
10. Pin code Integer (10) Pin code of the state
11. Country Characters (20) Country of the resident
where he/she lives
12. Occupation Characters (20) Occupation of the
resident
50
3.
Name:-Fees
Aliases:-None
Where used / how used:-To calculate the fees of a room.
Description:- Stores the amount of fees for different fee heads like Security,
Mess Charges etc.
S. no Field name Data type Description
1. Fees type Characters (15) Type of the fees
2. Charges Integer (5) Monthly amount to
be paid
3. Frequency Characters (15) The frequency at
which the fees is
collected
51
4.
Name:-Room
Aliases:-None
Where used / how used:-A resident wants to take a room.
Description:- Keeps record of the rooms that have been allotted
S. no Field name Data type Description
1. Room no. Integer (3) Identifies a unique
room no.
2. Room type Characters (15) Category of rooms
3. Vacancy Integer (2) The number of people
that can be
accommodated in the
room apart from those
already staying
4. Phone no. Integer (10) Phone number of
resident
52
5.
Name:-Employee
Aliases:-None
Where used / how used:-to store the details of an employee.
Description:-Stores the details of all employees in the hostel.
S. no Field name Data type Description
1. First name Characters (20) First name of the
employee
2. Last name Characters (20) Last name of the
employee
3. Address Both characters
and numbers. (40)
Residential address of
the employee
4. Phone no. Integer (10) Phone number of
employee
5. Email ID Characters,
numbers and
symbols (30)
e-mail id of the
employee
6. Designation characters (15) Designation of the
employee
7. Employee ID Integer (6) ID of the employee
8. Date of birth Both characters
and numbers (10)
Date of birth of the
employee
9. Salary Integer (5) Salary of the
employee
53
6.
Name:-Complaint
Aliases:-None
Where used / how used:-to store the complaint details.
Description:-Stores the details of all complaints in the hostel.
S. no Field name Data type Description
1. Complaint date Both characters
and numbers. (10)
Date of issue of
complaint
2. Particulars Characters (60) Details of that
complaint
3. Status Characters (10) Current status of the
complaint
4. Registration no. Integer (6) Registration Number of
the resident who made
the complaint
5. Complaint ID Integer (5) Complaint
identification no.
6. Room no. Integer (3) The room number
associated with the
complaint
54
7.
Name:-Local Guardian
Aliases:-None
Where used / how used:-to store the details of local guardian.
Description:- Stores the record of the local guardians associated with each
resident
S. no Field name Data type Description
1. Registration
no.
Integer (6) Registration no. of the
resident
2.. First name Characters (20) First name of the local
guardian of the
resident
3.. Last name Characters (20) Last name of the local
guardian of the
resident
4. Email ID Both Characters
and numbers. (30)
Email ID of the local
guardian of the
resident
5. Address Both Characters
and numbers (40)
Address of the local
guardian of the
resident
6. State Characters (10) State as a part of the
address
7. Telephone no. Integer (10) Phone no. of the local
guardian of the
resident
55
56
8.
Name:-Relative
Aliases:-None
Where used / how used:-to store the details of relative.
Description:- Stores the record of the local relatives associated with each
resident
S. no Field name Data type Description
1. Registration
no.
Integer (6) Registration no. of the
resident
2.. First name Characters (20) First name of the
relative of the resident
3.. Last name Characters (20) Last name of the
relative of the resident
4. Email ID Both Characters
and numbers. (30)
Email ID of the
relative of the resident
5. Address Both Characters
and numbers (30)
Address of the relative
of the resident
6. State Characters (10) State as a part of the
address
7. Telephone no. Integer (10) Phone no. of the
relative of the resident
8. Relation Characters (10) Relation of the
resident with the
relative, should be
husband or either
parent.
57
9.
Name:-Organization
Aliases:-None
Where used / how used:-to store the details of organization.
Description:- Stores the name, contact details of the organization where the
resident is an employee/student
S. no Field name Data type Description
1. Registration no. Integer (6) Gives the registration
number
2. Name Characters (20) Name of the
organization/institute of
the resident
3. Email ID Both Characters
and numbers. (30)
Email id of the
organization of the
resident
4. Address Both Characters
and numbers (40)
Address of the
organization of the
resident
5. Telephone no. Integer (10) Phone no. of the
organization of the
resident
58
10.
Name:-Payments
Aliases:-None
Where used / how used:-to store the details of payments.
Description:- Stores the payment details of the residents
S. no Field name Data type Description
1. Registration no. Integer (6) Gives the registration
number
2. Type Characters (15) Type of the facility
3. Transaction ID Integer (10) Stores the payment
details of the residents
4. Due date Both Characters
and numbers (10)
Date on which the
payment is due
5. Receipt no. Integer (40) Receipt Number given
to the resident
6. Date of payment Both Characters
and numbers (10)
Date on which the
payment is made
59
3. ARCHITECTURAL DESIGN
3.1 INTRODUCTION
The architectural design defines the relationship between major structural elements
of the software, the design pattern that can be used to achieve the requirements
that have been defined for the system, and the constraints that effect the way in
which architectural design patterns that- can be applied. The architectural design
representation-the framework of the computer-based system- can be derived from
the system specification, the analysis model and the interaction of sub systems
defined within the analysis model.
3.2 DATA FLOW DIAGRAMS (DFDs)
DFD Notations
: It represents a process or transform that is applied to data.
: It represents data store-stored information that is used by
Software
: It represents an entity.
60
or
 LEVEL ZERO
61
 LEVEL ONE
62
63
 LEVEL TWO
LOGIN
ROOM ALLOCATION-TERMINATION & RESIDENT REGISTRATION
64
EMPLOYEE DETAIL MAINTENANCE
FEE MANAGEMENT
65
COMPLAINT MANAGEMENT
66
4. TESTING OF THE DOCUMENT
4.1 TESTING
Testing often accounts for more project than any other software engineering
activity. If it is conducted haphazardly, time is wasted, unnecessary effort is
expended, and even worse, errors sneak through undetected. It would therefore
seem reasonable to establish a systematic strategy for testing software. The
software testing is a critical step of the software quality assurance and represents
the ultimate review of specification, design and code generation.
4.2 TESTING PROCEDURES
 UNIT TESTING: This is the testing of an individual module and is
usually carried out to ensure the validity of a particular module.
NOTE: It makes use of white box testing technique.
 INTEGRATED TESTING: Integrated testing is the testing of the system
modules. This is done to identify errors, which relate to the interaction of
different module, which cannot be found by unit testing but only through
an interactive testing.
NOTE: It makes use of black box testing technique.
 SYSTEM TESTING: System testing is the testing of the system against
its initial objectives. It is done either in a simulated environment or in a
live environment.
 VALIDATION TESTING: Validation testing is the testing where
requirement established as part of software requirement analysis are
validated against the software that has been constructed.
NOTE: It makes use of black box testing technique.
4.3 OBJECTIVES OF SYSTEM TESTING
Once a system has been designed, it is necessary to undergo an exhaustive testing
before installing the system. This is important because in some cases a small
system error, not detect and corrected early before installation, may explode into a
67
much larger problem later on. Testing is performed when user is asked to assist in
identifying all possible situations. That might arise as regards the factors that effort
was put to tackle the problem under consideration.
68
Any engineering product can be tested in one of two ways:
 Knowing the specified function that a product has been designed to
perform.
 Knowing the internal working of the product.
The first test approach is called black box testing and the second, white box
testing.
When computer software is considered, black box testing alludes to tests that are
conducted at the software interface. Although they are designed to uncover errors,
black box tests are used to demonstrate that software functions are operational,
that input is properly accepted and output is correctly produced, and the integrity
of external information is maintained. A black box test examines some
fundamental aspects of a system with little regard for the internal logical structure
of the software.
Black-box test design techniques include:
• Graph-based testing methods
• Equivalence partitioning
• Boundary value analysis
• Comparison testing
• Orthogonal Array Testing
White box testing of software is predicted on close examination of procedural
detail. Providing test cases that exercise specific conditions and/or loops tests
logical paths through the software.
White-box test design techniques include:
• Control flow testing
• Data flow testing
• Branch testing
• Path testing
During development, the software has to pass through a number of stages. At each
of these stages we have the probability of committing errors. It is actually the
inability of humans to communicate with perfection that introduces a step of
quality assurance, which is carried out after software development. Testing
represents the ultimate review of specification, design and coding.
Testing is carried out with the intent of finding errors, which always exist in
software, no matter how stringent the checks may be. This step can never show the
defects, it can only show their presence.
69
70
4.4 TEST CASES
 Login Information Maintenance
The login id should be a string of alphanumerics of length not exceeding 30 characters.
The password should be a string of alphanumerics of minimum length of 8 characters
and maximum of 20 characters.
Login id cannot be NULL.
Password cannot be NULL.
 Resident Information Maintenance
The resident name should be a string of alphanumeric with length upto 20 characters.
The registration ID is auto generated and should be a number of 6 digits.
The resident address contains city information that should be a string of alpha numeric
of length upto 40 characters.
The resident phone no. should a number of minimum length of 8 digits and maximum
of 10 digits.
The resident code cannot be NULL.
The resident name cannot be NULL.
 Employee Information Maintenance
The employee name should be a string of alphanumeric with length upto 20 characters.
The employee id no. should be a number of 6 digits which is unique for each employee.
The employee designation should be a string of alphabets of length upto 15 characters.
The employee address should be a string of alphanumerics of length upto 40 characters.
The employee phone no. should be a number with minimum length of 8 digits and
maximum of 10 digits.
Employee basic salary should be a number in the range 0-50,000.
Employee id cannot be NULL.
Employee basic salary cannot be NULL.
71
 Local Guardian Information Maintenance
The local guardian name should be a string of alphanumeric with length upto 20
characters.
The local guardian address should be a string of alphanumerics of length upto 40
characters.
The local guardian phone no. should be a number with minimum length of 8 digits and
maximum of 10 digits.
 Relative Information Maintenance
The relative name should be a string of alphanumeric with length upto 20 characters.
The relative address should be a string of alphanumerics of length upto 40 characters.
The relative phone no. should be a number with minimum length of 8 digits and
maximum of 10 digits.
 Room Information Maintenance
The room no should be a number of 3 digits.
The room type should be a string of alphanumeric of length upto 15 characters.
The room vacancy should be a number of 2 digits.
The room phone no. should be a number with minimum length of 8 digits and
maximum of 10 digits.
Room no cannot be NULL.
Room type cannot be NULL.
 Fees Information Maintenance
The fee amount should be a number in the range 0-30000.
The fee type should be a string of alphanumeric of length upto 15 characters.
The fee frequency should be a string of alphanumeric of length upto 15 characters.
Fee amount cannot be NULL.
72
 Complaint Information Maintenance
The room no should be a number of 3 digits.
The complaint details should be a string of alphanumeric of length upto 15 characters.
The complaint ID should be a number of 5 digits.
The reg no. should be a number of 6 digits.
The complaint status should be a string of alphanumeric of length upto 10 characters.
Room no cannot be NULL.
Reg no. cannot be NULL.
Complaint ID cannot be NULL.
 Organization Information Maintenance
The organization name should be a string of alphanumeric with length upto 20
characters.
The organization address should be a string of alphanumerics of length upto 40
characters.
The organization phone no. should be a number with minimum length of 8 digits and
maximum of 10 digits.
The reg no. should be a number of 6 digits.
Reg no. no cannot be NULL.
 Payment Information Maintenance
The reg no. should be a number of 6 digits.
The payment type should be a string of alphanumeric with length upto 15 characters.
The payment date should be a string of alphanumerics of length upto 10 characters.
The payment due date should be a string of alphanumerics of length upto 10 characters.
The payment transaction ID should be a number of 10 digits.
The payment receipt no should be a number of 10 digits.
Reg no. no cannot be NULL.
Payment transaction ID cannot be NULL.
Payment receipt no. cannot be NULL.
73
5. FEASIBILITY STUDY
It aim to objectively and rationally uncover the strengths and weaknesses of the
existing software, opportunities and threats as presented by the environment, the
resources required to carry through, and ultimately the prospects for success.
5.1 FINANCIAL AND ECONOMIC FEASIBILITY
For any system if the expected benefits equal or exceed the expected costs, the
system can be judged to be economically feasible. In economic feasibility, cost
benefit analysis is done in which expected costs and benefits are evaluated.
Economic analysis is used for evaluating the effectiveness of the proposed system.
In economic feasibility, the most important is cost-benefit analysis. As the name
suggests, it is an analysis of the costs to be incurred in the system and benefits
derivable out of the system.
When it comes to HOSTEL MANAGEMENT SYSTEM project, the project is
privately sponsored by the organization. Sponsoring such a project will not be a
problem for the organization as this S/W will decrease the time of various
operations and working of hostel by providing an automated system which takes
lesser time as compare to other means. The Project will enable user to perform all
the operations of the hostel quickly and correctly without any problem.
5.2 TECHNICAL FEASIBILITY
The assessment is based on an outline design of system requirements in terms of
Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified
in terms of volumes of data, trends, frequency of updating, etc. in order to estimate
whether the new system will perform adequately or not. Technological feasibility
is carried out to determine whether the company has the capability, in terms of
software, hardware, personnel and expertise, to handle the completion of the
project when writing a feasibility report, the following should be taken to
consideration:
 A brief description of the business
 The part of the business being examined
 The human and economic factor
 The possible solutions to the problems
74
At this level, the concern is whether the proposal is both technically and legally
feasible (assuming moderate cost)
75
5.3 LEGAL FEASIBILIY
It includes study concerning contracts, liability, violations, and legal other traps
frequently.
Our HOSTEL MANAGEMENT SYSTEM project is legally feasible as all the
licenses required for this project development and working are already taken from
the authorities.
5.4 SCHEDULE FEASIBILITY
A project will fail if it takes too long to be completed before it is useful. Typically
this means estimating how long the system will take to develop, and if it can be
completed in a given time period using some methods like payback period.
Schedule feasibility is a measure of how reasonable the project timetable is. Given
our technical expertise, are the project deadlines reasonable?
Our HOSTEL MANAGEMENT SYSTEM project is not schedule wise feasible as
the development of the S/W is done within the time bound assigned and is
completed according to the timetable.
76
FUTURE EXTENSIONS
 Employee Payroll: We can include the facility in this system that will
generate payroll for all the employees of the hostel.
 Resident attendance: The attendance of resident will be marked each time
the resident enters or leaves the hostel premises.
 Accounting Details except Hosteller’s Fee details: All the other
accounting details can be maintained in addition to the fee details.
CONCLUSION
To conclude the description about the project : The project is based on the
requirement specification of the user and the analysis of the existing system, with
flexibility for future enhancement.
The expanded functionality of today’s software requires an appropriate approach
towards software development. This hostel management software is designed for
people who want to manage various activities in the hostel. For the past few years the
numbers of educational institutions are increasing rapidly. Thereby the numbers of
hostels are also increasing for the accommodation of the students studying in this
institution. And hence there is a lot of strain on the person who are running the hostel
and software’s are not usually used in this context. 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.
77
BIBLIOGRAPHY
 Pressman, Roger S., etal, “Analysis Modeling” “Software Engineering”, PP-
299-334, McGraw-Hill, New York, Fifth edition.
 Pressman, Roger S., etal, “Software Testing Strategies” “Software
Engineering”, PP-477-498, McGraw-Hill, New York, Fifth edition.
 Wilson, Rodney, C. , etal, “Data Flow Diagram” “Software Documentation”,
PP-293-315, MIT Press, Cambridge, London, Third edition.
 Lyons, J., etal, “Software Requirement Specification” “Key to Software
Engineering”, PP-105-150, Cambridge University Press, New York.
78

Weitere ähnliche Inhalte

Was ist angesagt?

Student management system
Student management systemStudent management system
Student management systemAmit Gandhi
 
Hostel Management system Report
Hostel Management system ReportHostel Management system Report
Hostel Management system ReportPrasoon Rawat
 
Hostel management system Software Engineering SRS
Hostel management system Software Engineering SRSHostel management system Software Engineering SRS
Hostel management system Software Engineering SRSFahad Chishti
 
SRS for Library Management System
SRS for Library Management SystemSRS for Library Management System
SRS for Library Management SystemToseef Hasan
 
Hostel management system srs
Hostel management system srsHostel management system srs
Hostel management system srshira akram
 
Hotel management synopsis
Hotel management synopsisHotel management synopsis
Hotel management synopsisRahulraj Nirala
 
Hostel management system bhanu
Hostel management system bhanuHostel management system bhanu
Hostel management system bhanuNawaraj Ghimire
 
Documentation of railway reservation system
Documentation of railway reservation systemDocumentation of railway reservation system
Documentation of railway reservation systemSandip Murari
 
Student result mamagement
Student result mamagementStudent result mamagement
Student result mamagementMickey
 
Hospital management system project
Hospital management system projectHospital management system project
Hospital management system projectHimani Chopra
 
Hostel management system
Hostel management systemHostel management system
Hostel management systemYOGESH SHARMA
 
Hotel reservation system
Hotel reservation systemHotel reservation system
Hotel reservation systemManoj Malshan
 
Hostel Management Information system Abstract 2017
Hostel Management Information system Abstract 2017Hostel Management Information system Abstract 2017
Hostel Management Information system Abstract 2017ioshean
 
Hostel management
Hostel managementHostel management
Hostel managementkawsher11
 
Hotel Management System SRS
Hotel Management System SRS Hotel Management System SRS
Hotel Management System SRS Paras
 
Attendance management system
Attendance management system Attendance management system
Attendance management system SHIVANGI GOEL
 
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chart
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured ChartStock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chart
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chartgrandhiprasuna
 

Was ist angesagt? (20)

Student management system
Student management systemStudent management system
Student management system
 
Hostel Management system Report
Hostel Management system ReportHostel Management system Report
Hostel Management system Report
 
Hostel management system Software Engineering SRS
Hostel management system Software Engineering SRSHostel management system Software Engineering SRS
Hostel management system Software Engineering SRS
 
SRS for Library Management System
SRS for Library Management SystemSRS for Library Management System
SRS for Library Management System
 
Hostel management system srs
Hostel management system srsHostel management system srs
Hostel management system srs
 
Hostel management system
Hostel management systemHostel management system
Hostel management system
 
Hotel management synopsis
Hotel management synopsisHotel management synopsis
Hotel management synopsis
 
Hostel management system bhanu
Hostel management system bhanuHostel management system bhanu
Hostel management system bhanu
 
Documentation of railway reservation system
Documentation of railway reservation systemDocumentation of railway reservation system
Documentation of railway reservation system
 
Student result mamagement
Student result mamagementStudent result mamagement
Student result mamagement
 
Hospital management system project
Hospital management system projectHospital management system project
Hospital management system project
 
Hostel management system
Hostel management systemHostel management system
Hostel management system
 
Hotel reservation system
Hotel reservation systemHotel reservation system
Hotel reservation system
 
College Management System
College Management SystemCollege Management System
College Management System
 
Hostel Management Information system Abstract 2017
Hostel Management Information system Abstract 2017Hostel Management Information system Abstract 2017
Hostel Management Information system Abstract 2017
 
Srs for banking system
Srs for banking systemSrs for banking system
Srs for banking system
 
Hostel management
Hostel managementHostel management
Hostel management
 
Hotel Management System SRS
Hotel Management System SRS Hotel Management System SRS
Hotel Management System SRS
 
Attendance management system
Attendance management system Attendance management system
Attendance management system
 
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chart
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured ChartStock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chart
Stock Maintenance System-Problem Statement, SRS, ERD, DFD, Structured Chart
 

Ähnlich wie Hostel management

Fee collection system
Fee collection systemFee collection system
Fee collection systemharryz18
 
Real Estate Management System in Vb.Net
Real Estate Management System in Vb.NetReal Estate Management System in Vb.Net
Real Estate Management System in Vb.NetNafis Shaikh
 
Online hostel management_system
Online hostel management_systemOnline hostel management_system
Online hostel management_systemmd faruk
 
Admission system development
Admission system developmentAdmission system development
Admission system developmentJahurul Islam
 
Project black book TYIT
Project black book TYITProject black book TYIT
Project black book TYITLokesh Singrol
 
Projectblackbook tyit-170121122010
Projectblackbook tyit-170121122010Projectblackbook tyit-170121122010
Projectblackbook tyit-170121122010ShivanchalSingh
 
School management System
School management SystemSchool management System
School management SystemHATIM Bhagat
 
14.project online eamination system
14.project online eamination system14.project online eamination system
14.project online eamination systemVivek Mehta
 
Introduction
IntroductionIntroduction
IntroductionNAKHUNGU
 
Sales and inventory management system project report
Sales and inventory management system project reportSales and inventory management system project report
Sales and inventory management system project reportFuckboy123
 
Canteen Food Management System
Canteen Food Management SystemCanteen Food Management System
Canteen Food Management SystemShubham Dhage
 
Hotel Reservation System Presentation
Hotel Reservation System PresentationHotel Reservation System Presentation
Hotel Reservation System PresentationRohanRajMudvari
 
Hostel Management System
Hostel Management System Hostel Management System
Hostel Management System RegmiBhanu
 
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.doc
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.docSCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.doc
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.docbosed0737
 
Client Server System Development
Client Server System DevelopmentClient Server System Development
Client Server System DevelopmentManjuShanmugam1593
 
Final PPT
Final PPTFinal PPT
Final PPTsunnik
 

Ähnlich wie Hostel management (20)

Fee collection system
Fee collection systemFee collection system
Fee collection system
 
Real Estate Management System in Vb.Net
Real Estate Management System in Vb.NetReal Estate Management System in Vb.Net
Real Estate Management System in Vb.Net
 
Online hostel management_system
Online hostel management_systemOnline hostel management_system
Online hostel management_system
 
Admission system development
Admission system developmentAdmission system development
Admission system development
 
Scholarship Tracking System
Scholarship Tracking SystemScholarship Tracking System
Scholarship Tracking System
 
Project black book TYIT
Project black book TYITProject black book TYIT
Project black book TYIT
 
Projectblackbook tyit-170121122010
Projectblackbook tyit-170121122010Projectblackbook tyit-170121122010
Projectblackbook tyit-170121122010
 
Presentation.pdf
Presentation.pdfPresentation.pdf
Presentation.pdf
 
School management System
School management SystemSchool management System
School management System
 
14.project online eamination system
14.project online eamination system14.project online eamination system
14.project online eamination system
 
Introduction
IntroductionIntroduction
Introduction
 
Online help desk
Online help deskOnline help desk
Online help desk
 
Sales and inventory management system project report
Sales and inventory management system project reportSales and inventory management system project report
Sales and inventory management system project report
 
Real estate
Real estateReal estate
Real estate
 
Canteen Food Management System
Canteen Food Management SystemCanteen Food Management System
Canteen Food Management System
 
Hotel Reservation System Presentation
Hotel Reservation System PresentationHotel Reservation System Presentation
Hotel Reservation System Presentation
 
Hostel Management System
Hostel Management System Hostel Management System
Hostel Management System
 
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.doc
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.docSCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.doc
SCHOOL_MANAGEMENT_SYSTEM_This_Report_Pre.doc
 
Client Server System Development
Client Server System DevelopmentClient Server System Development
Client Server System Development
 
Final PPT
Final PPTFinal PPT
Final PPT
 

Kürzlich hochgeladen

Introduction of Object Oriented Programming Language using Java. .pptx
Introduction of Object Oriented Programming Language using Java. .pptxIntroduction of Object Oriented Programming Language using Java. .pptx
Introduction of Object Oriented Programming Language using Java. .pptxPoonam60376
 
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...Ayisha586983
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsResearcher Researcher
 
ADM100 Running Book for sap basis domain study
ADM100 Running Book for sap basis domain studyADM100 Running Book for sap basis domain study
ADM100 Running Book for sap basis domain studydhruvamdhruvil123
 
AntColonyOptimizationManetNetworkAODV.pptx
AntColonyOptimizationManetNetworkAODV.pptxAntColonyOptimizationManetNetworkAODV.pptx
AntColonyOptimizationManetNetworkAODV.pptxLina Kadam
 
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...arifengg7
 
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHTEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHSneha Padhiar
 
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxCurve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxRomil Mishra
 
Introduction to Machine Learning Part1.pptx
Introduction to Machine Learning Part1.pptxIntroduction to Machine Learning Part1.pptx
Introduction to Machine Learning Part1.pptxPavan Mohan Neelamraju
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfManish Kumar
 
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...IJAEMSJORNAL
 
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.elesangwon
 
Comprehensive energy systems.pdf Comprehensive energy systems.pdf
Comprehensive energy systems.pdf Comprehensive energy systems.pdfComprehensive energy systems.pdf Comprehensive energy systems.pdf
Comprehensive energy systems.pdf Comprehensive energy systems.pdfalene1
 
Detection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackingDetection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackinghadarpinhas1
 
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptx
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptxTriangulation survey (Basic Mine Surveying)_MI10412MI.pptx
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptxRomil Mishra
 
Indian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfIndian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfalokitpathak01
 
Theory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfTheory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfShreyas Pandit
 
Robotics Group 10 (Control Schemes) cse.pdf
Robotics Group 10  (Control Schemes) cse.pdfRobotics Group 10  (Control Schemes) cse.pdf
Robotics Group 10 (Control Schemes) cse.pdfsahilsajad201
 
A brief look at visionOS - How to develop app on Apple's Vision Pro
A brief look at visionOS - How to develop app on Apple's Vision ProA brief look at visionOS - How to develop app on Apple's Vision Pro
A brief look at visionOS - How to develop app on Apple's Vision ProRay Yuan Liu
 
Machine Learning 5G Federated Learning.pdf
Machine Learning 5G Federated Learning.pdfMachine Learning 5G Federated Learning.pdf
Machine Learning 5G Federated Learning.pdfadeyimikaipaye
 

Kürzlich hochgeladen (20)

Introduction of Object Oriented Programming Language using Java. .pptx
Introduction of Object Oriented Programming Language using Java. .pptxIntroduction of Object Oriented Programming Language using Java. .pptx
Introduction of Object Oriented Programming Language using Java. .pptx
 
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...
Submerged Combustion, Explosion Flame Combustion, Pulsating Combustion, and E...
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending Actuators
 
ADM100 Running Book for sap basis domain study
ADM100 Running Book for sap basis domain studyADM100 Running Book for sap basis domain study
ADM100 Running Book for sap basis domain study
 
AntColonyOptimizationManetNetworkAODV.pptx
AntColonyOptimizationManetNetworkAODV.pptxAntColonyOptimizationManetNetworkAODV.pptx
AntColonyOptimizationManetNetworkAODV.pptx
 
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...
Analysis and Evaluation of Dal Lake Biomass for Conversion to Fuel/Green fert...
 
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHTEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
 
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxCurve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
 
Introduction to Machine Learning Part1.pptx
Introduction to Machine Learning Part1.pptxIntroduction to Machine Learning Part1.pptx
Introduction to Machine Learning Part1.pptx
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
 
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...
Guardians of E-Commerce: Harnessing NLP and Machine Learning Approaches for A...
 
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
 
Comprehensive energy systems.pdf Comprehensive energy systems.pdf
Comprehensive energy systems.pdf Comprehensive energy systems.pdfComprehensive energy systems.pdf Comprehensive energy systems.pdf
Comprehensive energy systems.pdf Comprehensive energy systems.pdf
 
Detection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackingDetection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and tracking
 
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptx
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptxTriangulation survey (Basic Mine Surveying)_MI10412MI.pptx
Triangulation survey (Basic Mine Surveying)_MI10412MI.pptx
 
Indian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfIndian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdf
 
Theory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfTheory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdf
 
Robotics Group 10 (Control Schemes) cse.pdf
Robotics Group 10  (Control Schemes) cse.pdfRobotics Group 10  (Control Schemes) cse.pdf
Robotics Group 10 (Control Schemes) cse.pdf
 
A brief look at visionOS - How to develop app on Apple's Vision Pro
A brief look at visionOS - How to develop app on Apple's Vision ProA brief look at visionOS - How to develop app on Apple's Vision Pro
A brief look at visionOS - How to develop app on Apple's Vision Pro
 
Machine Learning 5G Federated Learning.pdf
Machine Learning 5G Federated Learning.pdfMachine Learning 5G Federated Learning.pdf
Machine Learning 5G Federated Learning.pdf
 

Hostel management

  • 1. HOSTEL MANAGEMENT SYSTEM Submitted in partial fulfilment of the requirements for the award of the degree of Computer Science Year, th Sem To Submitted To: Prepared By: Mr/Mrs 1
  • 2. ACKNOWLEDGEMENT The project work in this report is an outcome of continual work and intellectual support from various sources. It is almost impossible to express adequately the debts owed to many persons who have been instrumental in imparting this work a successful status. It is however a matter of great pleasure to express my gratitude and appreciation to all those people who had helped in completion of this project. We would like to take the opportunity to thank Mrs/Mr for giving us an opportunity to work on this project, which not only has increased our awareness but also has taught the importance of teamwork, it is because of her guidance, constant encouragement and inspiration that we have been able to accomplish the task of completing this project. We express our sincere thanks to our project mentor.Mr/Mrs for their invaluable guidance and frequent suggestions during the course of the project. Their suggestions helped us to maintain a good quality of work. We express our deep gratitude to them. Our special cordial thanks to Computer Science Department, INSTITUE NAME, Location for its earnest efforts and guidance throughout out project work. We also thank our lab assistants for allowing us to work in lab as need and for their readiness to help us in all our difficulties. name (roll no) 2
  • 3. Institue name location Batch (20XX-20XX) CERTIFICATE This is to certify that this is a record of the project work on Hostel Management System done sincerely and satisfactorily NAME . This report has not been submitted for any other examination and does not form part of any other course undergone by candidate and qualifies for submission of project evaluation purpose. Signature of candidate name Signature of project guide name 3
  • 4. LIST OF CONTENTS I PROBLEM STATEMENT 6 II SOFTWARE REQUIREMENT SPECIFICATION (SRS) 7 1. Introduction 8 1.1 Purpose 8 1.2 Scope 8 1.3 Abbreviations & Acronyms 8 1.4 Objectives & Goals 9 1.5 References 9 1.6 Overview 10 2. Overall Description 11 2.1 Product Perspective 11 2.2 Product Functions 12 2.3 User Characteristics 12 2.4 Constraints 13 2.5 Assumptions & Dependencies 13 3. Specific Requirements 14 3.1 External Interfaces 14 3.2 Software Product Features 29 3.3 Performance Requirements 36 3.4 Design Constraints 37 3.5 Software System Attributes 37 3.6 Logical Databases 37 3.7 Other requirements 39 III SOFTWARE DESIGN DOCUMENTATION (SDD) 40 1. Introduction 41 1.1 Introduction (of the document) 41 1.2 Scope 41 4
  • 5. 2. Data Design 42 2.1 Introduction 42 2.2 Data Modelling 42 ER Diagram 42 Data Dictionary 46 3. Architectural Design 56 3.1 Introduction 56 3.2 Data flow Diagrams (DFDs) 56 4. Testing 62 4.1 Testing 62 4.2 Testing Procedures 62 4.3 Objectives of System Testing 62 4.4 Test Cases 64 5. Feasibility Study 67 5.1 Financial & Economic Feasibility 67 5.2 Technical Feasibility 67 5.3 Legal Feasibility 68 5.4 Schedule Feasibility 68 IV FUTURE EXTENSIONS 69 V CONCLUSION 69 VI BIBLIOGRAPHY 70 5
  • 6. PROBLEM STATEMENT The Hostel Management System is developed for automating the activities of hostel. The software will be great relief to the employees. This software will help user in case of reporting, registration and searching the information about residents and rooms. The aim of the Hostel Management System is to carry out the activities of Hostel in an efficient way. It will take the operations of Hostel to an upper level by providing faster access to data and allowing addition, upgradation, modification, and deletion of data in a very systematic and reliable manner. EXISTING SCENARIO: • All the work is done manually. Different copies of the student information are kept for different departments. • Room is allotted according to the room requirements and other special facilities demanded by the student. • Room categories: Single, Double, Air-Conditioned and Corner. • Payment modes: Cash, Cheque and Draft. • Hostel facilities and charges and other information are all kept in a booklet. • Student’s information, staff information, fee records, student check-in and check-out, room status, staff’s salary all these information are kept in registers. • All calculations relating to students’s fees, staff salary, fines and penalties, hostel funds are done manually. DRAWBACKS: • The existing system is highly manual involving a lot of paper work and calculation and therefore may be erroneous. This has lead to inconsistency and inaccuracy in the maintenance of data. • The data, which is stored on the paper only, may be lost, stolen or destroyed due to natural calamity like fire and water. • The existing system is sluggish and consumes a lot of time causing inconvenience to students and the employees. • Due to manual nature, it is difficult to update, delete, add or view the data. • Since the number of students have drastically increased therefore maintaining and retrieving detailed record of every student is extremely difficult. FEATURES OF THE PROPOSED SYSTEM • Long-term storage of records. • High accuracy in calculations. • Efficiency in modification, sorting and retrieval of data. • Inexpensive updations in facilities and terms of organization. • Utilization of time and workforce. 6
  • 7. • Storage space for bulky record books can be ignored. • Upgrades the level of working and presentation. SOFTWARE REQUIREMENT SPECIFICATION 1. INTRODUCTION 1.1. PURPOSE The purpose is to make an automated system to carry out the various operation of a Hostel. The system will provide the ease of use to the staff of the hostel by performing all the work on a computer system rather than following a paper pen approach. This approach helps improving the reliability of the data maintained and provides a fast and efficient interface for the users of the software. 1.2. SCOPE The software product “Hostel Management System” will be an application that will be used for maintaining the records in an organized manner and to replace old paper work system. This project aims at automating the hostel management for smooth working of the hostel by automating almost all the activities. Updations and modifications will be easily achievable and all the calculations and accounting work would be accurate. OUT OF SCOPE The following features will not be delivered by the system: • Employee Payroll • Inventory Management • Resident attendance • Accounting Details except Hosteller’s Fee details 1.3. ABBREVATIONS AND ACRONYMS 7
  • 8. DFD :- Data Flow Diagram SRS :- Software Requirements Specification ERD :- Entity Relationship Diagram 8
  • 9. 1.4. OBJECTIVES AND GOALS  OBJECTIVE: Automating basic hostel management activities. The basic hostel management activities comprise of activities like: • Room Allotment • Bill Generation • Maintaining Student’s Records • Catering to Student’s Complaints • Maintaining Employee Records In course, they may face problems like: • Data Redundancy • Problems due to Human errors • Tedious Maintenance of data • Manually answering queries like: Residents with due fees, Facilities availed by the resident, Number of empty rooms etc.  GOAL The goal of the system is to tackle these problems in an effective and optimal manner by: • Centralizing the database and thus providing consistent data to all the employees in the hostel. • Make the system more user friendly by providing an intensive user interface. • Easy access through queries and reports. • Restricted data access to employees thus providing additional security to data. 1.5. REFRENCES 9
  • 10.  www.iitm.ipu.ac.in  www.du.ac.in  http://en.wikipedia.org/wiki/hostel_facilities  http://en.wikipedia.org/wiki/seondary_data 1.6. OVERVIEW The aim of the Hostel Management System is to carry out the activities of Hostel in an efficient way. It will take the operations of Hostel to an upper level by providing faster access to data and allowing addition, upgradation, modification, and deletion of data in a very systematic and reliable manner. 10
  • 11. 2. OVERALL DESCRIPTION 2.1. PRODUCT PERSPECTIVE  SYSTEM INTERFACES Null.  USER INTERFACES • At the start, there will be a login screen where the user have to enter its login name and password to authenticate himself. • After the login, a homepage will be displayed showing all the information and operations provided by the Hostel Management System. • All the operations available at the homepage will have a specific routine that will be followed up in order to complete that operation. For each operation, a different screen will be displayed demanding and providing the information regarding the operation. • A report will be generated for each student containing fee information, fines dues and penalties, check-in and check-out information.  HARDWARE INTERFACES 11
  • 12. • Screen resolution: 800X600 or Higher. • Support for printer that is, appropriate devices are installed and connected printer will be required for printing of the reports. • Desktop system, Handheld system-not a concern, as it will be possible to run the application on any of these.  SOFTWARE INTERFACES • Operating System: Windows 95/98/XP or higher. • Oracle as DBMS for database. Future release of the application will aim at upgrading Oracle 8i as the DBMS. • C++ for coding, developing the software.  COMMUNICATION INTERFACES Null.  MEMORY CONSTRAINTS • Min. 128 MB RAM. • Min. 1 GB of Hard-disk space.  SITE ADAPTATION REQUIREMENTS All the hardware and software requirements should be fulfilled at the client’s system. 2.2. PRODUCT FUNCTIONS "Hostel Management System” is an attempt to simulate the basic management system. The system enables to perform the following functions: 12
  • 13.  Maintaining Resident Information  Maintaining Room Information  Maintaining Fee Information  Maintaining Employee Information  Searching, Sorting and Retrieval of the data 2.3. USER CHARACTERSTICS  EDUCATIONAL LEVEL: At least user of the system should be comfortable with English language.  TECHNICAL EXPERTISE: User should be comfortable using general purpose applications on the system. 13
  • 14. 2.4. CONSTRAINTS  SOFTWARE CONSTRAINTS: 1. The system will run under windows 98 or above operating system. 2. the system must have word processor.  HARDWARE CONSTRAINTS: 1. Minimum 128 MB RAM 2. Pentium III or above processor 3. Minimum 500 MB of Hard disk space 2.5. ASSUMPTIONS AND DEPENDENCIES  Extensive documentation is available with the client  Users will be having a valid user name an password to access the software  Complete training is provided to all end users to handle the product  The software would not take into account the business impact i.e. the risks associated with constraints imposed by the management or the market place. 14
  • 15. 15
  • 16. 3. SPECIFIC REQUIREMENTS This section contains the software requirements to a level of detail sufficient to enable designers to design the system and the tester to test that system. 3.1 EXTERNAL INTERFACES This interface will be the actual interface through which the user will communicate with the application and perform the desired tasks. The following screens will be provided: 1. Use case ID: - Manager wishes to login to the system. Primary actor: - Manager Pre-condition: - Usernames and passwords must be available beforehand. Success End condition: - The main options screen is displayed. Failed end condition: - User has entered incorrect username or password or both. Main success scenario description 1. Select the “Log In” option from the desktop. 2. The following screen is displayed 16
  • 17. 3. Enter your username and password in the given spaces. 4. Click the “OK” button. 5. The main screen is displayed. Scenario extension description 1. Click the “Cancel” option. 2. Desktop screen is displayed 3. Entered username or password or both are incorrect. 4. System asks to input again correctly, maximum up to 3 times, after which the system is blocked. 17
  • 18. 2. Use case ID: - Add new records Goal in context: - Manager adds new record Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the main options screen. Success end condition: - A room is available and the new record is added. Failed end condition: - No room is available and new record cannot be inserted. Main success scenario description 1. On the ‘Residents’ menu, and click ‘Resident Details’. The window titled ‘Resident Details’ will open. 2. The window will be displaying the first record of the database on opening. Click the ‘Add’ button on the right of the screen. 3. All the entries of the fields will be cleared. You will see a number that’s been randomly generated in the ‘Registration Number’ field. 4. Fill in the rest of the fields of the resident details i.e. the name, date of birth, Category etc. 5. Make sure that certain fields such as ‘Facilities availed’ are checked appropriately, and the dates are correct. 6. Click on “Save” button to save it in database. 18
  • 19. Scenario extension description 1. Select the “Exit” button 2. It will return to the main screen NOTE: Do not forget to click on the ‘Save’ button when you have filled up all the fields and checked the details. Clicking on any other button will also erase all the details filled up by you and not save the record. The record will not be saved until you do so. 19
  • 20. 3. Use case ID: - Selecting an existing room by registration no. Goal In context: - Manager wishes to select a particular room from the list displayed. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - All the rooms and fair details are presented. Failed end condition: - No room and fair details are presented. Main success scenario description 1. In the ‘Residents’ menu, and click ‘Resident Details’. The window titled ‘Resident Details’ will open. The window will be displaying the first record of the database on opening. 20
  • 21. 1. In order to search a record by its registration number, select the ‘Registration number’ from the drop down list of ‘Search records by’ in the window. 2. On doing so, you will get a list of all the saved registration numbers in the database in the adjacent drop down list named ‘Select records to view details’. 3. From the list select the required registration number by clicking on it. 4. All details related to the particular registration number will be displayed in the window. 5. You can scroll through the records preceding and following the particular record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button respectively at the bottom of the screen. 6. The first record and the last record of the database can be viewed by clicking on the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the records at the beginning and the end of the database. 21
  • 22. 4. Use case ID: - Selecting existing resident details by resident name. Goal In context: - Manager wishes to select particular resident details from the list displayed. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - All the rooms and fair details are presented. Failed end condition: - No room and fair details are presented. 1. In the menu of the main window, select the resident tab, and click ‘Resident Details’. The main window titled ‘Resident Details will open: The window will be displaying the first record of the database on opening. 22
  • 23. 2. In order to search a record by its registration number, select the ‘Resident name’ from the drop down list of ‘Search records by’ in the window. 3. On doing so, you will get a list of all the saved resident names in the database in the adjacent drop down list named ‘Select records to view details’. 4. From the list select the required resident name by clicking on it. 5. All details related to the particular resident name will be displayed in the window. 6. You can scroll through the records preceding and following the particular record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button respectively at the bottom of the screen. 7. The first record and the last record of the database can be viewed by clicking on the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the records at the beginning and the end of the database. 23
  • 24. 5. Use case ID: - Selecting existing resident details by setting options. Goal In context: - Manager wishes to select a particular room from the list displayed. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - All the rooms and fair details are presented. Failed end condition: - No room and fair details are presented. You can select certain options for searching records in the database. For this you need to click on the ‘Set options’ button at the right hand side of the ‘Resident Details’ window. You will have the option of setting the search option of searching the records of existing i.e. the presently residing hostel residents and/or the records of previous residents of the hostel in the following window: 24
  • 25. 6. Use case ID: - Editing an existing room. Goal In context: - Manager wishes to edit a particular room. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - All the rooms and fair details are presented. Failed end condition: - No room and fair details are presented. To edit existing resident records in the database, first search the record you want to edit. Then click the ‘Edit’ button on the right hand side of the ‘Resident Details’ window: This will allow you to edit the currently displayed resident record. You can edit each of the fields of the record and finally after reviewing the changes, save the record by pressing the ‘Save’ button NOTE: Do not forget to click on the ‘Save’ button when you have edited all the required fields and checked the details. Clicking on any other button will erase all the details filled up by you and not save the record. NOTE: You may not be allowed to edit records depending on the privileges assigned to you by the system administrator. 25
  • 26. 7. Use case ID: - Deleting existing resident details. Goal In context: - Manager wishes to delete a particular resident details . Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - Actor has successfully deleted the details. Failed end condition: - No details are presented. In order to delete a resident record in the database, first search the desired record from the database that you want to delete. Then click the ‘Delete’ button on the right hand side of the ‘Resident Details’ window: You will get a warning from the system confirming your will to delete a record. Click yes to ‘Delete’ the record or ‘Cancel’ to abort deletion. NOTE: Be careful about deleting records from the database as such changes cannot be reverted. NOTE: You may not be allowed to delete records depending on the privileges assigned to you by the system administrator. 26
  • 27. 8. Use case ID: - Searching existing room details. Goal In context: - Manager wishes to search particular room detail . Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - Actor has successfully searched the details. Failed end condition: - No details presented. To search a room record, follow these steps: 4. In the main window of HMS, select the ‘Rooms’ tab and click on the ‘Room Allotment Details’. 5. A screen on ‘Room Allotment’ will open. Now select the room number of the room whose details you intend to view from the list of room numbers displayed. 6. The details of the particular room will be displayed. 7. The details of the resident(s) residing in the particular room can be viewed by clicking on the ‘Resident Details’ tab on the right hand side of the ‘Room Details’ window. 8. You can scroll through the records preceding and following the particular record that you are viewing by clicking on the ‘Previous’ and the ‘Next’ button respectively at the bottom of the screen. 9. The first record and the last record of the database can be viewed by clicking on the button titled ‘First’ and ‘Last’ respectively, which can help in scrolling the records at the beginning and the end of the database. 27
  • 28. 9. Use case ID: - Adding room details. Goal In context: - Manager wishes to add new room detail. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - Actor has successfully added the details. Failed end condition: - No room is empty. To add a new room and its details in the database follow these steps: 1. In the ‘Room Details’ window click on the ‘Add’ button. 2. Fills the details in the fields with the correct values and select the ‘Vacancy’ field value from the list according to the following convention: a. ‘X’ (where x is the full capacity of the room e.g. 3): If a particular room is completely occupied. b. 0: If the room is empty i.e. no one is residing in that room. c. -1: If the room is under repair/ not available for allotment. 3. After you have filled up all the details, click on the ‘Save’ button to save the record of that room. NOTE: Do not forget to click on the ‘Save’ button after you filled up all the fields and checked the details. Clicking on any other button will erase all the details filled up by you and not save the record. 28
  • 29. 10. Use case ID: - Editing room details. Goal In context: - Manager wishes to edit a room detail. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - Actor has successfully made the changes. Failed end condition: - No room detail is available. 1. To edit existing room records in the database, first search the record you want to edit. Then click the ‘Edit’ button on the right hand side of the ‘Room Details’ window: 2. Edit the particulars of the room that you wish to change. . 3. Click on the ‘Save’ button after you have edited all the required fields. NOTE: Do not forget to click on the ‘Save’ button when you have edited all the required fields and checked the details. Clicking on any other button will erase all the details filled up by you and not save the record. NOTE: You may not be allowed to edit records depending on the privileges assigned to you by the system administrator. 29
  • 30. 11. Use case ID: - Deleting room details. Goal In context: - Manager wishes to delete a room detail. Primary actor: - Manager Pre-condition:- Actor has successfully navigated to the search results. Success end condition: - Actor has successfully made the changes. Failed end condition: - No room detail is available. In order to delete a room record in the database, first search the desired record from the database that you want to delete. (Refer Section 5a.) Then click the ‘Delete’ button on the right hand side of the ‘Room Details’ window: You will get a warning from the system confirming your will to delete a record. Click yes to ‘Delete’ the record or ‘Cancel’ to abort deletion. NOTE: Be careful about deleting records from the database as such changes cannot be reverted. NOTE: You may not be allowed to delete records depending on the privileges assigned to you by the system administrator. 30
  • 31. 3.2 SOFTWARE PRODUCT FEATURES Hostel Management System 3.2.1 Login Information Maintenance  Description The system will maintain the login information of its user.  Validity checks: • Administrator needs to login with a unique id and password. • Only authorized user distinguished by the password can make modifications to the system. • The login id should be a string of alphanumerics of length not exceeding 30 characters. • The password should be a string of alphanumerics of minimum length of 8 characters and maximum of 20 characters. • Login id cannot be NULL. • Password cannot be NULL.  Sequencing information Login information has to be filled in before the user is allowed to choose from the options such as Menu Item Details, Facilities and Room Details and Payment Details.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.2 Resident Information Maintenance  Description The system will maintain the resident information regarding the personal details of the customer. It contains the name, code, address and phone no. of each resident that can be added/modified/deleted.  Validity checks: • Only the administrator can modify/delete the room and resident details. 31
  • 32. • The resident name should be a string of alphanumeric with length upto 20 characters. • The registration ID is auto generated and should be a number of 6 digits. • The resident address contains city information that should be a string of alpha numeric of length upto 40 characters. • The resident phone no. should a number of minimum length of 8 digits and maximum of 10 digits. • The resident code cannot be NULL. • The resident name cannot be NULL.  Sequencing information Resident information has to be filled in before the user is allowed choose from the options such as Menu Item Details, Facilities, Room details and Payment Details.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.3 Employee Information Maintenance  Description The system will maintain the employee information including an employee’s personal and professional details being needed by the organization. It contains the employee name, id no., address, phone no., department, designation, basic salary of each that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the employee details. • The employee name should be a string of alphanumeric with length upto 20 characters. • The employee id no. should be a number of 6 digits which is unique for each employee. • The employee designation should be a string of alphabets of length upto 15 characters. 32
  • 33. • The employee address should be a string of alphanumerics of length upto 40 characters. • The employee phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. • Employee basic salary should be a number in the range 0-50,000. • Employee id cannot be NULL. • Employee basic salary cannot be NULL.  Sequencing information Employee information has to be filled in every month for proper increments to be added to the employee salary.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.4 Local Guardian Information Maintenance  Description The system will maintain the resident’s local guardian information being needed by the organization. It contains the local guardian name, address, phone no. that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the local guardian details. • The local guardian name should be a string of alphanumeric with length upto 20 characters. • The local guardian address should be a string of alphanumerics of length upto 40 characters. • The local guardian phone no. should be a number with minimum length of 8 digits and maximum of 10 digits.  Sequencing information Local guardian information has to be filled at the same time when the resident information has been filled.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 33
  • 34. 3.2.5 Relative Information Maintenance  Description The system will maintain the resident’s relative information being needed by the organization. It contains the relative name, address, phone no. that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the relative details. • The relative name should be a string of alphanumeric with length upto 20 characters. • The relative address should be a string of alphanumerics of length upto 40 characters. • The relative phone no. should be a number with minimum length of 8 digits and maximum of 10 digits.  Sequencing information Relative information has to be filled at the same time when the resident information has been filled.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.6 Room Information Maintenance  Description The system will maintain the room information including room no, type, vacancy and phone num. being needed by the organization. The information can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the room details. • The room no should be a number of 3 digits. • The room type should be a string of alphanumeric of length upto 15 characters. • The room vacancy should be a number of 2 digits. 34
  • 35. • The room phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. • Room no cannot be NULL. • Room type cannot be NULL.  Sequencing information Room information has to be filled in before the user is allowed to choose that room from the options displayed for his desired facilities.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.7 Fees Information Maintenance  Description The system will maintain the fee information of all its residents. It contains the fee amount, type and frequency each resident that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the fee details. • The fee amount should be a number in the range 0-30000. • The fee type should be a string of alphanumeric of length upto 15 characters. • The fee frequency should be a string of alphanumeric of length upto 15 characters. • Fee amount cannot be NULL.  Sequencing information Fee information is filled in after the resident has chosen his required room and facilities.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 35
  • 36. 3.2.8 Complaint Information Maintenance  Description The system will maintain the complaint information for all of its residents. It contains the complaint details, ID, reg no, room no, status, complaint date for each resident that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the complaint details. • The room no should be a number of 3 digits. • The complaint details should be a string of alphanumeric of length upto 15 characters. • The complaint ID should be a number of 5 digits. • The reg no. should be a number of 6 digits. • The complaint status should be a string of alphanumeric of length upto 10 characters. • Room no cannot be NULL. • Reg no. cannot be NULL. • Complaint ID cannot be NULL.  Sequencing information Complaint information has to be filled in before the processing of the complaint.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.9 Organization Information Maintenance  Description The system will maintain the organization information for all of its residents. It contains the organization name, email ID, reg no, phone no and address for each resident that can be added/modified/deleted. 36
  • 37.  Validity checks: • Only the administrator can add/modify/delete the organization details. • The organization name should be a string of alphanumeric with length upto 20 characters. • The organization address should be a string of alphanumerics of length upto 40 characters. • The organization phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. • The reg no. should be a number of 6 digits. • Reg no. no cannot be NULL.  Sequencing information Relative information has to be filled at the same time when the resident information has been filled.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.2.10 Payment Information Maintenance  Description The system will maintain the payment information for all of its residents. It contains the payment type, transaction ID, due date, date of payment and receipt no for each resident that can be added/modified/deleted.  Validity checks: • Only the administrator can add/modify/delete the payment details. • The reg no. should be a number of 6 digits. • The payment type should be a string of alphanumeric with length upto 15 characters. • The payment date should be a string of alphanumerics of length upto 10 characters. • The payment due date should be a string of alphanumerics of length upto 10 characters. 37
  • 38. • The payment transaction ID should be a number of 10 digits. • The payment receipt no should be a number of 10 digits. • Reg no. no cannot be NULL. • Payment transaction ID cannot be NULL. • Payment receipt no. cannot be NULL.  Sequencing information Fee information should be calculated every month or every two months or quarterly as chosen by the resident in his fee frequency.  Error Handling If any of the validations/sequencing flow does not hold true system will display proper error messages for the user to do the needful. 3.3 PERFORMANCE REQUIREMENTS  USER FRIENDLY: The system should be user friendly so that it can easily be understand by the user without any difficulty.  EASE OF MAINTENANCE: The system should be easy to maintain and use.  LESS TIME CONSUMING: The system should be less time consuming which could be achieved by good programming.  ERROR FREE: The system should easily handle the user error in any case.  STATIC: Software runs on standalone machine. Support only single user. 38
  • 39. 3.4 DESIGN CONSTRAINTS None. 3.5 SOFTWARE SYSTEM ATTRIBUTES  SECURITY: The system should be secure from the unauthorized access and should be password protected so that no other user can access it.  PORTABILITY: The system should be machine independent.  MAINTAINABILITY: The system will be designed in a maintainable order. The system can be easily modified and renewed according to the need of the organization. 3.6 LOGICAL DATABASES S.no. Entity Attributes 1. Log In Log in ID Password 39
  • 40. 2. Resident Registration No. First name Last name Date of birth Local address State Pin code Country Telephone no. Occupation Email ID Gender 3. Fees Fees type Charges Frequency 4. Room Room no. Room type Vacancy 5. Employee Employee ID First name Last name Designation Email Address Telephone no. Date of birth Salary 6. Complaint Complaint ID Complaint date Particulars Status Registration no. Room no. 7. Local guardian Registration no. First name Last name Email Address State Telephone no 8. Relative Registration no. First name Last name Email Address State Telephone no Relation 40
  • 41. 9. organization Registration no. Name Email Address Telephone no. 10. payments Registration no. Type Transaction ID Due date Date of payment Receipt no. 3.7 OTHER REQUIREMENTS  CORRECTNESS: It is defined as the extent to which program satisfies specifications, fulfils user’s requirements.  EFFICIENCY: It is defined as the extent to which the amount of computing resources and code required to perform function.  FLEXIBILITY: It is defined as the extent to which effort needed to modify operational programs.  TESTABILITY: It is defined as the extent to which effort needed to test to ensure performance as intended.  REUSABILITY: It is defined as the extent to which effort it can be reused in another application. 41
  • 43. 1. INTRODUCTION 1.1 INTRODUCTION (of the document) Software Design sits at the kernel of software engineering and is applied regardless 7of the software process model that is used. Beginning once software requirements have been analyzed and specified, software design is the first of three technical activities- designs, code, generation and test- that are required to build and verify the software. Each activity transforms information in a manner that ultimately results in validated computer software. Software design is more creative process rather than analysis coz it deals with the development of the actual mechanics for a new workable system. While analyzing, it is possible to produce the correct model of an existing system. However, there is, no such thing a correct design. Good design is always system dependent and what is good design for one system may be bad for another. A SRS document tells us what a system does, and becomes input to the design process, which tells us how a software system works. Designing software system means determining how requirements are realized and result is a software design document (SDD). Thus the purpose of the design phase is to produce a solution to a problem given in SRS document. The flow of information during software design is illustrated in fig1. Software requirements, manifested by the data, functional and behavioral models feed the design tasks. Using number of design methods the design tasks produces a data design, an architectural design, an interface design and a component design. 1.2 SCOPE The most challenging and creative phase of the system life cycle is SYSTEM DESIGN. It shows how the software system will be structured to satisfy the requirements identified in the SRS. It refers to the technical specifications that will meet the stated requirements. The design specifications that get generated at the end of this phase are technical in nature and are the blueprint for the implementation activity. Thus the scope of SDD encompasses:-  User interface  Manual procedure  Data base design 43
  • 45. 2. DATA DESIGN 2.1 INTRODUCTION The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. The data object and relationships defined in the entity relationship diagram and the detailed data content depicted in the data dictionary provides the basis for the data design of software architecture. Data design also referred as data architecting creates a model of data that is represented at a high level of abstraction. This data model is then refined into progressively more implementation specific representation that can be processed by the computer- based system. The data object defined during software requirement analysis is modeled using ERD. The data design translates these elements of the requirements model into data structures at the software component level and, when necessary, a database architecture at the application level. 2.2 DATA MODELING Data modeling is a well-established pseudo-discipline. Most people in the information technology field are familiar with some kind of data structure diagram (sometimes referred to more specifically as entity relationship diagrams. There are innumerable software products each of which supports the preparation of one or more variants of data modelling and sometimes additionally some other kind of modelling, such as data flow diagrams. The term "data modelling" is usually interpreted as implying a diagramming technique. There are many such diagramming techniques in use worldwide. ER DIAGRAM  Cardinality Cardinality is the specification of the number of occurrences of one [object] that can be related to the number of occurrences of another [object]. Cardinality is usually expressed as simply 'one' or 'many.' For example, a husband can have only one wife (in most cultures), while a parent can have many children. Taking into consideration all combinations of 'one' and 'many,' two [objects] can be related as 45
  • 46. • One-to-one (l:l): An occurrence of [object] 'A' can relate to one and only one occurrence of [object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.' • One-to-many (l:N): One occurrence of [object] 'A' can relate to one or many occurrences of [object] 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A. 'For example, a mother can have many children, but a child can have only one mother. • Many-to-many (M:N): An occurrence of [object] 'A' can relate to one or more occurrences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A. 'For example, an uncle can have many nephews, while a nephew can have many uncles.  Modality The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 if an occurrence of the relationship is mandatory. To illustrate, consider software that is used by a local telephone company to process requests for field service. A customer indicates that there is a problem. If the problem is diagnosed as relatively simple, a single repair action occurs. However, if the problem is complex, multiple repair actions may be required. It represents Cardinality N(more than one data objects) and Modality 0. It represents Cardinality N(more than one data objects) and Modality 1. It represents Cardinality 1(one data object) and Modality 0. It represents cardinality 1(one data object) and Modality 1. The relationships that exist between the data objects are:- 46
  • 47. S. No. RELATIONSHIP PARTICIPATING ENTITIES 1. Belongs To Resident, Organization 2. Has A Resident, Local Guardian 3. Has A Resident, Relative 4. Pays Resident, Fees 5. Files Resident, Complaints 6. Is Allotted Resident, Room 7. Are Handled By Complaints, Warden 47
  • 48. 48
  • 49. DATA DICTIONARY 1. Name:-Login Aliases:-None Where used / how used:-Administrator wants to login Description:-Stores the login ID and Password. S. no Field name Data type Description 1. Login ID Characters (30) Login Name of the Administrator 2. Password Characters (20) Password of the Administrator 49
  • 50. 2. Name:-Resident Aliases:-None Where used / how used:-A resident wants to take a room. Description:-Stores the details of all residents of the hostel including past residents S. no Field name Data type Description 1. First name Characters (20) First name of the resident 2. Last name Characters (20) Last name of the resident 3. Address Both characters and numbers. (40) Residential address of the resident 4. Phone no. Integer (10) Phone number of resident 5. Email ID Characters, numbers and symbols (30) e-mail id of the resident 6. Gender One character long (1) Sex of the resident 7. Registration no. Integer (6) Registration no. of the resident 8. Date of birth Both characters and numbers ((10) Date of birth of the resident 9. State Characters (10) State of the resident 10. Pin code Integer (10) Pin code of the state 11. Country Characters (20) Country of the resident where he/she lives 12. Occupation Characters (20) Occupation of the resident 50
  • 51. 3. Name:-Fees Aliases:-None Where used / how used:-To calculate the fees of a room. Description:- Stores the amount of fees for different fee heads like Security, Mess Charges etc. S. no Field name Data type Description 1. Fees type Characters (15) Type of the fees 2. Charges Integer (5) Monthly amount to be paid 3. Frequency Characters (15) The frequency at which the fees is collected 51
  • 52. 4. Name:-Room Aliases:-None Where used / how used:-A resident wants to take a room. Description:- Keeps record of the rooms that have been allotted S. no Field name Data type Description 1. Room no. Integer (3) Identifies a unique room no. 2. Room type Characters (15) Category of rooms 3. Vacancy Integer (2) The number of people that can be accommodated in the room apart from those already staying 4. Phone no. Integer (10) Phone number of resident 52
  • 53. 5. Name:-Employee Aliases:-None Where used / how used:-to store the details of an employee. Description:-Stores the details of all employees in the hostel. S. no Field name Data type Description 1. First name Characters (20) First name of the employee 2. Last name Characters (20) Last name of the employee 3. Address Both characters and numbers. (40) Residential address of the employee 4. Phone no. Integer (10) Phone number of employee 5. Email ID Characters, numbers and symbols (30) e-mail id of the employee 6. Designation characters (15) Designation of the employee 7. Employee ID Integer (6) ID of the employee 8. Date of birth Both characters and numbers (10) Date of birth of the employee 9. Salary Integer (5) Salary of the employee 53
  • 54. 6. Name:-Complaint Aliases:-None Where used / how used:-to store the complaint details. Description:-Stores the details of all complaints in the hostel. S. no Field name Data type Description 1. Complaint date Both characters and numbers. (10) Date of issue of complaint 2. Particulars Characters (60) Details of that complaint 3. Status Characters (10) Current status of the complaint 4. Registration no. Integer (6) Registration Number of the resident who made the complaint 5. Complaint ID Integer (5) Complaint identification no. 6. Room no. Integer (3) The room number associated with the complaint 54
  • 55. 7. Name:-Local Guardian Aliases:-None Where used / how used:-to store the details of local guardian. Description:- Stores the record of the local guardians associated with each resident S. no Field name Data type Description 1. Registration no. Integer (6) Registration no. of the resident 2.. First name Characters (20) First name of the local guardian of the resident 3.. Last name Characters (20) Last name of the local guardian of the resident 4. Email ID Both Characters and numbers. (30) Email ID of the local guardian of the resident 5. Address Both Characters and numbers (40) Address of the local guardian of the resident 6. State Characters (10) State as a part of the address 7. Telephone no. Integer (10) Phone no. of the local guardian of the resident 55
  • 56. 56
  • 57. 8. Name:-Relative Aliases:-None Where used / how used:-to store the details of relative. Description:- Stores the record of the local relatives associated with each resident S. no Field name Data type Description 1. Registration no. Integer (6) Registration no. of the resident 2.. First name Characters (20) First name of the relative of the resident 3.. Last name Characters (20) Last name of the relative of the resident 4. Email ID Both Characters and numbers. (30) Email ID of the relative of the resident 5. Address Both Characters and numbers (30) Address of the relative of the resident 6. State Characters (10) State as a part of the address 7. Telephone no. Integer (10) Phone no. of the relative of the resident 8. Relation Characters (10) Relation of the resident with the relative, should be husband or either parent. 57
  • 58. 9. Name:-Organization Aliases:-None Where used / how used:-to store the details of organization. Description:- Stores the name, contact details of the organization where the resident is an employee/student S. no Field name Data type Description 1. Registration no. Integer (6) Gives the registration number 2. Name Characters (20) Name of the organization/institute of the resident 3. Email ID Both Characters and numbers. (30) Email id of the organization of the resident 4. Address Both Characters and numbers (40) Address of the organization of the resident 5. Telephone no. Integer (10) Phone no. of the organization of the resident 58
  • 59. 10. Name:-Payments Aliases:-None Where used / how used:-to store the details of payments. Description:- Stores the payment details of the residents S. no Field name Data type Description 1. Registration no. Integer (6) Gives the registration number 2. Type Characters (15) Type of the facility 3. Transaction ID Integer (10) Stores the payment details of the residents 4. Due date Both Characters and numbers (10) Date on which the payment is due 5. Receipt no. Integer (40) Receipt Number given to the resident 6. Date of payment Both Characters and numbers (10) Date on which the payment is made 59
  • 60. 3. ARCHITECTURAL DESIGN 3.1 INTRODUCTION The architectural design defines the relationship between major structural elements of the software, the design pattern that can be used to achieve the requirements that have been defined for the system, and the constraints that effect the way in which architectural design patterns that- can be applied. The architectural design representation-the framework of the computer-based system- can be derived from the system specification, the analysis model and the interaction of sub systems defined within the analysis model. 3.2 DATA FLOW DIAGRAMS (DFDs) DFD Notations : It represents a process or transform that is applied to data. : It represents data store-stored information that is used by Software : It represents an entity. 60 or
  • 63. 63
  • 64.  LEVEL TWO LOGIN ROOM ALLOCATION-TERMINATION & RESIDENT REGISTRATION 64
  • 67. 4. TESTING OF THE DOCUMENT 4.1 TESTING Testing often accounts for more project than any other software engineering activity. If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. It would therefore seem reasonable to establish a systematic strategy for testing software. The software testing is a critical step of the software quality assurance and represents the ultimate review of specification, design and code generation. 4.2 TESTING PROCEDURES  UNIT TESTING: This is the testing of an individual module and is usually carried out to ensure the validity of a particular module. NOTE: It makes use of white box testing technique.  INTEGRATED TESTING: Integrated testing is the testing of the system modules. This is done to identify errors, which relate to the interaction of different module, which cannot be found by unit testing but only through an interactive testing. NOTE: It makes use of black box testing technique.  SYSTEM TESTING: System testing is the testing of the system against its initial objectives. It is done either in a simulated environment or in a live environment.  VALIDATION TESTING: Validation testing is the testing where requirement established as part of software requirement analysis are validated against the software that has been constructed. NOTE: It makes use of black box testing technique. 4.3 OBJECTIVES OF SYSTEM TESTING Once a system has been designed, it is necessary to undergo an exhaustive testing before installing the system. This is important because in some cases a small system error, not detect and corrected early before installation, may explode into a 67
  • 68. much larger problem later on. Testing is performed when user is asked to assist in identifying all possible situations. That might arise as regards the factors that effort was put to tackle the problem under consideration. 68
  • 69. Any engineering product can be tested in one of two ways:  Knowing the specified function that a product has been designed to perform.  Knowing the internal working of the product. The first test approach is called black box testing and the second, white box testing. When computer software is considered, black box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black box tests are used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and the integrity of external information is maintained. A black box test examines some fundamental aspects of a system with little regard for the internal logical structure of the software. Black-box test design techniques include: • Graph-based testing methods • Equivalence partitioning • Boundary value analysis • Comparison testing • Orthogonal Array Testing White box testing of software is predicted on close examination of procedural detail. Providing test cases that exercise specific conditions and/or loops tests logical paths through the software. White-box test design techniques include: • Control flow testing • Data flow testing • Branch testing • Path testing During development, the software has to pass through a number of stages. At each of these stages we have the probability of committing errors. It is actually the inability of humans to communicate with perfection that introduces a step of quality assurance, which is carried out after software development. Testing represents the ultimate review of specification, design and coding. Testing is carried out with the intent of finding errors, which always exist in software, no matter how stringent the checks may be. This step can never show the defects, it can only show their presence. 69
  • 70. 70
  • 71. 4.4 TEST CASES  Login Information Maintenance The login id should be a string of alphanumerics of length not exceeding 30 characters. The password should be a string of alphanumerics of minimum length of 8 characters and maximum of 20 characters. Login id cannot be NULL. Password cannot be NULL.  Resident Information Maintenance The resident name should be a string of alphanumeric with length upto 20 characters. The registration ID is auto generated and should be a number of 6 digits. The resident address contains city information that should be a string of alpha numeric of length upto 40 characters. The resident phone no. should a number of minimum length of 8 digits and maximum of 10 digits. The resident code cannot be NULL. The resident name cannot be NULL.  Employee Information Maintenance The employee name should be a string of alphanumeric with length upto 20 characters. The employee id no. should be a number of 6 digits which is unique for each employee. The employee designation should be a string of alphabets of length upto 15 characters. The employee address should be a string of alphanumerics of length upto 40 characters. The employee phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. Employee basic salary should be a number in the range 0-50,000. Employee id cannot be NULL. Employee basic salary cannot be NULL. 71
  • 72.  Local Guardian Information Maintenance The local guardian name should be a string of alphanumeric with length upto 20 characters. The local guardian address should be a string of alphanumerics of length upto 40 characters. The local guardian phone no. should be a number with minimum length of 8 digits and maximum of 10 digits.  Relative Information Maintenance The relative name should be a string of alphanumeric with length upto 20 characters. The relative address should be a string of alphanumerics of length upto 40 characters. The relative phone no. should be a number with minimum length of 8 digits and maximum of 10 digits.  Room Information Maintenance The room no should be a number of 3 digits. The room type should be a string of alphanumeric of length upto 15 characters. The room vacancy should be a number of 2 digits. The room phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. Room no cannot be NULL. Room type cannot be NULL.  Fees Information Maintenance The fee amount should be a number in the range 0-30000. The fee type should be a string of alphanumeric of length upto 15 characters. The fee frequency should be a string of alphanumeric of length upto 15 characters. Fee amount cannot be NULL. 72
  • 73.  Complaint Information Maintenance The room no should be a number of 3 digits. The complaint details should be a string of alphanumeric of length upto 15 characters. The complaint ID should be a number of 5 digits. The reg no. should be a number of 6 digits. The complaint status should be a string of alphanumeric of length upto 10 characters. Room no cannot be NULL. Reg no. cannot be NULL. Complaint ID cannot be NULL.  Organization Information Maintenance The organization name should be a string of alphanumeric with length upto 20 characters. The organization address should be a string of alphanumerics of length upto 40 characters. The organization phone no. should be a number with minimum length of 8 digits and maximum of 10 digits. The reg no. should be a number of 6 digits. Reg no. no cannot be NULL.  Payment Information Maintenance The reg no. should be a number of 6 digits. The payment type should be a string of alphanumeric with length upto 15 characters. The payment date should be a string of alphanumerics of length upto 10 characters. The payment due date should be a string of alphanumerics of length upto 10 characters. The payment transaction ID should be a number of 10 digits. The payment receipt no should be a number of 10 digits. Reg no. no cannot be NULL. Payment transaction ID cannot be NULL. Payment receipt no. cannot be NULL. 73
  • 74. 5. FEASIBILITY STUDY It aim to objectively and rationally uncover the strengths and weaknesses of the existing software, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. 5.1 FINANCIAL AND ECONOMIC FEASIBILITY For any system if the expected benefits equal or exceed the expected costs, the system can be judged to be economically feasible. In economic feasibility, cost benefit analysis is done in which expected costs and benefits are evaluated. Economic analysis is used for evaluating the effectiveness of the proposed system. In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an analysis of the costs to be incurred in the system and benefits derivable out of the system. When it comes to HOSTEL MANAGEMENT SYSTEM project, the project is privately sponsored by the organization. Sponsoring such a project will not be a problem for the organization as this S/W will decrease the time of various operations and working of hostel by providing an automated system which takes lesser time as compare to other means. The Project will enable user to perform all the operations of the hostel quickly and correctly without any problem. 5.2 TECHNICAL FEASIBILITY The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project when writing a feasibility report, the following should be taken to consideration:  A brief description of the business  The part of the business being examined  The human and economic factor  The possible solutions to the problems 74
  • 75. At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost) 75
  • 76. 5.3 LEGAL FEASIBILIY It includes study concerning contracts, liability, violations, and legal other traps frequently. Our HOSTEL MANAGEMENT SYSTEM project is legally feasible as all the licenses required for this project development and working are already taken from the authorities. 5.4 SCHEDULE FEASIBILITY A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Our HOSTEL MANAGEMENT SYSTEM project is not schedule wise feasible as the development of the S/W is done within the time bound assigned and is completed according to the timetable. 76
  • 77. FUTURE EXTENSIONS  Employee Payroll: We can include the facility in this system that will generate payroll for all the employees of the hostel.  Resident attendance: The attendance of resident will be marked each time the resident enters or leaves the hostel premises.  Accounting Details except Hosteller’s Fee details: All the other accounting details can be maintained in addition to the fee details. CONCLUSION To conclude the description about the project : The project is based on the requirement specification of the user and the analysis of the existing system, with flexibility for future enhancement. The expanded functionality of today’s software requires an appropriate approach towards software development. This hostel management software is designed for people who want to manage various activities in the hostel. For the past few years the numbers of educational institutions are increasing rapidly. Thereby the numbers of hostels are also increasing for the accommodation of the students studying in this institution. And hence there is a lot of strain on the person who are running the hostel and software’s are not usually used in this context. 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. 77
  • 78. BIBLIOGRAPHY  Pressman, Roger S., etal, “Analysis Modeling” “Software Engineering”, PP- 299-334, McGraw-Hill, New York, Fifth edition.  Pressman, Roger S., etal, “Software Testing Strategies” “Software Engineering”, PP-477-498, McGraw-Hill, New York, Fifth edition.  Wilson, Rodney, C. , etal, “Data Flow Diagram” “Software Documentation”, PP-293-315, MIT Press, Cambridge, London, Third edition.  Lyons, J., etal, “Software Requirement Specification” “Key to Software Engineering”, PP-105-150, Cambridge University Press, New York. 78