---

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.

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.

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.

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.

---

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 1: Data Flow Diagram

Diagram 2: Targeted Users for our application

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	Responsible for implementing modifications and updates to the application and handling maintenance tasks. They have access to non-graphical elements, including the database and hosting servers.
U-2	Admin Staff	Authorized to approve and manage all requests for booking various halls. They can view overview statistics.
U-3	Professors/Teaching Assistants, Club Representatives	Can request booking of halls for quizzes and other academic purposes based on asset information.
U-5	Normal Student	Can view their weekly calendar and upcoming events to register for proper weekly planning.

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.

---

The "Hall Booking Management System" is designed using a modular program structure to achieve flexibility, scalability, and maintainability. The system is decomposed into several high-level subsystems, each responsible for specific functionalities. These subsystems collaborate to provide the complete functionality of the system.

Authentication Subsystem: Contains the User module. Club Subsystem: Contains Club module. Booking Subsystem: Contains Event and Booking Module. Ticket Management Subsystem: Contains Ticket and TicketBooking Module. Hall Subsystem: Contains Hall module. IT Complaints Subsystem: Contains IT Complaints module.

The Authentication Subsystem interacts with all other subsystems to ensure authorized access to system functionalities. The Club, Event, Booking, and Ticket Management subsystems collaborate to facilitate event organization and ticket booking processes. The Booking Subsystem interacts with the Hall Subsystem to check hall availability and manage bookings. The IT Complaints Subsystem collaborates with the Booking Subsystem to record complaints associated with hall bookings and resolve them efficiently. Diagram 3: Architecture Design - (Domain Level Partitioning)

This architecture decomposes the system into several high-level subsystems, each responsible for specific functionalities. These subsystems collaborate to deliver the complete functionality of the system. *Authentication Subsystem:

• Functionality: Responsible for user authentication and session management.
• Modules: User module handles login, registration, and session creation.
• Collaboration: Interacts with all other subsystems to ensure authorized access to system functionalities.

• Club Subsystem:

• Functionality: Manages the creation, deletion, and retrieval of clubs.
• Modules: Club module handles adding members and assigning positions of responsibility within clubs.
• Collaboration: Interacts with other subsystems to facilitate event organization and management.

• Booking Subsystem:

• Functionality: Facilitates hall booking functionalities.
• Modules:
• Event module handles the creation, deletion, and retrieval of events organized by clubs.
• Booking module facilitates hall booking operations such as creating, updating, and canceling bookings.
• Collaboration: Interacts with the Hall Subsystem to manage hall availability and bookings. Collaborates with IT Complaints Subsystem to handle associated complaints efficiently.

• Ticket Management Subsystem:

• Functionality: Manages event ticketing.
• Modules:
• Ticket module handles ticket creation, retrieval, by the event organizer.
• Ticket Booking module handles the ticket booking for an event by the regular student
• Collaboration: Facilitates event organization and ticket booking processes with other subsystems.

• Hall Subsystem:

• Functionality: Manages the creation, deletion, and retrieval of halls within the campus.
• Modules: Hall module manages hall details and availability for bookings.
• Collaboration: Interacts with Booking Subsystem to check hall availability and manage bookings.

• IT Complaints Subsystem:

• Functionality: Manages IT-related complaints associated with hall bookings.
• Modules: IT Complaints module records complaints, tracks resolution progress, and updates statuses.
• Collaboration: Collaborates with Booking Subsystem to handle complaints efficiently.

The chosen architectural design emphasizes modularity and separation of concerns, allowing for easier maintenance and scalability. Critical issues such as authentication security, event organization, and resource management were considered in the design process. Alternative architectures, such as a monolithic design or microservices architecture, were evaluated. However, the selected modular design was deemed optimal due to its balance between complexity and flexibility. Monolithic architectures were rejected due to their lack of scalability, while microservices architectures were considered overly complex for the scope of this project. The modular program structure provides a clear separation of responsibilities, making the system easier to understand, develop, and maintain over time.

---

• Identification of Entities: Entities still represent the major components or objects within the system, but in MongoDB, these are often referred to as collections. Collections are analogous to tables in relational databases.
• Definition of Attributes: Attributes remain the properties or characteristics of each entity, but in MongoDB, these are represented as fields within documents. Each document in a collection can have different fields based on the data it needs to store.
• Establishment of Relationships: Relationships in MongoDB are typically handled differently compared to relational databases. Instead of foreign keys, denormalization or embedding of related data within documents is common. This can reduce the need for complex joins but requires careful consideration of data duplication and consistency.
• Selection of Data Types: MongoDB supports various data types including strings, integers, dates, arrays, and embedded documents. These are used to define the structure of fields within documents.
• Organization into Collections: Instead of tables, entities and their attributes are organized into collections in MongoDB. Each document within a collection represents a distinct entity, and the structure of documents can vary within the same collection.
• Establishment of Constraints: Constraints in MongoDB are typically applied at the application level rather than at the database level. Data validation rules can be enforced using MongoDB's schema validation feature or within the application code.

