Software Requirements Specification
For
Hostel Management System
Version 1.0 approved
Prepared By –
October 2018
Table of Contents
Table of Contents ii
1. Introduction 1
1.1 Purpose 1
1.2 Document Conventions 1
1.3 Intended Audience and Reading Suggestions 2
1.4 Product Scope 2
1.5 References 2
2. Overall Description 3
2.1 Product Perspective 3
2.2 Product Functions 3
2.3 User Classes and Characteristics 3
2.4 Operating Environment 4
2.5 Design and Implementation Constraints 4
2.6 User Documentation 4
2.7 Assumptions and Dependencies 5
3. External Interface Requirements 6
3.1 User Interfaces 6
3.2 Hardware Interfaces 6
3.3 Software Interfaces 6
3.4 Communications Interfaces 7
4. System Features 8
4.1 Student Direct interface 8
4.2 hostel data managment 8
5. Other Nonfunctional Requirements 9
5.1 Performance Requirements 9
5.2 Safety Requirements 9
5.3 Security Requirements 10
5.4 Software Quality Attributes 10
5.5 Business Rules 10
6. Other Requirements 10
Appendix A: Glossary 11
Appendix B: Analysis Models 12
1. Introduction
The Hostel Management System software is used for booking the rooms of the desired hotel online. It provides easy access to the customer information and manages the system properly and efficiently. It also provides the facility for administrator to keep an overall record of customer and staff.
1.1 Purpose
This project is aimed at developing a Hostel Management System that is a collection of reports for the effective management of students in a Hostel. This system should contain modules like student details, room allocation and in-out register. This particular project deals with the problems on managing a hostel and avoids the problem which occurs when carried manually.
1.2 Document Conventions
• Header 1:
o Font: Times New Roman
o Font size: 18
• Header 2:
o Font: Times New Roman
o Font size: 14
• Header 3:
o Font: Times New Roman
o Font size: 12
• Header 4:
o Font: Times New Roman
o Font size: 12
• Header 5:
o Space :1.5
1.3 Intended Audience and Reading Suggestions
• Typical Users, such as customer, who want to use this application for booking their desired hotels online and to gain the desired specifications and information for that hotel.
• Hotel staff and manager, who want to use this application for keeping the record of their guests and the status of rooms and bookings.
• Administrator, uses this application for keeping an overall record of the guests and the the hotel staff.
• Programmers who are interested in working on the project by further developing it or fix existing bugs.
1.4 Product Scope
The product scope of HMS are-:
The proposed system of HMS is digitalized. Today is the era of computers and thus digitalizing the present system of Hostel Management could solve problems that could have been easily tackled. This Software allows maintaining the records of hostel students from different branches and years. Its prime objective is to evaluate the hostel accommodation status either of vacancies or accommodation while saving money and time.
1.5 References
• Use of various software engineering books like Shalini Puri.
• Use of IEEE format(https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc
• www.cs.gmu.edu
• www.scribd.com
• (https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc
• We take the material and the IEEE specified SRS format from the above-mentioned sites and followed the given pattern in the example.
2. Overall Description
2.1 Product Perspective
Different Perspective are:-
HMS was developed in the favour of all the end users- Customer, Hotel Staff and administrator. It reduces the work stress of all its users. It is an open source project and it has a very active developer team to support it and provide feedback to users. It was developed to run on Windows, Mac OS X and Linux.
2.2 Product Functions
The various functions covered by the “REQUIREMENT SPECIFICATION”, which follows, are to be provided to meet the requirements of the various user classes.
Functionalities available to the users-
• Registration/ update process: Institution is able to generate Ids and update the hosteller’s data.
• IN/OUT registry process: All users will be able to access the database, however only the warden will update the data.
• Room allocation: All users will be able to access the database. Warden will allocate the room.
• Leave request: Hostellers could place the request for leave in the system which will be confirmed or rejected by the warden.
• Attendance counter: Warden will be able to update the data and it will be accessible to all users.
2.3 User Classes and Characteristics
There are 3 kinds of users for the proposed system-
• Student- Every student who stays in a hostel and has a room allocated to him. The student has his own database and a student account in the HMS and can check his attendance report and/or whether his data is true or not.
• Hostel faculty- Warden is the person responsible for managing the hostel and monitoring all hostellers and their movements. He has to maintain the in-out register and to provide confirmation/rejection to the leave request put forwarded by the Hosteller.
• Administrator- The body that operates the Hostel (school, colleges, universities etc.). The institution could have the administrator permission to update the entire database along with other tasks such as issuing notices, adding student id etc.
2.4 Operating Environment
The user will be able to create and maintain the database of other user class. The application has an accurate, interactive and a pleasant user-friendly interface.
We can use this software on different operating system like:
• Windows 7
• Windows 8
• Windows 10
• Mac OS X
• Linux
• Ubuntu
2.5 Design and Implementation Constraints
Design constraints are-:
• The developed System should run under any platform i.e. Windows, Mac, Linux, Unix etc.
• All mandatory fields should be filled by an individual.
• There can be security risks involved.
• Student details can be updated or changed by the Institution itself only.
2.6 User Documentation
External/hard User-Manual, tutorials have been provided with the application. Internal application FAQ and support are available and all the course work for the following project has been provided to the user.
2.7 Assumptions and Dependencies
It is assumed that the system developed will work perfectly on platforms like Windows, Red hat and Ubuntu. It is developed in java hence required java in the system. For the up gradation of the software it will require java version 7 and above.in case of any difficulties the SRS is that flexible that it will adapt to the change smoothly and make the desired changes accordingly.
3. External Interface Requirements
3.1 User Interfaces
Since there are 3 types of users, there are 3 types of user interfaces and those are:
• Student interface- From here the user can interact with various features of the software.
• Hostel faculty- The user can book the desired room using this facility.
• Administrator user interface-The administrator will feed the details to the student.
Each user will have a dedicated menu with functionalities as according, however they will have some common properties as such-
• A customizable window
• Menus
• Details fields.
3.2 Hardware Interfaces
Hardware Interfaces exists between any hardware components associated with a computer system.
For this particular application, these are:
Processor : Intel Pentium 2-core processor or higher
RAM : 4 GB RAM
Monitor : 15” Color Monitor
Operating system : window 10
Keyboard &Mouse.
3.3 Software Interfaces
Different Types of software interface that are used are -:
HMS requires Java to be installed on the system, more specifically Java version 7 or 8 for its latest release. Additional information can be found on section 2.7 of this document. HMS can be connected with a WordPad, Microsoft word or other document software to open or save the details of rooms or hotel or any other information. The software also requires HTML and My –SQL database.
The software is developed with all the basic controls and class provided in java. Windows 7 or above installed on the system. Application package must be installed.
Operating system : Windows 7, 8, 8.1,10, Linux etc.
Developing tools : eclipse, intellij.
Developing software : IBM Software Development Platform
3.4 Communications Interfaces
Different Communication Interface are-:
HMS requires an internet connection to install new features, update already installed ones and update some of its components like the rooms details, add or delete any hotel or room, change the specifications of any room etc.
4. System Features
HMS is customizable and user-friendly software for Hostels. It has been designed to automate, manage and look after the over-all processing of even very large hostels.
4.1 Student Direct Interface.
4.1.1 Description and Priority
The system will maintain the hosteller’s information effectively which could include attendance reports, in-out registry data etc.
4.1.2 Stimulus/Response Sequences
The hosteller could check status of his attendance report and verify his/her leave request (if any).
4.1.3 Functional Requirements
The hosteller would need to login into the system using his login id for availing the information from the database.
REQ-1: The hosteller needs to have a unique login id.
REQ-2: Credentials are to be verified by the user itself.
4.2 Hostel Data Management
4.1.1 Description and Priority
The institution and the warden will be able to access and manage the data of even a large hostel and the hostellers easily.
4.1.2 Stimulus/Response Sequences
The Warden or the institution would need to login into the system just as same as the other user.
4.1.3 Functional Requirements
The Warden or institution can easily login into the system using the system login and avail the information from the database of hostellers and make updates/changes if required so that user experience could improve.
REQ-1: The warden and the institution would have their own dedicated login id.
REQ-2: Only the Institution should have the right to delete/ update user information.
5. Other Nonfunctional Requirements
5.1 Performance Requirements
• The application has to run on any platform.
• The performance shall depend upon the hardware & software components of the computer.
• The application shall take initial load time depending on performance of Operation System.
5.2 Safety Requirements
Safety is a very important aspect of the design and should cover areas of hardware reliability, fall back procedures, physical security of data and provision for detection of fraud and abuse.
5.3 Security Requirements
Security and privacy is a major concern in the system. The project provides a genuine security to all those individuals who are having their account on the database as they are password protected. All sensitive information are encrypted too so that no misuse could take place.
5.4 Software Quality
• Will be maintained as long as there are no hardware & software problems. Also database should be updated.
5.5 Attributes
The various software quality attributes are-
• The software will not require maintenance until there are software and hardware problems.
• Database should be updated.
• The system is portable.
• The system is easy to move from one hardware to another.
• The system is easy to edit and modify for further enhancement of the software.
• The system must be reliable.
5.6 Business Rules
There are many rules that has to be followed when making srs they are-:
• The institution has the right to terminate the stay of any hosteller (or break open rooms) in case of any violation of hostel rules, suspected unlawful activities and/or on a perceived security risk.
• The institution can also terminate the stay if the student don’t follow the required rules.
• The institution can also see whether the hostel room assigned to people is clean or not.
• If the hostel room is damaged then the institution can charge the student for all the damages.
6. Other Requirements
• 24/7 server uptime is mandatory to host the database.
Appendix A: Glossary
Short name Description
1 HMS Hostel Management System
2 User Hosteller/ Warden/ Institution
3 Rules Mandatory rules to be followed while in stay at the hostel
Appendix B: Analysis Models
DFD Model
Process: It have only one process namely Hostel Management System. The HMS software is used for booking the rooms of the desired hostel online. It provides easy access to the student information and manages the system properly and efficiently. It also provides the facility for administrator to keep and overall record of customer and staff.
Entities: It has 3 entities-
• Student- This entity search, book the room and make the payments.
• Hostel faculty- This entity will tell the status of the room and accept or reject the payment.
• Administrator- This entity will confirm or reject the registration and can add, modify or delete room and staff.
Task: The various tasks are performed as follow-
The registration takes place then the room is searched as per student needs. Tariff plan is discussed then confirmation of booking and payment is done. The status of booking can add, modify, deletes rooms and staff.
DFD level 1
• Registration Process- registration takes place.
• Search Process- searching of desired rooms.
• Room Allotment Process- room is allotted to the user.
• Payment Process- transaction is done.
• Room and Staff Update Process- administrator can modify, delete or add details.
Entities: It has 3 entities-
• Student- This entity search, book the room and make the payments.
• Hotel faculty- This entity will tell the status of the room and accept or reject the payment.
• Administrator- This entity will confirm or reject the registration and can add, modify or delete room and staff.
Task: The various tasks are performed as follow-
The registration takes place then the room is searched as per user’s needs. Tariff plan is discussed then confirmation of booking and payment is done. The status of booking can add, modify, deletes rooms and staff.
2.ER Diagram
Hostel management system is design so that our universities and colleges can easily manage the data of students and related things.
For the best understanding first, we have to define the project scope or the scenario because different problem can be solve different design and more than one scenarios can be created for each problem. People design them according to their thinking.
We are also creating some type scenario so that our design can be bit specific for some kind of situation.
• An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. An entity in this context is an object, a component of data. An entity set is a collection of similar entities. These entities can have attributes that define its properties.
• By defining the entities, their attributes, and showing the relationships between them, an ER diagram illustrates the logical structure of databases.
• ER diagrams are used to sketch out the design of a database.
The various entities are hostel staff having attributes like id, password, phone number, email. Administrator having attributes like id, password, name, phone number. Rooms which have attributes like room number, floor, hotel name, type. Registration system having attribute already existing further having attributes id and password and new further having attributes user name, password, e-mail, phone number. The last entity is student having attributes like id, password, name, phone number, e-mail.
The various relationships are-: manage records, payment, search, allotment, register, verify and maintain. Tariff plan between hotel staff and customer with cardinality 1-1. Hotel staff can manage various customers. Many customers can register by one registration system. 1 administrator can verify various registrations. 1 hostel staff manages many students. 1 student can make payment to 1 hotel staff. Many student can search many rooms. Single student can be allotted various rooms. One administrator can maintain various hostel staff. One administrator can maintain various rooms.
Comments
Post a Comment