SYSTEM REQUIREMENTS SPECIFICATION (SRS)

FINDERR MOBILE APPLICATION

Supervisor

Miss Iqra Iqbal

Submitted by

Mubashir Saleem (MTF2201005)

H. Zeeshan Shahzad (MTF2200979)
Gohar Ali Shah (MTF2200995)

Department of Information Sciences,

University of Education, Lahore.

[02nd Jan 2023]

 SYSTEM REQUIREMENTS SPECIFICATION (SRS)

FINDER MOBILE APPLICATION

POST-ADP-IT (5TH SEMESTER) 2023

A project submitted in partial fulfilment of the requirements for the award of the degree
of Post-ADP-IT.

DIVISION OF SCIENCE AND TECHNOLOGY, TOWNSHIP CAMPUS

UNIVERSITY OF EDUCATION
LAHORE
JANUARY 2023
 DECLARATION

I declare that this project title entitled “Finderr Mobile Application” is the result of my own research
and development except as cited in the references. This project has not been accepted for any degree and
is not concurrently submitted by a candidate for any other degree. At any time if my statement is found
to be incorrect even afterwards Post-ADP-IT, the university has the right to withdraw my degree.

Signature: _________________
Name: MUBASHIR SALEEM
Date: January 02, 2023

Signature: _________________
Name: H. ZEESHAN SHAHZAD
Date: January 02, 2023

Signature: _________________
Name: GOHAR ALI SHAH
Date: January 02, 2023
 PLAGIARISM UNDERTAKEN

I solemnly declare that the project work presented in this documentation entitles “Finderr Mobile
Application” is solely my work with no significant contribution from any other person. Small
contribution/help wherever taken has been acknowledged and that complete project has been written by
me.
I understand the zero-tolerance policy of the HEC and the University of Education, Lahore towards
plagiarism. Therefore, we as the author of the above-titled project declare that no portion of my project
documentation and any material used as reference is properly referred to / cited.
I undertake that if I am found guilty of any formal plagiarism in the above-titled project even after the
award of the Post-ADP-IT degree, the University reserves the right to withdraw/revoke my degree and
that HEC and the University have the right to publish my name on the HEC/University Website on
which names of students are placed who submitted plagiarized projects.

Signature: _________________
Name: MUBASHIR SALEEM
Date: January 02, 2023

Signature: _________________
Name: H. ZEESHAN SHAHZAD
Date: January 02, 2023

Signature: _________________
Name: GOHAR ALI SHAH
Date: January 02, 2023
 CERTIFICATE OF APPROVAL

This is to certify that the project work presented in this document entitled, “Finderr Mobile
Application”, was conducted by “H. Zeeshan Shahzad”, “Gohar Ali Shah”, and “Mubashir Saleem”,
under the supervision of “Ms Iqra Iqbal”. No part of this project has been submitted anywhere else for
any degree. This project is submitted to the “Division of Science and Technology, Township Campus,
University of Education” and is a partial fulfilment of the requirements of the degree of Post associate
degree in Information Technology.

Signature: _________________
Name: MUBASHIR SALEEM
Date: January 02, 2023

Signature: _________________
Name: H. ZEESHAN SHAHZAD
Date: January 02, 2023

Signature: _________________
Name: GOHAR ALI SHAH
Date: January 02, 2023
 Table of Contents

Title and Description:

• Inner Title Page

• Statement of Submission
• Declaration
• Plagiarism undertaken
• Certificate of Approval

CHAPTER NO. 1: Gathering and Analyzing Information

• Introduction
• Objectives
• Purpose
• Problem Statement
• Project Scope

CHAPTER NO. 2: Software Requirement Specification

• Stakeholders Characteristics
• Domain Requirements
• Functional Requirements
• Non-Functional Requirements

CHAPTER NO. 3: Analysis

• Use Case Description

• Use Case Diagrams

CHAPTER NO. 4: Design [with Description of each diagram]

• Sequence Diagram
• Class Diagram

CHAPTER NO. 5: Graphical User Interface (UX/UI)

• Application’s Prototype (Mobile Application)

 Software Requirement Specification

➢ CHAPTER NO. 1: Gathering and Analyzing Information

INTRODUCTION

