PROJECT REPORT

ON

CAMPUS LOST AND FOUND WEB PORTAL

SUBMITTED IN PARTIAL FULFILLMENT FOR AWARD OF
DEGREE
IN

BACHELOR OF COMPUTER APPLICATION

(BATCH 2023-2026)

AMBIKA SINGH
2341041010
SINOLIN BEHERA
2341041087
PRIYANKA PATTNAIK
2341041046
N.S KRINJALIKA SAHOO
2341041037
AMANDEEP MOHANTY
2341041080.

UNDER THE ESTEEMED GUIDANCE OF

MR. ALOK KUMAR PATI

Assistant Professor

Department of Computer Application

Institute of Technical Education and Research
2026

i
 DECLARATION

We hereby declare that the Project entitled “Campus Lost and Found Web Portal”
submitted to the Departmentof Computer Application, Institute of Technical Education&
Research, Siksha O Anusandhan Deemed to be University, Bhubaneswar, Odisha in
partial fulfillment for theaward of the degree of Bachelor of Computer Application in the
year 2025 is an authentic record of our own work carried out under the guidance of Mr. Alok
Kumar Pati and thatthe project has not been previously formed the basis for the award of
any other degree. The report has been prepared in compliance to the guidelines specified by
the University.

Signature: _______________ Signature: _______________

Ambika Singh Sinolin Behera
Regd. No.: 2341041010 Regd. No.: 2341041087

Signature: _______________ Signature: _______________

Priyanka Pattnaik N.S Krinjalika Sahoo
Regd. No.: 2341041046 Regd. No.: 2341041037

Signature: _______________
Amandeep Mohanty
Regd. No.: 2341041080

Place: Bhubaneswar
Date: _______________

This is to certify that the above statement made by the candidates is correct to the best of my
knowledge.

_____________________________________
Mr. Alok Kumar Pati
Assistant Professor, Department of Computer Application
ITER, Siksha O Anusandhan Deemed to be University, Bhubaneswar

ii
 ACKNOWLEDGEMENT

We are very grateful to our project guide Mr. Alok Kumar Pati for giving his/her
valuable time and constructive guidance in preparing the Project. It would nothave
been possible to complete this project in short period of time without his/her kind
encouragement and valuable guidance.

Signature: _______________ Signature: _______________

Ambika Singh Sinolin Behera
Regd. No.: 2341041010 Regd. No.: 2341041087

Signature: _______________ Signature: _______________

Priyanka Pattnaik N.S Krinjalika Sahoo
Regd. No.: 2341041046 Regd. No.: 2341041037

Signature: _______________
Amandeep Mohanty
Regd. No.: 2341041080

Place: Bhubaneswar
Date: _______________

iii
 CERTIFICATE

This is to certify that the project entitled “Campus Lost and Found Web Portal” submitted
in partial fulfillment of the requirements for the award of the degree of Bachelor of Computer
Application to the Department of Computer Application, Institute of Technical Education and
Research (ITER), Siksha ‘O’ Anusandhan Deemed to be University, Bhubaneswar, Odisha,
carried out by Ambika Singh (Reg. No.- 2341041010), Sinolin Behera (Reg. No.-
2341041087), Priyanka Pattnaik (Reg. No.- 2341041046), N.S Krinjalika Sahoo (Reg. No.-
2341041037), and Amandeep Mohanty (Reg. No.- 2341041080) is an authentic work
completed under proper guidance and supervision and is worthy of acceptance for the award of
the degree. The work fulfills the entire requirement as per the regulations of the University and
has reached the standard necessary for submission.

GUIDE HOD
Mr. Alok Kumar Pati Prof. (Dr.) Kaberi Das
Assistant Professor Head of Department
Department of Computer Application Department of Computer Application
Institute of Technical Education & Research Institute of Technical Education & Research

Department of Computer Application Institute

of Technical Education and Research
2026

iv
 SYNOPSIS

Particulars Details
Project Title Campus Lost and Found Web Portal
Technology Stack HTML5, CSS3, JavaScript, PHP 8.x, MySQL 8.x
Development Tool Visual Studio Code, XAMPP (Apache + MySQL)
Guided By Mr. Alok Kumar Pati, Assistant Professor, ITER
Academic Session 2025 - 2026 (6th Semester BCA)
Institute of Technical Education and Research (ITER), Siksha O
Institution
Anusandhan Deemed to be University

Overview
The Campus Lost and Found Web Portal is an online system created to improve the way lost
and found items are handled inside a college campus. In many educational institutions, missing
items are usually managed through notice boards, verbal communication, or WhatsApp
messages. These methods are often slow, unorganized, and unable to inform the right people on
time. Because of this, many lost belongings are never recovered even when there is a chance to
return them.

The project offers a single online platform where students and staff members can report lost or
found items in a proper and organized way. Users can browse available listings, search for
specific belongings, and contact the concerned person to help return the item. The portal is
designed using a LAMP-based web structure, where PHP manages backend operations and user
login functions, MySQL is used to store all data records, and the frontend is developed with
HTML, CSS, and JavaScript to provide a simple and responsive interface

Problem Being Solved

This project mainly focuses on solving the problem of not having a proper online system to
manage lost and found items on campus. The existing methods are not reliable because people
cannot quickly search for missing items, there is no proper way to verify claims, and past
records are not stored in an organized [Link] methods also depend mainly on people
noticing announcements on their own instead of receiving direct updates. To overcome these
problems, the project provides a dedicated web portal designed specifically to make the lost and

v
found process faster, organized, and more reliable.

Key Features
• Secure user registration and login with PHP session management

• Lost item report form with category, description, date, and location fields

• Found item report form with similar structured data capture

• A searchable All Posts page displaying all active listings in real time

• Admin panel for managing, reviewing, and deleting posts

• Responsive interface compatible with desktop and mobile browsers

• MySQL database with properly normalized tables for persistent data storage

Significance
The portal is helpful because it solves a common problem faced by students and staff members
on campus in their daily life. Many people lose their belongings, but there is usually no proper
system to report or find them easily. This project provides a simple and organized solution for
that problem. The system is also affordable to develop because it uses free and open-source
technologies. The technologies used in this project are widely used, dependable, and simple to
manage. The system can also be improved later by adding features such as photo uploading,
email updates, and smart matching of lost and found items.

vi
 CONTRIBUTION OF INDIVIDUAL TEAM MEMBERS

The following table provides a detailed breakdown of the contributions made by each team
member during the design, development, testing, and documentation phases of the Campus Lost
and Found Web Portal project.

[Link] Name Reg. No. Detailed Contribution

1 Ambika Singh 2341041010 Project lead and coordinator. Planned the project
timeline and assigned tasks. Designed and developed
the Home Page layout and navigation structure.
Implemented the user authentication module including
registration, login, and logout using PHP sessions.
Coordinated team meetings and ensured milestones
were met on time. Also contributed to the synopsis and
declaration sections of the report.

2 Sinolin Behera 2341041087 Designed and developed the Lost Item Report page -
both the frontend form and the PHP backend logic for
data submission. Created the MySQL database schema
for the lost_items table. Wrote and tested the SQL
queries for inserting, retrieving, and filtering lost item
records. Contributed to Chapter 3 (System Analysis and
Design) of the project report.

3 Priyanka Pattnaik 2341041046 Designed and developed the Found Item Report page
and the All Posts page. Implemented the search and
keyword-filter functionality using JavaScript. Wrote
the PHP logic for querying and displaying all active
records. Designed the card-based post layout on the All
Posts page. Contributed to Chapter 5 (Results and
Discussions) of the report.

4 N.S Krinjalika 2341041037 Led the UI/UX design work using CSS. Created a
Sahoo consistent visual design language across all pages
including color scheme, typography, button styles, and
layout grids. Ensured cross-browser compatibility.
Prepared the List of Figures and List of Tables. Led the
testing phase and prepared the unit and integration test
case tables in Chapter 4.

5 Amandeep 2341041080 Prepared the full project report documentation.

Mohanty Conducted the literature survey and wrote Chapter 2
(Literature Survey). Wrote Chapters 6 and 7 (Socio-
Economic Issues and Conclusion). Compiled
references and formatted the report as per university
guidelines. Also assisted in debugging PHP and
MySQL integration issues during development.

All five team members participated in the final testing phase, contributed feedback on the user
interface design, and reviewed the project report before submission.

vii
 LIST OF FIGURES

Fig. No. Figure Title Page

1.1 System Architecture / Block Diagram 4
2.1 Comparison of Existing System and Proposed System 12
3.1 Entity-Relationship (ER) Diagram: Campus Lost and Found Portal 19
3.2 Use Case Diagram: Registered User and Administrator 21
3.3 Data Flow Diagram (Level 0 / Context Diagram) 21
3.4 Flowchart of System Process 22
5.1 Home Page: User Interface Screenshot 30
5.2 Registration Page: New User Signup 31
5.3 Login Page: User Authentication 32
5.4 Lost Item Report Page 32
5.5 Found Item Report Page 33
5.6 All Lost and Found Posts Page 34

viii
 TABLE OF CONTENTS

Cover page i
Declaration ii
Acknowledgement iii
Certificate iv
Synopsis v
Contribution of Individual Team Members Vii
List of Figures Viii
Table of contents x

1. INTRODUCTION 1
1.1 Preface 1
1.2 Problem Definition and Objective(s) 1
1.3 Motivations(s) 2
3
1.4 Project Overview / Specifications
4
1.5 Hardware Specification 6
1.6 Software Specification 7
1.7 Organization/Arrangement of the Report 7

2. LITERATURE SURVEY 9
2.1 Preface 9
2.2 Existing System 9
2.3 Proposed System 11
2.4 Feasibility Study 13

