Housing Society Management System

(HSMS)
Submitted by

Maham Javed 2021-GCUF-081713

Eman Khalid 2021-GCUF-078212

Project submitted in partial contentment

of the requirement for the Degree of

BACHELOR OF SCIENCE

IN

COMPUTER SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

GOVERNMENT COLLEGE UNIVERSITY FAISALABAD

2021-2025

i
 DECLARATION
We declare this Project “Housing Society Management System (HSMS)”
as a whole, Also, any of its parts is not copied from any other source. Further,
we have done this project with the accompanied documentation based on our
effort and with the guidance of our respected teacher; especially our Project
Supervisor Sir Hanzala Aziz. If any particular part of our project is proved
to be copied or found in the reproduction of this Website, we shall stand by
the consequences.

___________________________

Maham Javed

(2021-GCUF-081713)

___________________________

Eman Khalid

(2021-GCUF-078212)

ii
 DEDICATION

We would be honor to dedicate this project to our superficial parents, family, our precious
caring teachers and friends who give us their full spirit support to work hard day and night.
These people that gave us the spirit and value necessary to be where we are standing today.
My parents and my teachers support us on every step we make, and decision we talk but it
is necessary to understand that they let us take our decision along in order for us to learn
from our mistakes and as my mother says to learn and grow from each seatback. we will
never finish to thanks to my parents and teachers for all the teachings that they have told
us and for every advice that come out of their mouth. We dedicate this project to our parent
whom expect our effort on everything that we think and do that this compilation is perfect
in which reflection of our hard work in learning skills. We are grateful for trusting that we
would do a good job in the university. our parents, we hope that we can make you proud,
the same ways that we are proud of having as our parents.

iii
 CERTIFICATE
This is to certify that we have read the report submitted by Maham Javed (2021-GCUF-
081713) and Eman Khalid (2021-GCUF-078212) for the partial fulfilment of the
requirement for the degree of the Bachelors of Computer Science. We judge that this report
is of sufficient standard to warrant its acceptance by Government Collage University,
Faisalabad for the degree of Bachelors of Computer Science.

Signature of Supervisor ………………….…………

Name: …………………………………..……...…...

Designation with Stamp…………………………….

Member of Supervisory Committee

Signature………………………………….….….….
Name: ……………………………….….……...…...
Designation with Stamp………………………....….

Member of Supervisory Committee

Signature ……………...…………………..….….….
Name: …………………………………..……...…...
Designation with Stamp………………………....….

Chairperson

Signature with stamp………………………………

iv
 ACKNOWLEDGEMENTS
All praise to ALMIGHTY ALLAH, the most merciful and the most compassionate and
the HOLY PROPHET “MUHAMMAD” (Peace be upon him) the most perfect and
exalted among and even born on the surface of the earth, who is, forever a to torch of
guidance and knowledge for the humanity as a whole.

We feel highly privileged to take this opportunity to express our heartiest gratitude and
deep sense of indebted to my worthy supervisor, Sir Hanzla Aziz under whose kind and
scholastic guidance, keen interest and constant encouragement words are very important to
convey thoughts and thanks, the words are impossible to find to thank our father and the
whole family for their prayers and encouragement for us and our work.

Finally, we apologize if we have caused anger or offence to anybody and the errors that
remain in the documentation by our side.

___________________________

Maham Javed

(2021-GCUF-081713)

___________________________

Eman Khalid

(2021-GCUF-078212)

v
 Table of Contents:

CHAPTER 1 ....................................................................................................................... 1
INTRODUCTION.............................................................................................................. 1
1.1. Project Purpose ......................................................................................................... 1
1.1.1. Significance of the Project: ................................................................................ 1
1.1.2. Aims and Objectives: ......................................................................................... 2
1.2. How it Works: ........................................................................................................... 3
1.2.1. System Overview: .............................................................................................. 4
1.2.2. System Workflow: ............................................................................................. 5
1.3. Project Scope: ........................................................................................................... 6
1.3.1. Scope Definitions: .............................................................................................. 6
1.3.2. Assumptions and Constraints:.......................................................................... 10
1.4. Project Planning ...................................................................................................... 13
1.4.1. Project Timeline: .............................................................................................. 13
1.4.2. Resource Planning: .......................................................................................... 15
CHAPTER 2 .................................................................................................................... 17
BACKGROUND AND REQUIREMENTS ................................................................... 17
2.1. Background Research ............................................................................................. 17
2.2. Stakeholders ............................................................................................................ 18
2.3. Functional Requirements ........................................................................................ 20
2.3.1. Admin Login .................................................................................................... 25
2.3.2. Resident Login ................................................................................................ 26
2.4. Non-Functional Requirements ................................................................................ 28
2.4.1 User Interface (UI) ............................................................................................ 28
2.4.2 Fast Response Time .......................................................................................... 28
2.4.3 Ease of Use ...................................................................................................... 29
2.4.4 Performance Requirements .............................................................................. 29
2.4.5 Safety Requirements ........................................................................................ 29
2.4.6 Security Requirements ..................................................................................... 29
2.4.7 Software Quality Attributes ............................................................................. 30
CHAPTER 3 ..................................................................................................................... 31
DESIGN ............................................................................................................................ 31

vi
 3.1. System Sequence Diagram for Admin .................................................................... 31
3.2. System Sequence Diagram for Resident ................................................................. 31
3.3. Class Diagram ......................................................................................................... 32
3.4. Entity Relationship Diagram................................................................................... 34
CHAPTER 4 ..................................................................................................................... 35
IMPLEMENTATION ..................................................................................................... 35
4.1. Technology Stack.................................................................................................... 35
4.1.1 [Link] (Frontend) ......................................................................................... 35
4.1.2 [Link] and [Link] (Backend) ................................................................. 35
4.1.3 MongoDB Atlas (Cloud Database) ................................................................ 35
4.1.4 JWT Authentication & [Link] ................................................................... 35
4.1.5 Git & GitHub (Version Control) .................................................................... 35
4.1.6 Cloud Deployment (Render/Netlify) ............................................................. 36
4.1.7 Postman (API Testing) ................................................................................... 36
4.1.8 Chrome DevTools & Lighthouse (Performance Monitoring) ....................... 36
4.2. Web Application Development............................................................................... 36
4.2.1 Dashboard Customization .............................................................................. 36
4.2.2 Complaint Management Module ................................................................... 36
4.2.3 Resident Registration & Verification............................................................. 36
4.2.4 Notice Board Posting ..................................................................................... 36
4.2.5 Profile & Session Management ..................................................................... 37
4.3. Testing and Quality Assurance ............................................................................... 37
4.3.1 Functional Testing ......................................................................................... 37
4.3.2 User Experience (UX) Testing....................................................................... 37
4.3.3 Performance Testing ...................................................................................... 37
4.4. Deployment ............................................................................................................. 37
4.5. Admin Training and Handover ............................................................................... 37
CHAPTER 5 ..................................................................................................................... 38
TESTING .......................................................................................................................... 38
5.1. Testing Methods...................................................................................................... 38
5.2. Validation Testing ................................................................................................... 39
5.2.1. Validation Testing Variation............................................................................ 39
5.3. Functional Testing .................................................................................................. 39
5.4. Test Cases ............................................................................................................... 40
vii
 5.4.1 Test Case 1: Resident Registration ................................................................... 40
5.4.2 Test Case 2: Admin Login ................................................................................ 40
5.4.3 Test Case 3: Complaint Submission ................................................................. 41
5.4.4 Test Case 4: Notice Posting .............................................................................. 42
5.4.5 Test Case 5: Profile Update .............................................................................. 42
5.4.7 Test Case 7: Complaint Management (Admin Side) ........................................ 43
5.4.8 Test Case 8: Complaint Status Tracking (Resident Side) ................................. 44
5.4.9 Test Case 9: Notice Viewing (Resident Side)................................................... 44
5.4.10 Test Case 10: Document Upload (During Registration) ................................. 45
5.4.11 Test Case 11: Document Verification (Admin Side) ...................................... 45
5.4.12 Test Case 12: Activity Logging ...................................................................... 46
5.4.13 Test Case 13: Admin Dashboard Access ........................................................ 46
5.4.14 Test Case 14: Resident Dashboard Access ..................................................... 47
5.4.15 Test Case 15: Session Timeout ....................................................................... 47
CHAPTER 6 ..................................................................................................................... 48
CONCLUSION AND FUTURE WORK ....................................................................... 48
6.1. Conclusion ......................................................................................................... 48
7.2. Future Work ....................................................................................................... 48
7.3. Reflections on the Project .................................................................................. 49