These days many of us lose our valuable items but no such proper platform is available for returning
these lost items. So, it is mandatory to develop a system that can help to overcome these problems. This
project is helpful because there is no proper tracking of lost item in our country. As this system’s
functionality is described here, whenever a person will lose their item, first of all he will get register on
the App and after successful login a form will appear for describing their lost item after filling and
adding location of lost item their ad of lost item will go live. Highlights of that item will also appear on
main page.

OBJECTIVES

Our goal is to return the owners their lost items. As of now there is very little development of such type
so we have developed an application that ease out the whole process of finding the lost items. We have
made an android application because this platforms are very common and easily accessible these days.
We have developed this application to provide a very basic and easy to use, user interface so that every
person can easily use the application. Every lost item will be shown in the highlights on the main app
page.

Purpose
The purpose of this document is to give a detailed description of the Software requirement for the "Lost
and found App" This Requirements Specification provides a complete description of all the functions
and specifications of Computer Science and Information Technology. It will illustrate the purpose and
complete declaration for the development system, it will also explain system constraints, and interface.

PROBLEM STATEMENT

These days many of us lose our valuable items but no such proper platform is available for returning
these lost items. So, it is mandatory to develop a system that can help to overcome these problems. This
project is helpful because there is no proper tracking of lost item in our country.
PROJECT SCOPE

Nowadays most of us go somewhere to visit place and sometimes we forget our valuable item at that
place. This is very stressful for every owner. There are many platforms but sometimes they neither
submit lost items nor return item to its exact owner. Some platforms are paid which are not suitable for
some users. Our project is based on android. Both owner and finder will register themselves.

User needs registration before performing any operation. After registration and login owner can search
their item and can also see all lost items.

➢ CHAPTER NO. 2: Software Requirement Specification

STACKHOLDER’S LIST

Name Role
Admin Manage the working of system

Owner Report lost item

Finder Report found item

Domain Requirements
❖ Hardware Interfaces:

Hardware Interfaces are:

• Processer Speed: 1.2 GHz

• RAM: 1 GB
• Hard Disk: 100 MB

❖ Software Interface:

Software interfaces are:

• Operating System: Android/IOS

• Development Tool: JavaScript, Java, Sharp NLP, JavaScript
• Database: MySQL
 Functional Requirements
No Requirement Description

FR1 Register new user

• The owner or finder can register him/herself into the
system.
• Owner or finder is able to enter their first name.
• Owner or finder is able to enter their last name.
• Owner or finder is able to enter a valid email address.
• owner or finder is able to set a password
• User is able to add their phone number.

FR2 Login Owner or finder is registered with the system,

then he/she can log in with the system.

• Owner or finder is able to enter registered email

address.
• Owner or finder is able to enter password.
• Owner or finder has given the correct email and
password, then they are able to press the login button.
• Admin is able to login into the system.

FR3 Register lost item

• Owner is able to report their lost item.
• Owner is able to enter their name.
• Owner is able to enter their contact email.
• Owner is able to enter the date on which their item was
lost.
• Owner is able to enter the category of their lost item.
• Owner is able to enter the brand of their lost item.

FR4 Register found item

• Finder is able to report their found item.
• Finder is able to enter their name.
• Finder is able to enter their contact email.
• Finder is able to enter the category of found item.
• Finder is able to enter the brand of found item.
• Finder is able to enter the color of found item.
• Finder is able to enter the brief description of found
item.
 • The user can search the desired item by entering the
FR5 Search
keyword.
• The user can search the desired item by category or
posted dated.

• User (owner/finder) is able to see all their post items

FR6 View status
after login in.
• User (owner/finder) is able to see details of their post
items.
• Admin is able to view their post items list.

• System shall enable the item owner and finder to

FR7 Do Chat
decide on what location they want to meet.
• System shall enable the finder to ask for more details
of the item to check the validity of the ownership of
the lost item from the item owner.
• Owner and finder are able to directly communicate
with each other

FR8 Delete Post

• User (owner/finder) is able to delete their posts.

FR9 Update account info

• User (owner/finder) is able to update item details.
• User (owner/finder) is able to update their email
address.
• User (owner/finder) is able to update their name.
• User (owner/finder) is able to update their phone
number.