3. SYSTEM ANALYSIS & DESIGN 15

3.1 Preface 15
3.2 Requirement Specification 15
3.2.1 Functional Requirements 15
3.2.2 Non-functional Requirements 17
3.3 Flowcharts / UML Diagrams / ER Diagrams 18
3.4 Design Steps / Criteria 23
3.5 Algorithms and Pseudo Code 24

4. TESTING PROCESS 26
4.1 Unit Testing 26
4.2 Integration Testing 27

5. RESULTS AND DISCUSSIONS 30

5.1 Preface 30
5.2 User Interface 30
5.3 Databases 30
5.4 Results and Outputs 34

6. SOCIO ECONOMIC ISSUES 37

ix
 6.1 Practical Relevance 37
6.2 Global Impact 37
6.3 Lifelong Learning 38

7. CONCLUSION AND FUTURE SCOPE 40

7.1 Conclusion 40
7.2 Future Scope 41

References / Bibliography Appendices 44

Similarity Report 48 - 53

x
 CHAPTER 1: INTRODUCTION

1.1 Preface
Nowadays, almost every work is connected with technology in some way. Colleges and universities are
also using online systems for many activities because they help in reducing manual work and make
things easier for students and staff. Services like online attendance, fee payment, result checking, and
library management have already become common in many institutions.

But one common campus problem is still mostly ignored - lost and found management. Students
regularly lose items such as ID cards, wallets, earphones, notebooks, chargers, bags, and sometimes even
mobile phones. When this happens, there is usually no proper place to report it. Most students either ask
their friends, post messages in WhatsApp groups, or check notice boards. These methods are not reliable
because the information often does not reach the right person. In many cases, the lost item is never
returned even if someone has found it.

The same problem happens from the other side too. If a student finds an item somewhere on campus,
there is no simple system to upload the details or contact the actual owner. Because of this, many found
items remain unclaimed.

To deal with this issue, the Campus Lost and Found Web Portal was developed. The portal works as a
common online platform where students and staff can post details about lost or found items. Users can
also search through the available posts and contact the concerned person if they find matching
information. Since the system is web-based, it can be used from a mobile phone, laptop, or any device
with internet access.

This chapter explains the basic idea behind the project. It describes the problem faced on campus, the
purpose of creating the system, and the main goals of the project. It also gives a short overview of the
report and the topics covered in the next chapters.

1.2 Problem Definition and Objectives

The main problem solved by this project is the lack of a proper and centralized system for managing lost
and found items inside the campus. At ITER campus, and in many other colleges across India, there is
no organized method to report, track, or recover missing belongings. After studying the current situation
on campus, several common problems and difficulties were identified:

1
Identified Problems:
• There is no proper platform, either online or offline, where students can officially report lost
items and keep the information stored safely for future use.
• Notice boards are the most commonly used method, but they become messy and outdated very
quickly. They also cannot be searched or updated easily from different locations.
• Depending on friends or verbal communication is not reliable because the information often
does not reach the correct person, especially in a large campus environment.
• There is no proper way to check whether a lost item has been found or whether a found item has
already been collected by its owner.
• Since there is no verification process, anyone can wrongly claim an item shown on a notice
board, which may lead to misuse or false ownership claims.
• No old records are maintained, so after some time it becomes difficult to search for previously
reported items.
• The whole process is time-consuming, unorganized, and mostly depends on students being
physically present at a particular place, which is not practical on a large campus.

Objectives of the System:

1. To create a web-based system where registered students and staff can submit proper
reports for lost and found items along with complete details.
2. To build a secure login and authentication system using PHP sessions so that only
authorized campus users can use the portal.
3. To provide a live and searchable list of all active posts so users can easily check whether
their lost item has been reported.
4. To store all lost and found records in a structured database with details such as category,
date, time, and item status for future reference.
5. To develop a simple and user-friendly interface that works properly on both computers
and mobile devices without needing technical knowledge.
6. To make the system easy to deploy on normal web hosting platforms without requiring
expensive infrastructure or advanced setup.
7. To keep the system ready for future improvements like image uploading, email alerts,
and smart matching features using AI technology.

1.3 Motivations
The idea for this project came from situations faced by students on our own campus. During our BCA
course, many team members and classmates either lost personal items or found belongings that they

2
could not return because there was no proper system available. These incidents made us realize that the
campus needed a better and more organized solution. Since we had already learned web development
skills during our course, we decided to build a system that could solve this problem in a practical way.

Another reason behind choosing this project was the learning experience it offered. Developing a
complete web application gave us the opportunity to apply different concepts studied during the BCA
programme in one project. From collecting requirements and designing the database to frontend
development, backend coding, and testing, the project helped us use knowledge from subjects like web
technology, database management, software engineering, and system design.

We were also motivated after studying similar systems available online and in research materials. Some
universities outside India already use lost and found portals, and a few open-source projects are also
available. However, many of them are either too complicated, difficult to manage for small campuses,
or not suitable for Indian college environments. This encouraged us to create a simpler and more
practical system that could match local campus requirements.
Another important reason for developing this project was its usefulness in real campus life. If
implemented properly, the system can help a large number of students and staff members by making the
lost and found process easier and more organized. Unlike many academic projects that remain limited
to documentation, this project has the potential to be used directly on campus and provide immediate
benefits.

1.4 Project Overview / Specifications

The Campus Lost and Found Web Portal is a dynamic web application made with a LAMP-based
technology stack. The system follows a client-server architecture where the frontend, developed using
HTML, CSS, and JavaScript, manages the user interface and user interactions. The backend is developed
using PHP, which handles the main system functions and connects with the MySQL database to save,
manage, and retrieve data records.

3
The system consists of the following core modules:

Module 1: User Authentication

This module is used for user registration and login in the system. New users can create an account by
entering their name, email ID, and password in the registration form. The password is not stored directly
in the database. It is converted into a secure encrypted form using PHP password_hash() function before
saving. This helps in protecting user account details and improves security.

For login, users enter their registered email and password. The system checks the entered details with
the database records. PHP password_verify() function is used to compare the entered password with the
encrypted password stored in the database. If both match correctly, the user is allowed to access the
system.

After successful login, session variables are created using PHP sessions. These session variables help
the system remember the logged-in user while moving between different pages of the portal. Without
login, users cannot access protected pages or perform actions like posting lost or found item details.

The module also performs basic validation checks during registration and login. If any required field is
empty or if wrong login details are entered, the system shows an error message. This module helps in
keeping the portal secure and allows only registered campus users to use the system properly.

Module 2: Lost Item Reporting

This module allows logged-in users to report items that they have lost on campus. Users can fill out a
form by entering details such as the item name, category, description, date when the item was last seen,
and the location where it was lost. Different categories are provided in the form like Electronics,
Accessories, Books, Stationery, Clothing, Identity Documents, and Others so that records can be
managed in a proper way.

The description field helps users provide extra details about the lost item, such as color, brand name,
size, or any special identification mark. This makes it easier for other users to identify the item correctly.

Before saving the information in the database, the system checks all entered details properly. Validation
is performed on the client side using JavaScript to reduce incorrect or empty inputs before submission.
Additional validation is also done on the server side using PHP for better security and data accuracy.
After successful validation, the item details are stored in the lost_items table of the MySQL database.

4
This module helps in creating a proper digital record of lost items and makes the searching and recovery
process more organized and efficient.

Module 3: Found Item Reporting

This module works similar to the lost item reporting module, but it is mainly used by users who have
found an item on campus. Through this form, users can submit details about the item they discovered so
that the actual owner can identify and recover it easily.

The form collects important information such as item name, category, detailed description, date when
the item was found, and the location where it was discovered. Categories like Electronics, Accessories,
Books, Clothing, Identity Documents, and Others are provided to keep the records organized.

Users can also add extra details in the description field, such as the color, brand, size, or any special
mark related to the item. This helps in identifying the item correctly and reduces false claims.

After submission, all entered details are checked through validation processes to ensure proper and
accurate data entry. Once validated, the information is stored in the found_items table in the MySQL
database. The system also stores the user ID of the person who reported the found item so that proper
communication and tracking can be maintained if needed.

This module makes the process of reporting found items more systematic and increases the chances of
returning lost belongings to their rightful owners.

Module 4: All Posts Page

This module acts as the main viewing page of the portal where users can browse all lost and found item
posts in one place. The page fetches active records from both the lost_items and found_items tables and
displays them in a clean card-style format for easy viewing.

Each card contains important details about the item such as item name, category, description, date, and
location. This helps users quickly check whether any listed item matches their lost belonging or a found
item they are searching for.

A search bar is also provided at the top of the page to make searching faster and easier. Users can enter
keywords related to the item name, category, or description, and the matching cards are filtered instantly
using JavaScript without reloading the page.

The layout of the page is designed in a simple and user-friendly way so that users can view all current
listings at a glance. The responsive design also allows the page to work properly on both desktop and

5
mobile devices. This module improves accessibility and helps users find relevant information quickly
and efficiently.

Module 5: Admin Panel

The admin panel is a special section of the portal that can be accessed only by authorized administrators.
This module helps in managing the overall system and monitoring all activities related to lost and found
item reports.

Inside the admin panel, the administrator can view all submitted posts from both lost and found sections.
The admin has the authority to remove posts that are already resolved, duplicated, incorrect, or found to
be invalid. This helps in preventing unnecessary or outdated records from remaining visible on the portal.
The module also allows the admin to view details of registered users stored in the system. This helps in
maintaining proper records and monitoring user activity when required.