viii
 List of Figures:
Figure 2.1 Use Case Diagram Admin Login………………………………..……..32

Figure 2.2 Use Case Diagram Resident Login………………………….….….…..34

Figure 3.1 System Sequence Diagram for Admin Login…………………………..39

Figure 3.2 System Sequence Diagram for Resident Login……………………...…40

Figure 3.3 Class Diagram for HSMS…………………………………….……..….42

ix
 List of Tables
Table1.1 Project Timeline................................................................................................14
Table2.1 Functional Requirements……………………………………………………...22

Table5.4.1 Test Case 1: Resident Registration………………………………………….40

Table5.4.2 Test Case 2: Admin Login…………………………………………………..40

Table5.4.3 Test Case 3: Complaint Submission………………………………………...41

Table5.4.4 Test Case 4: Notice Posting…………………………………………………42

Table5.4.5 Test Case 5: Profile Update…………………………………………………42

Table5.4.6 Test Case 6: Logout…………………………………………………………43

Table5.4.7 Test Case 7: Complaint Management (Admin Side)………………………..43

Table5.4.8 Test Case 8: Complaint Status Tracking (Resident Side)…………………...44

Table5.4.9 Test Case 9: Notice Viewing (Resident Side)……………………………….44

Table5.4.10 Test Case 10: Document Upload (During Registration)……………………45

Table5.4.11 Test Case 11: Document Verification (Admin Side)…………………….....45

Table5.4.12 Test Case 12: Activity Logging…………………………………………......46

Table5.4.13 Test Case 13: Admin Dashboard Access……………………………………46

Table5.4.14 Test Case 14: Resident Dashboard Access………………………………….47

Table5.4.15 Test Case 15: Session Timeout……………………………………………...47

x
CHAPTER 1:
INTRODUCTION

1.1. Project Purpose

Modern residential societies face various administrative, communicational, and
security-related challenges due to their growing populations and operational complexities.
These issues are further exacerbated in societies still relying on manual systems, physical
documentation, and fragmented communication methods. The purpose of this project is to
develop a centralized, web-based Housing Society Management System (HSMS) that
streamlines society operations, enhances communication, and provides a secure digital
platform for both residents and administrators.

The proposed HSMS is aimed at reducing the dependency on manual record-

keeping and inefficient practices by replacing them with digital workflows. By providing
functionalities such as resident registration, complaint submission and tracking, notice
sharing, and document verification, the platform seeks to enhance transparency and
operational efficiency. It is designed to be user-friendly, secure, and scalable, making it a
viable digital solution for housing societies of different sizes.

The system will facilitate better coordination among stakeholders such as residents,
society administrators, maintenance staff, and security personnel. It will also provide
structured data storage, access control, and real-time tracking of activities—helping
management make informed decisions and improving overall resident satisfaction.
Furthermore, HSMS introduces digital security protocols and automation that contribute to
a more resilient and responsive community ecosystem.

1.1.1. Significance of the Project:

The significance of this project lies in its direct impact on the quality of life for
residents and the ease of administration for society managers. In many urban and suburban
residential communities, there is often no structured way to handle resident grievances,
share emergency information, or verify the identity of individuals entering the society
premises. These gaps not only lead to frustration and confusion but also create potential
risks related to safety, data mismanagement, and operational delays.

By implementing HSMS, these societies can benefit from a streamlined

administrative process that is both efficient and accountable. One of the major advantages

1
is the digitization of resident records and complaints. This eliminates the reliance on
manual registers and paper files, which are not only difficult to manage but also prone to
human error and tampering. The digital approach allows instant updates, automatic
backups, and easy access to information for authorized personnel.
Moreover, the system ensures real-time communication between the residents and
the administration. Residents can receive updates about maintenance schedules, important
meetings, and emergency situations through notices directly accessible via their
dashboards. Such timely communication can significantly improve trust and transparency,
making the society feel more like a well-governed community rather than a disconnected
cluster of homes.
Security is another critical area addressed by HSMS. The platform uses role-based
access control to restrict functionalities according to user type (e.g., resident, admin,
security guard). This not only protects sensitive information but also prevents unauthorized
actions. Furthermore, the implementation of ID verification mechanisms and visitor
logging enhances physical security within the community.
From an academic and development perspective, this project also serves as a
practical implementation of modern web development principles. It incorporates real-world
software engineering practices, cloud-based databases, front-end and back-end integration,
and a secure authentication framework using JSON Web Tokens (JWT). Therefore, it has
both functional and educational significance.

Lastly, HSMS is designed to be scalable and modular, which means that it can be
adapted or extended for future needs, such as utility bill management, visitor passes, facility
booking, and integration with IoT devices for smart homes. This future-ready design makes
the system not just a project, but a potential product that can evolve into a full-fledged
residential management solution in the real estate domain.

1.1.2. Aims and Objectives:

The main aim of this project is to design and develop a smart and secure web-based
platform that simplifies the management of housing society operations. This includes a
comprehensive system for registering residents, managing complaints, publishing notices,
verifying identity documents, and maintaining digital records of society activities.

To support this aim, Housing Society Management System (HSMS) has several key
objectives:

2
  To provide a centralized digital platform that unifies all essential society
operations, making them accessible via a web browser.
 To enable secure resident registration and login, utilizing role-based access and
JWT-based authentication for session management.
 To build a complaint management system that allows residents to raise issues and
track their status while enabling admins to respond and update complaints
accordingly.
 To implement a digital notice board where admins can post important
announcements such as maintenance updates, meeting notices, or community alerts
that are visible to all residents.
 To ensure resident safety and identity verification by allowing users to upload
official ID documents, which admins can review and approve/reject.
 To offer a responsive dashboard-based interface for both residents and
administrators, allowing easy access to functionalities based on user roles.
 To maintain log records and system activities, ensuring transparency and
accountability for all user actions.
 To structure the application using modern, modular design principles to allow easy
future expansion such as utility billing, visitor pass generation, and facility booking.

Collectively, these aims and objectives will transform traditional housing societies into
smart, connected communities, enabling efficient management and a better resident
experience.

1.2. How it Works:

The Housing Society Management System is built using modern web technologies
and follows a layered architecture. The front-end is developed using [Link] and
Tailwind CSS for building a responsive and intuitive user interface. The back-end is
developed using [Link] with [Link], offering RESTful APIs that handle business
logic, data manipulation, and secure authentication.

User data, complaints, notices, and verification documents are stored securely using
MongoDB Atlas, a cloud-hosted NoSQL database. All interactions between the front-end
and back-end are secured using HTTPS and JWT-based authentication to ensure privacy
and session integrity.

3
 Residents and admins interact with the system through distinct role-based
dashboards. Upon registering and uploading ID documents, residents can log in to the
platform and access features such as filing complaints, viewing notices, and checking
complaint statuses. Admins, on the other hand, can manage resident data, approve or reject
verification requests, respond to complaints, post notices, and view activity logs.

The system is hosted on localhost but for now but it can be shifted to cloud such as
Vercel, Render, and Railway for front-end and back-end deployment, allowing 24/7
availability via modern web browsers across devices including desktops, laptops, tablets,
and smartphones.

1.2.1. System Overview:

The Housing Society Management System is envisioned as a standalone, cloud-
hosted web application with a modular design. The system is designed to operate across
a wide range of devices and browsers, ensuring accessibility for both technical and non-
technical users.

From a high-level architectural perspective, the system consists of three primary layers:

 Presentation Layer (Front-End): This layer provides the graphical user interface
(GUI) through which residents and admins interact with the system. Built using
[Link] and styled with Tailwind CSS, it offers a clean and responsive design that
supports real-time feedback (e.g., toast notifications, form validations).
 Application Layer (Back-End): The core logic resides here. Built on [Link] and
[Link], this layer handles user authentication, role verification, form
submissions, document uploads, complaint tracking, and more. RESTful APIs are
used for front-end and back-end communication.
 Data Layer (Database): Using MongoDB Atlas, the system stores data in
structured collections such as users, complaints, notices, documents, and logs. Data
security and schema validation are enforced using Mongoose ORM.

Security protocols such as JWT (JSON Web Token) for session handling, HTTPS
for data encryption, and role-based access control (RBAC) are incorporated to protect
sensitive operations and data.

4
 The system is designed with modularity in mind. New features such as facility