FR10 Deactivate account

• User (owner/finder) is able to delete their account.
• User (owner/finder) is able to delete item.
• Admin can block and deactivate the account of user.
 NON-FUNCTIONAL REQUIREMENTS

No Requirement Description
NFR1 Performance
• The average page loading time of our application is
less than 3 seconds.
• Response time of our application page is less than 1
second.

NFR2 Usability
• The main actions are completed under 1 minute once
the user see the interface
• The system UI is easy to understand that every time
the user re-uses the system, he/she shall easily get used
to it.
NFR3 Security
• For isolation of information from other users every
user would have a two-step verification.
• No other user can access the system functionality that
is not present in our database.

NFR4 Portability
• This system can be installed in any personal mobile
phone using Android as operating system platform.

NFR5 Reliability
• The average failure rate of the system is 3 or less than
that annually.
• The system runs 7 days a week, 24 hours a day.

NFR6 Availability
• Even if the system fails, the system is recovered back
up within an hour or less.
 ➢ CHAPTER NO. 3: Analysis

Use Cases Description and Diagrams:

Use Case Diagram for Whole Project:

UC Number: 01

UC Name: Registration New User

Functional Requirement No: FR1

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: It allows the user (finder, owner) to register himself with the system by
providing the information like name, valid email.

Preconditions: The email should be valid.

Main Success Scenario:

1. The user clicks on sign up button.

2. The user gives the information like username, email, and password.
3. A verification mail is sent to the provided email.

Alternative Scenario:

1.If user does not click on sign up then verification email will not be sent.

Post Conditions:

1. The user (finder, owner) will be successfully registered.

Extensions:
1. The system do not allow the user to add email which is already registered with in
the system.

UC Number: 02

UC Name: Login

Functional Requirement No: FR2

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: It allows the user to login himself into the system using the email and
password which they provide at the time of registration.
Preconditions: User should be registered with the system.

Main Success Scenario:

1. The user click on the login button.

2. The user provides the email and password.

Alternative Scenario:

1. If user enter invalid email or password, then an error of invalid credentials will appear.

Post Conditions:

1.The user (finder, owner) will be successfully logged in.

Extensions:

1. If the email or password is not valid then the user will not be able to log in with the
system.

UC Number: 03

UC Name: Register Lost Item

Functional Requirement No: FR3

Primary Actors/Stakeholders: Owner

Secondary Actors/Stakeholders: Admin

Description: It allows the owner to report his lost item into the system.
Preconditions: Owner should be registered and logged in with the system before reporting
lost item.

Main Success Scenario:

1. The owner clicks on the report lost item button.

2. The owner provides the information like name, email, lost item description, location, color,
and brand.
3. After entering all the information the owner will press the submit button.

Alternative Scenario:

1.If the user does not press submit button, then lost item is be registered.

Post Conditions:

1.Item will be successfully reported, and the database will be updated.

Extensions:

1. If the item is already registered, the system does not allow the owner to report.

UC Number: 04

UC Name: Register Found Item

Functional Requirement No: FR4

Primary Actors/Stakeholders: Finder

Secondary Actors/Stakeholders: Admin

Description: It allows the finder to report the found item into the system.

Preconditions: Finder should be registered and logged in with the system before reporting
found item.

Main Success Scenario:

1. The finder clicks on the report found item button.

2. The finder provides the information like name, email, lost item description, location, color,
and brand.
3. After entering all the information the finder press the submit button.

Alternative Scenario:

1. If the user does not press submit button, then found item will not be registered.

Post Conditions:

1. Item will be successfully reported, and the database will be updated.

Extensions:

1. If the item is already reported, the system does not allow the finder to report.

UC Number: 05

UC Name: Search

Functional Requirement No: FR5

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: Both finder and owner will be able to search the desired item by
selecting their desired item category.

Preconditions: User must be logged-in in order to search the item by category.

Main Success Scenario:

1. The user clicks on the search by category dropdown.

2. The user can search item by date posted.

Alternative Scenario:

1. If an item category that is not present is error, then no result would be found.

Post Conditions:

1. The user will successfully see all the items in that category.

Extensions:

1. User is not able to see any other item from other categories.

