Professional Documents
Culture Documents
Hostelmanagement 151101104929 Lva1 App6891 PDF
Hostelmanagement 151101104929 Lva1 App6891 PDF
Computer Science
Year, th Sem
To
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.
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.
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
name
3
LIST OF CONTENTS
I PROBLEM STATEMENT 6
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
3. Specific Requirements 14
1. Introduction 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
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.
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
OUT OF SCOPE
• Employee Payroll
• Inventory Management
• Resident attendance
7
DFD :- Data Flow Diagram
8
1.4. OBJECTIVES AND GOALS
OBJECTIVE:
• Room Allotment
• Bill Generation
• Data Redundancy
• Problems due to Human errors
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.
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
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.
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.
SOFTWARE INTERFACES
COMMUNICATION INTERFACES
Null.
MEMORY CONSTRAINTS
All the hardware and software requirements should be fulfilled at the client’s
system.
12
Maintaining Resident Information
Maintaining Room Information
13
2.4. CONSTRAINTS
SOFTWARE CONSTRAINTS:
HARDWARE CONSTRAINTS:
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.
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.
16
3. Enter your username and password in the given spaces.
4. Click the “OK” button.
5. The main screen is displayed.
17
2.
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.
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.
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.
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.
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.
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.
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.
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.
To add a new room and its details in the database follow these steps:
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.
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:
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.
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
Description
The system will maintain the login information of its user.
Validity checks:
• Administrator needs to login with a unique id and password.
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.
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.
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.
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.
32
• The employee address should be a string of alphanumerics of
length upto 40 characters.
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.
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.
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.
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.
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.
34
• The room phone no. should be a number with minimum length of
8 digits and maximum of 10 digits.
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.
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.
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.
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.
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.
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.
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.
37
• The payment transaction ID should be a number of 10 digits.
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.
USER FRIENDLY:
The system should be user friendly so that it can easily be understand by the
user without any difficulty.
EASE OF MAINTENANCE:
ERROR FREE:
The system should easily handle the user error in any case.
STATIC:
38
3.4 DESIGN CONSTRAINTS
None.
SECURITY:
The system should be secure from the unauthorized access and should be
password protected so that no other user can access it.
PORTABILITY:
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.
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
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.
CORRECTNESS:
EFFICIENCY:
FLEXIBILITY:
TESTABILITY:
REUSABILITY:
41
SOFTWARE
DESIGN
DOCUMENTATION
42
1. INTRODUCTION
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.
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.
User interface
Manual procedure
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.
ER DIAGRAM
Cardinality
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.
Modality
46
S. No. RELATIONSHIP PARTICIPATING ENTITIES
47
48
DATA DICTIONARY
1.
Name:-Login
Aliases:-None
Where used / how used:-Administrator wants to login
Description:-Stores the login ID and Password.
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
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.
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
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.
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.
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
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
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
58
10.
Name:-Payments
Aliases:-None
Where used / how used:-to store the details of payments.
Description:- Stores the payment details of the residents
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.
DFD Notations
or
: It represents a process or transform that is applied to data.
: It represents an entity.
60
LEVEL ZERO
61
LEVEL ONE
62
63
LEVEL TWO
LOGIN
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.
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:
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.
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
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.
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.
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.
72
Complaint Information Maintenance
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.
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.
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.
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?
76
FUTURE EXTENSIONS
Employee Payroll: We can include the facility in this system that will
generate payroll for all the employees of the hostel.
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.
77
BIBLIOGRAPHY
78