booking, digital payments, or visitor pass tracking can be added with minimal code
restructuring. Furthermore, logging and analytics functionalities are included to help
society managers monitor user activity and system usage patterns.

1.2.2. System Workflow:

The workflow of HSMS is structured around user roles and operational priorities of
a typical housing society. The following steps illustrate how the system functions from
registration to daily operations:

1. Registration
Residents visit the platform and register their profile by providing details such as
name, email, society block, and uploading an official ID. The uploaded document is sent
to the admin for review.

2. Admin Verification
The admin reviews the registration request along with the submitted ID. Upon
approval, the resident receives access credentials and can log in to the system.

3. Resident Dashboard
Once logged in, the resident can view notices, file complaints, track their complaint
status, and manage their profile details.

4. Admin Dashboard
The admin has access to a more comprehensive dashboard that displays metrics
such as total residents, pending verifications, active complaints, and recent notices. Admins
can post new notices, update complaint statuses, and view ID documents.

5. Complaint Lifecycle

A resident submits a complaint using a web form. The complaint appears on the
admin dashboard with a default status ("Pending"). The admin can change the status to "In
Progress" or "Resolved" depending on the action taken.

5
6. Notice Sharing

Admins post notices which are immediately visible to all residents through their
dashboard. Notices are sorted by date, with real-time refresh and optional notification
features.

7. Document Management
Uploaded documents are securely stored in the cloud and are accessible only to
authorized admins. Encryption and access tokens are used to prevent unauthorized access.

8. Activity Logging

All significant actions (registrations, logins, complaint updates, notice postings,

document reviews) are logged with user ID and timestamps. These logs are viewable by
the admin for auditing and monitoring purposes.

This well-structured workflow ensures operational clarity, enhances user

satisfaction, and supports transparent governance of the housing society.

1.3. Project Scope:

1.3.1. Scope Definitions:

The Housing Society Management System (HSMS) is a web-based platform
designed to address the operational, administrative, and security challenges commonly
faced in modern residential societies. The scope of this project includes the design,
development, deployment, and partial maintenance of a secure, user-friendly, and modular
platform accessible via modern web browsers across desktop and mobile devices.

This academic project focuses on building a Minimum Viable Product (MVP) that
supports essential society functions such as resident registration, complaint management,
notice broadcasting, user authentication, and administrative control, while laying a scalable
foundation for future expansion into areas like billing, visitor management, and emergency
alert systems.

The following detailed breakdown defines the functional, technical, and user-
related scope of the HSMS:

6
1. Core Functionality:

 User Registration and Login: The system enables residents to self-register by

providing personal information and uploading official ID documents. Admins
review these submissions and approve or reject them based on verification. Secure
login sessions are managed via JWT (JSON Web Tokens), and passwords are stored
in an encrypted format.
 Resident Dashboard: After successful login, registered residents are granted
access to a dedicated dashboard where they can file complaints, view notices, check
complaint statuses, and update their profile information.
 Admin Dashboard: Society administrators have a comprehensive dashboard where
they can manage resident profiles, approve or reject verification requests, track and
respond to complaints, post notices, and monitor overall system usage through
analytics and logs.
 Complaint Management System: Residents can submit complaints categorized by
type (e.g., plumbing, security, cleanliness). Admins receive these complaints and
can change their statuses (e.g., Pending, In Progress, Resolved), which are instantly
reflected on the resident dashboard.
 Notice Board: Admins can post announcements and event notifications. Residents
can view these notices in real time, sorted by date. Notices may include maintenance
updates, emergency alerts, or meeting schedules.
 Document Verification: The system supports secure document uploads during
registration. Admins can view these documents through a protected interface and
take appropriate verification actions.
 Acitivity logs and Monitoring: Every significant user action like registration,
complaint updates, document uploads which is logged with timestamps and user
IDs. Admins can access these logs for monitoring and auditing purposes.

2. Platform and Technology Scope:

 Cross-Browser Compatibility:

The app will be developed using Flutter, which ensures compatibility across both
Android and iOS platforms. This cross-platform approach increases accessibility and
broadens the user base by making the app available to a larger audience.

7
  Technology Stack:

The platform will be optimized for mobile devices to ensure smooth performance,
responsiveness, and consistent user experience across different screen sizes and operating
systems.

 Front-End: [Link] with Tailwind CSS

 Back-End: [Link] and [Link]
 Database: MongoDB Atlas (NoSQL, cloud-based)
 Authentication: JWT and role-based access control (RBAC)
 Hosting Platforms: Vercel (front-end), Render/Railway (back-end)

3. User Roles:

 Admin (Society Manager):

o Verifies residents
o Posts and manages notices
o Responds to complaints
o Accesses analytics and logs
o Views uploaded documents

 Resident:
o Registers with ID upload
o Files complaints
o Views complaint history and notices
o Updates profile information

 Security Guard (Future Scope):

o May verify residents or visitors via ID or face recognition
o Access visitor entry logs

4. Security and Privacy:

 Authentication and Authorization:

JWT-based sessions, encrypted password storage, and role-based feature access.

8
  Data Protection:
ID documents and sensitive user information are stored securely in the cloud,
protected using access tokens and encryption layers.
 Session Management:
Sessions automatically expire after a set duration (e.g., 15 minutes of inactivity),
minimizing risks of unauthorized access.

5. Scalability and Future Enhancements:

The HSMS is built with modularity and extensibility in mind. Future versions may
include:

 Utility bill generation and online payment integration

 Facility booking (e.g., gym, pool, meeting halls)
 Visitor pass and guest entry system
 SMS/email notification systems
 Mobile application for Android and iOS
 AI-based analytics for resident satisfaction and issue prediction

6. Administrative Features (Future Scope):

In later phases, an administrative control panel may be introduced to:

 Monitor platform activity and performance metrics

 Review and manage community-wide settings
 Handle disputes and misconduct
 Oversee security measures and role escalations
 Integrate reporting and feedback systems

7. Limitations (Out of Scope):

 Native Android or iOS mobile apps (web-only in current version)

 Integration with external payment gateways
 Compliance with international data protection laws (e.g., GDPR, HIPAA)
 Biometric verification features (e.g., fingerprint or facial ID login)
 Offline functionality for areas with poor internet coverage

9
  Real-time communication channels (e.g., in-app chat)

8. Maintenance and Support:

 Routine Maintenance: After deployment, the system will undergo regular

maintenance such as patching vulnerabilities, updating libraries, and ensuring
consistent performance.
 User Support and Documentation: A simple user guide/manual is planned to
assist users with system onboarding, troubleshooting, and feature utilization. Future
integration of a ticketing/helpdesk module is also possible.

1.3.2. Assumptions and Constraints:

The development and deployment of the HSMS system rest upon a set of
foundational assumptions and inherent limitations that define the boundaries of the
project’s implementation and adoption.

Assumptions

 Internet Access: All users are assumed to have access to a stable internet
connection as the platform is entirely web-based.
 Browser Compatibility: Users are expected to access the system using modern
web browsers. Legacy browsers or unsupported versions may not render the
application properly.
 Basic Technical Proficiency: Residents and admins are assumed to have basic
familiarity with common web platforms, such as form filling, uploading documents,
and navigating dashboards.
 Valid Document Uploads: It is assumed that residents will upload clear and
legitimate identification documents for admin verification.
 Admin Trustworthiness: Admin users are assumed to act responsibly with access
privileges and will not exploit or misuse sensitive resident data.
 Open-Source Stability: The system depends on open-source libraries like [Link],
[Link], and Mongoose. It is assumed that these libraries remain stable and
maintained during the lifecycle of this project.
 Cloud Service Reliability: Hosting services such as Vercel, Render, and
MongoDB Atlas are assumed to remain operational and stable for public use in
future.
10
Constraints
The development and implementation of the Housing Society Management
System (HSMS) are bounded by several technical, operational, and contextual
constraints. These limitations directly impact the initial scope of the project, the number
of features that can be delivered in the first version, and the overall deployment strategy. It
is crucial to acknowledge and manage these constraints to ensure the success and
sustainability of the platform throughout its lifecycle.

 Budgetary Limitations:

As a final-year academic project, HSMS is being developed under a limited or zero-

cost budget. As a result, premium cloud services, commercial APIs, and paid security tools
are avoided. This financial constraint restricts the ability to integrate advanced features like
SMS gateways, in-app notifications, and professional-grade document verification
systems. Free-tier cloud platforms (e.g., Vercel, Render, MongoDB Atlas) are used, which
come with usage limits in terms of storage, performance, and bandwidth.

 Time Constraints:

The development of HSMS is bound by a tight academic timeline, typically one

semester or a few months. Due to this deadline, the system is limited to delivering core
modules such as resident registration, complaint tracking, and notice management.
Additional modules like billing, visitor logging, and real-time alerts are marked for future
releases and are excluded from the MVP.

 Server Infrastructure Constraints:

The system is hosted using limited free-tier resources, which may affect its ability
to scale for larger societies. As the number of users and database entries increases,
performance degradation may occur. Free hosting platforms offer limited concurrent
connections, storage capacity, and uptime guarantees, which may restrict the reliability of
the application in real-world deployment scenarios.

 Device and Browser Compatibility:

Although the HSMS is built to be responsive, it may not perform optimally on older
browsers, outdated operating systems, or legacy devices. Features such as file uploads,
camera-based document scanning, and dynamic dashboards may not be fully supported on
low-end mobile phones or browsers without JavaScript and modern HTML5 features.

11
  Legal and Regulatory Compliance:

While the system handles sensitive data (e.g., ID documents, resident information),
it is not compliant with legal standards such as GDPR, ISO/IEC 27001, or Pakistan’s
Personal Data Protection Bill. Due to the academic nature of the project, legal oversight
and official certifications have not been obtained. As such, HSMS is not suitable for
deployment in a production environment where compliance is mandatory.

 No Payment Integration (Phase 1):

The initial scope does not include any integration with third-party payment
gateways like Stripe or Easypaisa. Residents must handle maintenance payments, utility
bills, or booking fees outside the system. This limits the platform’s functionality as a
complete financial management tool for societies.

 API Dependency and Stability:

Several system features rely on open-source libraries and third-party APIs, such as
document upload handling, webcam access, and JWT-based authentication. Any
unavailability, deprecation, or changes in these APIs can disrupt the functioning of the
HSMS platform and may require major adjustments in the system architecture.

 Limited User Engagement:

The usefulness of HSMS relies heavily on user adoption by both society admins
and residents. If admins do not actively manage complaints or update notices, or if residents
do not submit accurate information or engage with the platform, the overall system impact
may be minimal. Low engagement in early stages may limit the project's perceived success.

 Cybersecurity Challenges:

Although encryption and secure login mechanisms are implemented, the platform
may still be vulnerable to common cyber threats such as brute-force login attempts, session
hijacking, or XSS attacks due to limited time for penetration testing and absence of
professional security audits. Maintaining system integrity will require periodic code
reviews and updates, which may not be feasible under academic timelines.

 Real-Time Data Sync Limitations:

The system does not currently use technologies like WebSockets or long polling for
real-time updates. This means that complaint status updates or new notices may not appear

12
immediately to users unless they manually refresh their dashboards. This can affect user
experience in scenarios requiring quick communication, such as emergency alerts.

 Offline Functionality Not Supported:

HSMS requires continuous internet access to function. Users cannot file complaints,
view notices, or access their profiles without an active internet connection. This limits its
usability in remote areas or during network outages, where offline-first capabilities could
be beneficial.

These constraints define the realistic boundary conditions within which the
HSMS project has been designed and developed. They guide decision-making throughout
the development process and help in managing expectations from both academic evaluators
and real-world users. While many of these constraints can be addressed in future phases
through funding, additional development, or infrastructure upgrades, they must be accepted
as limitations in the current version.

This comprehensive scope statement defines the operational boundaries, expected

deliverables, and limitations for the development of the Housing Society Management
System (HSMS). Managing these assumptions and constraints is vital to ensure the project
remains realistic, functional, and adaptable throughout its development and future
evolution.

1.4. Project Planning

1.4.1. Project Timeline:

The Housing Society Management System (HSMS) follows a structured and
phased timeline to ensure systematic progression from ideation to deployment. The
timeline is divided into distinct phases covering research, planning, system design, core
development, testing, and final documentation. This plan ensures timely deliverables,
effective task management, and quality assurance throughout the lifecycle of the project.

Below is the detailed breakdown of the HSMS project timeline, with estimated start
and end dates along with major activities and deliverables.

13
Table 1. 1 Project Timeline

Phase Start Date End Date Key Activities and Deliverables

Initial team meeting
1. Project January 1, January 1, - Define project scope and goals
Initiation 2025 2025
- Assign initial team responsibilities
- Study problems in manual society
2. Research and
January 2, January management
Requirement
2025 15, 2025 - Define modules
Analysis
- Prepare feature list and SRS
- Share initial plan with supervisor
3. Stakeholder January 16, January
- Finalize major features and technical
Approval 2025 18, 2025
architecture
4. System - Design UI wireframes and
January 19, January
Design and admin/resident dashboards
2025 31, 2025
Prototyping - Create ERD and use case diagrams
- Build user registration and login system
5. Development February 1, February (JWT)
Phase 1 2025 28, 2025 - Setup MongoDB schema and basic
routing
- Perform unit tests on login, signup
6. Testing Phase March 1, March 5,
- Validate session handling and
1 2025 2025
dashboard access
- Implement resident complaint module
7. Development March 6, March 31,
- Develop admin complaint panel with
Phase 2 2025 2025
status management
- Bug fixing and validation
8. Testing Phase April 1, April 5,
- Review admin-resident communication
2 2025 2025
via complaints
9. Mid-Project April 7, April 7, - Supervisor feedback and timeline check
Evaluation 2025 2025 - Adjust future scope based on evaluation
10. - Add notice board module
April 8, April 22,
Development - Enable admin notice posting
2025 2025
Phase 3 - Implement real-time notice visibility
- Document verification system with
11.
April 23, May 7, uploads
Development
2025 2025 - Build document review interface for
Phase 4
admins

14
 12. Testing
May 8, May 14, - Integration testing of registration,
Phase 3
2025 2025 complaint, notice, and document modules
(Integration)
- Implement admin dashboard summary
13. Logs and
May 15, May 21, cards
Dashboard
2025 2025 - Add activity log tracking by user and
Phase
module
14. Final - Conduct user acceptance testing
June 22, June 27,
Testing and - Collect feedback from peers/test users
2025 2025
UAT - Final bug fixing
15. - Compile project documentation and
June 28, June 31,
Documentation reports
2025 2025
Finalization - Generate diagrams and code snippets
- Prepare presentation materials
16. Submission July 1, July 31,
- Conduct mock viva and supervisor
and Viva Prep 2025 2025
review
- Submit final report and project files
17. Project August 1, August 1,
- Post-launch monitoring and support to
Completion 2025 2025
resolve initial issues
- Continuous monitoring
- Bug fixing and performance
18. Post-Launch August 2, August 10,
improvements
Support 2025 2025
- Gathering user feedback for potential
updates

The timeline starts from March 1, 2024, and concludes on October 10, 2024. Each phase,
from research and design to development, testing, and launch, is carefully structured to
meet the deadline while ensuring a high-quality app. This timeline ensures that each phase
of the HSMS project is methodically planned, executed, and reviewed within the academic
semester's constraints. Buffer time is also included to accommodate supervisor feedback
and unforeseen challenges, ensuring that both the technical and academic requirements of
the project are met efficiently.

1.4.2. Resource Planning:

Effective resource planning is essential for the successful implementation of the
Housing Society Management System (HSMS). Resources have been identified across
key domains including human capital, technical infrastructure, and time-bound
deliverables. The primary objective of resource planning is to allocate team members, tools,

15
and technologies to ensure timely and quality-driven project completion within academic
constraints.

 Human Resources:

Human resources will be divided into front-end, back-end, and design, each
working collaboratively to meet project milestones. Additionally, cloud hosting services
will be utilized to manage data storage and ensure scalable performance. A budget will be
maintained to cover costs associated with software licensing, marketing, and maintenance
post-launch. This structured approach ensures that all necessary resources are available at
each stage of the project, minimizing delays and optimizing efficiency.

 Technical Resources:
o Front-End Framework: [Link]
o Styling: Tailwind CSS
o Back-End: [Link] + [Link]
o Database: MongoDB Atlas (NoSQL, cloud-hosted)
o Version Control: GitHub
o Development Tools: Visual Studio Code, Postman, Figma (for design)
o Authentication: JWT (JSON Web Tokens)
o Hosting: localhost
 Financial and Support Resources:
o Cloud Hosting: Free-tier services (MongoD)
o API Libraries: Open-source dependencies like Mongoose, [Link],
[Link]
o Documentation Tools: MS Word for reports, powerpoint for diagrams
o Testing Tools: Chrome DevTools (for unit testing)

Given that this is an academic project, all tools and platforms are selected based on
their zero-cost/free-tier availability to maintain budget neutrality while still ensuring
quality.

16
CHAPTER 2
BACKGROUND AND REQUIREMENTS:

2.1. Background Research

Residential housing societies have evolved rapidly in recent years, especially in
urban centers, where gated communities and multi-building complexes are now the norm.
These societies are home to hundreds or even thousands of residents, requiring structured
administrative systems to handle everyday operations such as resident onboarding,
complaint tracking, notice distribution, and security management. Traditionally, these tasks
have been handled using manual methods like physical registers, paper forms, and wall-
mounted notice boards. However, such practices are time-consuming, error-prone, and lack
transparency.

In many societies, complaints from residents are often logged manually or reported
verbally to guards or management staff. This informal process leads to delays in resolution,
lack of accountability, and poor tracking of issues. Similarly, notices about water
shutdowns, maintenance work, or society events are either pasted physically on boards or
sent via WhatsApp groups, which are neither reliable nor secure. In the absence of a
centralized system, communication between residents and society administrators remains
fragmented, and residents often feel disconnected from the decision-making process.

A significant gap also exists in terms of security and verification. In most residential
societies, new residents are manually entered into a register, and there is no digital process
to verify the authenticity of ID documents. This creates loopholes that can be exploited,
especially in large societies with multiple entry points and high footfall. Additionally, there
is often no proper record of visitor logs, emergency contacts, or administrative actions —
making it difficult to maintain accountability or perform audits.

Several digital society management platforms have emerged in recent years to

address these issues. Examples include MyGate, NoBrokerHood, and ApnaComplex,
which offer solutions ranging from digital visitor entry to maintenance billing. However,
these platforms often require paid subscriptions and focus heavily on mobile apps, limiting
accessibility for users who prefer web-based systems or operate from desktops.
Furthermore, most available systems do not offer role-based dashboards for different user
types (admin, resident, security staff) or flexible integration with future modules like utility
billing, facility booking, and emergency alerts.

17
 Trust and transparency are core challenges in any community management system.
Residents need assurance that their complaints are being taken seriously, their personal data
is secure, and administrative actions are traceable. Without digital logs or centralized
databases, it becomes difficult to prove whether a complaint was addressed, a notice was
ever posted, or a resident was actually verified. This creates friction and dissatisfaction,
especially in larger communities where personal interaction with management is limited.

As society management becomes more complex, there is a growing demand for

platforms that are secure, scalable, and easy to use. With the rise of cloud computing,
modern web frameworks, and real-time database technologies, it is now possible to build
efficient digital ecosystems even within the limitations of small residential societies. These
systems must prioritize accessibility (support across devices), transparency (logs,
dashboards), and modularity (ability to add features later).

The Housing Society Management System (HSMS) is built upon these identified
gaps and aims to solve real-world problems observed in manual and semi-digital society
operations. By providing a secure, web-based platform with centralized data management,
role-based dashboards, ID verification, and real-time complaint tracking, HSMS offers an
effective solution tailored for both small and mid-sized communities.

Moreover, HSMS integrates industry-standard security protocols such as token-

based authentication, role-based access control, and cloud data encryption to protect
sensitive resident data. In contrast to ad-hoc systems or expensive proprietary platforms,
HSMS is developed as a cost-effective, modular solution designed for academic
demonstration and real-world adaptation.

In summary, the background research reveals a clear need for a modernized,

accessible, and accountable society management platform. The limitations of traditional
systems such as poor transparency, insecure verification methods, and scattered
communication serve as the foundation upon which HSMS is built. By addressing these
challenges directly, the platform aims to improve operational efficiency, resident
satisfaction, and community safety through smart digitization.

2.2. Stakeholders
Stakeholders are individuals or groups who have a vested interest in the success,
development, and ongoing operation of the Housing Society Management System
(HSMS). These stakeholders either interact directly with the system or are impacted by its

18
implementation and usage. Identifying and understanding stakeholders is a critical part of
the project, as it ensures that the system meets the needs and expectations of all parties
involved.

Below is a detailed breakdown of the primary stakeholders in the HSMS project:

 Residents (End Users)

Role: Prime use of the System
Responsibilities & Interests
o Register and log in to the system using secure credentials
o Submit complaints and view their resolution status
o View society-wide notices posted by the administration
o Upload ID documents for verification
o Keep personal information updated through their profile
Impact: Residents are the main beneficiaries of the system, relying on it for
transparent communication, efficient complaint handling, and access to
timely information. Their satisfaction is essential for system adoption and
continued use.
 Society Administrator (Admin/Manager)
Role: System supervisor and operator
Responsibilities & Interest:
o Review and approve/reject resident registrations
o Verify uploaded ID documents
o Post notices and announcements
o Manage and resolve resident complaints
o Monitor system logs and user activities
Impact: The admin ensures the day-to-day functioning of the system. The
HSMS provides them with tools to efficiently manage society operations
from a centralized dashboard, saving time and improving record-keeping
accuracy.
 Project Team
Role: System designers, developers, and testers
Responsibilities & Interest:
o Design, develop, and test the HSMS based on user requirements
o Ensure functional and non-functional requirements are met

19
 o Deploy the system using suitable technologies ([Link], [Link],
MongoDB)
o Implement secure authentication and responsive user interfaces
Impact: The developer team is responsible for transforming stakeholder
needs into a working, user-friendly solution. Their technical decisions
impact system reliability, security, and performance.

In summary, the success of the Housing Society Management System depends on

the collective engagement and cooperation of these stakeholders. The system is designed
to cater to their unique needs, ensure usability, and foster a sense of community trust
through digital transparency and operational efficiency.

2.3. Functional Requirements

Functional requirements define the core operations, tasks, and interactions that
the system must be able to perform to fulfill user and stakeholder needs. These requirements
describe how the system behaves in response to user inputs, how data is managed, and how
different modules interact to deliver a seamless experience.

The Housing Society Management System (HSMS) includes several modules,

each designed with specific functionality that supports residents and administrators in
managing daily operations efficiently.

Below are the key functional requirements identified for the HSMS project:

1. User Registration and Authentication

 The system must allow new users (residents) to register by submitting personal
details and uploading a valid ID document.

 The system must support secure login functionality using email and password.

 Upon successful login, users should be redirected to dashboards based on their roles
(Admin or Resident).

 Passwords must be hashed before being stored in the database.

2. Resident Verification (Admin-Side)

 Admins must be able to review, approve, or reject registration requests.

 Admins must have access to uploaded ID documents to validate resident identities.

 Residents should receive status updates (Pending, Approved, Rejected) after admin
review.
20
3. Complaint Management

 Residents must be able to submit complaints via a complaint form.

 Complaints should be categorized (e.g., Water, Electricity, Security, Cleanliness).

 Admins must be able to view all complaints and update their statuses (e.g., Pending,
In Progress, Resolved).

 Residents must be able to track the status of their submitted complaints in real
time.

4. Notice Board Management

 Admins must be able to post announcements or notices.

 Notices should have a title, description, and timestamp.

 All residents should be able to view notices on their dashboards.

 Notices must be displayed in reverse chronological order.

5. Profile Management

 Residents should be able to view and update their personal details (excluding email
and ID).

 Admins must have access to view all resident profiles and make internal notes if
needed.

 Users should be able to upload or update their profile pictures.

6. Dashboard & Role-Based Navigation

 Upon logging in, residents should be taken to a resident dashboard containing their
complaints, notices, and profile.

 Admins should be directed to an admin dashboard containing resident management

tools, complaint handling, and notice posting options.

 Each user should only see the features relevant to their role.

7. Document Upload and Storage

 During registration, users must be required to upload scanned copies or photos of

valid ID documents (e.g., CNIC, driver’s license).

 Admins must have a secure interface to review these documents.

21
  The system must securely store and restrict unauthorized access to uploaded
documents.

8. Activity Logging and Audit Trail

 All major actions (registration, complaint submission, notice posting, ID approvals)

must be recorded with timestamps.

 Admins should be able to view logs to track user activity and system usage.

 Logs should be searchable and filterable by user or action type.

9. Secure Session Management

 The system must manage user sessions using JSON Web Tokens (JWT).

 Sessions should expire after a fixed duration of inactivity (e.g., 15 minutes).

 Unauthorized users should not be able to access protected routes or dashboards.

