1. Introduction

---

1.1 Purpose

This project aims to design, build, and deploy an end-to-end hall booking web-based application. The project aims to create a portal that allows registered users, including administrative staff, college faculty, and students, to efficiently check the availability of specific halls, initiate hall bookings, and seamlessly cancel bookings in a single transaction.

In addition to the core functionality of hall bookings, the software has a secondary purpose. It is designed to facilitate users in reserving tickets for all forthcoming institute events or any ongoing events in close proximity. The ultimate goal is to streamline and enhance the hall booking process, providing a user-friendly reservation management platform. The software also serves as a centralized system, allowing users to book tickets for various institute-sponsored events easily.

1.2 Product Scope

The project aims to replace the current manual and inefficient room booking process, where students need to visit the admin block to seek permission on paper physically. The proposed application will streamline this process by offering a digital solution that provides real-time tracking through visualized graphics and a calendar showcasing upcoming events.

The key objectives include enhancing efficiency by eliminating manual paperwork and enabling users to track room availability seamlessly. The application will mitigate common issues like double bookings, ensuring optimal utilization of room resources. Moreover, the system will democratize access to room booking statistics, providing transparency to all users and administrators. This data will contribute to informed planning and decision-making for administrative staff.

As the project progresses, there are plans to incorporate additional features into the portal, further enhancing its utility and functionality.

1.3 Definitions, acronyms, and abbreviations

1.3.1 Definitions

User: The person, or persons, who operates or interacts directly with the product. Supplier: The person, or persons, who produces a product for a customer. Here, the customer and supplier might be members of the same organization. Customer: The person who sets the requirements and needs of the project. Admin: The person who will have control over the accesses and private information.

1.3.2 Acronyms

CMS - Content Management System SDK - Software Development Kit UI - User Interface JWT - JSON Web Token DB - Database UX - User Experience

1.4 Overview

The SRS serves as a detailed guide for the hall booking application, outlining requirements, functionalities, and features. It follows a systematic structure, beginning with an introduction and progressing through sections like overall description, external interface requirements, system features, nonfunctional requirements, and business rules. This ensures clarity and easy reference, facilitating a logical understanding and implementation. The table of contents provides a detailed breakdown for quick reference.

1.5 Team Structure

• Product Owner - Tiya Jain
• Team Lead - Keshav Arora
• Scrum Master - Aviral Gupta
• Frontend Developers - Vasu Bansal, Suyash Varshney, Drishti Jain
• Backend Developers - Rohit Madan, Omkar More, Abhay
• Testing - Tejasvini, Yashaswini
• DevOps - Hiya Kwatra
• UI/UX Designer - Priti Shekhawat

---

2. Overall Description

2.1 Product Perspective

In the “Hall Booking Management System”, we will have a user interface for the admin staff, professors, club representatives and normal students. The user can log in to their accounts. Depending on the user, all other utilities will be decided for the interface. The representatives and professors can request specific empty halls, and the admin will be able to approve and provide permission for the requested time frame. The system will take care of the details and availability of every room, hall or other space in IIT Ropar. It will facilitate the search of spaces or events by providing search functionality. The search will be based on various categories, i.e., room number, block, hall name, or room occupancy. For events, it will be the name of the organizing club, event title, or day. Further, the college admin can add rooms and halls if available. Users will have passwords to access their respective accounts.

Diagram 1: Targeted Users for our application

2.2 Product Functions

The primary functions that the application provides can be described as follows -

• Hall/Room Management: The application efficiently manages the booking process for halls and rooms within the institute. Registered users, such as administrative staff, college faculty, and students, can seamlessly check availability, book, and cancel hall reservations.
• Visualization of events: The application will provide representation of all upcoming events including those currently taking place nearby. In this way users can access and stay informed about the scheduled events
• Registering for the upcoming events: The application will also allow the students to register for the upcoming events. There will also be a payment gateway integration for this function for registering in the paid events.
• Available Space Updates: The application allows users to check and receive updates on available spaces within the organization or institution, suitable for various activities like meetings and group discussions. Users can make informed decisions about space utilization, avoiding conflicts and ensuring optimal use of resources.
• Request Tracking Mechanism: The application will provide admin staff a separate dashboard where they can view the requests for various halls, in different slots. They can approve or reject the requests, and can also track the past requests. The applicants can as well view the status of their requests and will be informed once approved. After approval, booking is visible to all.

The below Data Flow Diagram clearly shows various processes associated with the project and how the data flows between all the entities -

Diagram 2: Data Flow Diagram

2.3 User Classes and Characteristics

2.3.1 General User Description (add the content of user actions)

Given below is a general description of the various users who would be involved with the application

