Project Synopsis: College Grievance

Redressal System

Programme Code: BCA

Submitted by: Sourabh Sharma

Enrollment Number: 2253264642

Study Centre: 06036: Goswami Ganesh Dutta Sanatan Dharma College

Chandigarh

Regional Centre: Chandigarh

Session: January 2025

1. Title
"College Grievance Redressal System"

2. Introduction
In modern educational institutions, students frequently encounter a spectrum
of issues ranging from administrative inefficiencies and academic concerns to
practical matters concerning hostel facilities, mess food quality, sports
amenities, and various other campus-related concerns. The prevalent challenge
in many colleges is the absence of a streamlined, structured mechanism for
students to formally register their complaints and for the institution to
efficiently track and address these grievances. This project endeavors to bridge
this gap by developing a comprehensive web-based Grievance Redressal
System. The primary goal of this system is to provide students with a dedicated
platform to submit their complaints, while simultaneously empowering
administrators with the tools to systematically review, respond to, monitor the
progress of, and ultimately resolve these issues in a timely and accountable
manner.

3. Objectives
The core objectives of the College Grievance Redressal System are as follows:

●​ Centralized Platform: To establish a singular, easily accessible online

platform where all students can register their complaints, eliminating
the need for fragmented, informal, or manual grievance submission
processes.

●​ Categorization of Grievances: To enable the classification of submitted

grievances into predefined categories such as Administration, Hostel,
 Mess, Academics, Sports, and Others, facilitating better organization and
routing of complaints to relevant departments.

●​ Administrator Management: To provide administrators and designated

department heads with robust functionalities to review all submitted
grievances, add comments, and update the status of each complaint
through its lifecycle (e.g., Pending, In Progress, Resolved).

●​ Robust User Authentication: To implement a secure user authentication

system that distinguishes between different user roles (Students,
Administrators, and Department Heads), ensuring appropriate access
control and data security.

●​ Automated Reporting: To develop a reporting module capable of

generating automated reports and analytics, offering insights into
grievance trends, resolution times, and recurring issues, thereby aiding
in institutional decision-making.

●​ Transparency and Accountability: To enhance the transparency of the

grievance resolution process and foster accountability among
administrative staff, ensuring that complaints are addressed fairly and
effectively.

4. Project Category
●​ Application Type: Web Application (Database Management System)
●​ Domain Category: Student Support System

5. System Analysis
5.1 Functional Requirements
The system will provide distinct functionalities tailored to different user roles:

User Role Functions

Student - Register and log in securely to the system.

- Submit new grievances, providing details and selecting

a relevant category (e.g., Administration, Hostel, Mess,
Academics, Sports, Others).

- Upload supporting documents or images with their

grievance (optional).

- Track the real-time status of their submitted

complaints (e.g., Pending, In Progress, Resolved).

- View administrative responses and comments on their

grievances.

- Receive notifications regarding status updates or

comments on their complaints.

Administrator / - Log in securely with appropriate credentials.

Department Head

- View a comprehensive list of all submitted grievances,

with filtering and sorting options by category, status,
date, and student.

- Assign grievances to specific departments or

individuals for resolution.
 - Add comments and internal notes to grievances.

- Update the status of grievances (e.g., change from

'Pending' to 'In Progress', or 'Resolved').

- Generate various reports and analytics based on

grievance data (e.g., number of grievances per category,
average resolution time, pending grievances report).

- Manage user accounts and roles (for primary

administrators).

5.2 Non-Functional Requirements

●​ Security: The system will enforce role-based access control (RBAC) to

ensure that users can only access functionalities and data relevant to
their assigned roles. All sensitive data, especially passwords, will be
securely encrypted. Measures will be taken against common web
vulnerabilities like SQL injection and cross-site scripting (XSS).

●​ Performance: The system must be capable of handling a minimum of

500+ concurrent users without significant degradation in response time.
Database queries will be optimized for quick data retrieval.

●​ Usability: The user interface will be intuitive, easy to navigate, and

mobile-friendly, ensuring a consistent and pleasant experience across
various devices (desktops, tablets, smartphones).