10. Logout Functionality

 Both residents and admins must be able to log out of the system securely.

 Upon logout, the token/session must be invalidated and the user redirected to the
login screen.

These functional requirements provide the foundation for designing and developing
each feature within the HSMS platform. They ensure that user expectations are clearly
defined and that the system is capable of supporting real-world operational needs in housing
society management.

Table 2.1 Functional Requirements

Requirement Functionality Description User System

ID Role Response

FR-01 User Allows new residents Resident Saves user data

Registration to register and upload to the database
ID for verification and marks status
as "Pending
Approval"

FR-02 Secure Login Authenticates user Resident, Grants access to

credentials (email and Admin role-specific
password)

22
 dashboard using
JWT token

FR-03 Profile View and edit personal Resident Displays

Management information and profile editable form
picture and updates
database on
submission

FR-04 Admin Provides admin access Admin Loads admin

Dashboard to resident, notice, and panel with
Access complaint management respective
management
tools

FR-05 Resident Provides residents Resident Displays

Dashboard access to notices, resident
Access complaints, and profile dashboard with
relevant
components

FR-06 Complaint Enables residents to Resident Stores

Submission submit categorized complaint with
complaints timestamp and
auto-sets status
to "Pending"

FR-07 Complaint View, update, and Admin Allows status

Management resolve resident updates to "In
complaints Progress" or
"Resolved" and
logs admin
action

FR-08 Complaint View current status of Resident Displays real-

Status submitted complaints time status (e.g.,
Tracking Pending, In

23
 Progress,
Resolved)

FR-09 Notice Posting Post Admin Saves notice in

announcements/alerts database and
to all users displays on
resident
dashboards

FR-10 Notice View posted notices by Resident Displays notices

Viewing title, body, and in descending
timestamp order (latest
first)

FR-11 Document Upload valid Resident Stores securely

Upload government-issued ID in cloud storage
during registration or database with
limited access

FR-12 Document Review uploaded ID Admin Displays

Verification documents document,
allows
approve/reject
action, and
updates resident
status

FR-13 Activity Log major actions System Saves log with

Logging (complaints, notices, user ID, action
registration) type, and
timestamp

FR-14 Secure Logout Log out and destroy Resident, Deletes JWT
active session Admin token from local
storage and
redirects to login

24
 FR-15 Session Auto-logout inactive System Invalidates JWT
Timeout users after a specified after inactivity
time period and
requires re-
authentication

2.3.1. Admin Login

The Admin Login functionality is a critical feature of the Housing Society
Management System (HSMS), allowing authenticated access to the administrative panel.
Through this panel, the admin can manage resident accounts, verify ID documents, respond
to complaints, and post notices. The system ensures that only authorized admins can access
the admin dashboard by verifying login credentials through a secure JWT-based
authentication mechanism.

Figure 2.1 Use Case Diagram Admin Login

25
Use Case Name: Admin Login

Use Case Element Details

Use Case ID UC-01

Use Case Name Admin Login

Primary Actor Admin

Goal in Context To allow the admin to securely log in and access the admin
dashboard

Preconditions Admin account must already exist in the system with valid
credentials

Postconditions Admin is authenticated and redirected to the admin

dashboard

Trigger Admin clicks on the "Login" button and submits

credentials

Main Success Scenario 1. Admin opens login page

2. Admin enters valid email and password
3. System verifies credentials
4. System generates JWT token
5. Admin is redirected to the admin dashboard

Extensions (Alternate - 2a. Admin enters invalid credentials → System displays

Flows) error message
- 3a. Server not reachable → Show "Try again later"
message

Frequency of Use Multiple times a day (typically once per admin session)

Security Requirements - Password must be hashed

- Token must be stored securely
- Session expires after inactivity

2.3.2. Resident Login

The Resident Login functionality is central to providing secure, role-specific
access to individual residents of the society. It enables registered and verified residents to

26
access their personal dashboards, file complaints, view notices, and manage their profiles.
Authentication is implemented via JWT-based token sessions, ensuring secure and
efficient access. If the resident’s registration is still pending or rejected, access is denied,
and a message is displayed accordingly.

Figure 2.2 Use Case Diagram Resident Login

Use Case Name: Resident Login

Use Case Element Details

Use Case ID UC-02

Use Case Name Resident Login

Primary Actor Resident

Goal in Context To allow residents to securely log in and access their role-
specific dashboard

Preconditions - Resident must have successfully registered

- Admin must have approved registration

27
 Postconditions Resident is authenticated and redirected to the resident
dashboard

Trigger Resident clicks on “Login” and submits valid credentials

Main Success Scenario 1. Resident accesses the login page

2. Enters email and password
3. System verifies credentials and registration status
4. JWT token is generated
5. Resident is redirected to the dashboard

Extensions (Alternate - 2a. Invalid credentials → error message shown

Flows) - 3a. Registration not approved → access denied message

Frequency of Use Typically, once per session

Security Requirements Password hashing, secure session token, session timeout

after inactivity

2.4. Non-Functional Requirements:

Non-functional requirements (NFRs) describe the quality standards and constraints
that the system must meet to ensure reliability, performance, security, scalability, and
user satisfaction. These characteristics determine how well the system performs its
functions rather than what it does.

Below are the key non-functional requirements for the HSMS project:

2.4.1 User Interface (UI)

 The system should have a clean, intuitive, and responsive interface to cater to
both technical and non-technical users.

 The UI must be device-agnostic, ensuring a consistent experience across desktops,

tablets, and mobile devices.

 Elements like buttons, forms, and dashboards must follow modern UI/UX
standards, with proper alignment, color contrast, and legible font sizes.

2.4.2 Fast Response Time

 The system should provide instant feedback on user actions such as login,
complaint submission, and profile updates.

28
  Page loads and database operations must complete within 3 seconds for typical use
cases on a standard internet connection.

 Real-time status updates (e.g., complaint status) should reflect changes without
needing to refresh the page.

2.4.3 Ease of Use

 Users should be able to complete core actions (e.g., filing a complaint or viewing
a notice) within three clicks.

 Navigation should be simple, with clear labels and logically grouped features.

 Error messages must be user-friendly, specifying what went wrong and how to
resolve it (e.g., “Invalid ID format” instead of “Error 400”).

2.4.4 Performance Requirements

 The system should support concurrent access by multiple users (e.g., 50 residents
and 5 admins simultaneously) without noticeable lag.

 Backend APIs must respond in under 500ms under normal load conditions.

 Image/document uploads should be processed efficiently and stored securely

without freezing the UI.

2.4.5 Safety Requirements

 Uploaded ID documents and personal resident data must be protected against
accidental loss, corruption, or unauthorized changes.

 The system should include backup procedures, ensuring critical data can be
recovered in the event of system failure or crash.

 Deletion of records must include confirmation prompts and logs to prevent

accidental loss of data.

2.4.6 Security Requirements

 All users must be authenticated via secure JWT-based login sessions.

 Sensitive data like passwords and documents must be encrypted at rest and in
transit.

 The system must implement role-based access control (RBAC) to prevent

unauthorized access to admin functionalities.

29
  Sessions must expire automatically after a defined period of inactivity (e.g., 15
minutes).

 All input fields should be validated to prevent SQL injection, XSS, and file upload
vulnerabilities.

2.4.7 Software Quality Attributes

 Maintainability: Code should follow modular design principles to allow easy
debugging and future updates.

 Scalability: The architecture must support future modules such as visitor

management, facility bookings, and SMS notifications.

 Portability: Since the system is browser-based, it should run on any modern web
browser without needing installation.

 Availability: The system should maintain 99% uptime during regular operational
hours.

 Reusability: Components like authentication, notifications, and logging can be

reused in future system expansions or similar applications.

30
CHAPTER 3
DESIGN

3.1. System Sequence Diagram for Admin:

The System Sequence Diagram (SSD) for Admin Login illustrates the interaction
between the Admin, the Login Interface, and the Authentication Controller during the
login process. It shows the sequence of messages exchanged to perform secure admin
authentication using email and password.

Figure 3.1 System Sequence Diagram for Admin Login

3.2. System Sequence Diagram for Resident:

The Resident Login system sequence diagram demonstrates the step-by-step
interaction between a resident and the system during the login process. This diagram helps

31
illustrate how the system handles user input, authentication logic, and secure session
generation to redirect the user to the appropriate dashboard.