By regularly managing and updating the records, the admin panel helps keep the database organized,
accurate, and relevant. It also improves the reliability of the portal and ensures that users can access
updated and trustworthy information.

1.5 Hardware Specifications

The following hardware configuration was used during the development and testing of the system:

Hardware Component Specification / Requirement

Processor Intel Core i3 7th Generation or above (Minimum: 1 GHz dual-

core processor)

Primary Memory (RAM) 4 GB DDR4 RAM (Recommended: 8 GB for smooth

development performance)

Secondary Storage 500 MB free disk space for project files, database, and server
configuration

Display / Monitor 1024 × 768 resolution (Recommended: 1920 × 1080 Full HD)

Network Adapter LAN or Wi-Fi (for accessing the portal on localhost or a local
network)

Input Devices Standard 104-key keyboard and optical mouse

Browser Support Google Chrome 100+, Mozilla Firefox 95+, Microsoft Edge 96+

6
 Table 1.1: Hardware Specifications

1.6 Software Specifications

The following software tools and technologies were used for the development of the portal:

Software / Technology Version / Details

Operating System Windows 10 / Windows 11 (64-bit)

Web Server Apache 2.4 (via XAMPP 8.x)

Server-Side Language PHP 8.1.x

Database Management System MySQL 8.0.x

Frontend: Markup Language HTML5

Frontend: Styling CSS3 (with custom responsive layout)

Frontend: Scripting JavaScript (ES6+)

Development IDE Visual Studio Code (v1.85+)

Browser for Testing Google Chrome (with DevTools for debugging)

Database GUI Tool phpMyAdmin (bundled with XAMPP)

Version Control Git (optional; used for local version tracking)

Table 1.2: Software Specifications

1.7 Organization / Arrangement of the Report

The remainder of this project report is structured as follows to provide a comprehensive account of the
Campus Lost and Found Web Portal:

• Chapter 2 - Literature Survey: This chapter explains the study of existing systems and
related research work. It discusses the problems present in current methods and explains
how the proposed system provides a better solution. It also includes feasibility studies
based on technical, economic, and operational aspects of the project.
• Chapter 3 - System Analysis and Design: This chapter describes the complete design
and structure of the system. It includes functional and non-functional requirements, ER

7
 diagrams, use case diagrams, data flow diagrams, activity diagrams, class diagrams,
sequence diagrams, design details, and the main algorithms used in the project.
• Chapter 4 - Testing Process: This chapter explains the testing methods used during
development. It contains unit testing for individual modules and integration testing to
check the overall system flow and functionality.
• Chapter 5 - Results and Discussions: This chapter presents the final output of the
project. It explains different user interface pages, database structure, and the behavior
of the system during testing. It also includes discussion of the results obtained after
implementation.
• Chapter 6 - Socio-Economic Issues: This chapter discusses the practical value and
importance of the project. It explains how the system can help students and staff on
campus and how it can be useful on a larger scale in the future. It also describes the
learning experience gained by the team during the project development process.
• Chapter 7 - Conclusion and Future Scope: This chapter gives the final summary of the
project and highlights the main achievements. It also explains possible future
improvements and additional features that can be added to make the system more
advanced and useful.
• References / Bibliography: This section contains the list of books, research papers,
websites, documentation, and other materials referred to during the development of the
project.

8
 CHAPTER 2: LITERATURE SURVEY

2.1 Preface
A literature survey is an important part of software project development because it helps in
understanding already existing systems related to the project topic. It also helps in finding the problems
and limitations in those systems so that a better solution can be developed. Before starting the
development of the Campus Lost and Found Web Portal, different related systems, research materials,
and technical resources were studied carefully.

The survey included three main areas. First, different web-based lost and found systems available on
open-source platforms and project websites were reviewed. Second, academic papers and research
articles related to campus management systems and item tracking solutions were studied. Third,
documentation and learning resources for the technologies used in this project, such as PHP, MySQL,
CSS, and JavaScript, were referred to during development.

Several online resources and platforms were used during this study, including [Link],
GeeksforGeeks, Code Projects, Devpost, MDN Web Docs, and Bootstrap Documentation.

The information collected from the survey helped in making important design decisions for the project.
It was especially useful while planning the database structure, designing the user authentication system,
and creating the user interface layout. This chapter explains the observations from the survey, discusses
the drawbacks of existing systems, introduces the proposed system as a better solution, and also includes
the feasibility analysis of the project.

2.2 Existing Systems

Several systems and approaches related to lost and found management were reviewed during the survey.
Each is described below with an evaluation of its strengths and limitations.

2.2.1 Physical Notice Board System

The physical notice board is by far the most commonly used method for lost and found management in
Indian college campuses. It involves students or security staff writing hand-written or printed notices
and pinning them on a shared board in a central location - typically near the college entrance, library, or
canteen.

Strengths: Simple to use, requires no technology, universally understood.

9
Limitations: Not searchable or filterable. Notices become outdated quickly and must be manually
removed. The board is only accessible to those who physically visit the location. It relies entirely on
chance - the right person must happen to read the right notice. There is no way to confirm whether an
item has been claimed. Records are not maintained after notices are removed. In rainy or humid
conditions, physical notices may become damaged or illegible.

2.2.2 Social Media and Messaging Groups (WhatsApp / Facebook)

Many campuses have moved to using social media platforms - particularly WhatsApp groups or college
Facebook pages - for lost and found announcements. These offer better reach than notice boards, as
messages can be sent instantly to all members of a group.

Strengths: Wide reach within the campus community, fast communication, images can be shared.
Limitations: Messages get buried quickly as more conversation is added, making older posts difficult
to find. There is no structured format for submissions - different students describe items differently,
making it hard to search or compare. No database is maintained. Membership in these groups is not
verified, creating privacy and security concerns. There is no admin oversight mechanism. The platform
is not designed for this purpose and functions poorly as a lost and found system.

2.2.3 Lost and Found Thing Management System ([Link])

An open-source project published on [Link] implements a basic lost and found management
system using PHP, CSS, JavaScript, and MySQL. It provides core functionality such as item submission
forms and a listing page.

Strengths: Uses a structured database backend, PHP-MySQL integration, provides a basic

administrative interface.
Limitations: The user interface is outdated and not responsive, making it unusable on mobile devices. It
lacks proper user authentication - anyone can submit or view posts without registering. There is no search
or filter functionality on the listings page. The code is not modular and is difficult to maintain or extend.
No session management is implemented, creating security vulnerabilities. The project has not been
updated in several years and does not follow current PHP coding practices.

2.2.4 Campus Lost and Found Portal (Devpost)

A project submitted on Devpost for a hackathon implements a campus lost and found portal aimed at
university students. It demonstrates a clear understanding of the problem and provides a functional user
interface for browsing and submitting reports.

10
Strengths: Well-designed user interface, uses modern frontend frameworks, demonstrates core
functionality effectively.
Limitations: The system was built as a hackathon prototype and lacks a fully developed backend. There
is no persistent database - data is stored in memory and is lost when the server restarts. Authentication
is minimal and not secure enough for institutional deployment. No admin panel is included. The project
is not designed for local Indian campus environments and does not account for offline or low-bandwidth
usage scenarios.

2.2.5 Research Papers from [Link]

Several academic papers discussing the design and development of campus management systems were
reviewed. Key papers examined include works on centralized student services portals, digital item
tracking systems, and web-based administrative tools for educational institutions.

Key findings from the literature include: (a) The importance of using a relational database with
normalized schema design for maintaining structured records. (b) The value of role-based access control
in institutional systems to prevent unauthorized access. (c) The necessity of client-side and server-side
input validation to prevent data inconsistency and security vulnerabilities. (d) The preference among
student users for simple, single-page-style interfaces over complex multi-step workflows. (e) The
significance of timestamping all records for audit and verification purposes.

2.2.6 Bootstrap and MDN Documentation

The Bootstrap documentation (v5.0) and Mozilla Developer Network (MDN) references for HTML,
CSS, and JavaScript were consulted extensively during the development phase. These resources
provided best practice guidelines for responsive grid layout, form design, button and typography styles,
and cross-browser compatible JavaScript patterns. Although Bootstrap itself was not directly imported
into the project due to the lightweight design goal, many of its conceptual patterns were adapted and
implemented through custom CSS.

2.3 Proposed System

Based on the gaps and limitations identified in the existing systems reviewed above, the proposed
Campus Lost and Found Web Portal was designed as a comprehensive, deployable solution that
addresses all identified shortcomings. The key improvements introduced by the proposed system are
described below.

• Centralized Digital Access: The portal is accessible from any device with a browser and
internet connection, eliminating the need for physical presence.

11
 • Registered User Accounts: All users must register and log in before submitting or browsing
reports. This ensures accountability and prevents misuse.

• Session-Based Authentication: PHP sessions are used to manage login state across pages,
providing security without requiring repeated logins.

• Structured Report Forms: Both lost and found forms capture data in a consistent, structured
format - item name, category, description, date, and location - making records searchable and
comparable.

• Real-Time Search: The All Posts page supports keyword-based filtering, allowing users to
quickly narrow down results without waiting for a page reload.

• Persistent Database Storage: All records are stored in a MySQL relational database, ensuring
data is not lost between sessions and is available for historical reference.

• Responsive Interface: The UI is designed to adapt to different screen sizes, making it

accessible on both desktop computers and mobile devices.

• Admin Management: The administrator can delete invalid, duplicate, or resolved posts,
keeping the portal clean and relevant.

• Security: Passwords are hashed, inputs are sanitized, and sessions are properly managed to
prevent common web vulnerabilities.

Feature Existing Systems Proposed System

Centralized access Not available Available (web-based)

User authentication Absent or minimal Secure (PHP sessions + hashing)