●​ Reliability: The system should exhibit high availability and resilience to

failures, with robust error handling and data backup mechanisms in
place.
 ●​ Scalability: The architecture will be designed to allow for future
expansion in terms of data volume, user base, and additional features
without requiring a complete overhaul.

5.3 System Models

Data Flow Diagram (DFD)

●​ Level 0 (Context Diagram): This diagram will illustrate the system as a

single process, showing the primary external entities (Student,
Administrator) and the major data flows. For instance, "Student submits
grievance" as input to the system, and "Admin processes grievance,"
leading to "Status updated" as output.

●​ Level 1 (Decomposition Diagram): This diagram will decompose the Level

0 process into its main sub-processes. It will detail the flow of data for
key functionalities like complaint submission (Student fills form System
validates → Grievance stored), administrator response (Admin retrieves
grievance → Admin adds comment → System updates status →
Notification sent), and notification generation. It will show data stores
(e.g., Grievances Database, Users Database) and their interactions with
processes.

Entity-Relationship (ER) Diagram

The ER Diagram will visually represent the entities within the system and the
relationships between them.

●​ Entities:
○​ Users: Stores information about all system users (students,
administrators, department heads).
○​ Grievances: Stores details of each submitted complaint.
○​ Comments: Stores all comments and responses related to
grievances.
○​ Departments: Stores information about various departments in
the college.
 ●​ Relationships:
○​ User submits Grievance: A one-to-many relationship, where one
user can submit multiple grievances.
○​ Grievance has Comments: A one-to-many relationship, where one
grievance can have multiple comments.
○​ User manages Grievance (Admin/Dept Head): A one-to-many
relationship, where an admin/department head can manage
multiple grievances.
○​ Grievance belongs to Department: A one-to-one or one-to-many
relationship, indicating which department is responsible for
resolving a specific grievance.

6. System Design
6.1 Technology Stack

●​ Frontend:
○​ HTML5: For structuring the web content.
○​ CSS3: For styling and responsive design.
○​ JavaScript ([Link]): For building dynamic and interactive user
interfaces, offering component-based development for scalability
and maintainability.

●​ Backend:
○​ [Link] ([Link] Framework): A robust and scalable JavaScript
runtime environment for server-side logic and API development.
[Link] provides a minimalistic and flexible framework.

●​ Database:
○​ MongoDB: A NoSQL document database chosen for its flexibility in
schema design, scalability, and performance, especially suitable
for handling dynamic data structures.

●​ Authentication:
○​ JSON Web Tokens (JWT): For secure, stateless authentication
between the frontend and backend, ensuring API security.
6.2 Database Schema

The database schema will define the structure of the data stored in MongoDB.

●​ Users Collection:
○​ user_id: String (Unique Identifier, Primary Key)
○​ name: String
○​ email: String (Unique, for login)
○​ password: String (Hashed)
○​ role: String (e.g., 'student', 'admin', 'department_head')
○​ department_id: String (Reference to Departments collection, if
user is department head)

●​ Grievances Collection:
○​ grievance_id: String (Unique Identifier, Primary Key)
○​ title: String (Concise summary of the grievance)
○​ description: String (Detailed explanation of the grievance)
○​ category: String (e.g., 'Administration', 'Hostel', 'Mess', 'Academics',
'Sports', 'Others')
○​ status: String (e.g., 'Pending', 'In Progress', 'Resolved', 'Closed')
○​ student_id: String (Reference to Users collection)
○​ assigned_to_department_id: String (Reference to Departments
collection)
○​ date_submitted: Date (Timestamp of submission)
○​ last_updated: Date (Timestamp of last status change or comment)
○​ attachments: Array of Strings (URLs to uploaded files, if any)

●​ Comments Collection:
○​ comment_id: String (Unique Identifier, Primary Key)
○​ grievance_id: String (Reference to Grievances collection)
○​ user_id: String (Reference to Users collection - who made the
comment)
○​ message: String (The content of the comment)
○​ timestamp: Date (When the comment was made)