Figure 3.2 System Sequence Diagram for Resident Login

3.3. Class Diagram:

A class diagram is a static structure diagram that represents the classes, attributes,
methods, and relationships among objects within the system. For the Housing Society
Management System (HSMS), the class diagram models the primary entities such as
Resident, Admin, Complaint, Notice, and Authentication—and illustrates how they interact
with each other in an object-oriented environment.

32
Figure 3.3 Class Diagram for HSMS

33
3.4. Entity Relationship Diagram:
The Entity Relationship Diagram (ERD) represents the logical structure of the
system's database. It outlines the key entities, their attributes, and the relationships
between them. The ERD provides a blueprint for how data will be stored, retrieved, and
connected within the Housing Society Management System (HSMS).

This diagram is essential for designing a scalable and normalized database

schema, which ensures data consistency and supports secure, efficient data operations.

Figure 3.3 Entity Relationship Diagram (ERD) for HSMS

34
CHAPTER 4:
IMPLEMENTATION
This chapter outlines the complete technical implementation process and the tools,
frameworks, and technologies used to develop the Housing Society Management System
(HSMS). It also describes the functional components developed, how quality assurance
was ensured through testing, and the deployment process.

4.1 Technology Stack:

The HSMS project is developed using modern web technologies that offer
scalability, security, and performance while maintaining ease of development and
maintainability. The following tools and frameworks were selected:

4.1.1 [Link] (Frontend)

[Link] is used for building the user interface of the system. Its component-based
architecture allows for reusability, responsiveness, and fast rendering of UI components,
ensuring a seamless user experience for both admins and residents.

4.1.2 [Link] and [Link] (Backend)

[Link] serves as the runtime environment for backend development, while
[Link] is used as the server framework. Together, they handle API routing,
authentication, data validation, and business logic.

4.1.3 MongoDB Atlas (Cloud Database)

MongoDB is used for storing system data such as resident profiles, complaints,
notices, and admin actions. Its NoSQL structure provides flexibility for data modeling and
supports fast querying. MongoDB Atlas is used for secure, cloud-based storage.

4.1.4 JWT Authentication & [Link]

Security is enforced through JWT (JSON Web Token) based authentication,
enabling role-based access control (Admin/Resident). Passwords are encrypted using
Bcrypt before being stored in the database.

4.1.5 Git & GitHub (Version Control)

Git is used for tracking code changes and managing version control. GitHub is used
for collaborative development and code backup, ensuring consistent integration and project
management among team members.

35
4.1.6 Cloud Deployment (Render/Netlify)
The frontend and backend are hosted using cloud deployment services such as
Netlify (for frontend) and Render or Cyclic (for backend APIs). These services offer auto-
deploy from GitHub, SSL, and scalability.

4.1.7 Postman (API Testing)

Postman is used to test backend APIs for all modules such as login, complaint
management, and notice posting. It ensures that routes work as expected and helps in
debugging during development.

4.1.8 Chrome DevTools & Lighthouse (Performance Monitoring)

Performance, accessibility, and responsiveness are validated using browser
development tools and Google Lighthouse, which helps identify performance bottlenecks
and UX issues.

4.2 Web Application Development:

The development of HSMS is broken down into modular components, each
corresponding to a key functional area of the platform.

4.2.1 Dashboard Customization

Role-based dashboards are created for Admins and Residents. The UI dynamically
adapts based on the logged-in user’s role, showing relevant features (e.g., complaint
management for residents vs. approval tools for admins).

4.2.2 Complaint Management Module

A core feature of the system, this module allows residents to submit complaints and
track status in real time. Admins can view, update, and resolve complaints with timestamps.

4.2.3 Resident Registration & Verification

New users register via a signup form and upload ID documents. Admins receive
notifications of new registrations and can approve or reject users after reviewing the
documents.

4.2.4 Notice Board Posting

Admins can create notices that are visible to all approved residents. Notices include
a title, description, and timestamp, and appear in descending order on the resident
dashboard.

36
4.2.5 Profile & Session Management
Residents can edit personal information (excluding email). Sessions are managed
via JWT tokens and include auto-timeout features for inactive users to enhance security.

4.3 Testing and Quality Assurance:

Comprehensive testing was conducted throughout development to ensure the
system meets functional, performance, and usability standards.

4.3.1 Functional Testing

Each core module (registration, login, complaint submission, notice creation) was
tested using unit tests and manual inputs. API endpoints were validated using Postman to
ensure correct data flow and error handling.

4.3.2 User Experience (UX) Testing

React components were tested for responsiveness and visual hierarchy. Sample
users (peers and supervisors) reviewed the dashboard to ensure that navigation, buttons,
and feedback messages were intuitive and clear.

4.3.3 Performance Testing

Page load speed and form submission times were measured using Google
Lighthouse and Chrome DevTools. The system maintained under 2-second average
response time during peak loads with mock users.

4.4 Deployment:
The frontend ([Link]) was deployed to Netlify, and the backend ([Link] +
Express) to Render. MongoDB Atlas provided a reliable cloud-hosted database. CI/CD
pipelines were established using GitHub integrations for auto-deployment on code push.

4.5 Admin Training and Handover:

A brief user manual and onboarding demo video were created to assist society
managers (admins) in using the system. The manual covers:

 Approving residents

 Posting notices

 Tracking complaints

This ensures smooth transition and minimizes the learning curve for end-users.

37
CHAPTER 5
TESTING

5.1. Testing Methods:

The reliability and success of the Housing Society Management System (HSMS)
depend on thorough testing during and after development. Software testing was conducted
at multiple levels to ensure that the system functions accurately, securely, and efficiently.
The objective was to validate that every module from complaint handling to user
authentication meets both functional and non-functional requirements.

The following testing methods were applied throughout the development cycle:

 Unit Testing: Individual functions such as form validation, user input handling, and
data submission were tested in isolation to verify correctness. Examples include
testing login form behavior and complaint submission logic.

 Integration Testing: After unit testing, the communication between frontend

components and backend APIs was validated. This included verifying complaint
updates, user approvals, and real-time dashboard updates across modules.

 System Testing: Complete end-to-end testing was performed across different flows
such as registering a resident, having them approved, submitting a complaint, and
viewing its resolution—to ensure proper flow and role-based access.

 User Acceptance Testing (UAT): Sample users (society residents and admin
personnel) were invited to interact with the system in real-time. Their feedback
helped confirm the system’s ease of use, reliability, and satisfaction with features.

 Performance Testing: The system was tested under simulated multi-user

conditions (50 concurrent users) to check its responsiveness and reliability under
load. MongoDB queries and API responses were monitored using Postman and
DevTools.

 Security Testing: Authentication mechanisms, document uploads, and access

control were tested to prevent unauthorized access. JWT tokens, password hashing
(via Bcrypt), and route-level security checks were validated.

 Regression Testing: Every time a new feature was added (e.g., notice posting),
previous modules were retested to ensure new additions didn’t break existing
functionality.

38
  Compatibility Testing: HSMS was tested on multiple devices and browsers
(Chrome, Edge, Firefox; Android and iOS devices) to ensure layout consistency,
usability, and responsiveness across platforms.

5.2. Validation Testing:

Validation testing ensures that the Housing Society Management System (HSMS)
fulfills its intended purpose and meets stakeholder expectations. It was critical in
confirming that the system operates in real-world conditions, beyond just development
environments.

5.2.1. Validation Testing Variation

Validation testing ensures that the Housing Society Management System (HSMS)
fulfills its intended purpose and meets stakeholder expectations. It was critical in
confirming that the system operates in real-world conditions, beyond just development
environments.

To achieve full validation coverage, various types of validation testing were

performed:

 Functional Validation: Verified that every module (registration, login, complaint

submission, notice posting) functions according to its design requirements and
provides the expected output.

 User Environment Validation: Simulated actual usage conditions (e.g., slow

internet, mobile access, different screen sizes) to ensure the system remains stable,
responsive, and error-free.

 Security Compliance Validation: Checked compliance with standard data

protection practices, such as encrypting user passwords and preventing
unauthorized dashboard access via secure tokens.

 User Experience (UX) Validation: Users from outside the development team were
asked to evaluate the interface. Their feedback helped enhance layout clarity, button
placement, and notification flow.

5.3. Functional Testing:

Functional testing was a core part of verifying the integrity and accuracy of the
HSMS modules. The goal was to ensure that each function individually and collectively
operated as described in the requirements.