Structured data entry No (notice boards, chat) Yes (category, date, location)

Keyword search Not possible Implemented (JS + PHP)

Persistent database Absent in most MySQL with normalized schema

Responsive UI No Yes (custom CSS)

Admin management panel Absent in most Included

Password security Not applicable BCrypt hashing via PHP

Historical record keeping No Yes (timestamps stored)

Cross-browser Inconsistent Tested on major browsers

compatibility

Table 2.1: Comparison of Existing Systems vs Proposed System

12
2.4 Feasibility Study
A feasibility study is carried out before developing a project to check whether the proposed system is
practical, useful, and possible to implement successfully. It helps in understanding if the project can be
developed with the available resources, technology, time, and budget. For this project, the feasibility
study was performed by analyzing three important aspects of the system

2.4.1 Technical Feasibility

The system relies entirely on free, open-source technologies - HTML, CSS, JavaScript, PHP, and
MySQL - all of which are widely documented, actively maintained, and supported by a large developer
community. The XAMPP package, which bundles Apache, PHP, and MySQL into a single installation,
provided a fully functional local development environment with minimal setup. All team members had
prior academic experience with these technologies, ensuring that the technical learning curve was
manageable.

The project does not require any specialized hardware, proprietary software licenses, or cloud
infrastructure for development and local testing. Deployment on a shared web host would require only
a basic PHP-MySQL hosting plan, which is readily and inexpensively available from numerous Indian
hosting providers. From a technical standpoint, therefore, the project is fully feasible.

2.4.2 Economic Feasibility

The development cost of this project was effectively zero - all tools, frameworks, and languages used
are free and open-source. The only cost incurred was the time investment of the five team members over
five months of work. For institutional deployment, the cost would be limited to shared web hosting
(approximately INR 3,000-6,000 per year in India) and a domain name registration if required. There
are no ongoing licensing fees.

The economic benefit to the institution is also significant: reducing the number of unclaimed items on
campus saves time for administrative staff, reduces financial losses for students, and contributes to a
more organized campus environment. The return on the minimal investment required is clearly justified,
making the project economically feasible.

2.4.3 Operational Feasibility

Operationally, the system is designed to be as simple and self-explanatory as possible. The interface
uses familiar web conventions - registration forms, login pages, search bars, and card-based listings -
that most students and staff already encounter in everyday digital life. No technical training is required
to use the portal effectively.

13
From an administrative standpoint, the system requires minimal maintenance. An administrator simply
needs to periodically review the listings page to remove resolved or invalid posts - a task that takes only
a few minutes each day. No technical expertise is required for routine operation. The system is
operationally feasible for deployment in any educational institution.

14
 CHAPTER 3: SYSTEM ANALYSIS & DESIGN

3.1 Preface
System analysis and design is an important part of software development. In this stage, the needs and
working process of the system are studied properly before coding starts. Things like system functions,
database structure, and overall flow of the project are planned in advance. This chapter explains the
analysis and design process used for developing the Campus Lost and Found Web Portal.

First, this chapter explains the functional requirements of the system, which tell what tasks and functions
the system should perform. After that, the non-functional requirements are discussed, including system
performance, security, user-friendliness, and reliability.

This chapter also contains different diagrams and models made for the project, such as ER diagram, Use
Case diagram, Data Flow Diagram, activity flowchart, class diagram, and sequence diagram. These
diagrams help in understanding the structure and working process of the system in a simple and
organized way.

This chapter also explains the design methods and important algorithms used in the project. All the
design documents were prepared before the coding work started and were used as a reference during
development. This proper planning helped in building the system in an organized way and reduced
mistakes and unnecessary changes during the development process.

3.2 Requirement Specification

3.2.1 Functional Requirements
Functional requirements explain the main tasks and activities that the system should perform for users.
They describe how the system will work and what features need to be included in the project. These
requirements were decided after discussing with the project guide and understanding the needs of users.

Req. Requirement Description Priority

ID

FR-01 User The system shall allow new users to create an High
Registration account by providing their full name, a valid email
address, and a password. The email must be unique.
The password shall be hashed before storage.

15
FR-02 User Login The system shall authenticate users by matching the High
submitted email and verifying the submitted
password against the stored hash. A session shall be
created upon successful login.

FR-03 User Logout The system shall destroy the user session and High
redirect to the login page when the logout option is
triggered.

FR-04 Report Lost Authenticated users shall be able to submit a report High
Item for a lost item, providing item name, category,
description, date last seen, and location.

FR-05 Report Found Authenticated users shall be able to submit a report High
Item for a found item, providing similar details as the
lost item form.

FR-06 View All Any authenticated user shall be able to view all High
Posts active lost and found listings on the All Posts page,
displayed in reverse chronological order.

FR-07 Keyword Users shall be able to filter the All Posts listings by Medium
Search entering a keyword, which is matched against item
names and descriptions in real time.

FR-08 Session The system shall maintain user login state across all High
Management pages using PHP session variables.
Unauthenticated users attempting to access
restricted pages shall be redirected to the login
page.

FR-09 Admin Access Designated administrators shall have access to an Medium

admin panel from which they can view all user
accounts and delete any post from the database.

FR-10 Data All form submissions shall be validated on the High

Validation client side using JavaScript and on the server side
using PHP before any data is written to the
database.

16
 FR-11 Input All data received from users shall be sanitized High
Sanitization using PHP's prepared statements and
htmlspecialchars() to prevent SQL injection and
XSS attacks.

Table 3.1: Functional Requirements

3.2.2 Non-Functional Requirements

Non-functional requirements describe the quality standards and conditions that the system should satisfy
for proper performance and user satisfaction. These requirements are not related to specific features or
functions of the system, but they are important for making the system secure, reliable, efficient, and easy
to use. They also define the limitations and overall behavior expected from the system during operation.

Attribute Requirement Description

Usability The interface shall be intuitive and self-explanatory. A first-time user with
basic computer literacy shall be able to register, log in, submit a report, and
search for items without any manual or training.

Performance All pages shall load within 3 seconds under normal network conditions.
Database queries shall be optimized to return results in under 1 second for up
to 5,000 records.

Security Passwords shall be stored as BCrypt hashes. All form inputs shall be sanitized.
Sessions shall be invalidated on logout. PHP prepared statements shall be used
for all database interactions.

Reliability The system shall be available 24/7 without unplanned downtime. Database
transactions shall be designed to avoid data loss in the event of a mid-process
failure.

Scalability The database schema and application architecture shall support growth to tens
of thousands of records without requiring structural changes.

Maintainability The PHP codebase shall be organized into modular files with clear naming
conventions. Functions shall be commented. The database schema shall be
documented.

17
 Portability The system shall be deployable on any web hosting environment that supports
PHP 7.4+ and MySQL 5.7+, without platform-specific dependencies.

Compatibility The user interface shall render correctly on the latest versions of Google
Chrome, Mozilla Firefox, and Microsoft Edge without CSS or JavaScript
errors.

Accessibility Text elements shall use sufficient contrast ratios. Form fields shall include
labels. The interface shall be navigable using a keyboard.

Table 3.2: Non-Functional Requirements

3.3 Flowcharts / UML Diagrams / ER Diagrams

3.3.1 Entity-Relationship (ER) Diagram
The database design is captured in the ER diagram below. The system has three main entities: User,
LostItem, and FoundItem.

Entity: User - Attributes: user_id (PK), name, email, password_hash, role, created_at
Entity: LostItem - Attributes: item_id (PK), user_id (FK), item_name, category, description, date_lost,
location, status, created_at
Entity: FoundItem - Attributes: item_id (PK), user_id (FK), item_name, category, description,
date_found, location, status, created_at

Relationships:

• A User may report zero or more LostItems (one-to-many relationship; one user, many lost
item reports).

• A User may report zero or more FoundItems (one-to-many relationship; one user, many found
item reports).

• Each LostItem is associated with exactly one User (many-to-one from LostItem to User).

• Each FoundItem is associated with exactly one User (many-to-one from FoundItem to User).

18
 Figure 3.1: Entity-Relationship Diagram - Campus Lost and Found Portal

3.3.2 Database Schema Tables

The three database tables are defined as follows:

Column Data Type Constraint Description

user_id INT PK, AI Auto-increment unique identifier for each

user

name VARCHAR(100) NOT NULL Full name of the registered user

email VARCHAR(150) UNIQUE, NOT Email address used for authentication

NULL

password_hash VARCHAR(255) NOT NULL BCrypt-hashed password string

role ENUM DEFAULT 'user' 'user' or 'admin' - determines access level

created_at DATETIME DEFAULT Timestamp of account creation

NOW()

Table 3.3: Database Schema - users Table

19
Column Data Type Constraint Description

item_id INT PK, AI Unique identifier for each lost item report

user_id INT FK → users ID of the user who submitted the report

item_name VARCHAR(150) NOT NULL Name or short title of the lost item

category VARCHAR(60) NOT NULL Category (Electronics, Books, Clothing,

etc.)

description TEXT NOT NULL Detailed description of the item

date_lost DATE NOT NULL Date on which the item was last seen

location VARCHAR(200) NOT NULL Last known location of the item on

campus

status ENUM DEFAULT 'active' 'active' or 'claimed' - claim state of the

report

created_at DATETIME DEFAULT NOW() Timestamp of report submission

Table 3.4: Database Schema - lost_items Table

Column Data Type Constraint Description

item_id INT PK, AI Unique identifier for each found item report

user_id INT FK → users ID of the user who found and reported the
item

item_name VARCHAR(150) NOT NULL Name or short title of the found item

category VARCHAR(60) NOT NULL Category of the found item