UC Number: 06

UC Name: View Status

Functional Requirement No: FR6

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: The user can search the desired item by entering the keyword.

Preconditions: The item should be reported into the system.

Main Success Scenario:

1. The user will click on the view status button.

2. The user will enter the reference number of the item.
3. The user will press the enter button.

Alternative Scenario:

1. The user will not be able to see the status if the session is expired.

Post Conditions:

1. The status of the item will be displayed on the screen.

Extensions:

1. If the reference number is not valid, the system will not show any status.

UC Number: 07

UC Name: Do Chat

Functional Requirement No: FR7

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: For the convenience of user, both the owner and finder can chat with each other
to decide for a mutual place to visit each other and exchange the lost item. It can also initially
help the user to communicate with each other regarding the lost item.

Preconditions: The user must be login into the system and the user must have either
uploaded a lost item request or found an item.

Main Success Scenario:

1. The user login into the system by providing email and password.
2. The user either posts a lost item request or responds to a person for finding a lost item.
3. The user is having a chat button on the screen that he/she would click to start chat.

Alternative Scenario:

1. The user will not be able to see the status if the session is expired.

Post Conditions:

1. The user will meet at a mutual place to exchange the lost product.

Extensions:

1. The system does not allow the user to chat if they have not either posted a lost item or
respond to lost item request.
UC Number: 08

UC Name: Delete Post

Functional Requirement No: FR8

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: Both the owner and finder can delete post after find/return items.

Preconditions: The user must be login into the system and the must have post some item to
find or found.

Main Success Scenario:

1. The user login into the system by providing email and password.
2. The user either posts a lost item request or responds to a person for finding a lost item.
3. The user can delete post after return/find.

Alternative Scenario:

1. The user will not be able to delete an item after session logout.

Post Conditions:

1. The user will delete post after return/find.

Extensions:

1. The system does not allow the user to delete before upload any post.
UC Number: 09

UC Name: Update Account Info

Functional Requirement No: FR9

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: Update Account info will provide the user to update his item info. It will also allow
the user to update his provided email address, password, phone number, also the location of
the item etc.
Preconditions:

1. The user must be logged into the system.

2. Item must be previously added into the system if user wants to update the item info.
3. User must be registered before if he wants to update his account info.

Main Success Scenario:

1. The user logs into the system.

2. The user updates the info which he wants to update.
3. The system responds the user after updating and updates the system.

Alternative Scenario:

1. The user will not be able to update info before authentication.

Post Conditions:

1. The database will be updated.

2. The information will be updated everywhere in the system.

Extensions:

1. The system does not allow the user to update another user info.
UC Number: 10

UC Name: Deactivate Account

Functional Requirement No: FR10

Primary Actors/Stakeholders: Finder, Owner

Secondary Actors/Stakeholders: Admin

Description: The user will delete his account or any posted items.

Preconditions:

1. The user must be logged in into the system.

2. Only previously user and item registered into the system will be deleted.

Main Success Scenario:

1. The user logs into the system by clicking on the button.

2. The user selects any posted item and then directs to the system to delete it.
3. The user is able to delete his account permanently.
4. The system respond message to the user after deleting.

Alternative Scenario:

1. The item is deleted if user does not confirm it.

Post Conditions:
 1. Account info will be successfully deleted, and the database will be updated.

Extensions:

1. The system does not allow the user to delete another user info.

➢ CHAPTER NO. 4: Design

Sequence Diagrams:
1. Sequence Diagram for Register New User:

2. Sequence Diagram for Login:

3. Sequence Diagram for Register Found Item:

4. Sequence Diagram for Register Lost Item:

5. Sequence Diagram for Search:

6. Sequence Diagram for View Status:

7. Sequence Diagram for Do Chat:

8. Sequence Diagram for Delete Post:

9. Sequence Diagram for Update Account Info:

10. Sequence Diagram for Deactivate Account:

Class Diagram for Whole Project:
 ➢ CHAPTER NO. 5: Graphical User Interface (UI/UX)

Project Prototypes:

❖ Prototype of Registration/Login:
❖ Prototype of User (Owner):
❖ Prototype of User (Finder):
❖ Prototype of User Profile (Owner, Finder):