UCS503- Software Engineering Lab
Lost and Found Application
UCS-503 Software Engineering Project Report
Mid-Semester Evaluation
Submitted by:
102303821 - Ritvik Bajaj
102303832 - Aryan Sirohi
102303833 - Aksh Khurana
BE Third Year, COE
Group No : 3 (3C61)
Submitted to : Ms. Damini Arora
Computer Science and Engineering Department
TIET, Patiala
Table of Contents
S. No. Assigments Page No.
1. Project Selection Phase
1.1. Software Bid 3
1.2. Project Overview 4-10
2. Analysis Phase
2.1 Use Cases 11-12
2.1.1 Use-Case Diagrams 14
2.1.2 Use Case Templates 15
2.2 Activity Diagram and 17-19
Swimlane Diagrams
2.3 Data Flow Diagrams 19-21
(DFDs)
2.3.1 DFD Level 0 19
2.3.2 DFD Level 1 20
2.3.2 DFD Level 2 21
2.4 Software Requirement 27-36
Specification in IEEE
Format
2.5 User Stories and Story 22-27
Cards
Software Bid/ Project Teams
UCS 503- Software Engineering Lab
Group : 3C61 Dated: 09-10-2025
Team Name:
Team ID (will be assigned by Instructor): 3
Please enter the names of your Preferred Team Members. : Ritvik Bajaj, Aryan Sirohi, Aksh Khurana
· You are required to form a three to four person teams
· Choose your team members wisely. You will not be allowed to change teams.
Name Roll No Project Experience Programming Signature
Language used
Ritvik Bajaj 102303821 Offline simulation of ritvik
nukemap typescript,javascri
pt
Aksh 102303833 Tiet-pyq-parser Typescript, aksh
Khurana [Link], Python
Aryan Sirohi 102303832
Programming Language / Environment Experience - C++, Typescript, Javascript, [Link]
List the languages you are most comfortable developing in, as a team, in your order of preference. Many
of the projects involve Java or C/C++ programming.
1. C++
2. Typescript
Project Overview
This project is a web-based Lost and Found system designed specifically for college students,
integrating concepts from database management, web development, and software engineering. The
platform features a secure login system that ensures only authorized students can access personalized
functionalities. It provides two main directories: the Found List and the Lost Item Directory. In the
Found List, students who come across lost belongings can upload item details such as their roll
number, hostel name, mobile number, and a photograph of the found item. Meanwhile, the Lost Item
Directory allows students who have lost belongings to submit reports describing their missing items.
The system supports real-time updates, enabling item owners to regularly check the "Found Items"
page for potential matches. All data is stored within a centralized database, ensuring efficient
management, tracking, and retrieval of lost and found reports. This design aims to streamline the
recovery process, reducing confusion and delays by providing a user-friendly, accessible online
platform that directly connects finders with owners.
The technologies and languages used for this project include MySQL for implementing the database,
TypeScript for scripting and type safety, and React for building the dynamic user interface. The
software development follows the Agile model, promoting iterative progress, flexibility, and
collaboration throughout the development cycle.
The novelty of this project lies in addressing a gap that currently exists within the college. There is no
dedicated website to manage lost and found items, and the existing system is inefficient — lost item
lists are simply emailed to all students, leading to unnecessary notifications and confusion. Moreover,
there is no centralized entry log where students can check the current status of their lost belongings,
nor an easy way for the finder to contact the owner. This project solves those issues by introducing a
dedicated platform that facilitates direct communication only between the finder and the rightful
owner. It also introduces separate entry logs for both lost and found items, ensuring better
organization. Finders can provide their hostel room number, roll number, and phone number, allowing
quick and secure contact.
The objectives of this project include developing a secure login system for students to ensure
authorized access, and creating an intuitive interface where users can easily report found items by
uploading necessary details like roll number, hostel name, and contact information along with images.
The system will also allow students to submit lost item reports containing identifying details of their
belongings. Another objective is to design and integrate a reliable database to store, manage, and
retrieve lost and found item records efficiently. The project further aims to facilitate quick and
effective communication between finders and owners, offer a responsive and user-friendly web
interface accessible on desktops, tablets, and smartphones, and ultimately reduce the time and effort
required to recover lost items on campus through an organized, automated system.
Methodology
The development of the Lost and Found system followed a structured methodology consisting of six
key phases to ensure efficiency, reliability, and user satisfaction.
1. Requirement Gathering & Analysis
The process began with extensive discussions involving students, hostel wardens, and faculty
members to identify the current challenges in reporting lost and found items. Through this
consultation, the team identified the core needs of the system, including a secure login feature, item
submission forms, image upload capabilities, and an efficient search function. Constraints such as
maintaining a simple and intuitive interface, minimizing personal data collection, and ensuring low
maintenance requirements were also finalized during this phase.
2. System Design
In the design stage, Data Flow Diagrams (DFDs) were created to visualize the movement of
data—specifically lost and found reports—between users, the database, and administrators.
Entity–Relationship (ER) diagrams were developed to represent the relationships between core
entities like Students, Items, Lost Reports, and Found Reports. Additionally, UI/UX wireframes were
designed for essential pages such as Login, Lost Report Submission, Found Report Submission, and
Search Results to ensure a user-friendly experience.
3. Technology Selection
A combination of modern and efficient technologies was chosen to build the system. The frontend
would be developed using HTML, CSS, and JavaScript, with the option of using frameworks such as
Angular or React for scalability. The backend could utilize [Link] with Express or PHP with Laravel,
depending on institutional preferences. The database layer was designed using MySQL or
PostgreSQL for reliable, structured data management. Image handling was planned through cloud
storage or a college server with compression capabilities to optimize space and performance. For
authentication, the system employs the student’s roll number paired with a password or a one-time
password (OTP) mechanism to ensure secure access.
4. Development Phase
During the development phase, individual user modules were implemented, including Login, Lost
Report Submission, Found Report Submission, and Search/Browse functionalities. Image upload and
validation mechanisms were integrated to support visual identification of items. An administrative
dashboard was also developed for content moderation and management. Privacy measures were
prioritized, with sensitive details such as mobile numbers masked by default until direct
communication was necessary.
5. Testing & Quality Assurance
The testing phase involved several levels of quality assurance. Unit tests were conducted for database
functions, form submissions, and authentication procedures. Integration testing verified that different
system components worked seamlessly together, following workflows such as the process of
submitting a lost item, finding a match, and claiming the item. Security testing was carried out to
prevent invalid inputs, fake reports, and unauthorized access. Finally, usability testing was conducted
with a small group of students to gather feedback and ensure an intuitive user experience.
6. Deployment & Maintenance
Upon completion, the system was deployed on a secure college server or cloud platform equipped
with SSL encryption for data protection. Regular database and image backups were scheduled to
prevent data loss. Training documents were provided to student moderators and administrators for
efficient system management. A feedback mechanism was also established to continuously improve
the platform based on user input and evolving needs.
Feasibility Study
The feasibility study for the Lost and Found system evaluates its practicality and sustainability from
multiple perspectives, ensuring that the project is technically achievable, economically viable, and
socially beneficial.
1. Technical Feasibility
The technical feasibility of this project is highly favorable, as it relies on readily available
technologies. The platform can be developed using common web technologies such as HTML, CSS,
and JavaScript for the frontend, and frameworks like [Link], PHP, or Django for the backend.
Database management will be handled by MySQL or PostgreSQL, providing efficient structured data
storage for student and item details.
In terms of infrastructure, the system can be operated using standard college computers, smartphones,
and basic internet access, making it easily deployable in a typical campus environment. Image uploads
may be stored either on college servers or low-cost cloud storage services. The project’s ease of
development and maintenance is enhanced by the use of open-source tools, reducing costs and
external dependencies. Moreover, student developers, with faculty guidance, can manage both
development and upkeep. The system is also sustainable, as it requires no specialized hardware and
can be easily scaled up as adoption increases across the campus.
2. Managerial Feasibility
From a managerial perspective, the project can be efficiently overseen by the college’s IT department
or a student technical society operating under faculty supervision. The moderation process ensures
that all posts are authentic and appropriate—administrators can verify submissions and remove any
spam or misleading content. Posting guidelines, including mandatory details such as roll number,
hostel information, and item photos, further prevent misuse.
The system significantly improves process efficiency by automating many of the manual tasks
currently performed by hostel wardens and security staff. Tracking and managing lost and found
reports becomes structured and transparent. Additionally, the management of the system requires
minimal ongoing effort and can be easily integrated into the college’s existing student support
frameworks.
3. Economic Feasibility
Economically, the project is both low-cost and resource-efficient. It utilizes free and open-source
technologies such as MySQL, PHP, [Link], React, or Angular, eliminating the need for expensive
software licenses. Hosting can be managed on college-owned servers to further reduce costs. The
system relies primarily on existing infrastructure and student skills, limiting the need for external
investment.
The economic benefits of the system are significant—it saves time and effort for both students and
administrators while reducing the cost associated with printing physical notices or manually managing
reports. In a cost-benefit analysis, the advantages of increased efficiency, better communication, and
improved student satisfaction far outweigh the minimal development and operational expenses.
4. Financial Feasibility
The financial feasibility of the project is strong, requiring only modest initial investment. Basic
expenses may include domain registration, hosting charges (if college servers are not used), and small
costs related to cloud storage or image management. Funding can be sourced from the college IT
budget, student activity funds, or contributions from technical societies.
Recurring costs are minimal, covering periodic database backups, software updates, and minor
maintenance activities. The return on investment (ROI) is primarily non-monetary, reflected in higher
student satisfaction, improved community trust, and a reduction in administrative complaints. Given
its low operational costs, the financial risks associated with this system are negligible.
5. Cultural Feasibility
Culturally, the project aligns perfectly with the values of the college community. It reinforces
principles such as honesty, cooperation, and mutual trust. Since students are already familiar with
informal lost-and-found practices, the transition to a formalized, digital system is expected to be
smooth.
The platform encourages positive behavior by recognizing students who report found items and
promotes accountability among users. It also respects privacy by ensuring that sensitive information,
such as mobile numbers, remains masked or is shared only with user consent. Overall, the system
fosters a responsible and trustworthy campus culture.
6. Social Feasibility
Socially, the Lost and Found system has a positive impact on the campus community. It helps
strengthen relationships among students by fostering a culture of support and cooperation. The
platform reduces confusion and disputes related to lost belongings by maintaining a transparent and
accessible record of reports.
Accessibility and inclusivity are key priorities—the interface is designed to be simple and
mobile-friendly, ensuring that all students can easily use it regardless of technical expertise.
Accountability measures, such as linking reports to student roll numbers and hostel details, enhance
authenticity and discourage fake or prank submissions. The overall perception of the platform is that it
is a student-friendly initiative that reduces stress and enhances trust within the campus environment.
7. Safety Feasibility
Safety is a central consideration in the system’s design. Data security is ensured through secure login
protocols and password encryption methods such as bcrypt or Argon2. Personal information like
phone numbers is masked to prevent misuse. The system also includes measures such as input
validation to prevent malicious uploads and SQL injection attacks, while administrators have the
authority to remove harmful or inappropriate content immediately.
From an environmental perspective, the platform supports sustainability by reducing reliance on
physical notice boards and printed materials. It operates safely and efficiently without causing any
adverse impact on students or the college’s infrastructure.
8. Political Feasibility
The project is fully aligned with institutional and administrative goals. It supports college policies
promoting student welfare and efficient administration and can be formally endorsed by authorities to
gain broader legitimacy. The system complies with IT policies, data privacy regulations, and general
campus rules.
Administratively, it provides tangible benefits by helping hostel and security staff manage lost and
found cases more efficiently. There are no conflicts with external or governmental policies; instead,
the initiative demonstrates a proactive approach to student welfare, enhancing the college’s reputation
as a forward-thinking institution.
Overall, the feasibility study demonstrates that the Lost and Found system is technically sound,
economically practical, culturally acceptable, and institutionally supported. It offers a low-cost,
sustainable, and student-centric solution to an everyday problem, aligning perfectly with the college’s
vision of digital transformation and community well-being.
Project Outcomes
1. Centralized Lost & Found Portal
The final outcome is a unified platform where students can easily report and track lost or found items.
This eliminates dependence on outdated physical notice boards or informal word-of-mouth
communication, ensuring faster and more reliable item recovery.
2. Improved Efficiency
The system significantly enhances operational efficiency by providing searchable digital records that
streamline the process of locating lost belongings. It also reduces the administrative workload for
hostel wardens and campus security personnel.
3. Enhanced Student Satisfaction
Students benefit from a structured, trustworthy mechanism to recover their lost possessions. This
fosters confidence in the system and promotes a stronger sense of trust and cooperation across the
campus community.
4. Privacy & Security Protection
The platform is designed with strong privacy measures. Personal information such as mobile numbers
remains masked by default to minimize misuse. The secure login ensures that only verified students
can post or view lost and found reports.
5. Accountability & Transparency
Each submission is linked to a student’s roll number, which enhances the authenticity of reports. The
inclusion of moderation tools ensures transparency and prevents the posting of fake or irrelevant
content.
6. Sustainable & Cost-Effective Solution
The project emphasizes sustainability by leveraging open-source software and student developers,
keeping costs low. Additionally, the system is environmentally friendly, reducing paper usage
associated with traditional notice-based approaches.
7. Long-Term Benefits
In the long run, the system can be expanded with advanced features such as automated matching
between lost and found reports, email or SMS notifications, and analytics to track frequently lost
items. This project strengthens the digital infrastructure of the college and serves as a scalable model
that other institutions can adopt for similar purposes.
Analysis Phase
2.1. Use Cases
UC1 — Register
● Actor: Visitor
● Trigger: Fill & submit signup form
● Outcome: Account created (email verified). Alt: invalid fields → error + retry.
UC2 — Login
● Actor: Registered user
● Trigger: Submit credentials
● Outcome: Session created, routed to dashboard. Alt: bad creds → error.
UC3 — Register Lost Item
● Actor: Owner (logged in)
● Trigger: “Report Lost Item”
● Outcome: Lost post saved (title, desc, location, time, photos); visible/searchable.
UC4 — Register Found Item
● Actor: Finder (logged in)
● Trigger: “Report Found Item”
● Outcome: Found post saved (details + photos); listed for matching.
UC5 — View Status
● Actor: Any logged-in user
● Trigger: Open “My Posts/Status”
● Outcome: See each post status (Published/Matched/Closed).
UC6 — Contact (Chat / Mobile Number)
● Actor: Owner ↔ Finder
● Trigger: Click “Contact/Chat” on a post
● Outcome: Start chat or view contact number; messages persisted. Alt: blocked → denied.
UC7 — Give Feedback
● Actor: Logged-in user
● Trigger: Submit rating/comment after resolution
● Outcome: Feedback stored and tied to post.
UC8 — Navigate (to handover point)
● Actor: Owner/Finder
● Trigger: Click “Navigate/ Directions” on a post/contact
● Outcome: Opens map link to agreed location.
UC9 — Account Settings (Update / Delete)
● Actor: Logged-in user
● Trigger: Open “Account Settings”
● Outcome: Update profile (name, photo, mobile) or delete account (soft delete). Alt: validation error →
retry.
UC10 — Search by Category
● Actor: Any user (visitor allowed)
● Trigger: Choose category / apply filters
● Outcome: Paginated results by category with thumbnails.
UC11 — View History
● Actor: Logged-in user
● Trigger: Open “History”
● Outcome: See past posts, claims, chats; can reopen or archive.
2.1.2. Use-Case Diagrams
2.1.3. Use-Case Templates
Element Detail
Name Report Lost Item
ID LF-UC-009
Description Allows an authenticated user to submit details about an item they have lost, including a
detailed description, the last known location, and the date it was lost. This action
populates the central database of lost items.
Actors Student, Teaching Staff, Non-Teaching/Administrative Staff, Security Personnel
Organization Provides owners with a formal, tracked way to report their lost belongings, increasing
Benefits the chance of recovery; contributes data for the notification system.
Frequency of Use Variable, expected to be moderate to high across the community.
Triggers User has lost an item and clicks the "Report Lost Item" link/button on the dashboard
or main navigation.
Preconditions The user is logged into the Lost and Found system; The system's database connection
is stable and available for writing.
Postconditions Lost item details are successfully saved to the MongoDB database; The item is
visible in real-time on the "Lost Items" browse page; Notification checks are
triggered against existing found items.
Main Course 1. The user navigates to the "Report Lost Item" page. 2. The system displays the item
submission form. 3. The user fills in all required fields: - Item Name/Title
- Detailed Description of the item (and any unique identifiers) - Last
Known Location/Area Lost - Date Lost 4. The user may optionally upload an
image of the item (if they have one). 5. The user clicks the "Submit Report" button.
6. The system validates all required input fields. 7. The system saves the item details
(and optional image) to the database. 8. The system displays a confirmation message:
"Lost item successfully reported. We will notify you if a match is found." 9. The
system redirects the user to the "Lost Items" browse page.
Alternate Course AC1: <User submits with an invalid date format> 1. The system detects an invalid
date format for "Date Lost" (Step 6 of Main Course). 2. The system prevents
submission and displays an error message: "Please enter a valid date in
DD/MM/YYYY format." 3. The user corrects the date and returns to Step 5 of the
Main Course.
Exception EX1: <Server or database timeout> 1. The system's backend ([Link]) exceeds the
Courses timeout limit while attempting to save the data to the database (Step 7 of Main Course).
2. The system displays an error message: "Request Timeout. The server is busy, please
check your network connection and try submitting again." 3. The system logs the
timeout error. EX2: <User is not authorized (Session expired)> 1. The user's session
token is found to be expired or invalid during submission (Step 6 of Main Course). 2.
The system immediately stops the submission process and forces a redirect to the Log
In/Sign Up (LF-UC-001) page. 3. The system displays a message: "Your session has
expired. Please log in again."
2.2 Activity Diagram and Swimlane Diagrams
● User-Level Workflow
● Registered User Workflow (Post Management Flow)
● Admin Workflow (Moderation / Verification Flow)
DATA FLOW DIGRAMS
LEVEL 0
LEVEL 1
LEVEL 2
USER STORIES AND CARDS
1. To Login to the system Safely
FRONT OF THE CARD
BACK OF THE CARD
2 To File a Lost Item Report
FRONT OF THE CARD
BACK OF THE CARD
3. To Review and Resolve Lost Items Complaint
FRONT OF THE CARD
BACK OF THE CARD
Lost & Found Campus System: Architecture and
Prototype for Rapid Item Recovery
Aksh, Aryan, Ritvik
CS / Thapar University
Abstract—
This paper presents an IEEE-style overview of the Software Requirements Specification (SRS) for a
campus-oriented Lost & Found web application. The system enables secure user authentication, real‑time
posting and browsing of lost/found items with images, and notifications for potential matches. We outline the
scope, architecture, functional capabilities, user characteristics, constraints, and staged roadmap.
Keywords—Lost and found, campus platform, SRS, web application, notifications, React, [Link], MongoDB.
I. INTRODUCTION · Search and filter by category, location, and
date range.
The Lost & Found website provides a centralized,
community-driven service to report and locate · Direct communication (chat) between
belongings within a campus. Users may post items owner and finder (socket-based).
they have lost or found, browse listings, and
contact each other to facilitate returns. · Notifications when new posts match saved
lost-item descriptions.
Purpose: Document the functional and
non-functional requirements that guide design, IV. USER CHARACTERISTICS
development, and verification. Scope: Authorized
users upload found items; owners monitor updates Target users include Students, Teaching Staff,
and receive notifications about potential matches. Administrative Staff, Security Personnel, and
System Administrators. Users are assumed to be
II. SYSTEM PERSPECTIVE browser-literate and able to upload images, enter
text, and apply filters; the system emphasizes
The application is a standalone web system using accessibility and simplicity.
[Link] (frontend), [Link] (backend), and
MongoDB (data store). It replaces manual V. CONSTRAINTS, ASSUMPTIONS, AND
processes with a secure, browser-based experience DEPENDENCIES
and lays groundwork for mobile and AI-assisted
search. Constraints:
III. PRODUCT FUNCTIONS · Stable internet connection and modern
browser required.
· Secure authentication and authorization
for user actions. · Enforce security/privacy: authenticated
access for privileged actions; protection of
· Create and manage lost/found posts with personal data.
images, descriptions, location, and
timestamps. Assumptions:
· Real-time visibility of new/updated posts · Users provide accurate item descriptions
for timely discovery. and images.
· Active community participation ensures VI. DEVELOPMENT APPROACH AND
timely reporting and discovery. FUTURE ENHANCEMENTS
Dependencies: Phase 1 delivers core capabilities—authentication,
post creation/browsing, and real-time persistence.
· [Link] frontend, [Link] backend, Subsequent phases add notifications, chat,
MongoDB database. location-based filtering, mobile apps, AI-assisted
matching, and enhanced admin tooling.
· Socket server and notification service for
real-time features.
· Hosting/CDN for image storage and
delivery.
REFERENCES. REFERENCES
[1] GeeksforGeeks, "Software Requirement Specification (SRS) Format,"
[Link]
[2] EITCA Academy, "Introduction to MySQL for Web Development,"
[Link]
[3] MySQL Docs, "Getting Started," [Link]
2. Overall Description uploading images, descriptions, and location
information. Submitted entries are stored in the
2.1 Product Perspective database and displayed in real time for other users
to browse, making it easier to identify and claim
The Lost and Found system is a standalone web belongings such as calculators, bags, and other
application developed using [Link] for the personal items. The platform also integrates a
frontend, [Link] for the backend, and MongoDB socket-based chat feature that enables direct
for data storage. It replaces traditional manual communication between the finder and the owner,
methods of managing lost and found items by improving coordination and trust in the recovery
providing a centralized, secure, and real-time process. Notifications and search functionalities
platform accessible through any modern web ensure that users are promptly informed when
browser. The system supports both users who have items matching their descriptions are reported.
lost belongings and those who have found items,
enabling them to upload details, search records, and
receive notifications through an intuitive interface.
Designed with modern UI libraries, the platform 2.3 User Characteristics
ensures ease of use and cross-device accessibility,
The goal is to design software for a campus-based
while also laying the foundation for future
Lost and Found System that can be accessed and
enhancements such as mobile app integration and
used by different categories of users. These user
AI-based search.
types are listed below as follows:
1. Student
2.2 Product Functions
2. Teaching Staff
The Lost and Found system allows users to log in
3. Non-Teaching/Administrative Staff
and submit details of lost or found items by
4. Security Personnel
5. System Administrator 2.5 Apportioning of the Requirements
As one can see from the list, each user will have a In the initial release of the Lost and Found system,
different background and expertise level in using the focus will be on implementing the core
the system. Our goal is to develop software that functionalities: secure user authentication, posting
should be easy to use for all types of users, and browsing lost or found items with images and
including those with minimal technical knowledge. descriptions, and maintaining a real-time database
Thus, while designing the software one can assume of entries. Advanced features such as socket-based
that each user type has the following real-time chat, notification systems, and
characteristics: location-based filtering will be deferred to later
phases once the basic platform is stable and
● The user is computer-literate and has little thoroughly tested. Future versions may also include
or no difficulty in operating a web browser mobile application support, AI-assisted item
or mobile application. matching, and enhanced administrative tools for
● The user is not required to understand the system monitoring and management. This staged
internal working of the database or approach ensures a reliable foundation while
backend technologies, but is expected to leaving room for scalability and incremental
know how to upload an image, enter text improvements.
details, or search for items using the
provided interface.
● The system should be intuitive enough for
all categories of users, ensuring
accessibility and usability regardless of
their technical expertise.
2.4 General Constraints, Assumptions, and
Dependencies
The Lost and Found system is designed as a web
application and therefore depends on stable internet
connectivity and access to a modern web browser.
It is constrained by the security requirements of
user authentication and data protection, ensuring
that only authorized users within the campus
community can post or interact with items. The
system assumes that users will provide accurate
descriptions, images, and location details for lost or
found items to enable effective matching. It also
assumes active participation from the community,
as the effectiveness of the platform relies on timely
reporting and searching of items. The application
depends on the proper functioning of its underlying
technologies, including [Link] for the frontend,
[Link] for the backend, MongoDB for data
storage, and socket-based communication for
real-time chat. Any failures or limitations in these
technologies, or in the hosting environment, may
directly affect system performance and availability.
3. Specific Requirements
3.1.3 Software Interface
3.1 External Interface Requirements
The system will interact with a MySQL / Oracle /
3.1.1 User Interface PostgreSQL database to store user and item
[Link] backend will be built using PL/SQL /
The system will have a web-based graphical user Java / Python / PHP (depending on our
interface accessible through standard web stack).Compatible browsers include Chrome,
[Link] can log in as a student, staff, or Firefox, and Edge.
administrator.
3.2 Detailed Description Of Functional
● The interface will contain: Requirements
○ A login screen with username 3.2.1 Functional Requirements for Student
and password fields. Welcome Screen
○ A registration form for new 1. The system shall allow students to log in
users. using registered credentials.
○ Navigation menus for filing 2. The system shall allow students to report a
complaints, searching lost/found lost item by filling a form containing item
items, viewing status, and name, description, date, location, and
contacting administrators. contact details.
○ Responsive design for desktops 3. The system shall allow students to view
and mobile devices. all found items uploaded by others.
4. The system shall allow students to search
3.1.2 Hardware Interface for an item using filters such as category,
date, or location.
The system shall operate on standard computing
devices with a stable internet [Link] special 5. The system shall allow students to track
hardware interfaces are [Link] terms of the status of their complaints (e.g., “Under
hardware, the system does not require any review”, “Resolved”).
specialized devices. It can be operated on standard
computers, laptops, or smartphones with a stable 6. The system shall allow students to edit or
internet connection. The software interface will withdraw their submitted complaint.
integrate with a backend database (for instance,
MySQL, Oracle, or PostgreSQL) that securely 7. The system shall allow students to view
stores user and item data. The system will support notifications or messages from the admin
backend technologies such as PL/SQL, PHP, Java, regarding their case.
or Python depending on deployment.
3.2.2 Functional Requirements for Staff
Welcome Screen
1. The system shall allow staff to log in and
manage their assigned complaints.
2. The staff shall be able to verify item
ownership based on submitted evidence or
description.
3.3 Performance Requirements
3. The staff shall be able to update complaint
The Lost and Found Management System should
status (e.g., “In process”, “Resolved”).
be optimized for performance to ensure quick
response times and stable operation even during
4. The staff shall be able to mark items as
found and return them after verification. heavy usage. The system shall support at least 50
concurrent users without noticeable delays.
5. The staff shall have access to view all Standard actions such as login, item search, or
complaints and filter them by category, complaint submission should have an average
date, or reporter. response time of under three seconds. Database
queries will be carefully designed and indexed to
6. The staff shall be able to send prevent unnecessary load or latency.
confirmation messages to users upon
resolution. The platform should maintain a minimum of 99%
uptime during operational hours, ensuring
uninterrupted service for users.
3.2.3 Functional Requirements for Student
cum Staff Welcome Screen
1. The system shall support at least 50
(This applies to users who can act as both — for concurrent users without performance
example, a faculty member who may also lose degradation.
items.)
2. Average response time for user actions
1. The system shall allow these users to (login, search, complaint filing) shall be
switch roles (Student/Staff) after logging under 3 seconds.
in.
3. Database queries shall be optimized to
2. In Student mode, they shall have all prevent delays in item retrieval or updates.
privileges of a student user.
4. The system shall maintain 99% uptime
3. In Staff mode, they shall have access to during operational hours.
complaint verification and status
management. 5. The system shall automatically log out
inactive users after 10 minutes of
4. The system shall maintain separate logs inactivity.
for each role’s actions.
5. The interface shall dynamically change
based on selected role.
3.4 Logical Database Requirements
The database is central to the system’s
functionality. It shall contain all records related to
users, items, complaints, and notifications. Major
entities include Users, Items, Complaints, and
Notifications, each uniquely identified by a
primary key. For example, the Users table may
include fields such as user_id, name, email, role,
and contact number. The Items table will store The quality of the system depends on several
details like item_id, name, category, date, location, non-functional characteristics. Reliability is
and reporter_id, while the Complaints table will ensured by designing robust error-handling
link users and items through foreign keys, mechanisms that prevent data loss or corruption
maintaining referential integrity. during failures. Usability is a key focus; the
interface will be designed with clarity and
All passwords will be stored in a hashed format to accessibility in mind, featuring intuitive navigation
ensure data security. The system shall also and context-sensitive help [Link] will be
implement transactional integrity to handle maintained through role-based authentication,
operations like complaint filing or resolution as encrypted password storage, and secure data
atomic transactions — ensuring that no partial or transmission using HTTPS. The maintainability of
inconsistent data is stored in the database. Regular the system will be supported through modular code
data backups will be taken to prevent loss in case of design, making future updates or bug fixes simpler.
system failure.
1. Reliability: The system shall handle
1. The database shall maintain the following unexpected failures without data
major tables: corruption.
○ Users: user_id, name, email, role, 2. Usability: Interfaces shall be intuitive,
password, contact_no. with clear navigation and helpful prompts.
○ Items: item_id, name, 3. Security: All passwords and sensitive
description, category, data shall be encrypted. Access control
date_lost_found, location, shall be enforced by user role.
reporter_id, status.
4. Maintainability: Code shall be modular
○ Complaints: complaint_id, to allow easy updates and debugging.
user_id, item_id, complaint_type,
description, date_filed, status. 5. Portability: The application shall run on
any OS supporting modern browsers.
○ Notifications: notification_id,
user_id, message, date_sent. 6. Scalability: The system shall be scalable
to accommodate future users or
2. Each record shall have a primary key and institutions.
referential integrity maintained using
foreign keys.
3. Passwords shall be hashed and stored 3.6 Other Requirements
securely.
The Lost and Found Management System must
4. The database shall support transactional comply with the institution’s IT policies, ensuring
integrity for operations like complaint that user data is handled responsibly and privacy is
filing and resolution. maintained. All user activities — including logins,
complaint filings, and administrative actions —
5. Backups shall be taken periodically to will be logged for audit and security purposes.
prevent data loss.
The system should also send email or in-app
notifications to inform users about updates such as
3.5 Quality Attributes complaint resolution or verification messages.
Administrators will possess full privileges to add or
remove users, manage existing complaints, and
generate system reports. Optionally, the interface
may support additional accessibility features such
as a dark mode or adjustable text sizes to enhance
the user experience.
1. The system shall comply with institutional
IT policies and privacy guidelines.
2. The system shall log all user activities for
audit purposes.
3. The system should send email or
dashboard alerts for status updates.
4. The admin shall have full authority to
add/remove users, manage complaints,
and generate reports.
5. The interface should support both dark
and light modes (optional).