description TEXT NOT NULL Detailed description including

distinguishing features

date_found DATE NOT NULL Date on which the item was found

location VARCHAR(200) NOT NULL Location where the item was found on
campus

status ENUM DEFAULT 'active' or 'returned' - disposition state

'active'

created_at DATETIME DEFAULT Timestamp of report submission

NOW()

Table 3.5: Database Schema - found_items Table

20
3.3.3 Use Case Diagram
The use case diagram for the Campus Lost and Found Web Portal identifies two primary actors and the
system use cases they interact with.

Actor 1 - Registered User: Register, Login, Report Lost Item, Report Found Item, View All Posts, Search
Listings, View Post Details, Logout.
Actor 2 - Administrator: Login (with admin role), View All Posts, Delete Any Post, View User
Accounts, Logout.

Figure 3.2: Use Case Diagram - Campus Lost and Found Portal

3.3.4 Data Flow Diagrams

Data Flow Diagrams (DFDs) represent the movement of data through the system. Two levels of DFD
were prepared.
Level 0 (Context Diagram): The system is represented as a single process. Two external entities - User
and Administrator - interact with the system. The User sends registration data, login credentials, and
item reports to the system, and receives search results and post listings. The Administrator sends
management commands and receives system status information.

21
Level 1 DFD: The system is decomposed into four sub-processes:

• Process 1.0 - User Authentication: Receives credentials, queries the users data store, creates or
destroys session.

• Process 2.0 - Lost Item Management: Receives lost item form data, validates it, and writes to
the lost_items data store.

• Process 3.0 - Found Item Management: Receives found item form data, validates it, and writes
to the found_items data store.

• Process 4.0 - Search and Retrieve: Receives a search keyword, queries both data stores, and
returns filtered results to the User.

3.3.5 Activity Flowchart - Lost Item Reporting

The following steps describe the complete flow of the lost item reporting process:

8. User opens the portal URL in a browser.

9. System checks for an active session. If no session exists, user is redirected to the login page.

10. User logs in with email and password. PHP verifies credentials against the users table.

11. On successful login, session is created and user is redirected to the Home Page.

12. User clicks 'Report Lost Item' in the navigation menu.

13. The Lost Item Report form is displayed.

14. User fills in: item name, category, description, date lost, and location.

15. User submits the form. JavaScript validates all fields on the client side.

16. If validation fails (empty fields, invalid date), error messages are displayed and user corrects
inputs.

17. On valid submission, data is sent via HTTP POST to the PHP processing script.

18. PHP sanitizes all inputs using prepared statements.

19. PHP inserts a new record into the lost_items table with status = 'active'.

20. A success message is displayed to the user.

21. The new listing appears on the All Posts page.

3.3.6 Activity Flowchart - User Login

22. User navigates to the Sign In page.

23. User enters email address and password in the login form.

22
 24. JavaScript checks that both fields are non-empty before allowing submission.

25. Form data is submitted via POST to [Link].

26. PHP queries the users table using a prepared statement: SELECT * FROM users WHERE
email = ?

27. If no matching record is found, an error message ('User not found') is displayed.

28. If a record is found, PHP calls password_verify(submitted_password, stored_hash).

29. If the password does not match, an error message ('Incorrect password') is displayed.

30. If the password matches, a PHP session is created: $_SESSION['user_id'],

$_SESSION['name'].

31. User is redirected to the Home Page with a welcome message.

3.4 Design Steps / Criteria

The system was designed following a structured set of criteria that guided all implementation decisions.
These criteria are described below:

• Separation of Concerns: HTML was used exclusively for page structure, CSS for styling and
layout, JavaScript for client-side behavior, and PHP for all server-side logic. Database
operations were isolated in a dedicated db_connect.php file.

• Modular File Structure: Each page of the portal corresponds to a separate PHP file. Reusable
components such as the database connection, session check, and header/footer HTML were
factored into include files to avoid code duplication.

• Database Normalization: All three tables were designed to conform to at least Second Normal
Form (2NF). Redundant data is avoided by using foreign keys to reference user information
rather than duplicating name or email fields in the lost_items and found_items tables.

• Security-First Design: All form inputs are passed through PHP's htmlspecialchars() before
display and through PDO prepared statements before insertion, preventing both XSS (Cross-
Site Scripting) and SQL injection attacks. Passwords are hashed using PHP's password_hash()
with BCRYPT as the algorithm.

• Responsive Design: CSS media queries are used to adjust the layout, font sizes, and
component widths for different screen sizes. The portal is tested at 320px (mobile), 768px
(tablet), and 1280px (desktop) breakpoints.

• Progressive Enhancement: Core functionality works without JavaScript (server-side validation

handles all cases). JavaScript is used to enhance the user experience through client-side
validation and real-time search filtering.

23
3.5 Algorithms and Pseudo Code
Algorithm 1: User Registration
INPUT: name, email, password

STEP 1: Receive form data via HTTP POST.

STEP 2: Trim whitespace from all inputs.

STEP 3: Validate - check name is not empty.

STEP 4: Validate - check email format using filter_var().

STEP 5: Validate - check password length >= 8 characters.

STEP 6: Check if email already exists:

SELECT COUNT(*) FROM users WHERE email = ?

STEP 7: IF count > 0 THEN

Display error: 'This email is already registered.'

ELSE

hash = password_hash(password, PASSWORD_BCRYPT)

INSERT INTO users (name, email, password_hash)

VALUES (?, ?, ?)

Display success: 'Registration successful. Please log in.'

OUTPUT: New record in users table OR error message

Algorithm 2: User Login and Session Creation

INPUT: email, password
STEP 1: Receive email and password via POST.

STEP 2: Sanitize inputs (trim whitespace, validate email format).

STEP 3: Query: SELECT * FROM users WHERE email = ?

STEP 4: IF no record found THEN

Return error: 'No account found with this email.'

STEP 5: IF record found THEN

result = password_verify(submitted_pwd, stored_hash)

IF result == TRUE THEN

session_start()

$_SESSION['user_id'] = row['user_id']

$_SESSION['name'] = row['name']

$_SESSION['role'] = row['role']

24
 Redirect to [Link] (Home Page)

ELSE

Return error: 'Incorrect password.'

OUTPUT: Authenticated session OR error message

Algorithm 3: Keyword Search on All Posts Page

INPUT: keyword (string from search box)

STEP 1: Receive keyword via JavaScript input event.

STEP 2: Convert keyword to lowercase.

STEP 3: For each post card on the page:

text = [Link]()

IF text includes keyword THEN

[Link] = 'block'

ELSE
[Link] = 'none'

STEP 4: If no cards are visible, show 'No results found' message.

OUTPUT: Filtered list of post cards matching the keyword

25
 CHAPTER 4: TESTING PROCESS

4.1 Unit Testing

Unit testing is the process of testing individual modules or components of the system in isolation to
verify that each one behaves correctly according to its specifications. Unit tests are performed before the
modules are integrated together, making it easier to identify and fix bugs at their source before they
propagate to other parts of the system.

For the Campus Lost and Found Web Portal, unit tests were performed on the following modules: User
Registration, User Login, Lost Item Report Form, Found Item Report Form, All Posts retrieval, Keyword
Search, and User Logout. Each test case was executed manually using a local XAMPP server with
Google Chrome as the browser. Results were compared against the expected outputs defined in the test
cases.

Test Module Test Case / Input Expected Result Actual Result

ID

UT-01 User Valid name, new email, Account created, Account created, redirect
Registration password ≥ 8 chars redirect to login to login

UT-02 User Email already in database Error: 'Email already Error message displayed
Registration registered' correctly

UT-03 User Name field left empty Validation error: Error shown before
Registration name required submission

UT-04 User Invalid email format (no Validation error: JS validation blocked
Registration @) invalid email submission

UT-05 User Password less than 8 Validation error: Error shown correctly
Registration characters password too short

UT-06 User Login Correct email and correct Session created, Redirected to Home Page
password redirected to Home

UT-07 User Login Correct email, wrong Error: 'Incorrect Error message displayed
password password'

UT-08 User Login Unregistered email Error: 'No account Error message displayed
found'

UT-09 User Login Both fields left empty JS validation: fill in Submission blocked by JS

26
 fields

UT-10 Lost Item All fields filled correctly Record inserted, Success message shown,
Form success message DB record created

UT-11 Lost Item Description field left Validation error: Error shown, submission
Form empty required field blocked

UT-12 Lost Item Date set to future date Validation error: Error message displayed
Form invalid date

UT-13 Found Item All fields filled correctly Record inserted, Success message shown,
Form success message DB record created

UT-14 Found Item Location field left blank Validation error: Error shown
Form required field

UT-15 All Posts Page Page loaded after login All records displayed All records shown
in card layout correctly

UT-16 Search Valid keyword: 'laptop' Cards with 'laptop' Only matching cards
Function visible, others hidden shown

UT-17 Search Keyword with no No cards visible, 'No No results message

Function matches: 'xyz123' results' shown displayed

UT-18 Logout User clicks logout button Session destroyed, Login page displayed,
redirect to login session cleared

UT-19 Admin Panel Admin logs in and views All posts shown with Admin panel loaded
posts delete option correctly

UT-20 Admin Panel Admin deletes a post Post removed from Post deleted, page
DB and page refreshed

Table 4.1: Unit Test Cases

All twenty unit test cases passed without any failures. Minor issues observed during early testing - such
as incorrect error message wording and a PHP warning for undefined session variables - were resolved
during the testing phase itself before integration testing began.

4.2 Integration Testing

Integration testing verifies that the individual modules, once combined into the complete system, interact
correctly with each other. The focus of integration testing is on the interfaces and data flows between