●​ Departments Collection:
○​ department_id: String (Unique Identifier, Primary Key)
○​ name: String (e.g., 'Academic Affairs', 'Hostel Warden', 'Mess
Committee', 'Sports Department')
6.3 Modules

The system will be segmented into the following key modules:

1.​ User Authentication Module:

○​ Handles student and administrator registration processes.
○​ Manages user login and logout functionalities.
○​ Implements secure password hashing and JWT token generation
for session management.
○​ Manages different user roles and permissions.

2.​ Grievance Submission Module (Student Interface):

○​ Provides a user-friendly form for students to submit new
grievances.
○​ Allows selection of grievance categories and inclusion of detailed
descriptions.
○​ Enables optional file attachments (e.g., photos, documents).
○​ Displays a dashboard for students to view their submitted
grievances and their current status.

3.​ Admin Dashboard Module (Administrator/Department Head Interface):

○​ Presents a comprehensive dashboard displaying all grievances.
○​ Includes robust filtering, searching, and sorting capabilities for
grievances.
○​ Enables administrators/department heads to view grievance
details, assign them to departments, add comments, and update
their status.
○​ Provides an overview of pending, in-progress, and resolved
grievances.

4.​ Reporting and Analytics Module:

○​ Generates various reports, such as:

■​ Number of grievances by category.
■​ Average grievance resolution time.
■​ Status breakdown of all grievances.
■​ Reports on frequently occurring issues.
 ○​ Provides analytical insights to help identify systemic problems and
areas for improvement.

7. Testing Strategy
A multi-faceted testing strategy will be employed to ensure the system's
robustness, reliability, and user satisfaction:

●​ Unit Testing: Individual components and functions (e.g., user

authentication logic, grievance submission API endpoint, status update
function) will be tested in isolation to verify they perform as expected.
This will utilize testing frameworks compatible with [Link] and React.

●​ Integration Testing: The interaction between different modules and

components will be tested. This includes verifying the entire workflow
from student grievance submission to administrator response and status
update, ensuring seamless data flow between frontend, backend, and
database.

●​ User Acceptance Testing (UAT): A critical phase involving actual students

and college staff (administrators, department heads) to test the system
in a real-world scenario. Feedback from these end-users will be collected
to identify usability issues, validate that functional requirements are met,
and ensure the system aligns with their expectations and needs.

●​ Performance Testing: Load testing will be conducted to assess the

system's behavior under expected and peak user loads, ensuring it
meets the non-functional requirement of handling 500+ concurrent
users efficiently.

●​ Security Testing: Penetration testing and vulnerability scanning will be

performed to identify and mitigate potential security weaknesses,
ensuring data protection and secure access control.
8. Expected Outcomes
The successful implementation of the College Grievance Redressal System is
expected to yield several significant benefits:

●​ Reduced Resolution Time: Anticipated reduction in the average time

taken to resolve grievances by approximately 40%, due to improved
tracking, faster communication, and streamlined processes.

●​ Enhanced Transparency: Greater transparency in the grievance

resolution process, allowing students to track the progress of their
complaints and holding administrators accountable.

●​ Improved Communication: Facilitation of clearer and more efficient

communication channels between students and the college
administration.

●​ Automated Reminders: Implementation of automated reminders or

notifications for pending grievances, ensuring that no complaint is
overlooked or unduly delayed.

●​ Data-Driven Insights: Provision of valuable data for administrators to

identify recurring issues, analyze trends, and make informed decisions to
improve college services.

9. Future Scope
The proposed system has significant potential for future enhancements and
expansions:

●​ Mobile Application: Development of dedicated mobile applications (iOS

and Android) to provide students and staff with convenient access and
real-time push notifications.
 ●​ AI-based Categorization: Integration of Artificial Intelligence (AI) or
Machine Learning (ML) algorithms for automated categorization of
grievances based on their description, improving efficiency and
accuracy.

●​ SMS/Email Alerts: Implementation of SMS and/or email notification

services to provide instant alerts to students and administrators
regarding status updates, new comments, or resolution confirmations.

●​ Feedback Mechanism: Introduction of a feedback mechanism for

students to rate the resolution process once their grievance is marked as
'Resolved', providing valuable insights for continuous improvement.

●​ Knowledge Base/FAQ: Creation of a searchable knowledge base or

Frequently Asked Questions (FAQ) section to address common issues,
potentially reducing the number of new grievances.

●​ Integration with Existing Systems: Potential integration with other

college systems (e.g., student information systems, HR systems) for
seamless data exchange.

10. Conclusion
The College Grievance Redressal System is designed as a crucial technological
intervention to modernize and professionalize the grievance management
process within educational institutions. By providing a centralized, transparent,
and efficient platform, this system will not only streamline the handling of
student complaints but also significantly enhance student-administration
communication. Ultimately, it aims to ensure the timely and satisfactory
resolution of issues, fostering a more responsive and accountable institutional
environment that prioritizes student well-being and academic success.
Level 0 DFD (Context Diagram)

+----------------+ +--------------------+

| | Submit Grievance | |

| Student | ----------------------> | Grievance System |

| | <---------------------- | (Web Application) |

+----------------+ Status Update/View +--------------------+

^ |

| |

+-----------------------------+ v

| +----------------+
+---------------------+

| | Administrator /| | Department Head

|

| | Department Head| |
|

| +----------------+
+---------------------+

| View/Assign/Resolve/Comment

Level 1 DFD

Decomposition of Core Processes:

Process: Submit Grievance

-----------------------------------
Student --> Fill Grievance Form --> Validate Form --> Store
Grievance in DB

Process: Admin Review

-----------------------------------

Admin --> Login --> View Grievance --> Assign/Comment --> Update
Status

Process: Notification

-----------------------------------

System --> Generate Notification --> Send to Student/Admin

Process: Reporting

-----------------------------------

Admin --> Request Report --> System Fetches Data --> Show Analytics

Data Stores:

- Users DB

- Grievances DB

- Comments DB

- Departments DB

- Reports DB

Level 1 DFD Layout:

+-------------+ +-----------------+
+----------------+

| Student | -------> | Submit Grievance| -----> | Grievances DB

|

+-------------+ +-----------------+
+----------------+

+-----------------+

| Notification |

+-----------------+

+------------------+ +--------------+

| Admin / Dept Head | <--- View Status | <----- | Users DB |

+-----------------------+ | +--------------+

+------------------+

| Admin Response |

+------------------+

+------------------------+

| Update Grievance DB |

+------------------------+
 |

+-----------------+

| Reporting Module|

+-----------------+

+------------+

| Reports DB |

+------------+

Entity Relationship Diagram (ERD)

Entities and Attributes

1.​ Users​

○​ user_id (PK)​

○​ name​

○​ email (Unique)​

○​ password (Hashed)​

○​ role (student/admin/department_head)​

○​ department_id (FK)​

2.​ Grievances​
 ○​ grievance_id (PK)​

○​ title​

○​ description​

○​ category​

○​ status​

○​ student_id (FK from Users)​

○​ assigned_to_department_id (FK)​

○​ date_submitted​

○​ last_updated​

○​ attachments​

3.​ Comments​

○​ comment_id (PK)​

○​ grievance_id (FK)​

○​ user_id (FK)​

○​ message​

○​ timestamp​

4.​ Departments​

○​ department_id (PK)​

○​ name​

Relationships
 ●​ One User can submit many Grievances​

●​ One Grievance belongs to one User​

●​ One Grievance is handled by one Department​

●​ One Grievance can have multiple Comments​

●​ One User can make multiple Comments​

●​ One Department can have multiple Users (dept heads/admins)​

ER Diagram Sketch

Users

------

user_id (PK)

name

email

password

role

department_id (FK) ------------+

Departments

-----------

department_id (PK)

name
Users 1 ---- * Grievances

grievance_id (PK)

title

description

category

status

student_id (FK)

assigned_to_department_id (FK)

date_submitted

last_updated

attachments

Grievances 1 ---- * Comments

comment_id (PK)

grievance_id (FK)

user_id (FK)

message

timestamp