39
The following core features were tested during functional validation:

 Resident registration and login

 Admin approval of resident accounts

 Complaint submission and status tracking

 Notice posting and dashboard visibility

 Profile management and session handling

 Secure document upload and retrieval

 Logout and token invalidation

5.4. Test Cases:

Below are structured test cases for each of the core modules in HSMS:

5.4.1 Test Case 1: Resident Registration

Field Value

Test Case ID HSMS_Func_01

Designed by Maham

Priority High

Module Name Resident Registration

Test Title Verify resident registration functionality

Description Ensure residents can register and upload ID

Designed Date 2025-06-10

Execution Date 2025-07-01

Executed by Eman

Expected Result Account created and pending admin approval

Actual Result Passed

5.4.2 Test Case 2: Admin Login

Field Value

Test Case ID HSMS_Func_02

40
 Designed by Maham

Priority High

Module Name Admin Authentication

Test Title Verify secure admin login

Description Admin logs in with credentials

Designed Date 2025-06-10

Execution Date 2025-07-01

Executed by Eman

Expected Result Admin is redirected to dashboard

Actual Result Passed

5.4.3 Test Case 3: Complaint Submission

Field Value

Test Case ID HSMS_Func_03

Designed by Maham

Priority High

Module Name Complaint Handling

Test Title Verify resident complaint submission

Description Submit and categorize complaint

Designed Date 2025-06-15

Execution Date 2025-07-01

Executed by Eman

Expected Result Complaint submitted and logged in database

Actual Result Passed

41
5.4.4 Test Case 4: Notice Posting
Field Value

Test Case ID HSMS_Func_04

Designed by Maham

Priority Medium

Module Name Notice Management

Test Title Verify notice creation

Description Admin creates and posts a new notice

Designed Date 2025-06-18

Execution Date 2025-07-01

Executed by Eman

Expected Result Notice is visible on resident dashboard

Actual Result Passed

5.4.5 Test Case 5: Profile Update

Field Value

Test Case ID HSMS_Func_05

Designed by Maham

Priority Medium

Module Name Profile Management

Test Title Verify profile update

Description User updates phone number and address

Designed Date 2025-06-20

Execution Date 2025-07-01

Executed by Eman

Expected Result Changes saved and reflected immediately

Actual Result Passed

42
5.4.6 Test Case 6: Logout

Field Value

Test Case ID HSMS_Func_06

Designed by Maham

Priority Medium

Module Name Session Management

Test Title Verify secure logout

Description Session is cleared and user is logged out

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result User is redirected to login screen

Actual Result Passed

5.4.7 Test Case 7: Complaint Management (Admin Side)

Field Value

Test Case ID HSMS_Func_07

Designed by Maham

Priority High

Module Name Complaint Management

Test Title Verify admin complaint update

Description Admin updates status of a submitted complaint

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result Complaint status is updated (e.g., In Progress)

Actual Result Passed

43
5.4.8 Test Case 8: Complaint Status Tracking (Resident Side)
Field Value

Test Case ID HSMS_Func_08

Designed by Maham

Priority Medium

Module Name Complaint Tracking

Test Title Verify real-time complaint status tracking

Description Resident checks updated status of complaint

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result Complaint status reflects admin update

Actual Result Passed

5.4.9 Test Case 9: Notice Viewing (Resident Side)

Field Value

Test Case ID HSMS_Func_09

Designed by Maham

Priority Medium

Module Name Notice Viewing

Test Title Verify that residents can view posted notices

Description Resident sees new notices in dashboard

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result All recent notices are displayed correctly

Actual Result Passed

44
5.4.10 Test Case 10: Document Upload (During Registration)
Field Value

Test Case ID HSMS_Func_10

Designed by Maham

Priority High

Module Name Document Upload

Test Title Verify ID upload during registration

Description Resident uploads government ID during sign-up

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result File is stored securely and linked to user

Actual Result Passed

5.4.11 Test Case 11: Document Verification (Admin Side)

Field Value

Test Case ID HSMS_Func_11

Designed by Maham

Priority High

Module Name Document Verification

Test Title Verify admin document review and approval

Description Admin reviews uploaded ID and changes status

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Eman

Expected Result Document visible to admin, status is changeable

Actual Result Passed

45
5.4.12 Test Case 12: Activity Logging
Field Value

Test Case ID HSMS_Func_12

Designed by Eman

Priority Medium

Module Name System Activity Logs

Test Title Verify backend logs of user actions

Description Actions like complaint submission are logged

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Maham

Expected Result User actions are recorded with timestamps

Actual Result Passed

5.4.13 Test Case 13: Admin Dashboard Access

Field Value

Test Case ID HSMS_Func_13

Designed by Eman

Priority High

Module Name Admin Dashboard

Test Title Verify admin dashboard is role-restricted

Description Only admins can access admin panel

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Maham

Expected Result Role-based access is enforced

Actual Result Passed

46
5.4.14 Test Case 14: Resident Dashboard Access
Field Value

Test Case ID HSMS_Func_14

Designed by Eman

Priority High

Module Name Resident Dashboard

Test Title Verify resident dashboard role enforcement

Description Only approved residents see complaint tools

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Maham

Expected Result Residents see only resident-level tools

Actual Result Passed

5.4.15 Test Case 15: Session Timeout

Field Value

Test Case ID HSMS_Func_15

Designed by Eman

Priority Medium

Module Name Session Management

Test Title Verify auto logout after inactivity

Description System logs out inactive user after 15 mins

Designed Date 2025-06-25

Execution Date 2025-07-01

Executed by Maham

Expected Result Session is cleared after timeout

Actual Result Passed

47
CHAPTER 6
CONCLUSION AND FUTURE WORK

6.1. Conclusion:
The development and testing of the Housing Society Management System
(HSMS) represent a significant achievement in streamlining and digitizing residential
community operations. From the initial concept to implementation and testing, the project
has followed a user-centric design approach with strong emphasis on modularity, security,
and ease of use. Each system feature from resident registration and complaint management
to notice posting and document verification was thoroughly designed and validated to meet
real-world functional needs.

The platform provides an intuitive interface for residents and administrators,

enabling smooth communication and issue resolution within a secure environment.
Through rigorous testing including functional, integration, and user acceptance testing the
system has demonstrated reliability and robustness across devices and user roles. With
dedicated dashboards, role-based access control, and real-time data updates, HSMS
successfully enhances administrative transparency and resident engagement.

The system's deployment marks a shift from manual processes to an organized

digital solution that promotes accountability, record-keeping, and operational efficiency in
housing societies.

7.2. Future Work:

To ensure long-term impact and scalability, several enhancements and new features
can be explored in future versions of HSMS:

 Mobile App Development: While the current system is web-responsive, a native

mobile app for Android and iOS can improve accessibility and push notification
capabilities for real-time complaint or notice alerts.

 Payment Integration: Adding secure payment gateways for managing society

maintenance fees, event dues, or utility charges can extend the platform’s utility.

 Visitor Management Module: Introducing a module to record and approve visitor

entries can improve overall security and access control within the housing premises.

48
  AI-based Complaint Prioritization: Leveraging AI to categorize and prioritize
complaints based on urgency and historical data could help administrators resolve
issues more efficiently.

 Data Analytics Dashboard: Equipping admins with visual dashboards for insights
like complaint trends, resident activity, and document verification status could drive
data-informed decisions.

 Multi-language Support: Implementing localization features for languages like

Urdu, Punjabi, or Sindhi can make the platform more inclusive and accessible to
diverse residential communities.

 Green Initiatives Tracker: Future versions may include features to monitor and
promote sustainable practices like recycling programs, energy-saving events, and
eco-friendly vendor listings.

7.3. Reflections on the Project:

Developing the Housing Society Management System (HSMS) has been an
enriching experience for the team, offering valuable lessons in requirement gathering,
modular design, stakeholder communication, and agile development. One of the key
insights was the importance of involving potential users such as residents and society
admins—during prototyping and testing. Their feedback helped shape core features like
complaint tracking, notice visibility, and the streamlined registration workflow.

The project also emphasized the necessity of balancing functionality with

simplicity, especially when designing tools for non-technical users. As such, intuitive
navigation, user feedback (toast messages, error prompts), and role-specific interfaces
became a design priority.

In conclusion, the HSMS is not just a digital solution, but a foundation for building
smarter, more connected residential communities. With room to grow and evolve, it is well-
equipped to adapt to future needs and play a meaningful role in transforming housing
society management across regions.

49