27
components - particularly the communication between the HTML/JavaScript frontend, the PHP
backend, and the MySQL database.

Integration testing for the Campus Lost and Found Web Portal was performed using a bottom-up
approach, starting from the database layer and progressively testing the PHP layer and then the full
frontend-to-database round trip. Each test case below describes a specific end-to-end scenario.

Test Integration Scenario Expected Outcome Verified By Result

ID

IT-01 Registration form → PHP validation → User record created with phpMyAdmin + Pass
MySQL INSERT into users table hashed password; duplicate browser
email rejected

IT-02 Login form → PHP query → session Session variables set; Browser session Pass
creation → page redirect correct page loaded; check
unauthenticated access
blocked

IT-03 Lost item form → PHP sanitization → Record stored with correct phpMyAdmin Pass
MySQL INSERT into lost_items table user_id, all fields intact, no query
injection possible

IT-04 Found item form → PHP sanitization Record stored correctly in phpMyAdmin Pass
→ MySQL INSERT into found_items found_items table with FK query
table relationship intact

IT-05 All Posts page → PHP query both All active records from Browser UI Pass
tables → HTML card display both tables rendered as check
cards in correct order

IT-06 Search box input → JS filter → DOM Only cards matching Browser live test Pass
manipulation keyword visible; others
hidden; no page reload

IT-07 Admin delete button → PHP DELETE Record removed from DB; phpMyAdmin + Pass
query → page refresh card no longer appears on UI
All Posts page

IT-08 Logout → PHP session_destroy() → Session cleared; direct URL Browser test Pass
redirect to login access to protected page
redirects to login

IT-09 Unverified access attempt → session User navigating to report Browser test Pass

28
 check → redirect page without login is
redirected to [Link]

IT-10 Full flow: Register → Login → Report Complete user journey End-to-end test Pass
→ Search → Logout works end-to-end without
errors

Table 4.2: Integration Test Cases

All ten integration test cases passed successfully. The system demonstrated correct end-to-end behavior
across all tested scenarios, with data flowing accurately between the frontend, the PHP layer, and the
MySQL database. No critical integration bugs were found. The system is considered stable and ready
for deployment.

Additionally, a final round of user acceptance testing was informally conducted with three classmates
who were asked to use the portal without guidance. All three were able to complete the full workflow -
register, log in, submit a report, and search for items - without any assistance, confirming that the system
meets its usability requirements.

29
 CHAPTER 5: RESULTS AND DISCUSSIONS

5.1 Preface
This chapter presents the final outputs and results of the Campus Lost and Found Web Portal project.
The system was developed, tested, and validated on a local XAMPP server running Apache 2.4 and
MySQL 8.0, using Google Chrome as the primary browser. All user interface screenshots described
below were captured from the locally running application after all testing was completed.

The chapter is organized into three sections: a description of each user interface screen, a presentation
of the database structure and sample records, and a discussion of the overall results and their alignment
with the objectives defined in Chapter 1.

5.2 User Interface

5.2.1 Home Page
The Home Page is the first screen a visitor encounters when navigating to the portal. It establishes the
identity and purpose of the system immediately, displaying the portal name - Campus Lost and Found
Web Portal - and the tagline 'Report • Track • Recover'. Below the tagline, a brief introductory paragraph
explains what the portal does and prompts the user to either sign up (if new) or sign in (if already
registered).