In MongoDB, data is stored as collections of documents in BSON (Binary JSON) format. These collections can be thought of as analogous to tables in relational databases. MongoDB provides a flexible schema model, allowing documents within the same collection to have varying structures. This can be advantageous for systems with evolving data requirements.

Alphabetically list the system entities or major data along with their types and descriptions. If you provided a functional description in Section 3.2, list all the functions and function parameters. If you provided an OO description, list the objects and its attributes, methods and method parameters.

Given below is the data dictionary for the Hall Booking Management System, organized alphabetically:

• Booking Description: Represents a booking made by a user for a specific event or hall. Fields: _id (ObjectId): Primary key, unique identifier for the booking. userID (ObjectId): Identifier of the user making the booking. eventID (ObjectId): Identifier of the booked event. status (String): Status of the booking request (e.g., "Pending", "Approved", "Rejected"). bookingDateTime (Date): Date and time of the booking. approvalDateTime (Date): Date and time of approval. hallIDs (Array): Array of hall IDs booked for the event.

• Clubs Description: Represents clubs or academic communities within the institute. Fields: _id (ObjectId): Primary key, unique identifier for the club. clubName (String): Name of the club. description (String): Description of the club.

• Event Description: Represents an event organized by a club. Fields: _id (ObjectId): Primary key, unique identifier for the event. eventName (String): Name of the event. eventType (String): Type of the event (e.g., "Club Activity", "Guest Lecture", "Quiz"). clubID (ObjectId): Identifier of the organizing club. purpose (String): Purpose or description of the event. startDateTime (Date): Start date and time of the event. endDateTime (Date): End date and time of the event. duration (Number): Duration of the event in minutes. ticketBooking (Boolean): Indicates if tickets can be booked for the event. ticketID (ObjectId): Identifier of the associated ticket.

• Hall Description: Represents a hall or room available for booking. Fields: _id (ObjectId): Primary key, unique identifier for the hall. hallName (String): Name of the hall. block (String): Block where the hall is located. capacity (Number): Maximum capacity of the hall.

• ITComplaints Description: Represents IT complaints associated with bookings. Fields: _id (ObjectId): Primary key, unique identifier for the complaint. bookingID (ObjectId): Identifier of the associated booking. hallID (ObjectId): Identifier of the associated hall. note (String): Note describing the IT complaint.

• Membership Description: Represents the membership of users in clubs. Fields: _id (ObjectId): Primary key, unique identifier for the membership. userID (ObjectId): Identifier of the user. clubID (ObjectId): Identifier of the club. positionOfResponsibility (String): Position of responsibility within the club (e.g., "Coordinator", "Representative", "Member").

• Session Description: Represents user sessions for authentication. Fields: _id (ObjectId): Primary key, unique identifier for the session. userID (ObjectId): Identifier of the associated user. token (String): Session token for authentication. expirationTime (Date): Expiration time for the session token.

• Ticket Description: Represents tickets available for booking. Fields: _id (ObjectId): Primary key, unique identifier for the ticket. ticketPrice (Number): Price of the ticket. totalTickets (Number): Total number of tickets available.

• TicketBooking Description: Represents the booking of tickets by users. Fields: _id (ObjectId): Primary key, unique identifier for the ticket booking. studentID (ObjectId): Identifier of the student booking the ticket. ticketID (ObjectId): Identifier of the booked ticket. bookingDateTime (Date): Date and time of the ticket booking.

• User Description: Represents system users. Fields: _id (ObjectId): Primary key, unique identifier for the user. username (String): User's username (email id) for authentication. password (String): User's password hash for authentication. userType (String): Type of user (e.g., “Admin”, "Student", "Faculty", "TA", "IT Staff").

This data dictionary outlines the major entities in the Hall Booking Management System along with their respective fields and descriptions. Each entity is represented as a collection in MongoDB, and documents within these collections store specific instances of data for each entity.

User Authentication:

PDL:

Description: This function verifies user credentials by checking the username and password against the stored records. If the credentials are valid, it generates a session token and stores it for the user's session.

Club Creation:

PDL:

Description: This function allows administrators to create new clubs within the system by providing the club name and description. It creates a new club record in the database.

Event Creation:

PDL:

Description: This function allows users to create events within the system. It creates a new event record in the database with the provided details such as event name, type, organizing club ID, purpose, start date and time, end date and time, duration, and ticket booking availability.

PDL:

Description: This function enables users to book halls for a specific event. It first checks if the event exists in the system. If the event exists, it iterates through the list of hall IDs provided by the user, checks the availability of each hall for the event, and creates bookings for available halls, marking them as pending for admin approval.

Ticket Booking:

PDL:

Description: This function allows students to book tickets for events. It checks if tickets are available for the specified event and ticket type, creates a ticket booking record, and decrements the available ticket count.

Hall Availability Check:

PDL:

Description: This function checks the availability of a hall for a specified event. It retrieves event details and hall availability information from the database and returns true if the hall is available, otherwise false.

IT Complaint Filing:

PDL:

Description: This function allows users to file IT complaints associated with hall bookings. It creates a new IT complaint record in the database with the provided details.

The user interface of the Hall Booking Management System is designed to provide an intuitive and efficient experience for users across various roles including students, faculty, club representatives, and administrative staff. Here's a detailed explanation of the system's functionality from the user's perspective:

• User Authentication: Users are presented with a login screen where they input their username and password. Upon successful authentication, users gain access to the system's features based on their role.
• Viewing Available Spaces: Users can access a dashboard or menu where they can view a list of available halls and rooms. Each space is displayed with relevant information such as hall name, capacity, and availability status.
• Booking Halls: Users can initiate hall booking requests by selecting a specific date and time from a calendar interface. They choose the desired hall from the available options and provide additional details such as event name and purpose. Upon submission, the system processes the request and provides feedback indicating whether the booking was successful or not. In case of a successful booking, users receive confirmation details including the booked hall and event information.
• Viewing Events: Users have access to a section where they can browse through upcoming events organized by various clubs. Event details such as name, type, date, and organizer are displayed in a list format for easy navigation.
• Booking Tickets for Events: For events that require ticket booking, users can reserve tickets directly from the event details page. They specify the number of tickets they wish to book and proceed to complete the booking process. Feedback is provided to confirm the successful booking of tickets, along with details such as ticket numbers and event information.
• Managing Bookings: Users can view their current and past hall bookings from a dedicated section within the interface. Each booking is displayed with relevant details including date, time, hall name, and status. Users have the option to cancel bookings if needed, with feedback provided to confirm the cancellation.
• Submitting IT Complaints: In case of any technical issues or complaints related to hall bookings, users can submit IT complaints through a designated form. They provide details such as booking ID, hall ID, and a description of the issue. Upon submission, users receive feedback acknowledging receipt of the complaint and providing an expected timeline for resolution.

Feedback Information for the User: Throughout the interaction with the system, users receive feedback to ensure clarity and transparency. Feedback mechanisms include:

• Success messages confirming successful actions such as booking requests or ticket reservations.
• Token messages confirming successful login, showing errors for incorrect password while logging in.
• Error messages indicating issues such as invalid inputs or failed actions, with clear instructions on how to rectify them.
• Confirmation dialogs for critical actions such as booking cancellations, ensuring users are aware of the consequences of their actions.
• Notification banners or alerts for important updates or system announcements, keeping users informed about relevant changes or events.

A discussion of screen objects and actions associated with those objects.

• Screen Objects: Username field: Input field for users to enter their username. Password field: Input field for users to enter their password. Login button: Button to submit the login credentials and authenticate the user.
• Actions: Users input their username and password. Upon clicking the Login button, the system verifies the credentials. If the credentials are correct, the user is logged in and directed to the appropriate dashboard or landing page.

• Screen Objects: Date and time selector: Interface for users to choose the date and time of the booking. Hall selection dropdown/list: Dropdown menu or list displaying available halls for booking. Event name field: Input field for users to enter the name of the event. Purpose field: Input field for users to specify the purpose of the booking. Book button: Button to submit the hall booking request.
• Actions: Users select the desired date and time for the booking. Users choose a hall from the available options. Users enter the event name and purpose. Upon clicking the Book button, the system processes the booking request and provides feedback on the status of the booking.

• Screen Objects: Event list: List displaying upcoming events organized by various clubs. Event details: Information such as event name, type, date, and organizer for each event. Ticket booking button: Button or link to initiate the ticket booking process for an event.
• Actions: Users browse through the list of events. Users view details of individual events. Users click the ticket booking button to reserve tickets for specific events.

• Screen Objects: Number of tickets selector: Interface for users to specify the number of tickets they want to book. Book tickets button: Button to confirm the ticket booking.
• Actions: Users select the desired number of tickets. Upon clicking the Book tickets button, the system processes the ticket booking request and provides feedback on the status of the booking.

• Screen Objects: Booking list: List displaying current and past hall bookings made by the user. Booking details: Information such as booking date, hall name, and status for each booking. Cancel button: Button or option to cancel existing bookings.
• Actions: Users view their list of bookings. Users click on individual bookings to view more details. Users have the option to cancel bookings if needed.

• Screen Objects: IT complaint form fields: Input fields for users to enter details of IT complaints. Submit button: Button to submit the IT complaint.
• Actions: Users fill out the IT complaint form with relevant details. Upon clicking the Submit button, the system processes the complaint submission and provides feedback on the status of the submission.

Provide a cross ­reference that traces components and data structures to the requirements in your software requirements specification (SWRS) document.

Use a tabular format to show which system components satisfy each of the functional requirements from the SWRS. Refer to the functional requirements by the numbers/codes that you gave them in the SWRS.