ID	User Class / Actor Name	Description / Actor’s Role
U-1	Developers, Maintainers	These users are responsible for implementing modifications and updates to the application and handling maintenance tasks. They will be granted access to the non-graphical elements, including the database and hosting servers.
U-2	Admin Staff	These users will have the authorization to approve and manage all the requests for booking various halls. They would also be able to see overview statistics.
U-3	Professors/Teaching Assistants, Club Representatives	These users will be able to request booking of halls for quizzes and other academic purposes based on the asset information.
U-5	Normal Student	These users can see their weekly calendar and upcoming events to register for proper weekly planning.

2.3.2. User Documentation

The U-1 class users must receive comprehensive documentation covering the entire codebase, enabling them to maintain the application actively. This documentation should encompass details about the hosting platform, the Express server, and the React application. Additionally, suitable test files should be provided to preserve prior functionality.

For users falling under the U-2, U-3, and U-4 classes, the documentation will guide them on how to use the web application and execute their tasks seamlessly. This information will be presented in the form of a README.

2.4 Implementation Constraints

2.4.1 Design Constraints

The project encounters challenges related to design, including the need for effective filtering and validation mechanisms. The UI design, with specific features like colors and layout, is subject to refinement based on consumer requirements and feedback. Additionally, the choice of a programming language, framework, or database may evolve over time, introducing potential design adjustments.

2.4.2 Security/Privacy Constraints

Integration of Google OAuth and JWT poses security considerations that demand meticulous implementation. Handling user permissions, editing bookings, and managing content through a CMS require stringent security measures. As the project progresses, changes in security and privacy protocols may necessitate continuous adaptation to maintain robust protection against potential vulnerabilities.

2.4.3 Accessibility Constraints

Working with dates and times poses challenges in ensuring accessibility for all users. The project must prioritize inclusive design practices to accommodate users with diverse needs. Regular assessments and optimizations are crucial to address potential accessibility constraints and provide an equitable user experience for a broad audience.

2.5 Assumptions and Dependencies

2.5.1. Assumptions

Users possess a basic understanding of English to comprehend the interface. Users maintain a reasonably stable internet connection for continuous access to the web application. The service is exclusively available for IIT Ropar students, faculty, and staff. Each ID is associated with a unique authorized person.

2.5.2. Dependencies

The sole dependencies are the MongoDB database and the hosting platform. The application will be hosted on a server, utilizing the SDK to communicate with the database.

2.6 Operating Environment

The operating environment for the application is listed below: React JS Node.js with ExpressJS MongoDB Google OAuth + JWT Google Calendars Hosting - (To be decided)

---

3. External Interface Requirements

3.1 User Interfaces

3.1.1. Admin Interface

Admin Dashboard Admin Requests Page

3.1.2. Professor/Student Interface

Landing Page

Register

Login

Hall Availability Monthly

Hall Availability Weekly

Hall Bookings

Booking Form

Booking Status

---

4. Other Nonfunctional Requirements

4.1 Performance Requirements

We want the hall booking app to be quick and smooth for users. Here's what we're aiming for:

• Response Time: We expect the app to respond within 2 seconds for common actions like checking hall availability, making bookings, and canceling reservations.
• Concurrent Users: The system needs to handle at least 1000 users at the same time without slowing down.
• Scalability: The app should grow with us. It needs to handle a 20% increase in users and bookings over the next year without any hiccups.

4.2 Server Storage Requirements

• Database Storage (MongoDB): We need enough space to store all our bookings, user data, and everything else. Keep an eye on it, and make sure it stays speedy.
• Application Code and Assets: The server should have at least 2 GB of space for the app's code and other files. Regular backups are a must.

4.3 Security Requirements

• Google Auth and JWT Authentication: Let's keep things secure. Use Google Auth and JWT to make sure only the right people access our system. Update security measures as needed.
• Access Control: Only let authorized users do important stuff. Implement roles so only the right people can make big decisions.

4.4 Software Quality Attributes

• Maintainability:
• Keep the code clean and easy to understand. Document everything to make life simpler for future developers.
• Use Git for version control. It helps us keep track of changes and work together without stepping on each other's toes.
• Reliability:
• If something goes wrong, we need to know why. Set up good error handling and logs to catch problems early.
• Regular testing is key. Check everything – from small parts to the whole system – to make sure it works as it should.
• Robustness:
• Stop bad stuff before it happens. Validate and clean up inputs to avoid common problems like hacking.
• Plan for the worst. Have a solid backup and recovery plan so we can bounce back quickly if something unexpected occurs.

4.5 Business Rules

• Reservation Policies: Let's be clear about how hall bookings work. Set rules like how long a booking can be, how early someone can book, and any fees for changing plans.
• User Responsibilities: Everyone needs to know their role. Outline what admin staff, faculty, and students are responsible for when it comes to booking and attending events.
• Data Privacy: Keep user info safe and sound. Follow privacy rules and update our policies regularly. If things change, make sure users know.
• Event Ticketing Rules: Lay down the law for reserving event tickets. Decide on prices, when tickets are available, and who gets to go. Make it fair and square.