The navigation bar at the top of the page provides links to Sign In, Sign Up, and the All Posts page. For
authenticated users, the navigation also shows the user's name and a Logout button. The overall color
scheme uses deep blue (#1F3864) as the primary theme color, with white backgrounds for content areas.
This creates a professional, institutional look appropriate for a university portal.

Figure 5.1: Home Page - Campus Lost and Found Web Portal

30
5.2.2 Sign Up Page
The Sign Up page provides a registration form where new users can create an account. The form collects
three pieces of information: full name, email address, and password. Below the password field, a note
informs the user that the password must be at least 8 characters long.

Client-side validation using JavaScript checks that all fields are filled, the email is in a valid format, and
the password meets the minimum length requirement. If any check fails, an error message in red is
displayed below the relevant field without the page reloading. This provides immediate, non-disruptive
feedback to the user.

On the server side, PHP checks whether the submitted email already exists in the users table. If it does,
the registration is rejected with an appropriate error message. If the email is new, the password is hashed
using password_hash() and the full record is inserted into the database. A success message prompts the
user to proceed to the Sign In page.

Figure 5.2: Sign Up Page - User Registration Form

5.2.3 Sign In Page

The Sign In page presents a simple login form with two fields: email address and password. The form
uses the HTTP POST method to submit credentials to [Link]. On the backend, PHP retrieves the user
record associated with the submitted email and uses password_verify() to check the submitted password
against the stored hash.

Upon successful authentication, a PHP session is initialized with the user's ID, name, and role stored as
session variables. The user is then redirected to the Home Page, where their name is displayed in the
navigation bar as a confirmation of the successful login. Incorrect credentials result in an error message
displayed at the top of the form without clearing the email field, allowing the user to re-enter only the
password.

31
 Figure 5.3: Sign In Page - User Login Form

5.2.4 Lost Item Report Page

The Lost Item Report page is one of the two core content-creation pages of the portal. It presents a form
with the following fields:

• Item Name: A short text field for the name of the lost item (e.g., 'Blue Titan Water Bottle').
• Category: A dropdown menu with options - Electronics, Accessories, Books, Stationery,
Clothing, Identity Documents, and Others.
• Description: A large text area for a detailed description including any distinguishing features,
colors, brands, or markings.
• Date Lost: A date picker that allows the user to select the date the item was last seen. Future
dates are rejected by the validation logic.
• Location: A text field for the last known location (e.g., 'BCA Lab, 3rd Floor, Block B').
After passing client-side validation, the data is submitted to a PHP script that sanitizes the inputs using
PDO prepared statements and inserts a new record into the lost_items table with the session user_id as
the foreign key. A success confirmation is displayed, and the user is given the option to return to the
Home Page or browse All Posts.

Figure 5.4: Lost Item Report Form - Authenticated User View

32
5.2.5 Found Item Report Page
The Found Item Report page mirrors the structure and behavior of the Lost Item Report page. The key
difference is in the terminology: the date field is labeled 'Date Found' and the location field asks where
the item was discovered rather than where it was last seen. The data is stored in the found_items table
rather than lost_items.

This page plays an important role in the overall system by allowing the campus community to formally
report items they find, rather than keeping them or discarding them. The structured format ensures that
each found item report contains enough detail for the owner to recognize their property and reach out.

Figure 5.5: Found Item Report Form - Authenticated User View

5.2.6 All Posts Page

The All Posts page is the central browsing interface of the portal and arguably its most important feature
from a user perspective. It retrieves all active records from both the lost_items and found_items tables
using a PHP query and renders each record as an individual card in a grid layout.

Each card displays: a header label (Lost or Found), the item name in bold, the category as a tag, a
truncated version of the description (with a 'See more' option), the date of the report, and the location.
Cards are sorted in reverse chronological order - the most recently submitted reports appear first.

At the top of the page is a search bar. As the user types, JavaScript filters the visible cards in real time
by checking whether the card's text content contains the typed keyword. Cards that do not match are
hidden using CSS display:none. If no cards match, a 'No results found' message is displayed. This
provides an immediate, responsive search experience without the overhead of a server round trip.

33
 Figure 5.6: All Posts Page - Search and Browse Interface

5.3 Databases
The MySQL database named campus_laf was designed and managed using phpMyAdmin, which
provides a graphical interface for database administration. The database contains three primary tables:
users, lost_items, and found_items, whose schemas were defined in Chapter 3.

Sample records from the lost_items and found_items tables, as observed in phpMyAdmin during testing,
are presented below:

ID Item Name Category Date Lost Location Status

1 Blue Titan Water Accessories 2026-02-14 Cafeteria, Ground Floor active

Bottle

2 Samsung Electronics 2026-02-20 BCA Lab, Block B, 3rd Floor active

Earphones (Black)

3 Calculus Textbook Books 2026-03-05 Library Reading Hall claimed

4 Student ID Card - Identity 2026-03-11 Basketball Court, Sports Block active

Ravi Kumar Documents

5 Grey Hoodie (Size Clothing 2026-03-22 Seminar Hall 2, Admin Block active
M)

Table 5.1: Sample Data - lost_items Table

34
 ID Item Name Category Date Found Location Status

1 Black Wallet Accessories 2026-02-16 Men's Restroom, Block A active

(Leather)

2 Bluetooth Mouse Electronics 2026-02-28 Computer Lab 1, Block C active

(White)

3 Set of Keys (3 Accessories 2026-03-08 Parking Area, Gate 2 returned

keys, red
keychain)

4 Architecture Stationery 2026-03-14 Design Studio, Ground Floor active

Drawing Sheet
Roll

5 Purple Silk Clothing 2026-04-01 Girl's Common Room, Block D active

Dupatta

Table 5.2: Sample Data - found_items Table

5.4 Results and Outputs

The following results were observed and recorded after the completion of development and the execution
of all test cases:

• User Registration and Authentication: The registration module successfully created user
accounts in the database with BCrypt-hashed passwords. Login was verified to work correctly
for all tested credential combinations. Session management maintained authentication state
across all pages and was correctly terminated on logout.

• Lost and Found Report Submission: Both report forms accepted valid submissions and
correctly rejected invalid inputs. Records were inserted into the appropriate database tables
with the correct user_id foreign key, timestamps, and status values. No data integrity
violations were observed.

• All Posts Page and Search: All active records from both tables were successfully retrieved and
displayed as cards. The real-time keyword search correctly filtered visible cards without a
page reload. Search was tested with multiple keywords including item names, categories, and
location fragments.

35
 • Admin Panel: The admin delete functionality successfully removed records from the database.
The change was immediately reflected on the All Posts page without requiring a full
application restart.

• Cross-Browser Compatibility: The portal was tested on Google Chrome, Mozilla Firefox, and
Microsoft Edge. No significant layout or functionality issues were observed across these
browsers.

• Security Testing: Attempts to submit SQL injection strings through form fields were blocked
by PDO prepared statements. Attempts to access protected pages without logging in correctly
redirected to the login page. Passwords were confirmed to be stored only in hashed form.

Overall, the system performed reliably across all tested scenarios. All seven primary objectives defined
in Chapter 1 were met. The portal is functionally complete and ready for deployment. Minor
enhancements - such as image upload support and email notifications - are identified as future scope
items in Chapter 7.

36
 CHAPTER 6: SOCIO-ECONOMIC ISSUES

6.1 Practical Relevance

The Campus Lost and Found Web Portal is not merely an academic exercise - it addresses a genuine,
recurring need that affects students and staff in educational institutions every day. Personal belongings
such as mobile phones, wallets, identity cards, laboratory equipment, stationery, and clothing are
frequently misplaced or left behind in the course of a busy academic day. Without a structured
mechanism to report and track these items, most of them remain unclaimed or are permanently lost,
causing financial stress and inconvenience to individuals who may not be in a position to easily replace
them.

The practical relevance of this portal can be understood at several levels. At the individual level, it
reduces the time and anxiety a student experiences when they lose an important item. Instead of retracing
their steps, asking every acquaintance, or checking physical notice boards, they can simply log in to the
portal, submit a report, and search for matching found item listings - all within minutes. This directly
reduces lost time and improves the quality of life on campus.

At the institutional level, the portal helps create a more organized campus environment. When found
items are formally reported and stored in a database rather than left on a bench or handed informally to
a security guard, the chances of those items being returned to their owners increase significantly. This
reduces waste and fosters a culture of responsibility and honesty among campus members.

From an administrative perspective, the portal reduces the workload on security staff and administrative
departments who currently handle lost and found inquiries manually. With a self-service digital system,
students no longer need to visit the admin office or security booth to report a lost item - the entire process
is handled online. This frees up staff time for more critical responsibilities.

The system is also practically relevant because of its accessibility. It is accessible from any device with
a browser - including smartphones - which means students can report a found item immediately upon
discovering it, before they even leave the location where it was found. This immediacy significantly
improves the chances of recovery.

6.2 Global Impact

While this project was developed for the specific context of the ITER campus, the underlying framework
and the problem it solves are universal. The management of lost and found items is a challenge shared
by every large institution in the world - universities, hospitals, airports, train stations, shopping centers,

37
and corporate campuses all face the same problem. A digital, web-based portal of this kind can be
deployed in any of these contexts with appropriate customization.

From a global sustainability perspective, the portal contributes to reducing material waste. Every year,
large quantities of personal items that could have been returned to their owners are instead discarded or
permanently lost because no recovery mechanism existed. A working lost and found system increases
the rate of item recovery, which means fewer items need to be replaced. This is particularly significant
for electronic devices, which have a substantial environmental footprint in manufacturing and disposal.

From a global digital inclusion perspective, the fact that this system is built on open-source technologies
- HTML, PHP, MySQL - means it can be replicated by any institution with access to basic web hosting,
including institutions in developing countries with limited budgets. The absence of proprietary software
requirements makes it democratically accessible in a way that commercial solutions are not.

The project also contributes to the growing body of student-built, practical web applications that
demonstrate the capability of undergraduate computer science and technology students in India to
develop real-world solutions. As these projects become more visible through institutional deployment,
they help change the perception of vocational technology education and highlight the practical value of
applied computer science training.

Finally, the architecture of this project - a PHP-MySQL web application with session management, form
validation, and a responsive frontend - represents a pattern that is widely used in real-world web
development. By building a working system using this architecture, the team has developed skills that
are directly transferable to professional software development projects in the global job market.

6.3 Lifelong Learning

One of the most important outcomes of this project is not the software itself, but the learning that
occurred during its development. Each of the five team members developed a range of technical and
non-technical skills that will serve them throughout their professional and personal lives.

From a technical standpoint, the project provided practical, hands-on experience with the full web
development lifecycle. This included frontend development with HTML5, CSS3, and JavaScript; server-
side scripting with PHP; relational database design and management with MySQL; and system testing
and debugging. These are among the most in-demand skills in the current software industry, and the
project provided a depth of engagement with these technologies that is difficult to achieve through
classroom instruction alone.

38
Beyond technical skills, the project provided important lessons in software engineering practices. The
team followed a structured development process - beginning with requirements gathering, moving
through design, implementation, and testing, and concluding with documentation. This experience with
the Software Development Lifecycle (SDLC) gave each team member a frame of reference for how
professional software projects are organized and managed.

The project also developed skills in team collaboration and project management. Dividing a complex
project into individual modules, coordinating work across five people, resolving integration issues,
managing a shared deadline, and collectively reviewing each other's work are all skills that are rarely
taught explicitly but are critical in professional environments.

Problem-solving was another significant learning outcome. During development, the team encountered
several unexpected challenges - including database connection issues, session variable conflicts, CSS
layout bugs on mobile devices, and PHP deprecation warnings. Debugging these issues systematically,
using browser developer tools, PHP error logs, and phpMyAdmin, developed the kind of practical
troubleshooting skill that only comes from working on a real project.

Finally, the process of writing this report itself was an important learning experience. Documenting a
technical project in a structured, academic format - defining the problem, reviewing the literature,
specifying requirements, describing the design, presenting test results, and reflecting on socio-economic
relevance - requires a form of thinking that bridges technical and communicative competencies. This
ability to document and explain technical work clearly is increasingly recognized as one of the most
valuable skills a software professional can have.

In summary, the Campus Lost and Found Web Portal project has contributed to the lifelong learning of
all five team members in ways that extend well beyond the technical content of the project itself.

39
 CHAPTER 7: CONCLUSION AND FUTURE SCOPE

7.1 Conclusion
The Campus Lost and Found Web Portal has been successfully designed, implemented, tested, and
documented as the final year project for the Bachelor of Computer Application programme at the
Institute of Technical Education and Research (ITER), Siksha O Anusandhan Deemed to be University,
Bhubaneswar.

The project was motivated by a genuine problem observed in the campus environment - the lack of any
formal, centralized mechanism for managing lost and found items. The existing approaches, which relied
on physical notice boards, informal communication channels, and manual record keeping, were found
to be inefficient, unreliable, and inadequate for the scale and pace of a modern educational institution.

In response, the team designed and developed a web-based portal that provides a structured, secure, and
accessible platform for the campus community. The system allows registered users to submit formal
reports for lost and found items, search through all active listings using a keyword-based interface, and
connect with the relevant parties to facilitate the recovery of belongings. An administrative panel allows
authorized staff to manage the database and keep the portal accurate and up to date.

The system was built using a standard, industry-relevant technology stack: HTML5 and CSS3 for the
frontend, JavaScript for client-side interactivity, PHP for server-side processing and authentication, and
MySQL for persistent data storage. Visual Studio Code was used as the development environment, and
XAMPP provided the local Apache-MySQL server for development and testing.

All seven objectives defined at the beginning of the project were fulfilled:

32. A web-based portal for reporting lost and found items was developed and is fully functional.

33. User authentication with session management was implemented securely using PHP sessions
and BCrypt password hashing.

34. A searchable, real-time listings interface was developed and tested successfully.

35. A persistent MySQL database with a normalized schema was designed and deployed.

36. A responsive, intuitive user interface was delivered, compatible across major desktop
browsers.

37. The system is deployable on any standard PHP-MySQL web hosting environment.

38. The architecture was designed to accommodate future enhancements with minimal refactoring.

40
A comprehensive testing process - covering twenty unit test cases and ten integration test cases -
confirmed that all modules perform correctly in isolation and when integrated. No critical bugs were
found, and the system performed reliably under all tested scenarios.

This project has been a meaningful and rewarding experience for all five team members. It provided an
opportunity to apply the technical knowledge acquired throughout the three-year BCA programme to a
real-world problem, producing a working system that could genuinely benefit the campus community.
The skills developed - in web development, database design, system testing, project management, and
technical writing - will remain valuable throughout each team member's professional career.

In conclusion, the Campus Lost and Found Web Portal is a practical, deployable, and extensible solution
that successfully addresses the problem it was designed to solve. It stands as a demonstration of what
undergraduate technology students can achieve when they combine classroom learning with real-world
application.

7.2 Future Scope

While the current version of the Campus Lost and Found Web Portal meets all defined objectives and is
ready for deployment, there are several directions in which the system can be extended in future versions.
These enhancements are described below:

7.2.1 Email and Push Notification System

One of the most impactful enhancements would be the addition of automated email notifications. When
a new found item is submitted, the system could scan existing lost item reports and notify users whose
descriptions match the found item. This would significantly reduce the need for users to actively check
the portal and would increase the rate of successful item recovery. This feature can be implemented
using PHPMailer with an SMTP configuration.

7.2.2 Image Upload Capability

Allowing users to upload a photograph of the lost or found item when submitting a report would make
the matching process much more reliable. Visual identification is often more accurate than textual
description, particularly for items such as clothing, accessories, or electronics where colors, brands, and
conditions are important. Image uploads can be implemented using PHP's file upload functions with size
and type validation.

41
7.2.3 Item Claim Verification Workflow
The current system marks an item as 'claimed' or 'returned' based on admin action. A future version
could implement a structured claim verification workflow in which the person claiming an item is
required to answer specific questions about it - questions whose answers only the true owner would
know - before the claim is approved. This would significantly reduce the risk of fraudulent claims.

7.2.4 Mobile Application

A dedicated mobile application for Android and iOS would make the portal significantly more
accessible. Students are more likely to immediately report a found item if they can do so from their
smartphone on the spot. A mobile app could also leverage smartphone camera functionality to allow
direct photo capture and upload. The mobile app could be built using React Native or Flutter,
communicating with the existing PHP backend via a REST API.

7.2.5 AI-Based Item Matching

A more advanced enhancement would involve implementing a machine learning model that
automatically compares the text descriptions of submitted lost and found items and identifies likely
matches. This could use Natural Language Processing (NLP) techniques such as TF-IDF or sentence
embeddings to measure similarity between descriptions. Items with a match score above a defined
threshold would be flagged and the relevant users notified automatically.

7.2.6 Geolocation-Based Reporting

Integrating the browser's Geolocation API would allow the system to automatically suggest the user's
current location when submitting a report, reducing friction and improving location accuracy. The
location data could also be used to display reports on an interactive campus map, helping users quickly
identify the area where an item was reported.

7.2.7 Multi-Institutional Deployment

With appropriate changes to the role management and access control system, the portal could be
extended to support multiple campuses or institutions from a single codebase. Each institution would
have its own isolated database partition, its own set of administrators, and its own user community, while
sharing the same application logic. This would make the portal a viable Software-as-a-Service (SaaS)
product for educational institutions.

7.2.8 Analytics and Reporting Dashboard

An analytics dashboard for administrators would provide valuable insights into the portal's usage and

42
the campus's lost and found patterns. Metrics such as the most commonly lost item categories, peak
reporting times, average time between loss and recovery, and overall recovery rate could be visualized
using charts and graphs. This data could help the institution make informed decisions about campus
layout, security, and student services.

Each of these enhancements represents a natural extension of the current system and could be
implemented incrementally in future project phases or taken up as independent final year projects by
subsequent batches of students. The modular architecture of the current system is designed to
accommodate these additions with minimal disruption to the existing codebase.

43
 REFERENCES / BIBLIOGRAPHY

[1] [Link]. (n.d.). Research Papers on Lost and Found Management Systems. Retrieved May
2026 from [Link]

[2] GeeksforGeeks. (n.d.). Web Development Tutorials: HTML, CSS, JavaScript, PHP, and MySQL.
Retrieved April 2026 from [Link]

[3] [Link]. (n.d.). Lost and Found Thing Management in PHP, CSS, JavaScript and MySQL
- Free Download. Retrieved February 2026 from [Link]
management-in-php-css-javascript-and-mysql-free-download/

[4] Devpost. (n.d.). Lost and Found Campus Portal - Project Submission. Retrieved February 2026 from
[Link]

[5] Mozilla Developer Network (MDN). (n.d.). CSS - Cascading Style Sheets. Retrieved March 2026
from [Link]

[6] Bootstrap. (n.d.). Bootstrap 5.0 Documentation - Getting Started. Retrieved March 2026 from
[Link]

[7] W3Schools. (n.d.). PHP Tutorial - Server-Side Scripting. Retrieved March 2026 from
[Link]

[8] PHP Group. (n.d.). PHP Manual - Official Documentation. Retrieved April 2026 from
[Link]

[9] Oracle Corporation. (n.d.). MySQL 8.0 Reference Manual. Retrieved April 2026 from
[Link]

[10] Microsoft. (n.d.). Visual Studio Code Documentation. Retrieved throughout development from
[Link]

[11] XAMPP. (n.d.). XAMPP Apache + MariaDB + PHP + Perl - ApacheFriends. Retrieved January
2026 from [Link]

[12] Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th

44
ed.). McGraw-Hill Education.

[13] Welling, L., & Thomson, L. (2017). PHP and MySQL Web Development (5th ed.). Addison-
Wesley Professional.

[14] Date, C. J. (2019). An Introduction to Database Systems (8th ed.). Pearson Education.

[15] Mozilla Developer Network (MDN). (n.d.). JavaScript Reference. Retrieved March-April 2026
from [Link]

45
 APPENDIX

Appendix A: Database Overview

The Campus Lost and Found Web Portal uses a relational database designed to maintain structured and
consistent records of users and reported items. The database follows a simple normalized design to avoid
redundancy and ensure data integrity.
The system contains three main tables:
• Users Table: Stores registered user information including authentication credentials and role-
based access control.
• Lost Items Table: Stores details of items reported as lost by users.
• Found Items Table: Stores details of items found and reported within the campus.
Each lost and found record is linked to a specific user using a foreign key relationship, ensuring
traceability of every submission.

Appendix B: Key Database Fields Summary

Users Table
• user_id: Unique identifier for each user
• name: Full name of the user
• email: Login credential (unique)
• password_hash: Encrypted password using secure hashing
• role: Defines access level (user/admin)
• created_at: Account creation timestamp
Lost Items Table
• item_id: Unique identifier for lost report
• user_id: References the user who reported the item
• item_name: Name/title of the lost item
• category: Classification of item type
• description: Detailed information about the item
• date_lost: When the item was last seen
• location: Place where item was lost
• status: Current state (active/claimed)
• created_at: Submission timestamp
Found Items Table
• item_id: Unique identifier for found report
• user_id: References the user who submitted the report
• item_name: Name/title of found item

46
 • category: Item classification
• description: Physical details and identifying marks
• date_found: Date of discovery
• location: Place where item was found
• status: Current state (active/returned)
• created_at: Submission timestamp

Appendix C: System Workflow Summary

The system follows a basic flow:
1. User registers and logs in using secure credentials.
2. Session is created to maintain authentication.
3. User can report either a lost item or a found item.
4. Data is validated on both client and server sides.
5. Valid records are stored in the database.
6. All active records are displayed on a common listing page.
7. Users can search items using keywords.
8. Admin manages and removes resolved or invalid entries.

Appendix D: Key Security Measures

The system implements basic security practices to protect user data:
• Passwords are stored in hashed format (not plain text)
• SQL queries are executed using prepared statements
• Session management is used for login control
• Input validation is applied on both frontend and backend
• Restricted pages are protected from unauthorized access

47
G5
ORIGINALITY REPORT

8 %
SIMILARITY INDEX
8%
INTERNET SOURCES
2%
PUBLICATIONS
%
STUDENT PAPERS

PRIMARY SOURCES

1
[Link]
Internet Source 1%
2
[Link]
Internet Source 1%
3
[Link]
Internet Source <1%
4
[Link]
Internet Source <1%
5
[Link]
Internet Source <1%
6
[Link]
Internet Source <1%
7
[Link]
Internet Source <1%

<1%
[Link]
8 Internet Source

9
[Link]
Internet Source <1%
48
10
[Link]
Internet Source <1%
11
[Link]
Internet Source <1%
12
[Link]
Internet Source <1%
13
[Link]
Internet Source <1%
14
[Link]
Internet Source <1%
15
[Link]
Internet Source <1%
16
[Link]
Internet Source <1%
17
[Link]
Internet Source <1%
18
[Link]
Internet Source <1%
19
[Link]
Internet Source <1%
20
[Link]
Internet Source <1%
21
K. V. Sambasivarao, Anasuya Sesha Roopa
Devi Bhima. "Artificial Intelligence,
<1%
49
 Computational Intelligence, and Inclusive
Technologies - Proceedings of International
Conference on Artificial Intelligence,
Computational Intelligence, and Inclusive
Technologies (ICRAIC2IT – 2025)", CRC Press,
2026
Publication

22
[Link]
Internet Source <1%
23
[Link]
Internet Source <1%
24
[Link]
Internet Source <1%
25
[Link]
Internet Source <1%
26
[Link]
Internet Source <1%
27
[Link]
Internet Source <1%
28
[Link]
Internet Source <1%
29
[Link]
Internet Source <1%
30
[Link]
Internet Source <1%
50
31
[Link]
Internet Source <1%
32
[Link]
Internet Source <1%
33
[Link]
Internet Source <1%
34
[Link]
Internet Source <1%
35
[Link]
Internet Source <1%
36
[Link]
Internet Source <1%
37
[Link]
Internet Source <1%
38
[Link]
Internet Source <1%
39
[Link]
Internet Source <1%
40
[Link]
Internet Source <1%
41
[Link]
Internet Source <1%
42
[Link]
Internet Source <1%
51
43
[Link]
Internet Source <1%
44
[Link]
Internet Source <1%
45
[Link]
Internet Source <1%
46
[Link]
Internet Source <1%
47
[Link]
Internet Source <1%
48
Costa, Gui Botelho Silva. "Plataforma de
Estágios @DEI v2", Universidade de Coimbra
<1%
(Portugal)
Publication

49
[Link]
Internet Source <1%
50
[Link]
Internet Source <1%
51
[Link]
Internet Source <1%
52
[Link]
Internet Source <1%
53
Alves, Eduardo Miguel Ferreira. "Interactive
Computer Assisted Diagnosis System for
<1%
52
 Gastroenterology", Universidade do Porto
(Portugal), 2024
Publication

54
Vincenza Cofini, Laura Piccardi, Eugenio
Benvenuti, Ginevra Di Pangrazio et al. "The I-
<1%
KAPCAM-AI-Q: A Novel Instrument for
Evaluating Health Care Providers' AI
Awareness in Italy", Cold Spring Harbor
Laboratory, 2025
Publication

Exclude quotes Off Exclude matches Off

Exclude bibliography Off

53