UTAR LOST AND FOUND MANAGEMENT

SYSTEM

CHIN YUN TING

UNIVERSITI TUNKU ABDUL RAHMAN

UTAR LOST AND FOUND MANAGEMENT SYSTEM

CHIN YUN TING

A project report submitted in partial fulfilment of the

requirements for the award of Bachelor of Science
(Honours) Software Engineering

Lee Kong Chian Faculty of Engineering and Science

Universiti Tunku Abdul Rahman

September 2020
 iii

DECLARATION

I hereby declare that this project report is based on my original work except for
citations and quotations which have been duly acknowledged. I also declare that it has
not been previously and concurrently submitted for any other degree or award at
UTAR or other institutions.

Signature :

Name : Chin Yun Ting

ID No. : 1701169

Date : 27th September 2020

 iv

APPROVAL FOR SUBMISSION

I certify that this project report entitled “UTAR LOST AND FOUND
MANAGEMENT SYSTEM” was prepared by CHIN YUN TING has met the
required standard for submission in partial fulfilment of the requirements for the award
of Bachelor of Science (Honours) Software Engineering at Universiti Tunku Abdul
Rahman.

Approved by,

Signature :

Supervisor : Chean Swee Ling

Date : 30 Sept 2020

Signature :

Co-Supervisor :

Date :
 v

The copyright of this report belongs to the author under the terms of the
copyright Act 1987 as qualified by Intellectual Property Policy of Universiti Tunku
Abdul Rahman. Due acknowledgement shall always be made of the use of any material
contained in, or derived from, this report.

© 2020, Chin Yun Ting. All right reserved.

 vi

ABSTRACT

People lose things occasionally. Scattered and unorganized lost and found information
can have a significant impact on the possibility to get back the lost items. The
information cannot reach the rightful owner if they are not well-managed.
Hence, the UTAR lost and found management system project was
implemented to provide a standardized, centralized way to handle lost and found items
in UTAR. The project objectives are to analyze the existing lost and found problems
in UTAR as well as the features of similar systems and develop a cross-platform lost
and found management system to improve the efficiency and effectiveness in
managing and organizing the lost and found items in UTAR.
The result showed the user preference between web application and mobile
application are almost equal based on the survey conducted. Thus, a cross-platform
application was developed so users can access through a web browser or mobile
application. The basic functionality of the application includes viewing, reporting and
updating lost and found items, submitting claims, selling and bidding expired items.
MySQL database was used as the system database. The framework of the web
application is Laravel while the mobile application is React Native. The adopted
methodology in this project is prototyping methodology. Unit testing, integration
testing and user acceptance testing were conducted to evaluate the system. Based on
the user acceptance testing conducted, most of the respondents are satisfied with the
function of the system. Some respondents suggested to improve the user interface of
mobile application so it can be more attractive for users.
 vii

TABLE OF CONTENTS

DECLARATION iii
APPROVAL FOR SUBMISSION iv
ABSTRACT vi
TABLE OF CONTENTS vii
LIST OF TABLES xi
LIST OF FIGURES xiv
LIST OF SYMBOLS / ABBREVIATIONS xviii
LIST OF APPENDICES xix

CHAPTER

1 INTRODUCTION 1
1.1 Introduction 1
1.2 Problem Statement 1
1.3 Project Objectives 4
1.4 Proposed Solution 4
1.5 Project Approach 6
1.6 Scope 7
1.6.1 System Scope 7
1.6.2 Project Modules 8

2 LITERATURE REVIEW 11
2.1 Introduction 11
2.2 Software Development Methodologies 11
2.2.1 Waterfall Methodology 11
2.2.2 Agile Methodology 13
2.2.3 Comparison of Waterfall and Agile 16
2.2.4 Prototyping Methodology 17
 viii

2.2.5 Conclusion 18
2.3 Existing Lost and Found Systems 19
2.3.1 Crowdfind 19
2.3.2 RepoApp 21
2.3.3 FidoFinder 23
2.3.4 Comparison of Crowdfind, RepoApp and FidoFinder
25
2.3.5 Conclusion 25
2.4 Auction Models 26
2.4.1 Open-Bid Auction 27
2.4.3 Sealed-Bid Auction 28
2.4.4 Conclusion 29

3 METHODOLOGY AND WORK PLAN 31

3.1 Introduction 31
3.2 Project Planning 31
3.2.1 Work Breakdown Structure (WBS) 32
3.2.2 Gantt Chart 32
3.2.3 Survey Analysis 33
3.2.4 Development Tools 42
3.2.5 Quick Design 43
3.3 Iteration Process 44
3.3.1 First Iteration 44
3.3.2 Second Iteration 44
3.3.3 Third Iteration 45
3.4 Development and Testing 45
3.4.1 Unit Testing 46
3.4.2 Integration Testing 46
3.4.3 User Acceptance Testing 46
3.5 Deployment 46

4 PROJECT SPECIFICATION 47
4.1 Introduction 47
 ix

4.2 Functional Requirement 47

4.3 Use Case Diagram 52
4.4 Use Case Description 53

5 SYSTEM DESIGN 72
5.1 Introduction 72
5.2 System Architecture Design 72
5.3 User Interface Navigation Design 73
5.4 Database Design 74
5.4.1 Entity Relationship Diagram 74
5.4.2 Data Dictionary 75
5.5 Activity Diagram 81

6 SYSTEM IMPLEMENTATION 96
6.1 Introduction 96
6.2 Route Design 96
6.3 Role-Based Access Control Diagram 102
6.4 Results and Discussions 103
6.4.1 Register 103
6.4.2 Login 105
6.4.3 Announcement 107
6.4.4 Found Item 110
6.4.5 Claim Item 112
6.4.6 Lost Case 115
6.4.7 Item for Sale 117
6.4.8 Profile 120
6.4.9 Staff Account 122
6.4.10 Item Category 123

7 SYSTEM TESTING 125

7.1 Introduction 125
7.2 Unit Testing 125
7.3 Integration Testing 155
 x

7.4 User Acceptance Testing 161

8 CONCLUSIONS AND RECOMMENDATIONS 163

8.1 Conclusions 163
8.2 Recommendations for Future Work 163

REFERENCES 165

APPENDICES 167
 xi

LIST OF TABLES

Table 2.1: Average scores for each factor, for both Kanban and
Scrum (Lei, et al., 2015) 15

Table 2.2: Defect Analysis for Waterfall and Agile Projects (Poe
and Seeman, 2019) 16

Table 2.3: Comparison Matrix of Software Development

Methodologies 18

Table 2.4: Comparison Matrix of Crowdfind, RepoApp and

FidoFinder 25

Table 2.5: Comparison Matrix of Open-Bid Auction and Sealed-

Bid Auction 29

Table 3.1: Main problems encountered by students in accessing

information 35

Table 3.2: Main Expected Features in Lost and Found Application

40

Table 4.1: Register Use Case 53

Table 4.2: Login Use Case 54

Table 4.3: View Found Item Use Case 55

Table 4.4: View Lost Case Use Case 56

Table 4.5: View Item for Sale Use Case 57

Table 4.6: View Announcement Use Case 58

Table 4.7: Claim Item Use Case 59

Table 4.8: Report Lost Item Use Case 59

Table 4.9: Bid Selling Item Use Case 60

Table 4.10: Manage Found Item Use Case 61

Table 4.11: Manage Claim Use Case 63

Table 4.12: Manage Item for Sale Use Case 64

Table 4.13: Manage Announcement Use Case 66

 xii

Table 4.14: Manage Staff Admin Account Use Case 67

Table 4.15: Customize Item Category Use Case 69

Table 5.1: Description of Entity Relationship Diagram 75

Table 5.2: Data Dictionary for ‘users’ Entity 75

Table 5.3: Data Dictionary for ‘found_items’ Entity 76

Table 5.4: Data Dictionary for ‘claims’ Entity 77

Table 5.5: Data Dictionary for ‘lost_items Entity 77

Table 5.6: Data Dictionary for ‘selling_items’ Entity 78

Table 5.7: Data Dictionary for ‘bids’ Entity 78

Table 5.8: Data Dictionary for ‘announcements Entity 79

Table 5.9: Data Dictionary for ‘attachments’ Entity 79

Table 5.10: Data Dictionary for ‘settings Entity 80

Table 5.11: Data Dictionary for ‘categories Entity 80

Table 6.1: Route Design for ‘found_items’ 96

Table 6.2: Route Design for ‘lost_items’ 97

Table 6.3: Route Design for ‘selling_items’ 98

Table 6.4: Route Design for ‘bids’ 99

Table 6.5: Route Design for ‘claims’ 99

Table 6.6: Route Design for ‘announcements’ 100

Table 6.7: Route Design for ‘attachments’ 101

Table 6.8: Route Design for ‘settings’ 101

Table 6.9: Route Design for ‘users’ 101

Table 6.10: Route Design for ‘category’ 102

Table 7.1: Unit Test Case – Test Register New Account 125

Table 7.2: Unit Test Case – Test Login Verification 126

 xiii

Table 7.3: Unit Test Case – Test View and Search Announcement 128

Table 7.4: Unit Test Case – Test Create, Edit and Archive
Announcement 130

Table 7.5: Unit Test Case – Test View and Search Item Found 132

Table 7.6: Unit Test Case – Create, Edit and Archive Item Found 134

Table 7.7: Unit Test Case – Test Claim Item 136

Table 7.8: Unit Test Case – Test Claim Item 137

Table 7.9: Unit Test Case – Test Archive Claim 141

Table 7.10: Unit Test Case – Test View and Search Lost Case 141

Table 7.11: Unit Test Case – Test Report Lost Case 144

Table 7.12: Unit Test Case – Test Archive Lost Case 145

Table 7.13: Unit Test Case – Test View and Search Item for Sale 146

Table 7.14: Unit Test Case – Test Bid Item for Sale 147

Table 7.15: Unit Test Case – Test Approve Item for Sale 148

Table 7.16: Unit Test Case – Test Update Profile 150

Table 7.17: Unit Test Case – Test Change Password 152

Table 7.18: Integration Test Case 155

Table 7.19: User Acceptance Test Result for Admins 162

Table 7.20: User Acceptance Test Result for Students 162

Table 8.1: System Limitations and Recommendations for Future

Work 164
 xiv

LIST OF FIGURES

Figure 1.1: Prototyping Methodology (Dennis, Wixom and

Tegarden, 2005) 6

Figure 1.2: Overview of System Scope 7

Figure 1.3: Overview of Project Module 8

Figure 2.1: Waterfall Model (Dennis, Wixom and Tegarden, 2005)

12

Figure 2.2: Kanban Methodology 13

Figure 2.3: Scrum Events 14

Figure 2.4: Prototyping Model (Dennis, Wixom and Tegarden,

2005) 17

Figure 2.5: Interface of Crowdfind (Crowdfind, n.d.) 19

Figure 2.6: Interface of RepoApp (RepoApp, n.d.) 21

Figure 2.7: Interface of FidoFinder (FidoFinder, n.d.) 23

Figure 2.8: Auction Models 26

Figure 3.1: Prototyping Methodology 31

Figure 3.2: Work Breakdown Structure (WBS) 32

Figure 3.3: Gantt Chart 33

Figure 3.4: Way to find the lost and found information in UTAR 33

Figure 3.5: Problems encountered by students in accessing lost and

found information 35

Figure 3.6: Comments on the lost and found information posted on

Facebook 36

Figure 3.7: Confidence level on the deliverability of lost and found

information on Facebook to students 37

Figure 3.8: The most important components in lost and found

advertisements 38
 xv

Figure 3.9: Preferred platform to access UTAR lost and found

information 38

Figure 3.10: Expected features in lost and found application 40

Figure 3.11: Confidence level on the positive impact of search

functionality towards the deliverability of lost and
found information 41

Figure 3.12: Development Tools 42

Figure 4.1: Use Case Diagram 52

Figure 5.1: System Architecture Design 72

Figure 5.2: Navigation Design for Web 73

Figure 5.3: Navigation Design for Mobile 73

Figure 5.4: Entity Relationship Diagram 74

Figure 5.5: Activity Diagram : Login 81

Figure 5.6: Activity Diagram : Register 82

Figure 5.7: Activity Diagram : View and Search Announcement 83

Figure 5.8: Activity Diagram : Manage Announcement 84

Figure 5.9: Activity Diagram : View and Search Found Item 85

Figure 5.10: Activity Diagram : Manage Item Found 86

Figure 5.11: Activity Diagram : Claim Item 87

Figure 5.12: Activity Diagram : Manage Claim 88

Figure 5.13: Activity Diagram : View Lost Case 89

Figure 5.14: Activity Diagram : Report Lost Item 90

Figure 5.15: Activity Diagram : View and Search Item for Sale 91

Figure 5.16: Activity Diagram : Bid Item for Sale 92

Figure 5.17: Activity Diagram : Manage Item for Sale 93

Figure 5.18: Activity Diagram : Update Profile 94

Figure 5.19: Activity Diagram : Change Password 95

 xvi

Figure 6.1: Role-Based Access Control Diagram 103

Figure 6.2: Register page 104

Figure 6.3: Verification mail received after registration 104

Figure 6.4: Resend email form 104

Figure 6.5: Register page in mobile view 105

Figure 6.6: Login page 106

Figure 6.7: Home page from staff and student view 106

Figure 6.8: Home page from staff admin view 106

Figure 6.9: Login page from mobile view 107

Figure 6.10: Announcement Page from admin view 108

Figure 6.11: Announcement Details Page 108

Figure 6.12: Post new announcement page from admin view 109

Figure 6.13: Announcement page from mobile view 109

Figure 6.14: Item Found page from staff and student view 110

Figure 6.15: Item Details page from staff and student view 111

Figure 6.16: Item Found page from admin view 111

Figure 6.17: Item Found page from mobile view 112

Figure 6.18: Claim Item page from staff and student view 113

Figure 6.19: Claim Item page from staff and student view 113

Figure 6.20: Claim Record page from staff admin view 114

Figure 6.21: Claim Item page from mobile view 114

Figure 6.22: Lost Case page from staff and student view 115

Figure 6.23: Report Lost page from staff and student view 116

Figure 6.24: Lost Case page from admin view 116

Figure 6.25: Lost Case page from mobile view 117

 xvii

Figure 6.26: Item for Sale page from staff and student view 118

Figure 6.27: Item Details page from staff and student view 118

Figure 6.28: Item for Sale page from staff admin view 119

Figure 6.29: Item for Sale page from mobile view 119

Figure 6.30: Profile page from staff and student view 120

Figure 6.31: Profile page from staff and student view 121

Figure 6.32: Profile page from staff admin view 121

Figure 6.33: Profile page from mobile view 122

Figure 6.34: Staff Admin Account page from system admin view 123

Figure 6.35: Create New Staff Admin account page from system
admin view 123

Figure 6.36: Item Category page from system admin view 124

Figure 6.37: Add New Item Category page from system admin
view 124
 xviii

LIST OF SYMBOLS / ABBREVIATIONS

UTAR Universiti Tunku Abdul Rahman

DSS Department of Safety and Security
CRUD Create, Retrieve, Update and Delete
UI User Interface
SDLC Software Development Life Cycle
WIP Limiting Work in Progress
NUS National University of Singapore
WBS Work Breakdown Structure
MVC Model-View-Controller
IDE Integrated Development Environment
 xix

LIST OF APPENDICES

APPENDIX A: Questionnaire 167

APPENDIX B: Result of Questionnaire 171

APPENDIX C: Storyboard 177

APPENDIX D: User Acceptance Test Case for Admin 185

APPENDIX E: User Acceptance Test Case for Student 187

 1

CHAPTER 1

1 INTRODUCTION

1.1 Introduction
According to James Gleik’s study, people spend around 16 minutes each day to search
for their lost items (Ahmad, et al., 2015). Furthermore, according to Tunajek (2009),
the American Demographic Society states that Americans as a whole spend almost 9
million hours a day looking for lost items and it might be because of excessive clutter.
The above research shows that people are extremely careless in handling personal
items. Most of the time these lost items are around us but we are not able to find out
on time.
People nowadays are too busy and it is common for them to lose items.
Universiti Tunku Abdul Rahman (UTAR) students have a habit of losing or misplacing
their personal items which might be valuable to them such as keys, student id cards
and mobile phones. All UTAR students are allowed to report and hand over any lost
items to the Department of Safety and Security (DSS). There are some Facebook
groups such as “UTAR-Sg Long Campus” that allow students to post or check their
lost and found items. If students found their items on the Facebook groups, they can
contact the persons to claim back their lost items. However, the current way is not
efficient to manage and deliver the latest lost and found information to relevant
students so the rate of return items is low.
The main goal of the project is to design and implement an application to
handle all these items and ensure that everything is tracked efficiently. It is a cross-
platforms so users can access it through a web browser and mobile device. This will
eventually reduce the time and efforts for handling lost and found information.

1.2 Problem Statement

These are the few problems listed in this project. These problems are identified from
direct observation of the target users and survey conducted in UTAR. The problems
are listed below:
 2

i. Inconvenient lost and found procedures

All students desire to find their lost items through the easiest way as soon as
possible. Based on Appendix B, 76.7% of respondents usually find the lost and
found information at DSS if they lost an item. However, some respondents think
that it is inconvenient and time-consuming to go DSS many times to check for the
items until their lost items have been found.
We can see the above lost and found procedures are not efficient based on the
students’ perspective. Sometimes the lost items are very common such as keys or
water bottles and it is hard to identify uniquely based on descriptions. The
department staff cannot confirm the actual owner of the lost items unless they call
students for verification. The case of misidentification by department staff can be
very high if the number of lost and found items increases. For students, they need
to come over the DSS several times to verify until their lost items have been found.
Furthermore, the department provides a limited time for students to report or
claim back items. The working hours of the department staff are from 8:30 a.m. to
5:30 pm. It causes inconvenience if students want to report or claim back their lost
items at night immediately.

ii. Lost and found information is scattered and unorganized

The lost and found information should be managed and well-organized for a better
view. However, the different ways to handle the lost and found items by UTAR
cause the lost and found information to be scattered and unorganized. Most of the
students follow UTAR standard lost and found procedures to hand over the items
to DSS. However, some of them prefer to keep things to themselves and post
advertisements on social media such as Facebook, waiting for the owners to
contact them and claim back the items. By doing so, all the lost and found
information is not well-organized.
Based on Appendix B, 76.7% of respondents usually find the lost and found
information in UTAR at DSS but only 16.7% of respondents find it in Facebook
groups such as “UTAR-Sg Long Campus”. It is because the information is
unorganized and it reduces a student’s willingness to search for it on Facebook.
46.7% of the respondents think that the current lost and found information on
Facebook is hard to access as it is scattered and unorganized. Some of the
 3

respondents also reveal that there is too much information on Facebook and they
do not know where to get the actual information.
For students who have lost items, many actions should be taken to search for
their items. For example, they should go to DSS to check for their items. In addition,
students should check the Facebook posts as people might post lost and found
advertisements anywhere. It is time-consuming for students to read through all the
Facebook posts one-by-one to find their lost items. At this time, there is no specific
platform that allows the staff to manage and organize all information at ease. It
causes confusion and inconvenience as students require to access various sources
to find all relevant information.

iii. Failure to deliver the latest lost and found information to students
The latest lost and found information is expected to reach target students to ensure
a high rate of returned items. However, based on Appendix B, 73.3% of
respondents think that students have half a chance or even less than it to see their
lost items being advertised on Facebook. No respondent believes that students can
see their lost items being advertised on Facebook. It shows that the confidence
level of students at Facebook in delivering the latest lost and found information is
quite low.
There are so many posts on Facebook per day as users are allowed to post
anything on it. Most of the time the lost and found advertisements are mixed with
other irrelevant posts and it is easy to skip over the posts. Once they skip over the
posts, they might never see it again and it reduces the chances for the owners to
claim back their items.
Furthermore, there is no restriction for the contents of Facebook posts so
students can post the lost and found advertisements in any format. For example,
some Facebook posts only attach with single items images without any further
descriptions such as location and date found. It might cause people to be confused
with just providing the images if the items are very common. Some people might
use the search by keywords function on Facebook to find their lost items. However,
it might be useless if students do not provide a detailed description for the items.
 4

1.3 Project Objectives

1. To analyze the existing lost and found problems in UTAR and the features of
similar systems.
2. To design an architecture for the lost and found management system.
3. To develop a cross-platforms lost and found management system which
provides a standardized, centralized way to manage lost and found items in
UTAR.
4. To improve the efficiency and effectiveness in managing and organizing the
lost and found items in UTAR.

1.4 Proposed Solution

i. Able to use both web browser or mobile device to access information
Based on Appendix B, 53.5% of respondents prefer to use mobile applications and
46.7% of respondents prefer to use web applications to access all lost and found
information in UTAR. Therefore, a cross-platform application was implemented
so students can use both web browsers or mobile devices to access lost and found
information anytime to increase efficiency.
The implementation of cross-platform applications can simplify the whole lost
and found procedures. It allows students to use personal computers or mobile
devices to search for their items. Furthermore, it allows students to post lost and
found advertisements immediately on the application without going to the DSS.
By doing so, students can find their lost items through the easiest way in a short
time.
Students can report anytime by using their personal computers or mobile
devices once they lost or found an item no matter where they are as the system is
available 24/7. This increases their willingness of students to take the initiative to
post the lost and found advertisements by just filling in the forms in the application.
Once the report rate of the lost items increases, it means that owners have a high
chance to find and claim back their items.
 5

ii. Centralized information within an application

By implementing the lost and found management system, all information can store
and maintain in a single database so it can be retrieved at the same time from the
system. Any updates to records are immediately reflected to users.
Staff will update the items with detailed information in the system if they
receive lost and found items from students. For students who prefer to keep things
to themselves and post advertisements on Facebook, they are encouraged to report
in the system to ensure all information is centralized within a single application.
By doing so, students are not required to access multiple sources to get the lost and
found information.

iii. Provide search and filter functions

Based on Appendix B, 93.3% of respondents believe that an accurate search
functionality in an application can improve the deliverability of lost and found
information to students. Thus, users are allowed to search and filter the lost and
found items in this system. For example, if a student lost his phone, he can search
the items by using the keyword of ‘phone’ in the specific column to filter out
irrelevant items and just focus on what they want to find. In addition, users can
search the items based on different categories such as clothing, mobile device or
student card. By doing so, all relevant information can reach the target students
effectively.
To aim for a better search and filter experience, it is important to ensure all
records can be stored and well-organized in the database. Therefore, form
validation was applied in the system to ensure the information provided by users
is properly formatted in the database. The data will further be sent to the server for
processing only if users provide all the required details.
 6

1.5 Project Approach

Figure 1.1: Prototyping Methodology (Dennis, Wixom and Tegarden, 2005)

As shown in the figure above, the proposed methodology is prototyping methodology.

Prototyping methodology performs the analysis, design and implementation stage
concurrently (Dennis, Wixom and Tegarden, 2005). These stages can be performed
repeatedly until all the features in the system prototype is completed. Nacheva (2017)
states that the prototyping methodology can provide a clear representation of the
software requirements to users and facilitate the development process.
Prototyping methodology is suitable to be applied in this project because users
are involved in the development stage. User interface (UI) is essential in the
development of software applications. A well-designed interface provides a better user
experience as well as improves the usability and accessibility of the system. Therefore,
a software prototype with much user involvement is required before the actual
implementation of the lost and found management system.
After the multiple times of evaluation from users to the system prototype,
errors can be detected and refined earlier. It is because users can provide constructive
feedback and comments on the initial system prototype immediately based on their
needs. The prototyping methodology can improve the user acceptability of the final
system as all necessary changes have been informed by the users in the early stage.
 7

1.6 Scope
The section below explains the system scope and project modules.

1.6.1 System Scope

Figure 1.2: Overview of System Scope

This project is to implement a lost and found management system for UTAR staff and
students which involves a few modules in this cross-platform application. The admins
can only access through web browsers. However, for UTAR staff and students, they
can access through web browsers and mobile applications.
All lost and found information will be displayed orderly with detailed
descriptions. The system provides a search engine for staff and students to search and
filter the items based on different criteria. If items matched the search criteria, the
system will display that particular item as a search result, otherwise, it displays ‘No
record found’. Staff and students are allowed to report lost items by filling in the forms
in the system. Form validation is applied in this system so staff and students are
required to provide all necessary information in order to report the items successfully.
If staff and students found their lost items in the system, they can submit the claim
form before they claim back their items at the department. Furthermore, the staff and
students can view all announcements posted by admins.
Admins can login into the system to manage all records in this system such as
lost and found items records, claims records as well as announcements. All the found
items will be kept for a certain duration. The default expired duration is 30 days.
 8

However, the admin can set their own expired duration in the system. If there is no
response from students within the expired duration, all unclaimed items will be opened
for students to bid. Staff and students can enter the bid amount for the items. The bid
amount should be higher than the current bid. The admins are allowed to determine
the starting bid of these selling items.

1.6.2 Project Modules

Figure 1.3: Overview of Project Module

i. Found Item Module

Staff and students can view all found items with detailed descriptions. They
can use the search and filter functions to find specific items based on different
criteria. They can click into the items to view more information.

ii. Lost Case Module

Staff and students can view all lost cases with detailed descriptions. They can
use the search and filter functions to find specific items based on different
criteria. They can click into the items to view more information.

iii. Item for Sale Module

This module shows the list of items for staff and students to place their bids.
All the found items will be kept for a certain duration. If there is no response
after the expired duration, all expired items will be opened for staff and
students to bid.
 9

iv. Announcement Module

Staff and students can view all announcements posted by admins. They can use
the search function to filter the announcements based on different criteria. They
can click on the announcement subject to view the content.

v. Manage Found Item Module

Admins are allowed to manage and perform create, retrieve, update and delete
(CRUD) operations to all found item records in this module.

vi. Manage Claim Module

This module shows the list of claim records submitted by students. Admins are
allowed to manage and perform create, retrieve, update and delete (CRUD)
operations to all claim records in this module.

vii. Manage Item for Sale Module

Admins are allowed to approve the expired items for sale. They are required to
determine the starting bid price and the bid end date of selling items. Admins
are allowed to manage and perform create, retrieve, update and delete (CRUD)
operations to all items for sale in this module.

viii. Manage Announcement Module

Admins are allowed to manage and perform create, retrieve, update and delete
(CRUD) operations to all announcements in this module. It is optional for
admins to upload the attachments for the announcements.

ix. Claim Module

If staff and students found their items from the listings, they can submit the
claim form before they want to claim back their items. Claim form is to inform
admin the personal information of item owners and their claim date.

x. Report Lost Module

The staff and students can report their lost items by filling up the form with
item descriptions in the system. They are required to provide all necessary
 10

information in order to report their items successfully. All updated information

will be stored in the database after they report a new item.

xi. Bid Item Module

The staff and students are allowed to enter a new bid amount for the selling
items. The new bid amount must be higher than the current bid. Students with
the highest bid can win the items after the bid end date.
 11

CHAPTER 2

2 LITERATURE REVIEW

2.1 Introduction
In this chapter, the comparison of software development methodology will be
discussed. Besides that, similar existing lost and found systems are studied. The system
features will be discussed and extracted out to include in this software project. Various
auction models will also be compared and discussed in the following section.

2.2 Software Development Methodologies

Software development methodology is the process we use to develop a software
application. Different methodologies have different implementations of the software
development life cycle (SDLC). In this section, four development methodologies will
be discussed, which are waterfall methodology, Kanban methodology, scrum
methodology and prototyping methodology.

2.2.1 Waterfall Methodology

Waterfall methodology is a linear and sequential development model. It is a plan-
driven methodology as it only focuses on plan implementation. In this sequentially
structured approach, the project team will only proceed to the next development stage
if the previous stage is completed (Yang, 2013). The key deliverables for each phase
are very long. Normally, it requires the approval of the project manager to end the
current phase before proceeding to the next step.
 12

Figure 2.1: Waterfall Model (Dennis, Wixom and Tegarden, 2005)

 High costs and efforts

According to Petersen, Wohlin and Baca (2009), the waterfall model is
connected to high costs and efforts. It is because waterfall requires a lot of
documents approval, changes are expensive, iterations require much effort to
rework and the problem only be identified in later phases. A survey was
conducted by Petersen, Wohlin and Baca in 2009, the respondents stated that a
lot of documentation needs to be prepared during the requirements phase,
however, it is not used in later stages and sometimes it should be discarded and
reworked.
 Changes in requirement can be problematic
According to Casteren (2017), the Waterfall model emphasizes on the software
specification free, which means that any new requirements or features are not
allowed to add in once finalized, agreed and approved by all stakeholders. It
caused customers’ sudden changes are not addressed, resulting in a low
customer satisfaction product. Therefore, the waterfall model is more suitable
to be used if the project requirements are well-defined and no possible changes
are required.
 13

2.2.2 Agile Methodology

Agile methodology was inspired by the Toyota Production System and it is widely
implemented in software development projects around the world. According to Lei, et
al. (2017), unlike traditional software development models, the attractive
characteristics of agile methodology are short development cycle, high customer
interaction and high adaptability to change.
The findings of 13th Annual State of Agile Survey conducted in 2018 by CollabNet
VersionOne stated that 69% of respondents use agile to enhances the ability to manage
changing priorities by adopting agile. 65% of respondents state that agile improves
project visibility and 64% of respondents realize that agile increases the business-IT
alignment. It shows that agile will be benefited in delivering a successful software
project.
The popular frameworks used to implement agile methodology are Kanban and
Scrum. In the following section, we will discuss the comparison between Kanban and
Scrum.

2.2.2.1 Kanban Methodology

Figure 2.2: Kanban Methodology

 14

 High visibility
Kanban card wall enables the project team to visualize the current progress of
the project. The card wall states accurately what work should be done within a
certain period. All required tasks are written onto colored sticky notes and
added into the Kanban backlog. Once a task is completed in a specific step, it
moves to the next step until it is fully completed. The tasks in the backlog
should move through a number of steps until they are completed (Lei, et al.,
2015).
 Limiting Work in Process (WIP)
Kanban limits the number of tasks in any step of the card wall. It can accept
more tasks if a step has fewer tasks. However, if a step reaches a maximum
number of tasks, it should only accept a new task if any tasks complete and
move to the next step. A queue is used to allow for slack between steps and the
tasks are assigned based on their priority. It means that we should put the most
attention to the most important tasks to reduce any risk of task incompletion.

2.2.2.2 Scrum Methodology

Figure 2.3: Scrum Events

The sprint is the core of the Scrum process. According to Lei, et al. (2015), each sprint
can be considered as a sub-project with a plan of what should be built as well as how
it should be built. Normally, the project teams require 30 days for a sprint. The
development goals cannot be changed within the sprint cycle. However, the sprints can
 15

be cancelled and project scope can be redefined if any changes occur to meet customers’
requirements.
Scrum teams require a lot of meetings during the sprint cycle to ensure the product
quality of each sprint. In the beginning, the project teams should conduct a sprint
planning meeting to plan for the goals as well as the product’s implementation process.
Each member should have a common understanding of the project goals after the
discussion. The duration of the sprint planning meeting is usually eight hours. In the
sprint execution, there is a daily Scrum meeting for 15 minutes. Project team members
should update their current progress and challenges faced each day. In addition, a sprint
review meeting is conducted to discuss the contribution of each team member. It can
also be a product demonstration so the project teams can identify the potential
improvements for future sprint.

2.2.2.3 Comparison of Kanban and Scrum

According to Lei, et al. (2017), a survey was conducted to collect the responses from
employees who use Kanban and Scrum in their software development projects. Among
the total of 35 respondents, there are 60% (21 respondents) of the Scrum users and 40%
(14 respondents) of Kanban users. The table below shows the average scores for each
factor for both Kanban and Scrum:

Table 2.1: Average scores for each factor, for both Kanban and Scrum (Lei, et al.,
2015)
Factor Kanban Scrum
Time schedule 4.05 3.67
Clear project scope 3.68 3.60
Budget handling 3.79 3.87
Risk control 3.93 3.83
Available resource 3.93 3.88
Quality of project 4.02 3.98

Kanban scored an average of 4.36 but Scrum only had an average score of 3.76
for the awareness of project status. It shows that Kanban users are more aware of the
project status than Scrum users. Furthermore, in the time schedule factor, the result
 16

states that Kanban scored 4.05 while Scrum only scored 3.67. It shows that Kanban
users can deliver tasks on time according to the project schedule. In scope, budget, risk
and resources factors, Kanban scored slightly better than Scrum as the difference of
average scores between them is not more than 0.1. Both Kanban and Scrum can deliver
successful software projects as they scored around 4.0 in the quality factor. The survey
results show that Kanban is more efficient than Scrum in terms of schedule, scope,
budget, risk, resources and quality factors. In addition, Kanban performs better than
Scrum in awareness of project status.

2.2.3 Comparison of Waterfall and Agile

According to Poe and Seeman (2019), a case study was conducted to investigate the
software code quality in Waterfall and Agile projects based on software development
hours and software defects. Eight project teams participated in the case study. Three
of the project teams were selected to use Waterfall whereas five of them used Agile.
The table below shows the defect analysis for Waterfall and Agile projects:

Table 2.2: Defect Analysis for Waterfall and Agile Projects (Poe and Seeman, 2019)
Project Methodology Waterfall Agile
Total Combined Development Hours 3140 2076
Total Number of Production Defects 19 21
Total Number of Pre-Production Defects 43 13
Percentage of Production Defects to Development 0.61% 1.01%
Hours
Percentage of Pre-Production Defects to 1.37% 0.63%
Development Hours

The software development hours and software defects were recorded for all teams
during the software development life cycle. Based on the result, the project teams
required 3140 development hours to complete a Waterfall project, which is 1064 hours
longer than the Agile project (2076 hours). The total number of pre-production defects
in Waterfall project teams was much higher than Agile project reams, 43 to 13
respectively, with the percentage of pre-production defects to development hours, 1.37%
 17

to 0.63%. Furthermore, the total number of production defects for Waterfall (19
defects) and Agile (21 defects) were almost the same.
However, when we factored in the software development hours for both
methodologies, Waterfall only had 0.61% of production defects to development hours
whereas Agile had 1.01%. It is because more defects were found during the pre-
production stage and the Waterfall project team spent more time fixing it before it
came to production. The result of case study reveals that Waterfall methodology can
ensure a higher software quality code but it requires a longer software development
time for testing.

2.2.4 Prototyping Methodology

The prototyping methodology performs analysis, design and implementation phases
concurrently to deliver a system prototype for user review. This cycle can be repeated
multiple times until it meets user satisfaction. According to Dennis, Wixom and
Tegarden (2019), the first prototype is usually the first part of the system and it can be
re-analyze, re-design and re-implement to add in a few more features in every cycle.
If the system prototype has been reviewed and approved by users, the developer can
start the actual implementation to develop the final system.

Figure 2.4: Prototyping Model (Dennis, Wixom and Tegarden, 2005)

 Error can be detected earlier

Prototyping methodology requires much user involvement in the development
stage. Users can interact with the system prototype provided. At the same time,
any immediate comments and feedback can be provided on time before it
 18

comes to the actual implementation. Any misunderstandings or

miscommunications between users and developers about the features of a
system can be avoided. It helps to improve the quality of system specification
provided by users and as the necessary changes have been informed in the early
stage.

 Excessive development time

The prototyping methodology requires user feedback and recommendation on
system prototype for improvements. The developers might spend too much
time to deliver a complex prototype for user review. As the prototyping
methodology allows users to request changes or enhancements, a lot of
disagreements from users can cause an endless loop in re-analyzing, re-
designing and re-implementing in order to provide a system prototype that
achieves user satisfaction. In this situation, the project might run over time and
budget.

2.2.5 Conclusion

Table 2.3: Comparison Matrix of Software Development Methodologies

Project Methodologies Waterfall Kanban Scrum Prototyping
with Unclear Project Scope Poor Good Good Excellent
with Short Time Schedule Poor Excellent Excellent Excellent
Schedule Visibility Poor Excellent Good Good
Flexibility Poor Excellent Good Excellent
Cost of change High Low Low Low

In conclusion, different software development methodologies have their own

advantages and disadvantages. People should select the methodologies based on the
situation as well as their needs and requirements. It is important to select a right
methodology as it determines the success or failure of the software project.
Prototyping methodology will be chosen as the software development
methodology in this project. This is because end users are allowed to be involved in
 19

the development stage of the project. The feedback and comments of end-users are
very important to a system prototype as any errors can be detected earlier.
Furthermore, the prototyping methodology has a better change control process.
The changes or modifications can be flexible based on the users’ feedback. It ensures
that there are no out of scope or run-away-requirements at the end of the development
stage. A more user-friendly system can be developed with the involvement of users by
implementing the prototyping methodology.

2.3 Existing Lost and Found Systems

Four existing lost and found systems are studied in this section. The main features of
these systems will be discussed and evaluated.

2.3.1 Crowdfind

Figure 2.5: Interface of Crowdfind (Crowdfind, n.d.)

Main features of Crowdfind

 View lost and found information
Users can view all lost items in the homepage. Only item images and item
categories are provided in the list. Users can search for a particular item by date
or any keywords.
 Customized claim forms
The users are required to provide information in the claim forms based on the
item category. They are encouraged to share any unique information for the
 20

admin to verify their lost items. The more information provided, the higher the
chance to match an item successfully.
 Chat function
The admins can directly communicate with customers in the system for further
information or coordinate the pickup time and location.
 Automated reporting
The system can generate reports from the dashboard automatically. These
reports can show the number of items is matched, the most common lost items
and others.
 Email notification
The users will receive a confirmation email once a claim form is submitted. If
they receive a message from the admin or their claim is accepted, they will
receive an email notification from the system.

Evaluation on Crowdfind
Crowdfind is a lost and found system that was developed by a Chicago-based company.
Crowdfind is an enterprise software and it is very popular to be used at universities in
the United States such as University of Michigan, University of Iowa, Texas State
University and more. Its image-based features and specialized dashboard provide
companies with a better user experience
The best feature of Crowdfind is the customized claim forms. The system will
generate customized questions that are set by admins for different items categories.
For example, mobile phone owners should provide brand, model, color and passcode.
The person who wants to claim back the identity card should provide the last 4 digits
on the card as well as the date of birth. This item verification process is based on the
detailed information provided by users on the claim form. Therefore, claims may be
rejected by admins if accurate information is not provided. It helps to ensure that all
the found items are returned to the actual owners. For those who plan to pretend to be
someone else will fail to claim the items as they cannot provide sufficient information
for that particular item.
Furthermore, another good feature is the email notification for claim forms. A
confirmation email with relevant details will be sent to students’ inbox after a claim
form is submitted. It is possible that some students might forget the appointment they
 21

have made before. With the existence of email notification, students can directly check
and confirm their appointment in the email without logging into the system.
However, Crowdfind has a limitation as there is not much information provided
in the lost and found list. The system only shows item images and item categories in
the user view. It is still very difficult for the users to identify their items accurately
although the images are provided as some of the items look similar. It causes many
rejected claim cases as people need more unique information for verification.
In conclusion, unlike Crowdfind, the system should provide at least 3 types of lost
and found information in the list. It is very helpful for students to identify their personal
lost items clearly without much clicking. Furthermore, the email notification will also
be implemented in the system.

2.3.2 RepoApp

Figure 2.6: Interface of RepoApp (RepoApp, n.d.)

Main features of RepoApp

 View lost and found information
Users can view lost and found information with descriptions, expired date,
location and date found, categories, status, updated date.
 Email notification
If the admins found a suspected owner, they can directly send emails through
the system by just clicking on the email icon. The system can automatically fill
 22

in the receiver, subject and body of the email. The admin can modify any
information before sending it if they are not satisfied with the email contents
generated. Furthermore, the email template can be customized anytime based
on the requirements.
 Auto-match items
The users can search items with different criteria in the system. Based on the
criteria provided, the system will try to find and match all the items. Any
suspected items that match the criteria will show on the match list for users’
verification.
 Release of unclaimed items
Admins are allowed to set the expired date for each item. After the items are
updated, the system will count the number of days until it reaches the expired
date. Any unclaimed items will be released from the lost and found information
list.

Evaluation on RepoApp
RepoApp is a web-based lost and found software with a mobile-friendly design of user
interface. It allows customers to integrate with the website so any operations can be
done within their organization website. National University of Singapore (NUS) is
now using RepoApp to manage lost and found items within the campus.
The best feature of RepoApp is the email notification to suspected owners.
Normally, if the admins want to contact the suspected owners, they should login into
their email account and write the email content before sending emails. It is a very time-
consuming procedure. By implementing this email notification feature, admin can
customize their own email template and the system can directly send emails based on
the template provided. This feature reduces the employees’ time spent working on
unproductive tasks.
However, RepoApp does not provide item images in the lost and found
information list. A picture is worth a thousand words as it can show the unique features
of items more quickly and effectively than words. Users might find it very difficult to
identify their lost items based on the descriptions provided.
In conclusion, the features of the search engine and email notification to inform
suspected owners will be implemented in this system. It helps to reduce the issues of
information overload as well as improve the deliverability of lost and found
 23

information to students. The release of unclaimed items will also be implemented in

the lost and found system. All the expired items will be opened for students to bid.

2.3.3 FidoFinder

Figure 2.7: Interface of FidoFinder (FidoFinder, n.d.)

Main features of FidoFinder

 View lost and found information
Users can access all lost and found dogs with images. Only images will be
shown on the listings. Users should click into the image to view more detailed
information such as color, breed, gender and more. They can search the dog
listings based on the characteristics as well as the postal code area.
 reCAPTCHA verification
Some users might provide their phone number for others to contact them
immediately. There is a “View Phone Number” button that can reveal the
phone number. Users should check the reCAPTCHA checkbox of “I’m not a
robot” for verification before showing the phone number.
 Instant notification to mobile application
Users are encouraged to use mobile applications to receive instant notification.
After installing the mobile application, they should login to their account and
accept “Allow Notifications” when the application asks for permission.
 Pre-registration
 24

Users can pre-register their dogs although the dogs are still safe. The system
will update dogs in safe listings. Users can mark the status as “lost” if their
dogs get lost. The person who found the dogs can change status to “presumably
safe” and directly contact the owners of lost dogs.

Evaluation on FidoFinder
FidoFinder is a lost and found dog website that helps to connect the lost dog’s owners
and finders. The best feature of FidoFinder is the pre-registration function. It allows
people to register their dogs online before they get lost. Currently, FidoFinder already
has 508,387 registered dogs. It becomes a large public database to store information
about dogs. If people find a lost dog, they can search the registered dog listings based
on the characteristics of the dog to get the owner’s information. It eases the whole lost
and found process to be more efficient and effective.
However, the user interface (UI) design of FidoFinder looks messy. The lost and
found dog listings are not shown in the home page. Users should enter the search
criteria such as postcode, colour or dog breeds in order to get the information. It is not
user-friendly as users are required to fill in the form before viewing the dog
information and it reduces the willingness for people to use this website. Therefore,
the system should directly show the lost and found dog listings in the first page of the
website so all information can reach users at the earliest.
In conclusion, the issues of UI design in FidoFinder are studied and will be
improved in this system. The lost and found information will be shown in the home
page so users can view the item directly once they enter the web page. Furthermore,
the search options are provided on the top of the listings so users can search the items
anytime if it is needed.
 25

2.3.4 Comparison of Crowdfind, RepoApp and FidoFinder

Table 2.4: Comparison Matrix of Crowdfind, RepoApp and FidoFinder

Existing System Crowdfind RepoApp FidoFinder
Features
View lost and found information Yes Yes Yes
Show images Yes No Yes
Search and filter function Yes Yes No
Customize claim form Yes No No
Chat function Yes No No
Automated reporting Yes Yes No
Email notification Yes Yes No
Instant notification to mobile No No Yes
Auto-match items No Yes No
Release of unclaimed items No Yes No
reCAPTCHA verification No No Yes
Pre-registration No No Yes

2.3.5 Conclusion
In conclusion, different lost and found systems have their own unique features that
serve for different purposes. There are also some general features such as view lost
and found information. Based on the evaluation of these lost and found systems,
Crowdfind has the best features as compared to RepoApp and FidoFinder.
The overall interface design of Crowdfind is clean and neat which enables users
to identify their items effectively. The features that are chosen to be implemented in
this project are:
i. View lost and found information in card format
ii. Show item images
iii. Search and filter function
iv. Release of unclaimed items
v. Email Registration
 26

The above features can increase the willingness of students to report their lost
items and actively view the information in the system. The search and filter function
allow students to find the information they want rapidly. All the unclaimed items will
be released and opened for students to bid after the expired date. If the students register
a new account, they will receive a verification mail.

2.4 Auction Models

Auction is the event of a competitive sale where various potential buyers can place
their bids for particular products or services. When the auction ends, the selected
bidders should pay for the products or services based on the final bids they placed.
According to Aldaej, et al. (2018), in recent years, the concept of auctions becomes
increasingly common with online providers such as eBay. However, the benefits of
auctions can be lost if they are not well-planned. It means that the architecture design
of an auction is essential to deliver a best practice for the auction system.
There are 4 standard auction models to study in this section, which are English
auction, Dutch auction, first-price sealed-bid auction as well as second-price sealed-
bid auction. Different auction models have their own unique features that serve for
different purposes. The main characteristics of these auction models will be discussed
in the following section. The figure below illustrates the auction models.

Figure 2.8: Auction Models

 27

2.4.1 Open-Bid Auction

Open-bid auction is the auction which is open and transparent for all participants. It
consists English auction and Dutch auction. Both of them will be discussed in the
following section.

2.4.2 English Auction

English auction, also called ascending-bid auction. According to Ilonka (2017), it is
mostly used when it is difficult to determine the value of items or the seller is not aware
of the valuation of the potential buyers. The process of English auction is carried out
synchronously. All potential buyers can place their bids based on their acceptable
prices which are higher than the current price. At the same time, the seller gradually
raises the price of item until there is no more bid. The auction ends at a fixed time and
the final bidder should pay his bid to get the item.
The main characteristics of English auction:
 Easily observe the item value

Unlike the sealed-bid auction, English auction is completely open and transparent.
The participants are able to know the identity of others during the auction.
Therefore, the participants can easily estimate the item valuation based on the
observation towards each other. For the bidders who do not have much auction
experience, they can observe other bidding behaviour as well as the highest bids at
the past moments. All this information reveals the actual value of the items and
current market demand.
 Flexible bid jumping

During the English auction, all participants can determine their own next bid
amount. It encourages the participants to place the bids based on their ability.
Flexible bid jumping actually increases their willingness to bid for the items as the
bidders only require to bid a small amount with a slightly price increment.
However, if all the participants have limited financial ability, the bid jumping can
be very low, the seller cannot obtain the maximum possible price.

2.4.2.1 Dutch Auction

Dutch auction, also called descending-bid auction. According to Ilonka (2017), it is
suitable when the auctions are required to sell out the items in a short time. Nicu, et al.
 28

(2014) also stated that Dutch auction is useful if the seller wants to sell expensive items
with high demand. The process of Dutch auction is also synchronous. Unlike English
auction, the item of Dutch action starts at an extremely high price. If the potential
buyers are willing to accept the price, they can submit the bid to get the item. The seller
gradually lowers the price of the item until the item has been sold out.
The main characteristics of Dutch auction:
 Work well when the bidding process is slow

Unlike English auction, the participants can wait until the last possible moments
to place their bid to prevent others to compete with them. It causes the whole
bidding process to become slow as most participants are not willing to place bids
at the beginning. According to Ilonka (2017), Dutch auction can solve this problem
perfectly. In Dutch auction, the seller continuously lowers the price if there is no
bidder. It reduces the waiting time as well as the high pressure causes participants
tend to place the bids earlier to prevent others win the item. Therefore, the Dutch
auction can be carried out faster than English auction.
 Starting price is relatively close to market price

In Dutch auction, the seller can set a starting price which is relatively close or even
higher than the market price. The high pressure causes participants to bid sooner
as the number of bids is limited. If the items are in high demand, the final price of
the items should be very high. However, for the bidder without much experience,
they might miscalculate or overbid the item. This situation is called the winner’s
curse.

2.4.3 Sealed-Bid Auction

Sealed-bid auction is a less transparent auction as compared to the open-bid auction.
It consists of first-price sealed-bid auction and second-price sealed-bid auction.
According to Ilonka (2017), the first-price sealed-bid auction is equivalent to
the English auction. It means that only the bidder with the highest bid can win the item.
However, all participants can only place one bid before the end of the auction. The bid
placed by each participant is not visible to others. After the bidding time, the seller
starts to evaluate all the bids and select the highest bid to be the winner.
Second-price sealed-bid auction also called Vickrey auction. It is comparable
to the first-price sealed-bid auction. The main difference is the winner determined by
 29

the highest bid only has to pay the amount submitted by the second-highest bidder
(Ilonka, 2017). Since all participants are not able to know the bid amounts submitted
by others, the second-price sealed-bid auction can give them the confidence to bid the
item with the best price without overpaying.
According to Hong, Wang and Paylou (2016), a study was conducted to
investigate the effect of bid visibility on the auction performance by using the data
from an online labor market. Based on the result, the sealed-bid auction (59.2%) can
attract 18.4% more bids than open-bid auction (40.8%). However, the open-bid auction
can offer a higher buyer surplus, which is $10.87 higher than the sealed-bid auction.
Based on customer feedback, the open-bid auction can also generate higher customer
satisfaction than the sealed-bid auction. It shows that although the sealed-bid auction
can attract more bids, the open-bid auction can have higher buyer surplus and customer
satisfaction. Therefore, the sellers should determine the auction model based on their
requirements and expected achievements of the auction.

2.4.4 Conclusion

Table 2.5: Comparison Matrix of Open-Bid Auction and Sealed-Bid Auction

Open-Bid Auction Sealed-Bid Auction
English Dutch First-Price Second-Price
Auction Auction Sealed-Bid Sealed-Bid
Auction Auction
Suitable Sellers cannot Sellers want to Items have Items have
Situation determine the sell out items enough enough demand
actual value of within a short demand to but still aim to
items time attract bidders attract more
bidders to join
Advantages Flexible bid Sellers can A low Bidders gain
jumping can minimize the transparent the confidence
attract more difference bid can to bid item
bids between the increase the
selling price potential for
high return
 30

and the actual

price
Disadvantages Bid jumping Stress bidding Private Bidders can
can be very process bidding only place one
low causes process causes bid and cannot
miscalculation low adjust their bid
or overbid participation after submitted

In conclusion, English auction will be chosen as the auction model in the system to
sell the unclaimed items. It is because all items being sold are pre-owned items so it is
difficult for the admin to determine the value of items. By implementing the English
auction, the admin can set a minimum price for the items. Once the items are open for
sale, all users are allowed to place any bids which are higher than the current price.
The system will automatically raise the bids according to the bids submitted by users.
Furthermore, the auction in the system mainly aims to clear out all unclaimed
items, instead of to earn higher profits. Therefore, English auction with flexible bid
jumping actually encourages potential buyers to place their bids based on their ability
without any financial pressure since the users in the system are mainly students. By
doing so, the auction can have more participation from students.
 31

CHAPTER 3

3 METHODOLOGY AND WORK PLAN

3.1 Introduction
The software development methodology used in this project is prototyping
methodology. The figure below shows the model of prototyping methodology.

Figure 3.1: Prototyping Methodology

There are 4 phases in prototyping methodology, which are project planning,

iteration process, implementation and testing and deployment. The detailed work of
each phase will be discussed in the following section.

3.2 Project Planning

During the project planning, a set of plans were developed. All project tasks were
planned and scheduled to ensure the project can be delivered within the time and scope.
Work breakdown structure (WBS) and Gantt chart were developed to identify the
project scope as well as illustrate the project schedule. Furthermore, a survey was
conducted to collect the requirements Based on the analysis of the survey, the software
 32

requirements and development tools can be determined. A quick design for system
storyboard was also developed.

3.2.1 Work Breakdown Structure (WBS)

All tasks involved in this project are split into multiple sub-tasks and organized into
the WBS. Each phase consists of specific tasks that should be completed before
moving to the next phase. The figure below shows the WBS of this project.

Figure 3.2: Work Breakdown Structure (WBS)

3.2.2 Gantt Chart

The purpose of Gantt Chart is to schedule all the project subtasks based on the given
duration. By doing all, a clear and well-illustrated project schedule can be developed
based on WBS. In this project, a Gantt chart was developed within the period of time
between January and August. The figure below shows the Gantt chart in this project.
 33

Figure 3.3: Gantt Chart

3.2.3 Survey Analysis

During the planning phase, a survey was conducted with 30 UTAR students. The
objective of the survey is to collect the functional requirements from the target user as
well as understand their needs and opinion towards the lost and found management
system. The result of the questionnaires will be analysed and discussed in this section.
The sample of questionnaires and its results are attached to Appendix A and Appendix
B respectively.

Figure 3.4: Way to find the lost and found information in UTAR

Based on Figure 3.3, most of the students (76.7%) access the lost and found
information in UTAR through DSS. Some students (16.7%) access UTAR lost and
 34

found information through Facebook groups such as ‘UTAR-Sg Long Campus’. A

Facebook page called ‘UTAR SLC Lost & Found’ occasionally updates lost and found
information. However, no student finds the lost and found information through
Facebook pages. In my opinion, it is because the update frequency of Facebook pages
is very low. Currently, students still prefer to check the lost and found information
through DSS as it is the most direct and fastest way.

What is the problem you encounter when you try to find the lost and found
items in UTAR?
30 responses

No issue.

It is time-consuming because I should frequently go to department to find my items.

Hard to see my items on Facebook

Normally the item is hard to be found

Don't know where to collect the information

Sometimes Inconvenient to walk to DSS

Hard to search information.

Advertisements on Facebook are too messy

Cannot get all lost and found information in a platform

No image provided

Need to go DSS many times to check my items

Hard to find my items

Only can find lost item on DSS, but sometime I lazy go to DSS department

Can't find my items

Some people are lazy to hand over the items to relevant department

Too many information

Sometime lost item cannot be found at DSS

Hard to access. Don't know where to get the information.

 35

Sometime hard to get information of the lost item.

inconvenient to Department of Safety and Security

Cannot get latest information from DSS

Cannot check information immediately

When I lost something at school and I can't find it at the spot I left it.

Hard to find

No idea

Can’t find my items although I go DSS

Not enough descriptions.

Lost item may pick up by student and not passing to DSS

Lazy to go DSS

Figure 3.5: Problems encountered by students in accessing lost and found

information

Based on Figure 3.4, the main problems encountered by students are as listed
below:

Table 3.1: Main problems encountered by students in accessing information

Problems Encountered Number of Respondents
Hard to search and access the information. 15 (50.0%)
Inconvenient and time consuming for students to 8 (26.7%)
check information through DSS
Cannot get the latest information immediately 2 (6.7%)
Item information is incomplete such as no image or 2 (6.7)
not enough descriptions
No issue 3 (10.0%)

Based on Table 3.1, 15 respondents (50%) think that it is hard to search and
access the lost and found information in UTAR. For the student who usually checks
 36

lost and found information through DSS, 8 respondents (26.67%) think that it is
inconvenient and time-consuming to check information through DSS. It is because
some students might need to go DSS multiple times to check for their lost items until
the item is found. 2 respondents (6.67%) state that they cannot get the latest
information immediately and the other 2 respondents (6.67%) think that the item
information on Facebook is incomplete. Some of the students do not provide the item
images or the item descriptions are not unique enough for owners to identify their lost
items.

Figure 3.6: Comments on the lost and found information posted on Facebook

Based on Figure 3.5, most of the respondents (46.7%) think that it is hard to
access the lost and found information on Facebook as it is scattered and unorganized.
They are different types of sources for students to post lost and found advertisements
on Facebook. It causes confusion as students cannot identify which are the most
reliable and trustable sources. Furthermore, 40% of respondents state that it is still
acceptable for the lost and found information posted on Facebook. Only 13.3% of
respondents have no issue with it.
 37

Figure 3.7: Confidence level on the deliverability of lost and found information on
Facebook to students

In this question, the respondents are required to rate the deliverability of lost
and found information on Facebook to students based on their opinions. Based on
Figure 3.6, most of the respondents (36.7%) rate 3 for the deliverability of lost and
found information on Facebook to students. It is because the deliverability of Facebook
posts is very random so people cannot predict who will receive the information. No
respondent believes that students definitely can receive the lost items posts advertised
on Facebook. Furthermore, only 1 respondent thinks that the student definitely cannot
receive the lost and found information on Facebook. Based on the result in this
question, we conclude that most of the respondents have a moderate confidence level
on the deliverability of lost and found information on Facebook to students.
 38

Item image 29 (96.7%)

Item category 5 (16.7%)
Item name 5 (16.7%)
Item description 10 (33.3%)
Location found 24 (80%)
Date found 11 (36.7%)
Item status 6 (20%)

0 5 10 15 20 25 30 35

Figure 3.8: The most important components in lost and found advertisements

In this question, all respondents are allowed to select the three most important
components. Based on Figure 3.7, item image (29 respondents) are the most important
component in a lost and found advertisement, followed by location found (24
respondents) and date found (11 respondents). It is because the image can directly
show the unique features of the item, together with the location found and date found,
the owner can almost identify their lost item. Furthermore, 10 respondents think that
the additional descriptions for the item are also important. The least important
components are the item category (5 respondents) and the item name (5 respondents).

Figure 3.9: Preferred platform to access UTAR lost and found information
 39

Based on Figure 3.8, 53.3% of respondents prefer to use web applications to

access lost and found information whereas 46.7% of respondents prefer to use mobile
applications. We can see that the percentage of web application and mobile application
are almost the same. Some respondents prefer to use web applications as they do not
require to install another application on mobile. However, some respondents prefer
mobile applications as they can access the lost and found information anytime no
matter where they are. Therefore, a cross-platform application can be developed to
fulfill the needs of all respondents.

What are the features you expect in a lost and found application?
30 responses

Receive notification if items found

Well-organized items. Able to filter items.

Check who has claimed the item

Able to filter the lost items

User can see the return info of lost item.

Directly show the item images.

Search feature.

Search, filter and sort items

Search by keywords

Can access information anytime

Check items current status

Can tag other user.

Show lost and found items photos

Students can directly post advertisements in app. No need to hand over to

department as some students are very lazy.

Register by student id

User who lost their item can also post picture to find back their lost item.
 40

Can search based on keywords

Can get the contact of finder of lost item.

User friendly interface.

Can stated which item is already found

Allow students to post lost and found items

Can view & update lost and found items immediately.

Easy and convenient to use

Item filter

Can match the lost item image

Location of my item

Make appointment if I want to get back my items at DSS

Able to organize all items in an application

rules for disposal if no one claims a found item.

Can filter items for better search

Figure 3.10: Expected features in lost and found application

Based on Figure 3.9, the main expected features can be concluded as listed
below:
Table 3.2: Main Expected Features in Lost and Found Application
Expected Features Number of Respondents
Clear and well-organized lost and found 13 (43.3%)
information
Search and filter items 8 (26.7%)
Allow student to report lost and found items 3 (10.0%)
User-friendly interface 2 (6.7%)
High accessibility 2 (6.7%)
Make appointment before claim back items 1 (3.3%)
Notification 1 (3.3%)
 41

Based on Table 3.2, 13 respondents (43.3%) expect to have a clear and well-
organized lost and found information in the application so they can have a better view
on all items. 8 respondents think that search and filter functions are important in a lost
and found application. Furthermore, 3 respondents also suggest to allow students to
report their lost and found items on the application. It is because some of the students
are too lazy to hand over the items to DSS. By doing so, it increases the willingness of
students to report anything they found around UTAR. Few respondents also suggest
to have a user-friendly interface (2 respondents), a high accessibility system (2
respondents), make an appointment before claim back items (1 respondent) as well as
the notification function (1 respondent).

Figure 3.11: Confidence level on the positive impact of search functionality towards
the deliverability of lost and found information

Based on Figure 3.10, most of the respondents (93.3%) believe that an accurate
search functionality in application can improve the deliverability of lost and found
information to students. Only 6.7% of respondents hold the opposite views. An
accurate search functionality means that students can retrieve the lost and found items
accurately based on the selected search criteria such as keywords, item categories or
date range. The result shows that the respondents have a high confidence level on the
positive impact of search functionality towards the deliverability of lost and found
information to students.
 42

3.2.4 Development Tools

In this project, various tools were used to implement the system for both web
application and mobile application. All development tools will be discussed in this
section.

Figure 3.12: Development Tools

i. Wamp Server
Wamp Server is a web development platform that allows us to create a dynamic
web application with Apache, PHP and MySQL (WampServer, n.d.). The
features of Apache, PHP and MySQL are explained below.
 Apache: Apache is a HTTP web server
 PHP: PHP is a scripting language that is used for web development.
 MySQL: MySQL is a database management system that is used to store
all data

ii. Laravel
Laravel is a free, open-source PHP framework intended for web application
development by adopting the model-view-controller (MVC) architectural
 43

pattern (Laravel, n.d.). A consistent API and predictable structures are provided
by Laravel framework (Stauffer, 2019). According to Kaluža, Kalanj and
Vukelić (2019), Laravel has large communities that can respond to the issues
quickly. Therefore, developers can learn faster as there are more sufficient
documentation and guidelines provided in Laravel communities.

iii. React Native

React native is an open-source framework for mobile application development.
The developer can create a native mobile application for Android and IOS
using React Native (React Native, n.d.). Furthermore, React Native enables the
developer to build the application faster as they can reload the application
instantly, instead of recompiling it.

iv. Android Studio

Android Studio is an integrated development system (IDE) for Android
operating systems. It includes the emulators for different types of Android
devices such as Android smartphones or Android Tablets for developers to test
on their application (React Native, n.d.).

v. Atom
Atom is a text and source code editor. The most attractive feature of Atom is
the GitHub package is bundled with Atom so developers can directly create
new branches, push and pull as well as solve the merge conflicts in Atom
(Atom, n.d.).

3.2.5 Quick Design

A storyboard was developed to show the system flow. The storyboard describes the
user interactions with the system as well as enables developers to have a better
understanding of system flow. The storyboard is attached to Appendix C.
 44

3.3 Iteration Process

The iteration process is feature-driven. New features will be added for each iteration
process. There are 4 main phases for each iteration, which are design, prototyping,
evaluation and refining.

3.3.1 First Iteration

For the first iteration, the main features such as view and search lost and found
information, claim lost and found items, report lost and found items as well as book
unclaimed items was developed for web application. The iteration can be separated
into 4 main phases:
i. Design phase
A storyboard was developed to have a better view on user interactions with the
system. The interfaces of web application were developed in this phase.
ii. Prototyping phase
A prototype for web application was developed based on the storyboard in the
design phase. The prototype should consist of the system flow from one screen
to another screen.
iii. Evaluation phase
5 users were invited to evaluate the prototype developed in the previous phase.
The feedback from users was collected and analysed for better improvements.
iv. Refining phase
The feedback analysis was summarised to determine the section to be refined.
Then, the prototype was refined.

3.3.2 Second Iteration

For the second iteration, new features such as login, manage found item, manage
unclaimed item as well as manage claim were added. The iteration can be separated
into 4 main phases.
i. Design phase
After the previous prototype is refined, new features were added into this phase.
A storyboard is developed and the interfaces of web application were
developed based on the added features in this phase.
ii. Prototyping phase
 45

Additional features were added into the prototype for web application.
iii. Evaluation phase
5 users were invited to evaluate the prototype with added features. Another
feedback from users was collected and analysed for better improvements.
v. Refining phase
The feedback analysis was summarised to determine the section to be refined.
Then, the prototype was refined.

3.3.3 Third Iteration

For the third iteration, the main features in the first iteration were developed for the
mobile application. The iteration can be separated into 4 main phases:
i. Design phase
The interfaces for mobile application were developed in this phase based on
the storyboard in the first iteration.
ii. Prototyping phase
A prototype for mobile application was developed based on the storyboard in
the design phase. The prototype should consist of the system flow from one
screen to another screen.
iii. Evaluation phase
5 users were invited to evaluate the prototype developed in the previous phase.
The feedback from users was collected and analysed for better improvements.
iv. Refining phase
The feedback analysis was summarised to determine the section to be refined.
Then, the prototype was refined.

3.4 Development and Testing

During the development phase, the web application will be implemented first as it is
the main platform for both staff and students to perform CRUD operation. After the
features of the web application was completed, the features of mobile application will
be implemented subsequently.
During the testing phase, various testing was conducted to ensure the quality
of the system such as unit testing, integration testing and user acceptance testing. All
types of testing will be discussed in the following section.
 46

3.4.1 Unit Testing

Unit testing was performed to test on a single piece of functionality. All components
in the system were tested one by one. Test cases were developed not only to prove that
the successful build of each component, but also reveal the system bug so the potential
bug can be fixed immediately.

3.4.2 Integration Testing

Integration testing was performed to test the combination of two or more components
in the system to ensure the system flow is working correctly. Test cases for integration
testing were also developed.

3.4.3 User Acceptance Testing

For user acceptance testing, 15 users were selected to test on the web application as
well as mobile application. A short survey was conducted to collect feedback from
users. The result of the survey was analysed.

3.5 Deployment
During the deployment phase, the system for both web application and mobile
application was fully completed. All features in the system were tested with no error
and necessary bug fixing was done. The system is ready to be available for use.
 47

CHAPTER 4

4 PROJECT SPECIFICATION

4.1 Introduction
In this chapter, functional requirements were determined based on the result of the
survey conducted. The use case diagram and use case descriptions will also be shown
and described in the following section.

4.2 Functional Requirement

Register
1. The system shall require users to enter name, email, contact number, password
and confirm password to register an account.

2. The system shall send a verification mail to users to activate user accounts.

3. The system shall allow users to request for a resend email if the users have not
received a verification email.

Login
1. The system shall require users to enter email and password to login into the
system.

View and Manage Announcement

1. The system shall display all announcements in table format.

2. The system shall allow users to search announcements based on different

attributes such as posted date, subject or department.

3. The system shall display “No Record Found” if no announcement matches the
search criteria.

4. The system shall allow admins to post a new announcement.

5. The system shall require admins to enter announcement information such as

subject and content.

6. The system shall allow admins to attach at most 5 attachments in the

announcements.
 48

7. The system shall display an error message if users do not provide all
information required.

8. The system shall allow admins to modify the announcements.

9. The system shall allow to archive the announcements.

10. The system shall display a confirmation dialog box if the admins clicks on the
archive button.

View Found Item

1. The system shall display item image, date found and location found in
multirow card format.

2. The system shall allow users to filter items by item category.

3. The system shall allow users to filter items by selected date range.

4. The system shall allow users to search items by keyword.

5. The system shall display “No Record Found” if no item matches the search
criteria.

6. The system shall allow users to click on the item card to navigate to the detailed
page.

7. In the detailed page, the system shall display item image, item name, item
category, description, date found, location found and current status.

Claim Item
1. The system shall display item information and user’s personal information.

2. The system shall require users to enter the claim date.

3. The system shall allow users to submit the claim form after the claim date is
selected.

4. The system shall change the item status from “Available” to “Pending” if the
claim form is submitted.

5. The system shall display an error message if users do not select the claim date.
 49

View Lost Case

1. The system shall display item image, date lost and possible location in
multirow card format.

2. The system shall allow users to filter items by item category.

3. The system shall allow users to filter items by selected date range.

4. The system shall allow users to search items by keyword.

5. The system shall display “No Record Found” if no item matches the search
criteria.

6. The system shall allow users to click on the item card to navigate to the detailed
page.

7. In the detailed page, the system shall display item image, item name, item
category, description, possible location, date lost and owner information.

Report Lost Item

1. The system shall require users to enter item name, item category, description,
possible location and date lost for lost item.

2. The system shall require users to upload the image of the lost item.

3. The system shall allow users to submit the report form after all information are
provided.

4. The system shall display an error message if users do not provide all required
information.

View Item for Sale

1. The system shall display the selling item image and current price in multirow
card format.

2. The system shall allow users to filter items by item category.

3. The system shall allow users to search items by keyword.

4. The system shall allow users to click on the item card to navigate to the detailed
page.
 50

5. In the detailed page, the system shall display all information of the item such
as item image, item name, item category, description, starting price, current
price and bid end date.

6. The system shall allow users to view all bids for the selling items.

7. The system shall allow users to enter the bid amount for the selling items.

8. The system shall display an error message if the bid amount entered by users
is lower than or equal to the current price.

9. The system shall change the value of the current bid after users place a new bid
amount.

Manage Found Item

1. The system shall display item id, item name, item image, item category,
description, location found, date found, person to claim item, location to claim
the item and current status in table format.

2. The system shall allow admins to search the item based on different attributes.

3. The system shall display “No Record Found” if no item matches the search
criteria.

4. The system shall allow admins to add a new found item.

5. The system shall require admins to enter item information such as item name,
item category, description, location found, date found, person to claim item and
the location to claim item.

6. The system shall require the admins to upload the item image.

7. The system shall allow admins to update a new found item after all information
are provided.

8. The system shall display an error message if admins do not provide all required
information.

9. The system shall set the item status as “Available” as default once a new item
is added.

10. The system shall allow admins to modify the item information.
 51

11. The system shall allow admins to archive the item.

12. The system shall display a confirmation dialog box if the admins clicks on the
archive button.

13. The system shall set the item status as “Expired” if the item is expired.

Manage Claim
1. The system shall display the claim records such as claim id, item id, item name,
item image, item category, claim date, owner name, email, contact number and
current status in table format.

2. The system shall allow admins to search the claim records based on different
attributes.

3. The system shall display “No Record Found” if no claim record matches the
search criteria.

4. The system shall allow admins to change the claim status from “Pending” to
“Claimed” or “No show”.

Manage Item for Sale

1. The system shall display a list of expired items which are not being approved
to sell yet.

2. The system shall allow admins to determine the starting bid and bid end date
to approve the item for sale.

3. The system shall set the item status as “Selling” as default once a new item is
approved for sale.

4. The system shall allow admins to view all bids of the selling item.

5. The system shall set the selling item status as “Closed” after the bid end date.

6. The system shall allow admins to determine the final winner of auction after
the bid end date.

7. The system shall allow admins to modify the selling item information.

8. The system shall allow admins to archive the selling item.

 52

9. The system shall display a confirmation dialog box if the admins clicks on the
archive button.

4.3 Use Case Diagram

Figure 4.1: Use Case Diagram

 53

4.4 Use Case Description

Table 4.1: Register Use Case

Use Case Name: Register ID: 1 Importance Level: High
Primary Actor: Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Staff – wants to register a new account
Student – wants to register a new account
Brief Description: This use case describes how staff or student registers a new
account
Trigger: Staff or student enters the system.
Type: External
Relationships:
Association: Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The staff or student enters the system.
2. The staff or student enters the name, email, contact number, password and
confirm password.
3. The staff or student clicks the ‘Register’ button.
4. The system sends a verification mail to staff or student.
4.1 If the staff or student clicks the link provided in verification mail, the
account is verified.
4.2 If the staff or student does not click the link provided in verification mail,
the account is not verified.
Subflows:
Alternate / Exceptional Flows:
2a: If the name, email, contact number, password and confirm password are invalid,
an error message will be shown.
 54

Table 4.2: Login Use Case

Use Case Name: Login ID: 2 Importance Level: High
Primary Actor: Admin, Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to login into the system as admin.
Staff – wants to login into the system.
Student – wants to login into the system.
Brief Description: This use case describes how admin, staff or student logins into
the system.
Trigger: Admin, staff or student enters the system.
Type: External
Relationships:
Association: Admin, Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
5. The admin, staff or student enters the system.
6. The admin, staff or student enters the email and password.
7. The admin, staff or student clicks the ‘Login’ button.
3.1 Verification of account is performed. (S-1)
8. The admin, staff or student login into the system.
Subflows:
S-1: Verification of account
1. The system sends email and password to the server.
2. The system retrieves the password of the email from the database.
3. The system checks if the password entered by admin is correct.
4. The system checks if the account is verified.
5. The system proceeds to the home page.
Alternate / Exceptional Flows:
S-1, 2a: If the email does not exist in the database, an error message will be shown.
S-1, 3a: If the password is incorrect, an error message will be shown.
S-1, 4a: If the account is not verified, the system displays a resend email page
 55

Table 4.3: View Found Item Use Case

Use Case Name: View Found Item ID: 3 Importance Level: High
Primary Actor: Admin, Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to view all found items.
Staff – wants to view all found items.
Student – wants to view all found items.
Brief Description: This use case describes how admin, staff or student views all
found items.
Trigger: Admin, staff or student enters the home page.
Type: External
Relationships:
Association: Admin, Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The admin, staff or student enter the home page.
2. The admin, staff or student select “Item Found” section.
3. The system displays all item found with detailed information.
3.1 If the current user is admin, the system displays all detailed information
of the item in table format.
3.2 If the current user is staff or student, the system displays item image, date
found and location found in multirow card format.
4. The system allows the staff or student to click the item to navigate to the
detailed page.
5. The system displays item image, item name, item category, description,
location found, date found and current status in the detailed page.
5.1 If the current user is staff or student, the system displays a “Claim”
button.
5.2 If the current user is admin, the system does not display a “Claim” button.
Subflows:
Alternate / Exceptional Flows:
 56

Table 4.4: View Lost Case Use Case

Use Case Name: View Lost Case ID: 4 Importance Level: High
Primary Actor: Admin, Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to view all lost cases.
Staff – wants to view all lost cases.
Student – wants to view all lost cases.
Brief Description: This use case describes how admin, staff or student views all lost
cases.
Trigger: Admin, staff or student enters the home page.
Type: External
Relationships:
Association: Admin, Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The admin, staff or student enter the home page.
2. The admin, staff or student select “Lost Case” section.
3. The system displays all lost cases with detailed information.
3.1 If the current user is admin, the system displays all detailed information
of the item in table format.
3.2 If the current user is staff or student, the system displays item image, date
lost and possible location in multirow card format
4. The system allows the staff or student to click the item to navigate to the
detailed page.
5. The system displays item image, item name, item category, description,
possible location, date lost, current status, and contact info of owner in the
detailed page.
Subflows:
Alternate / Exceptional Flows:
 57

Table 4.5: View Item for Sale Use Case

Use Case Name: View Item for Sale ID: 5 Importance Level: High
Primary Actor: Admin, Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to view all items for sale.
Staff – wants to view all items for sale.
Student – wants to view all items for sale.
Brief Description: This use case describes how admin, staff or student views all
items for sale.
Trigger: Admin, staff or student enters the home page.
Type: External
Relationships:
Association: Admin, Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The admin, staff or student enter the home page.
2. The admin, staff or student select “Item for Sale” section.
3. The system displays all items for sale with detailed information.
3.1 If the current user is admin, the system displays all detailed information
of the item in table format.
3.2 If the current user is staff or student, the system displays item image and
current bid price in multirow card format
4. The system allows the admin, staff or student to click the item to navigate to
the detailed page.
5. The system displays item image, item name, item category, description,
starting bid price, current bid price and bid end date in the detailed page.
6. The system displays all bids of the item in the detailed page.
Subflows:
Alternate / Exceptional Flows:
 58

Table 4.6: View Announcement Use Case

Use Case Name: View Announcement ID: 6 Importance Level: High
Primary Actor: Admin, Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to view all announcements.
Staff – wants to view all announcements.
Student – wants to view all announcements.
Brief Description: This use case describes how admin, staff or student views all
announcements.
Trigger: Admin, staff or student enters the home page.
Type: External
Relationships:
Association: Admin, Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The admin, staff or student enter the home page.
2. The admin, staff or student select “Announcement” section.
3. The system displays date posted, announcement subject and department in
table format
4. The system allows admin, staff or student to click the announcement subject
to navigate to the detailed page
5. The system displays the announcement subject, announcement content and
attachments in the detailed page.
6. The system allows admin, staff or student to click the attachment link to
navigate to attachment page
7. The system displays the content of attachment file.
Subflows:
Alternate / Exceptional Flows:
 59

Table 4.7: Claim Item Use Case

Use Case Name: Claim Item ID: 7 Importance Level: High
Primary Actor: Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Staff – wants to claim back the item.
Student – wants to claim back the item.
Brief Description: The use case describes how the staff or student claims back the
item.
Trigger: Staff or student clicks on the “Claim” button.
Type: External
Relationships:
Association: Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays the item information
2. The system displays the personal information of staff or student.
3. The staff or student select the claim date from date picker
4. The staff or student clicks on the “Submit” button
5. The system updates item status from “Available” to “Pending”.
Subflows:
Alternate / Exceptional Flows:
3a: If the staff or student select invalid claim date, an error message will be shown.

Table 4.8: Report Lost Item Use Case

Use Case Name: Report Lost Item ID: 8 Importance Level: High
Primary Actor: Staff, Student Use Case Type: Detail, Essential
Stakeholders and Interests:
Staff - wants to report the lost item.
Student - wants to report the lost item.
 60

Brief Description: The use case describes how the staff or student reports the lost
item.
Trigger: Staff or student enters the home page
Type: External
Relationships:
Association: Staff, Student
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The admin, staff or student enter the home page.
2. The admin, staff or student select “Report Your Lost” section.
3. The system displays a report form.
4. The staff or student enters the lost item information such as item name, item
category, description, possible location lost and date lost.
5. The staff or student upload the item image
6. The student clicks on the “Submit” button.
7. The system updates a new lost case.
Subflows:
Alternate / Exceptional Flows:
4a: If the staff or student enters an invalid information, an error message will be
shown.

Table 4.9: Bid Selling Item Use Case

Use Case Name: Bid Selling Item ID: 9 Importance Level: High
Primary Actor: Staff, Student Use Case Type: Detail, essential
Stakeholders and Interests:
Staff – wants to bid the selling item.
Student – wants to bid the selling item.
Brief Description: This use case describes how the staff or student bid the item.
Trigger: Staff or student enters the detailed page of the item for sale
Type: External
Relationships:
 61

Association: Staff, Student

Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays item image, item name, item category, description,
starting bid price, current bid price and bid end date.
2. The staff or student enters a new bid amount.
3. The staff or student clicks on the “Bid” button.
4. The system displays a confirmation box
5. The staff or student selects “OK”
6. The system updates the new bid.
Subflows:
Alternate / Exceptional Flows:
2a: If the bid amount is lower than or equal to the current bid price, an error message
will be shown.
5a: If the staff or student selects “Cancel” for confirmation box, the system will
cancel the new bid.

Table 4.10: Manage Found Item Use Case

Use Case Name: Manage Found Item ID: 10 Importance Level: High
Primary Actor: Admin Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to create, update and archive the found item.
Brief Description: This use case describes how the admin creates, updates and
archives the found item.
Trigger:
1. Admin clicks on the “Add New Item” button in the item found page.
2. Admin clicks on the edit icon of the item.
3. Admin clicks on the archive icon of the item.
Type: External
Relationships:
Association: Admin
 62

Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all item information in table format.
2. The system displays an “Add New Item” button in the home page.
2.1 If the admin clicks on the “Add” button, add new item is performed. (S-
1)
3. The system displays an edit icon on each item.
2.1 If the admin clicks on the edit icon, edit item is performed. (S-2)
4. The system displays an archive icon each item.
5. 3.1 If the admin clicks on the archive icon, archive item is performed. (S-3)
Subflows:
S-1: Add New Item
1. The system displays an add new item form.
2. The admin enters item information such as item name, item category,
description, location found, date found.
3. The admin uploads the item image.
4. The admin clicks on the “Submit” button.
5. The system updates a new item.
S-2: Edit Item
1. The system displays the item name, item category, description, location
found, date found and the item image.
2. The system allows admin to select which information to edit.
2.1 If the admin selects item name, the admin can enter a new item name in
the text box.
2.2 If the admin selects item category, the admin can select a new item
category from the drop-down list.
2.3 If the admin selects description, the admin can enter a new description
in the text box.
2.4 If the admin selects location found, the admin can enter a new location
found in the text box.
 63

2.5 If the admin selects date found, the admin can enter a new date found in
the text box.
2.6 If the admin selects item image, the admin can upload a new item image.
3. The admin clicks on the “Submit” button.
4. The system updates the item with new details.
S-3: Archive Item
1. The system displays the confirmation dialog box.
1.1 If the admin selects “OK”, the item is archived from the system.
1.2 If the admin selects “Cancel”, the archive action is cancelled.
Alternate / Exceptional Flows:
S-1, 2a: If the admin enters invalid information, an error message will be shown.
S-2, 2a: If the admin enters invalid information, an error message will be shown.

Table 4.11: Manage Claim Use Case

Use Case Name: Manage Claim ID: 11 Importance Level: High
Primary Actor: Admin Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to view, update and archive claim records.
Brief Description: This use case describes how the admin views, updates and
archives claim records.
Trigger:
1. Admin enters the claim record page.
2. Admin clicks on the “Claimed” button of the claim record.
3. Admin clicks on the “Archive” button of the claim record.
Type: External
Relationships:
Association: Admin
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all the claim records in the claim record page.
2. The system displays an “Claimed” button on each pending claim record.
 64

2.1 If the admin clicks on the “Claimed” button, claim item is performed.
(S-1)
3. The system displays an archive icon on each claim record.
3.1 If the admin clicks on the archive icon, archive claim record is
performed. (S-2)
Subflows:
S-1: Claim Item
1. The system displays the item information
2. The system displays the information of the person who claim the item.
3. The admin clicks “Confirm” button.
4. The system changes the claim status from “Pending” to “Claimed”
S-2: Archive Claim Record
1. The system displays the confirmation dialog box.
1.1 If the admin selects “Yes”, the claim record is archived from the system.
1.2 If the admin selects “No”, the archive action is cancelled.
Alternate / Exceptional Flows:

Table 4.12: Manage Item for Sale Use Case

Use Case Name: Manage Item for Sale ID: 12 Importance Level: High
Primary Actor: Admin Use Case Type: Detail, Essential
Stakeholders and Interests:
Admin – wants to manage item for sale.
Brief Description: The use case describes how the admin manages items for sale.
Trigger: Admin enters the item for sale page
Type: External
Relationships:
Association: Admin
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all the expired items.
2. The system displays “Approve for Sale” button for each expired item.
 65

2.1 If the admin clicks on the “Approve for Sale” button, approve for sale is
performed. (S-1)
3. The admin displays an archive button for each expired item.
3.1 If the admin clicks on the archive icon, archive expired item is
performed. (S-2)
4. The system displays all items for sale.
5. The system displays an edit icon for each item for sale.
5.1 If the admin clicks on the edit icon, edit item for sale is performed. (S-3)
6. The system displays an archive icon for each item for sale.
6.1 If the admin clicks on the archive icon, archive item for sale is performed.
(S-4)
7. The system displays “View all bids” button for each item for sale.
7.1 If the admin clicks on the “View all bids” button, view all bids is
performed. (S-5)
Subflows:
S-1: Approve for Sale
1. The system displays expired item information.
2. Admin enters the starting bid price and bid end date.
3. Admin clicks on the “Submit” button.
4. The system updates the item status from “Expired” to “Selling”
S-2: Archive Expired Item
1. The system displays the confirmation dialog box.
1.1 If the admin selects “Yes”, the expired item is archived from the system.
1.2 If the admin selects “No”, the archive action is cancelled.
S-3: Edit Item for Sale
1. The system displays starting bid price and bid end date of the item for sale.
2. The system allows admin to select which information to edit.
2.1 If the admin selects the starting bid, the admin can enter a new starting
bid in the text box.
2.2 If the admin selects the bid end date, the admin can enter a new bid end
date.
S-4: Archive Item for Sale
1. The system displays the confirmation dialog box.
 66

1.1 If the admin selects “Yes”, the item for sale is archived from the system.
1.2 If the admin selects “No”, the archive action is cancelled.
Alternate / Exceptional Flows:
S-1, 2a: If the admin enters invalid information, an error message will be shown.
S-3, 2a: If the admin enters invalid information, an error message will be shown.

Table 4.13: Manage Announcement Use Case

Use Case Name: Manage Announcement ID: 13 Importance Level: High
Primary Actor: Admin Use Case Type: Detail, essential
Stakeholders and Interests:
Admin – wants to post, update and archive the announcement
Brief Description: This use case describes how the admin posts, updates and
archives the announcement.
Trigger:
1. Admin clicks on the “Post New Announcement” button in the announcement
page.
2. Admin clicks on the edit icon of the announcement.
3. Admin clicks on the archive icon of the announcement.
Type: External
Relationships:
Association: Admin
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all announcements in table format.
2. The system displays an “Post New Announcement” button in the home page.
2.1 If the admin clicks on the “Post New Announcement” button, post new
announcement is performed. (S-1)
3. The system displays an edit icon on each announcement
2.1 If the admin clicks on the edit icon, edit announcement is performed. (S-
2)
4. The system displays an archive icon each announcement.
 67

5. 3.1 If the admin clicks on the archive icon, archive announcement is

performed. (S-3)
Subflows:
S-1: Post New Announcement
1. The system displays a post new announcement form.
2. The admin enters announcement subject and content.
3. The admin uploads the attachment.
4. The admin clicks on the “Post” button.
5. The system updates a new announcement.
S-2: Edit Announcement
1. The system displays the announcement subject and content.
2. The system allows admin to select which information to edit.
2.1 If the admin selects announcement subject, the admin can enter a new
announcement subject.
2.2 If the admin selects announcement content, the admin can enter a new
announcement content
2.3 If the admin selects announcement attachment, the admin can upload a
new attachment.
3. The admin clicks on the “Submit” button.
4. The system updates the announcement with new details.
S-3: Archive Item
1. The system displays the confirmation dialog box.
1.3 If the admin selects “OK”, the announcement is archived from the
system.
1.4 If the admin selects “Cancel”, the archive action is cancelled.
Alternate / Exceptional Flows:
S-1, 2a: If the admin enters invalid information, an error message will be shown.
S-2, 2a: If the admin enters invalid information, an error message will be shown.

Table 4.14: Manage Staff Admin Account Use Case

Use Case Name: Manage Staff Admin Account ID: 14 Importance Level: High
Primary Actor: System Admin Use Case Type: Detail, essential
Stakeholders and Interests:
 68

System Admin – wants to create, update and delete staff admin account.
Brief Description: This use case describes how the system admin posts, updates and
deletes the staff admin account.
Trigger:
1. System admin clicks on the “Create New Staff Account” button in the staff
admin account page.
2. System admin clicks on the edit icon of the staff admin account.
3. System admin clicks on the archive icon of the staff admin account.
Type: External
Relationships:
Association: System Admin
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all staff admin account in table format.
2. The system displays an “Create New Staff Account” button in the home
page.
2.1 If the system admin clicks on the “Create New Staff Account” button,
create new staff admin account is performed. (S-1)
3. The system displays an edit icon on each staff admin account
2.1 If the system admin clicks on the edit icon, edit staff admin account is
performed. (S-2)
4. The system displays a delete icon each staff admin account.
5. 3.1 If the system admin clicks on the delete icon, delete staff admin account
is performed. (S-3)
Subflows:
S-1: Create New Staff Admin Account
1. The system displays a create new staff account form.
2. The system admin enters staff department, name, email and contact number.
3. The system admin clicks on the “Submit” button.
4. The system admin creates a new staff admin account.
S-2: Edit New Staff Admin Account
 69

1. The system displays the department, name, email and contact number.
2. The system allows system admin to select which information to edit.
2.4 If the system admin selects department, the system admin can enter a
new department.
2.5 If the system admin selects name, the system admin can enter a new
name.
2.6 If the system admin selects email, the system admin can upload a new
email.
2.7 If the system admin selects contact number, the system admin can upload
a new contact number.
3. The system admin clicks on the “Submit” button.
4. The system updates the user account with new details.
S-3: Delete Staff Admin Account
2. The system displays the confirmation dialog box.
1.5 If the system admin selects “OK”, the user account is deleted from the
system.
1.6 If the system admin selects “Cancel”, the delete action is cancelled.
Alternate / Exceptional Flows:
S-1, 2a: If the system admin enters invalid information, an error message will be
shown.
S-2, 2a: If the system admin enters invalid information, an error message will be
shown.

Table 4.15: Customize Item Category Use Case

Use Case Name: Customize Item Category ID: 15 Importance Level: High
Primary Actor: System Admin Use Case Type: Detail, essential
Stakeholders and Interests:
System Admin – wants to create, update and delete item category.
Brief Description: This use case describes how the system admin creates, updates
and deletes the item category
Trigger:
1. System admin clicks on the “Add New Item Category” button in the item
category page.
 70

2. System admin clicks on the edit icon of the item category.

3. System admin clicks on the archive icon of the item category.
Type: External
Relationships:
Association: System Admin
Include: -
Extend: -
Generalization: -
Normal Flow of Events:
1. The system displays all item categories in table format.
2. The system displays an “Add New Item Category” button in the home page.
2.1 If the system admin clicks on the “Add New Item Category” button,
create new item category is performed. (S-1)
3. The system displays an edit icon on each item category.
2.1 If the system admin clicks on the edit icon, edit item category is
performed. (S-2)
4. The system displays a delete icon each item category.
5. 3.1 If the system admin clicks on the delete icon, delete item category is
performed. (S-3)
Subflows:
S-1: Create New Item Category
1. The system admin enters new item category.
2. The system admin clicks on the “Submit” button.
3. The system admin creates a new item category
S-2: Edit New Item Category
1. The system displays current item category.
2. The system admin enters a new item category.
3. The system admin clicks on the “Submit” button.
4. The system updates the item category.
S-3: Delete Item Category
3. The system displays the confirmation dialog box.
1.7 If the system admin selects “OK”, the item category is deleted from the
system.
 71

1.8 If the system admin selects “Cancel”, the delete action is cancelled.
Alternate / Exceptional Flows:
S-1, 2a: If the system admin enters invalid information, an error message will be
shown.
S-2, 2a: If the system admin enters invalid information, an error message will be
shown.
 72

CHAPTER 5

5 SYSTEM DESIGN

5.1 Introduction
In this chapter, system architecture design, navigation design and database design will
be discussed based on the functional requirements which are determined in the
previous chapter. Furthermore, the activity diagram will also be illustrated in the
following section to show the system flow.

5.2 System Architecture Design

Figure 5.1 shows the architecture design of UTAR lost and found management system.
It implements the Model-View-Controller (MVC) framework as the structure of
system. It means the system architecture is separated into 3 main components which
are model, view and controller.
Web browser and mobile acts as view in MVC framework, which is the client-
side that displays the data on the user interface. Application Programming Interface
(API) acts as a controller to handle all CRUD operations from the user interface.
Furthermore, MySQL database acts as the model to manage all data as well as the
relationship between the database table.

Figure 5.1: System Architecture Design

 73

5.3 User Interface Navigation Design

The navigation design shows the ways of the user to navigate through the system. The
root page of the system starts from the login page. After the user login into the system,
they will be redirected to their homepage. The homepage displays links to various
pages so users can perform different operations to the database. Figure 5.2 and Figure
5.3 illustrate the navigation design for both web and mobile platforms.

Figure 5.2: Navigation Design for Web

Figure 5.3: Navigation Design for Mobile

 74

5.4 Database Design

5.4.1 Entity Relationship Diagram

Figure 5.4: Entity Relationship Diagram

 75

Table 5.1: Description of Entity Relationship Diagram

Table Name Description
users Information about all system users, which are system admin,
UTAR staff and UTAR students
found_items Information about all found items
claims Information about all claim record of the found items
lost_items Information about all report cases of lost item
selling_items Information about all expired items for sell
bids Information about all bids of the selling items
announcements Information about all announcements posted
attachments Information about all attachments of the announcements
settings Information about all account settings
categories Information about all item categories

5.4.2 Data Dictionary

Table 5.2: Data Dictionary for ‘users’ Entity
Attribute Description Data Type PK/FK NULL
id Unique identification for all int PK
system users
name Name of system users varchar
email Email of system users varchar
contactNo Contact Number of system varchar
users
role Role of system users varchar
department Department of system users varchar √
password Password for the system users varchar
to login
remember_token ‘Remember me’ function which varchar √
keep the user authenticated
until they manually logout
created_at Timestamp when the user timestamp √
account was first created
 76

updated_at Timestamp of the most recent timestamp √

change to the record
verified Status of email verification tinyint

Table 5.3: Data Dictionary for ‘found_items’ Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all int PK
found items
item_id Unique identification for all varchar
found items in user view
name Name of the found item varchar
image Image path of the found varchar
item
category Category of the found item varchar
description Description of the found varchar
item
location_found Location of the item found varchar
date_found Date for the item found varchar
item_holder_name Name of the person who varchar
currently hold the item
current_location Currently location of the varchar
item
item_holder_dept_id User who create the found varchar FK
item record
status Current status of the item varchar
found
created_at Timestamp when the found timestamp √
item record was first created
updated_at Timestamp of the most timestamp √
recent change to the found
item record
 77

Table 5.4: Data Dictionary for ‘claims’ Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all claim int PK
records
claim_id Unique identification for all claim varchar
records in user view
claim_date Date for the owner to claim back date
their item
status Current status of the claim record varchar
user_id Item owner int
found_item_id Item to be claimed int FK
created_at Timestamp when the claim record timestamp √
was first created
updated_at Timestamp of the most recent timestamp √
change to the claim record

Table 5.5: Data Dictionary for ‘lost_items Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all int PK
report cases
item_id Unique identification for all varchar
report cases in user view
name Name of the lost item varchar
image Image path of the lost item varchar
category Category of the lost item varchar
description Description of the lost item varchar
possible_location Possible location of the lost varchar
item
date_lost Date for the item lost varchar
status Current status of the lost item varchar
user_id User who report lost item int FK
 78

created_at Timestamp when the report timestamp √

case record was first created
updated_at Timestamp of the most recent timestamp √
change to the report case record

Table 5.6: Data Dictionary for ‘selling_items’ Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for int PK
selling items
bid_starting_price Starting price of the selling decimal
item
bid_current_price Current price of the selling decimal
item
bid_end_date End date of the auction date
status Current status of the selling varchar
item
found_item_id Found item of the selling int FK
item belongs to
created_at Timestamp when the selling timestamp √
item record was first created
updated_at Timestamp of the most timestamp √
recent change to the selling
item record

Table 5.7: Data Dictionary for ‘bids’ Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all bids int PK
for the items
bid_amount Amount of the bid for the item decimal
status Current status of the bid varchar
selling_item_id Selling item of the bid belong to int FK
 79

user_id User who place the bid int FK

created_at Timestamp when the bid record timestamp √
was first created
updated_at Timestamp of the most recent timestamp √
change to the bid record

Table 5.8: Data Dictionary for ‘announcements Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all int PK
announcements
announcement_id Unique identification for all varchar
announcements in user view
subject Title of the announcement varchar
content Content of the announcement longtext FK
status Current status of the varchar
announcement
user_id User who post the int FK
announcement
created_at Timestamp when the timestamp √
announcement record was first
created
updated_at Timestamp of the most recent timestamp √
change to the announcement
record

Table 5.9: Data Dictionary for ‘attachments’ Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for int PK
attachments in the
announcements
name Path of the attachment varchar
 80

announcement_id Announcement of the int FK

attachment belongs to
created_at Timestamp when the timestamp √
attachment record was first
created
updated_at Timestamp of the most recent timestamp √
change to the attachment
record

Table 5.10: Data Dictionary for ‘settings Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all int PK
settings by system users
expired_duration Customized duration for the int
item to be expired
user_id User who create the setting int FK
created_at Timestamp when the setting timestamp √
record was first created
updated_at Timestamp of the most recent timestamp √
change to the setting record

Table 5.11: Data Dictionary for ‘categories Entity

Attribute Description Data PK/FK NULL
Type
id Unique identification for all item int PK
categories
name Name of item category varchar
created_at Timestamp when the categories timestamp √
record was first created
updated_at Timestamp of the most recent timestamp √
change to the categories record
 81

5.5 Activity Diagram

The objective of the activity diagram is to illustrate the user flow of UTAR lost and
found management system. In the following section, there are 15 activity diagrams
which represent different features of UTAR lost and found management system.

Figure 5.5: Activity Diagram : Login

 82

Figure 5.6: Activity Diagram : Register

 83

Figure 5.7: Activity Diagram : View and Search Announcement

 84

Figure 5.8: Activity Diagram : Manage Announcement

 85

Figure 5.9: Activity Diagram : View and Search Found Item

 86

Figure 5.10: Activity Diagram : Manage Item Found

 87

Figure 5.11: Activity Diagram : Claim Item

 88

Figure 5.12: Activity Diagram : Manage Claim

 89

Figure 5.13: Activity Diagram : View Lost Case

 90

Figure 5.14: Activity Diagram : Report Lost Item

 91

Figure 5.15: Activity Diagram : View and Search Item for Sale
 92

Figure 5.16: Activity Diagram : Bid Item for Sale

 93

Figure 5.17: Activity Diagram : Manage Item for Sale

 94

Figure 5.18: Activity Diagram : Update Profile

 95

Figure 5.19: Activity Diagram : Change Password

 96

CHAPTER 6

6 SYSTEM IMPLEMENTATION

6.1 Introduction
In this chapter, the route design of the system will be listed according to the database
table. The role-based access control diagram is also provided to illustrate the rights of
3 different roles in this system. Furthermore, the final system user interface as well as
the functionalities will also be discussed with image in the following section.

6.2 Route Design

Routes are created for each user action based on the database design. Some routes
contain semicolon which represents the path parameter. The path parameter can be the
item id or user selection. All routes in the system will be listed in the following section.

Table 6.1: Route Design for ‘found_items’

Table Name: found_items
Route Description
Method: GET
/admin/ItemFound Return all found items to admin
/admin/ItemFound/edit/{id} Return found item by id on edit
page
/admin/ItemFound/search-{option}={content} Return found item by search
option and content to admin
/admin/ItemFound/create Return create found item page
/admin/ItemFound/ Update selling item status to
updateItemStatusToArchivedFromSelling/{id} ‘Archived’ by id
/admin/ItemFound/updateStatusToArchived/{id} Update found item status to
‘Archived’ by id
/ItemFound Return all available found item
to users
/ItemFound/search-keyword={keyword} Return available found items by
keyword to users
 97

/ItemFound/search-category={category} Return available found items by

category to users
/ItemFound/search-date={startdate}to{enddate} Return available found items by
start date and end date to users
/ItemFound/{id} Return available found item by
id to users
/admin/Dashboard/ItemFound Return dashboard page to show
the status of all found items
/admin/Dashboard/LostCase Return dashboard page to show
the status of all lost cases
/admin/Dashboard/ClaimRecord Return dashboard page to show
the status of all claim records
/admin/Dashboard/ItemSold Return dashboard page to show
the status of all selling items
Method: POST
/admin/ItemFound/store Create a new found item record
Method: PUT
/admin/ItemFound/update/{id} Update found item record by id

Table 6.2: Route Design for ‘lost_items’

Table Name: lost_items
Route Description
Method: GET
/admin/ItemLost Return all lost items to admin
/admin/ItemLost/search-{option}={content} Return lost item by search option
and content to admin
/admin/ItemLost/updateStatusToArchived/{id} Update lost item status to
‘Archived’ by id
/ItemLost Return all available lost item to
users
/ItemLost/edit/{id} Return lost item by id on edit page
/ItemLost/report Return create new lost item page
 98

/ItemLost/search-keyword={keyword} Return available lost items by

keyword to users
/ItemLost/search-category={category} Return available lost items by
category to users
/ItemLost/search-date={startdate}to{enddate} Return available lost items by
start date and end date to users
/ItemLost/{id} Return available lost item by id to
users
/Profile/editStatusToFound/{id} Return confirm page to update
lost item status to ‘Found’ by
Method: POST
/ItemLost/store Create a new lost item record
Method: PUT
/ItemLost/update/{id} Update lost item record by id
/Profile/updateStatusToFound/{id} Update lost item status to ‘Found’
by id

Table 6.3: Route Design for ‘selling_items’

Table Name: selling_items
Route Description
Method: GET
/admin/ItemForSell Return all selling items to
admin
/admin/ItemForSell/create/{id} Return confirm page to
approve expired item for sell
/admin/ItemForSell/edit/{id} Return selling item by id on
edit page
/admin/ItemForSell/updateStatusToArchived/{id} Update selling item status to
‘Archived’ by id
/admin/ItemForSell/ Update closed selling item
updateClosedItemStatusToArchived/{id} status to ‘Archived’ by id
/ItemForSell Return all selling items to
users
 99

/ItemForSell/search-keyword={keyword} Return selling items by

keyword to users
/ItemForSell/search-category={category} Return selling items by
category to users
/ItemForSell/{id} Return selling items by id to
users
Method: POST
/admin/ItemForSell/store/{id} Create a new selling item
record
Method: PUT
/admin/ItemForSell/update/{id} Update selling item record by
id
/admin/ItemForSell/updateStatusToSold/{id} Update selling item status to
‘Sold’ by id

Table 6.4: Route Design for ‘bids’

Table Name: bids
Route Description
Method: GET
/admin/ItemForSell/bid/{id} Return all bids by selling item
id to admin
/admin/ItemForSell/editStatusToSelected/{id} Return confirm page to update
selling item status to ‘Selected’
Method: POST
/ItemForSell/createBid/{id} Create a new bid for a selling
item
Method: PUT
/admin/ItemForSell/updateStatusToSelected/{id} Update selling item status to
‘Selected’ by id
/admin/ItemForSell/updateStatusToNoShow/{id} Update selling item status to
‘No Show by id

Table 6.5: Route Design for ‘claims’

 100

Table Name: claims

Route Description
Method: GET
/Claim/create={founditem_id} Return confirm page to claim the
found item
/admin/Claim Return all claim records to admin
/admin/Claim/search-{option}={content} Return claim records by search
option and content to admin
/admin/Claim/editStatusToClaimed/{id} Return confirm page to update claim
status to ‘Claimed’
/admin/Claim/updateStatusToArchived/{id}
/Profile Return profile page with user’s claim
records
Method: POST
/Claim/store={founditem_id} Create a new claim record for a
found item
Method: PUT
/admin/Claim/updateStatusToClaimed/{id} Update claim status to ‘Claimed’ by
id

Table 6.6: Route Design for ‘announcements’

Table Name: announcement
Route Description
Method: GET
/Announcement Return all announcements
/Announcement/search-{option}={content} Return announcements by
search option and content
/Announcement/{id} Return announcements by
id
/admin/Announcement/create Return create new
announcement page
 101

/admin/Announcement/edit/{id} Return announcement by id

on edit page
/admin/Announcement/updateStatusToArchived/{id} Update announcements
status to ‘Archived’ by id
Method: POST
/admin/Announcement/store Create an announcement
post
Method: PUT
/admin/Announcement/update/{id} Update announcement post
by id

Table 6.7: Route Design for ‘attachments’

Table Name: attachments
Route Description
Method: GET
/Attachment/{id} Return attachments by announcement id
/Attachment/delete/{id} Delete attachments

Table 6.8: Route Design for ‘settings’

Table Name: settings
Route Description
Method: GET
/Setting/edit/{id} Return setting by id on edit page
Method: PUT
/Setting/update/{id} Update setting by id

Table 6.9: Route Design for ‘users’

Table Name: users
Route Description
Method: GET
/admin/User Return all users to admin
 102

/admin/User/search- Return users by search option and content to admin

{option}={content}
/admin/User/create Return create new staff account page
/Profile/edit/{id} Return user by id on edit page
/Profile/changePassword/{id} Return change password page by user id
Method: POST
/admin/User/store Create a new staff account
/Profile/updatePassword/{id} Update user password by user id
Method: PUT
/Profile/update/{id} Update user by id

Table 6.10: Route Design for ‘category’

Table Name: category
Route Description
Method: GET
/admin/Category Return all item categories to admin
/admin/Category/create Return create new item category page
/admin/Category/edit/{id} Return edit item category page by id
/admin/Category/delete/{id} Delete item category by id

Method: POST
/admin/Category/store Create a new item category account
Method: PUT
/admin/Category/update/{id} Update item category by id

6.3 Role-Based Access Control Diagram

Role-Based Access Control was implemented in UTAR lost and found management
system. It is to ensure that every user is only authorized to certain rights based on their
roles. Figure 6.1 shows the rights for each role.
 103

Figure 6.1: Role-Based Access Control Diagram

6.4 Results and Discussions

6.4.1 Register
To login into the system, the users are required to register a new account in this module
by entering name, email, contact number, password and confirm password. Only
UTAR email which ends with “@utar.edu.my” or “@1utar.my” are allowed in this
system. Form validation is also applied for registration so all fields are required to
enter.
After users click on the “Register” button, a verification mail will be sent to
users to perform email verification. The email provides a link for users to enter the
system. If the users click on the “Complete Registration” page, the user account is
activated and they will be redirected to the login page of the system.
However, if users attempt to login into the system without email verification,
the system will request users to check their mail to activate their account. If the users
have not received a verification email or they have mistyped their email address, they
can enter a new email address to resend email.
 104

Figure 6.2: Register page

Figure 6.3: Verification mail received after registration

Figure 6.4: Resend email form

 105

Figure 6.5: Register page in mobile view

6.4.2 Login
This module verifies users with database through API. The users should enter email
and password to login into the system. The verification of email and password is
performed when the users click on the ‘Login’ button. If the email does not exist in the
database, or the password is incorrect, an error message ‘These credentials do not
match our records.’ will be shown. If the email or password is empty, an error message
‘Please fill out this field.’ will be shown.
In this system, there are 3 user roles, which are system admin, staff admin, staff
and student. Each role is authorized to certain rights. If both of the email and password
is matched, the system will verify the role of users and redirect them to their home
page respectively. The home page lists out various sections for users to click in to view
respective information.
 106

Figure 6.6: Login page

Figure 6.7: Home page from staff and student view

Figure 6.8: Home page from staff admin view

 107

Figure 6.9: Login page from mobile view

6.4.3 Announcement
This module contains all announcements posted by admin. The system displays posted
date, subject and relevant department of the announcements in table format. The search
boxes are provided on the top of the table to enable users to search specific
announcements based on different attributes such as posted date, subject and relevant
department. If users want to search the announcements by posted date, a date picker is
also provided for them to select the specific date.
Users can click on the subject to view the content of announcements. Each
announcement can attach at most 5 attachments. The attachments can be pdf file or
any image file. Users can also click on the attachments to view the content.
The admin can post a new announcement by entering the announcement’s
subject, content. Form validation is applied so the subject field and content field are
required in this section. If necessary, at most 5 attachments can be attached in the
 108

announcements. Only the person who post the announcement can edit the content of
that particular announcement. Furthermore, the admin can archive the announcements.

Figure 6.10: Announcement Page from admin view

Figure 6.11: Announcement Details Page

 109

Figure 6.12: Post new announcement page from admin view

Figure 6.13: Announcement page from mobile view

 110

6.4.4 Found Item

In this module, all items are displayed in card format with item image, item name and
the date and location found from staff and student view. Search function is provided
for staff and students in this page. Staff and students can search the item by item
category, date found and keyword. If no item matched the selected category, date range
or keyword, the system will display “No record found”. Staff and students can click
on the “Details” to view the detailed information of item such as item name, item
category, item description, date found, location found and current status with a ‘Claim’
button.
From admin view, all items are displayed in table format for better searches.
The search boxes are provided on the top of the table to enable admin to search specific
item based on different attributes. If they want to search the item by date found, a date
picker is also provided for them to select the specific date.
Furthermore, the admin can update new item by entering the item’s name,
category, description, date and location found, image, item holder name and location
to claim back the item. Form validation is applied so all fields are required to enter.
Only the person who update the item can edit the information of that particular item.
The admin can also archive the items.

Figure 6.14: Item Found page from staff and student view
 111

Figure 6.15: Item Details page from staff and student view

Figure 6.16: Item Found page from admin view

 112

Figure 6.17: Item Found page from mobile view

6.4.5 Claim Item

The staff and students can click on the ‘Claim’ button in the item details page to claim
the item. The claim page displays the item details and also their personal information
for them to check before claim. If the staff and students confirm to claim this item,
they require to select a claim date. Form validation is applied in this page so staff and
students are not allowed to select the date before today.
When the staff and students click the ‘Submit’ button, the status of the item is
changed to ‘Pending’. The item is not displayed in the item found page anymore as it
is reserved for the staff and students to claim back their item. From the admin view,
there is a new claim record.
All claim records are displayed in table format for better searches. The search
boxes are provided on the top of the table to enable admin to search specific claim
record based on different attributes. If they want to search the item by claim date, a
 113

date picker is also provided for them to select the specific date. The admin can also
archive the claim records.
If the item owner claim back their item within the claim date, the staff admin
can click on the ‘Claimed’ button to mark the claim status as ‘Claimed’. However, if
the person who submit the claim form does not claim back the item within the claim
date, the system will mark the claim status as ‘No Show’.

Figure 6.18: Claim Item page from staff and student view

Figure 6.19: Claim Item page from staff and student view
 114

Figure 6.20: Claim Record page from staff admin view

Figure 6.21: Claim Item page from mobile view

 115

6.4.6 Lost Case

In this module, all items are displayed in card format with item image, item name, date
lost and possible location from staff and student view. Search function is provided for
staff and students in this page. Staff and students can search the item by item category,
date lost and keyword. If no item matched the selected category, date range or keyword,
the system will display “No record found”. Staff and students can click on the “Details”
to view the detailed information of item such as item name, item category, item
description, date lost, passible location, current status and the contact information of
owner.
If the staff and students lost their item, they can report their item in the report
lost page by entering the item name, category, description, possible location, date lost
and item image. Form validation is applied so all fields are required to enter. Only the
person who report the item can edit the information of that particular item.
From admin view, all items are displayed in table format for better searches.
The search boxes are provided on the top of the table to enable admin to search specific
item based on different attributes. If they want to search the item by date lost, a date
picker is also provided for them to select the specific date. The admin can also archive
the record of lost case from the system.

Figure 6.22: Lost Case page from staff and student view
 116

Figure 6.23: Report Lost page from staff and student view

Figure 6.24: Lost Case page from admin view

 117

Figure 6.25: Lost Case page from mobile view

6.4.7 Item for Sale

The staff admin can set the expired duration for their updated items in the system. The
default expired duration is 30 days. It means that if the updated item is still available
without any staff or student’s claim after 30 days, the system will mark the item status
as “Expired”. All expired item will be pending for the staff admin to approve for sell
as auction format in this system. The staff admin is required to enter the starting price
and the end date of auction.
From staff and students view, all items are displayed in card format with item
image and current price. Search function is provided for staff and students in this page.
Staff and students can search the item by item category and keyword. If no item
matched the selected category or keyword, the system will display “No record found”.
Staff and students can click on the “Details” to view the detailed information of item
such as item name, item category, item description, starting price, current price and
 118

auction end date. Staff and students can also view all bids for the particular item. Staff
and students can place their bids which are more than the current bid.
After the staff and students click on the “Bid” button, a confirmation box will
pop out to inform staff and students about the difference between their bid amount and
the current price. The bid is confirmed after they click on the “OK” button. The item
is available for staff and students to place their bid until the bid end date. The system
will close the auction and the staff admin can select final winner of the auction.

Figure 6.26: Item for Sale page from staff and student view

Figure 6.27: Item Details page from staff and student view
 119

Figure 6.28: Item for Sale page from staff admin view

Figure 6.29: Item for Sale page from mobile view

 120

6.4.8 Profile
This module shows user’s personal details such as name, email and contact number.
Users can click on the edit icon to update their personal information. They can also
click on the “Change Password” button to change their account password by entering
the current password, new password and confirm password.
Furthermore, from staff and student view, the profile module also shows their
claim cases, lost cases as well as the successful bid. It allows the staff and students to
check the current status of their records within a page. For the lost case, if the staff and
students found their lost items, they can click on the “Found” button to inform the
system. When the status of lost case is marked as found, the item will not be displayed
in the lost case page anymore.
From staff admin view, there is a settings section for staff admin to edit the
expired duration of items. By doing so, all the items updated in the system will be
expired based on this expired duration.

Figure 6.30: Profile page from staff and student view

 121

Figure 6.31: Profile page from staff and student view

Figure 6.32: Profile page from staff admin view

 122

Figure 6.33: Profile page from mobile view

6.4.9 Staff Account

In this module, the system admin can a new staff admin account for each department.
The system shows all staff admin accounts in table format. The search boxes are
provided on the top of the table to enable system admin to search for specific staff
admin account based on different attributes such as department, abbreviation, email
and contact number. The system admin can click on the “Create New Staff Account”
to create a new staff admin account by entering department, name, email and contact
number. Form validation is applied in this page so all fields are required. The system
admin can also edit any staff admin account information from the list.
 123

Figure 6.34: Staff Admin Account page from system admin view

Figure 6.35: Create New Staff Admin account page from system admin view

6.4.10 Item Category

In this module, the system admin can customize the item categories in the system. All
item categories are displayed in alphabetical order. The system admin can click on the
“Add New Item Category” button to add a new item category. Furthermore, the system
admin can also edit or delete the current item category.
 124

Figure 6.36: Item Category page from system admin view

Figure 6.37: Add New Item Category page from system admin view
 125

CHAPTER 7

7 SYSTEM TESTING

7.1 Introduction
In this chapter, unit testing, integration testing and user acceptance testing were
conducted to evaluate the system. The test case result will be listed in the following
section.

7.2 Unit Testing

Table 7.1: Unit Test Case – Test Register New Account

Test Case ID: TC001 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Register Module Test Executed by: Chin Yun Ting
Test Title: Test Register New Text Execution date: 24th August 2020
Account
Pre-condition:
User is required to enter the system
User is required to click the “Register” button from the navigation bar
Test Case Test Steps Test Data Expected Post- Actual Status
Summary Result condition Result
Register 1. Enter valid name “Chin Yun New User is New PASS
with valid Ting” account is redirected account is
name, 2. Enter valid email “yting98@ registered to login registered
email, 1utar.my” . A page . A
contact no, 3. Enter valid “01223597 verificati verificati
password contact no 1” on mail is on mail is
and 4. Enter valid “123456” sent to sent to
confirm password user user
password 5. Enter valid “123456”
confirm password
 126

6. Click “Register”
button
Register 1. Enter valid name “Chin Yun Error Error PASS
with valid Ting” message message
name, 2. Enter invalid “yting98@ “The “The
contact no, email gmail.com” email email
password 3. Enter valid “01223597 should be should be
and contact no 1” UTAR UTAR
confirm 4. Enter valid “123456” mail” is mail” is
password password shown shown
but invalid 5. Enter valid “123456”
email confirm password
6. Click “Register”
button
Register 1. Enter valid name “” Error Error PASS
with 2. Enter valid email “” message message
empty 3. Enter valid “” “Please “Please
value contact no fill out fill out
4. Enter valid “” this field” this field”
password is shown is shown
5. Enter valid “”
confirm password
6. Click “Register”
button

Table 7.2: Unit Test Case – Test Login Verification

Test Case ID: TC002 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Login Module Test Executed by: Chin Yun Ting
Test Title: Test Login Text Execution date: 24th August 2020
Verification
Pre-condition:
User is required to click the link in the verification mail to verify account
 127

Test Case Test Steps Test Expected Post- Actual Status

Summary Data Result condition Result
Login 1. Enter valid “yting98 Successfully User is Successfully PASS
with valid email @1utar. login redirected login
email and my” to
valid 2. Enter valid “123456” homepage
password password

3. Click “Login”
button
Login 1. Enter valid “yting98 Error Error PASS
with valid email @1utar. message message
email and my” “These “These
invalid 2. Enter invalid “1234567 credentials credentials
password password 89” do not match do not match
our records” our records”
3. Click “Login” is shown is shown
button

Login 1. Enter invalid “yting@1 Error Error PASS

with email utar.my” message message
invalid 2. Enter valid “123456” “These “These
email and password credentials credentials
valid 3. Click “Login” do not match do not match
password button our records” our records”
is shown is shown
Login 1. Enter invalid “yting@1 Error Error PASS
withs email utar.my” message message
invalid 2. Enter invalid “1234567 “These “These
email and password 89” credentials credentials
invalid 3. Click “Login” do not match do not match
password button our records” our records”
is shown is shown
 128

Table 7.3: Unit Test Case – Test View and Search Announcement
Test Case ID: TC003 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Announcement Module Test Executed by: Chin Yun Ting
Test Title: Test View and Search Text Execution date: 24th August 2020
Announcement
Pre-condition:
User is required to login into the system
User is required to select the “Announcement” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
View 1. Click the subject Announcem User is Announcem PASS
announceme of ent subject, redirected ent subject,
nt details announcement content and to content and
attachments announce attachments
are shown ment are shown
details
page
View 1. Click the subject The content User is The content PASS
attachments of of redirected of
announcement attachment to attachment
2. Click the is shown attachmen is shown
attachment link t page
Search 1. Click the All All PASS
announceme calendar icon in announceme announceme
nts by date the search box nts which nts which
2. Select date from 08/17 are posted are posted
datepicker /2020 on on
08/17/2020 08/17/2020
are shown are shown
 129

Search 1. Click the Message Message PASS

announceme calendar icon in “No record “No record
nt by date the search box found” is found” is
which is not shown shown
match with 2. Select date from 01/01
all records datepicker /2020

Search 1. Enter subject in “Stud All All PASS

announceme subject search ents announceme announceme
nts by valid box cards nts which nts which
subject ” contains contains
“Student “Student
cards” in the cards” in the
subject are subject are
shown shown
Search 1. Enter subject “aucti Message Message PASS
announceme which is not on “No record “No record
nt by subject match with all funds found” is found” is
which is not records in ” shown shown
match with subject search
all records box
Search 1. Enter empty “” No change No change PASS
announceme value in subject in number of in number of
nt by subject search box announceme announceme
with empty nts nts
value

Search 1. Enter “Safe All All PASS

announceme department in ty” announceme announceme
nts by valid department nts which nts which
department search box contains contains
“Safety” in “Safety” in
the the
 130

department department
are shown are shown

Search 1. Enter “Engi Message Message PASS

announceme department neeri “No record “No record
nt by which is not ng” found” is found” is
department match with all shown shown
which is not records in
match with department
all records search box
Search 1. Enter empty “” No change No change PASS
announceme value in in number of in number of
nts by department announceme announceme
department search box nts nts
with empty
value

Table 7.4: Unit Test Case – Test Create, Edit and Archive Announcement
Test Case ID: TC004 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Announcement Module Test Executed by: Chin Yun Ting
Test Title: Test Create, Edit and Text Execution date: 24th August 2020
Archive Announcement
Pre-condition:
User is required to login into the system as admin
User is required to select the “Announcement” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
Post new 1. Click “Post New New User is New PASS
announce Announcement” announceme redirected announceme
ment with 2. Enter valid Valid nt is posted to nt is posted
all valid subject and subject announce
field content and ment page
 131

conten
t
3. Upload
attachment file
Post new 1. Click “Post New Both error Both error PASS
announce Announcement” message message
ment with “The subject “The subject
2. Enter empty “”
empty field is field is
subject and
value required” required”
content
and “The and “The
content field content field
is required” is required”
are shown are shown
Edit 1. Click edit icon The selected User is The selected PASS
announce announceme redirected announceme
2. Change Valid
ment nt subject is to nt subject is
announcement subject
subject changed announce changed
subject
ment page
Edit 1. Click edit icon The selected User is The selected PASS
announce announceme redirected announceme
ment 2. Change Valid nt content is to nt content is
content announcement conten changed announce changed
content t ment page
Update 1. Click edit icon The selected User is The selected PASS
attachmen announceme redirected announceme
ts in 2. Delete previous nt to nt
attachmen attachment attachment announce attachment
t 3. Upload new is updated ment page is updated

attachment
Archive 1. Click archive The selected The selected PASS
announce icon announceme announceme
 132

ment with 2. Click “OK” for nt is nt is

confirm confirmation box archived archived
Archive 1. Click archive No No PASS
announce icon announceme announceme
ment 2. Click “Cancel” nt is nt is
without for confirmation archived archived
confirm box

Table 7.5: Unit Test Case – Test View and Search Item Found
Test Case ID: TC005 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Item Found Module Test Executed by: Chin Yun Ting
Test Title: Test View and Search Text Execution date: 24th August 2020
Item Found
Pre-condition:
User is required to login into the system
User is required to select the “Item Found” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
View item 1. Click “Details” Item image, User is Item image, PASS
found button of item item name, redirected item name,
details item to item item
category, details category,
item page item
description, description,
date and date and
location location
found are found are
shown shown
Search item 1. Click “Show All All items All items PASS
found by Categories” under under
category button “Keys” “Keys”
 133

2. Select item “Keys category category

category ” are shown are shown
Search item 3. Click “Show All Message Message PASS
found by Categories” “No record “No record
category button found” is found” is
which is not 4. Select item “Bags shown shown
match with category &
all records Backp
acks”
Search item 1. Click first 08/10/ All items All items PASS
found by calendar icon and 2020 found found
date range select date from within within
date picker 08/10/2020 08/10/2020
2. Click second 08/13/ and and
calendar icon and 2020 18/13/2020 18/13/2020
select date from are shown are shown
date picker

3. Click “Search”
button
Search item 1. Click first 12/01/ Message Message PASS
found by calendar icon and 2020 “No record “No record
date range select date from found” is found” is
which is not date picker shown shown
match with 2. Click second 12/31/
all records calendar icon and 2020
select date from
date picker
3. Click “Search”
button
Search item 1. Click first “” No change No change PASS
found by calendar icon and in number in number
date range select date from of items of items
date picker
 134

with empty 2. Click second “”

value calendar icon and
select date from
date picker
3. Click “Search”
button
Search item 1. Enter keyword “bottle All items All items PASS
found by ” where the where the
keyword 2. Press “Enter” name name
matches matches
“bottle” are “bottle” are
shown shown
Search item 1. Enter keyword “Lapto Message Message PASS
found by which is not p” “No record “No record
keyword match with all found” is found” is
which is not records shown shown
match with 2. Press “Enter”
all records

Search item 1. Enter keyword “” No change No change PASS

found by with empty value in number in number
keyword 2. Press “Enter” of items of items
with empty
value

Table 7.6: Unit Test Case – Create, Edit and Archive Item Found
Test Case ID: TC006 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Item Found Module Test Executed by: Chin Yun Ting
Test Title: Test Create, Edit and Text Execution date: 24th August 2020
Archive Item Found
Pre-condition:
User is required to login into the system as admin
 135

User is required to select the “Item Found” section from homepage

Test Case Test Steps Test Data Expected Post- Actual Status
Summary Result condition Result
Create 1. Click “Add New New item User is New item PASS
Item Item” button found redirected found
Found 2. Enter item name, “Key”, created to item created
with all item category, “Keys”, “A found
valid description, bunch of page
value location found, silver key”,
date found, person “KB500”,
to claim item and “08/10/202
location to claim 0”, “Alice”,
item “DSS”
3. Upload item
image
4. Click “Submit”
button
Create 1. Click “Add New Error Error PASS
Item Item” button message message
Found 2. Enter empty item “” “The “Th field
with all name, item field is is
empty category, required” required”
value description, is shown is shown
location found,
date found, person
to claim item and
location to claim
item
3. Click “Submit”
button

1. Click edit icon PASS

 136

Edit Item 2. Change item “Keychain” The User is The

Found name selected redirected selected
with valid 3. Click “Submit” item to item item
value button name is found name is
updated page updated
Edit Item 1. Click edit icon Error Error PASS
Found message message
with “The “The
2. Change empty “”
empty name name
item name
value field is field is
3. Click “Submit” required” required”
button is shown is shown

Archive 1. Click archive icon The The PASS

item found 2. Click “OK” for selected selected
with confirmation box item is item is
confirm archived archived
Archive 1. Click archive icon No item No item PASS
item found 2. Click “Cancel” is is
without for confirmation archived archived
confirm box

Table 7.7: Unit Test Case – Test Claim Item

Test Case ID: TC007 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Claim Module Test Executed by: Chin Yun Ting
Test Title: Test Claim Item Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system
User is required to click the “Claim” button from “Item Found” details page
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
 137

Claim 1. Enter claim 08/30/ The claim User is The claim PASS
item with date 2020 form is redirected form is
valid 2. Click “Submit” successfully to item successfully
claim date button submitted found page submitted
Claim 1. Enter claim 01/01/ Error Error PASS
item with date 2020 message message
the claim 2. Click “Submit” “The claim “The claim
date button date must be date must be
before a date after a date after or
today or equal to equal to
today” is today” is
shown shown
Claim 1. Enter claim “” Error Error PASS
item with date message message
empty 2. Click “Submit” “Please fill “Please fill
claim date button out this out this field”
field” is is shown
shown

Table 7.8: Unit Test Case – Test Claim Item

Test Case ID: TC008 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Claim Module Test Executed by: Chin Yun Ting
Test Title: Test Search Claim Record Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system as admin
User is required to select the “Claim Record” section from homepage
Test Case Test Steps Test Expected Post- Actual Result Status
Summary Data Result condition
Search claim 1. Enter claim “C0 Claim records Claim records PASS
record by id 03” where the where the
claim id 2. Press Enter claim id claim id
matches matches
 138

“C003” are “C003” are

shown shown
Search claim 1. Enter claim “C0 Message “No Message “No PASS
record by id 10” record found” record found”
claim id 2. Press Enter is shown is shown
which is not
match with
all records
Search claim 1. Enter claim “” No change in No change in PASS
record by id the number of the number of
claim id with claim records claim records
2. Press Enter
empty value

Search claim 1. Enter name “spe Claim records Claim records

record by ctacl where the where the
name es” name matches name matches
2. Press Enter “spectacles” “spectacles”
are shown are shown
Search claim 1. Enter name “lapt Message “No Message “No
record by op” record found” record found”
name which 2. Press Enter is shown is shown
is not match
with all
records
Search claim 1. Enter name “” No change in No change in PASS
record by the number of the number of
2. Press Enter
name with claim records claim records
empty value
Search claim 1. Enter name “Spe Claim records Claim records PASS
record by ctacl where the where the
name es” name matches name matches
 139

2. Press Enter “Spectacles” “Spectacles”

are shown are shown

Search claim 1. Enter name “Lap Message “No Message “No PASS
record by top” record found” record found”
name which is shown is shown
is not match
2. Press Enter
with all
records
Search claim 1. Enter name “” No change in No change in PASS
record by the number of the number of
name with claim records claim records
2. Press Enter
empty value

Search claim 1. Select Eye Claim records Claim records PASS

record by category wear which is under which is under
category from “Eyewear” “Eyewear”
dropdown category are category are
lost shown shown
Search claim 1. Select Clot Message “No Message “No PASS
record by category hing record found” record found”
category from is shown is shown
which is not dropdown
match with lost
all records
Search claim 1. Click 08/1 Claim records Claim records PASS
record by calendar 9/20 where the where the
claim date icon in the 20 claim date claim date
search box matches matches
2. Select the “08/19/2020” “08/19/2020”
date form are shown are shown
datepicker
 140

Search claim 1. Click 12/1 Message “No Message “No PASS

record by calendar 2/20 record found” record found”
claim date icon in the 20 is shown is shown
which is not search box
match with
2. Select the
all records
date form
datepicker

Search claim 1. Enter owner “Yu Claim records Claim records PASS
record by information n where the where the
owner info Ting owner info owner info
” matches “Yun matches “Yun
2. Press Enter Ting” are Ting” are
shown shown
Search claim 1. Enter owner “Tan Message “No Message “No PASS
record by information Ah record found” record found”
owner info Kow is shown is shown
which is not ”
match with 2. Press Enter
all records
Search claim 1. Enter owner “” Message “No Message “No PASS
record by information record found” record found”
owner info is shown is shown
with empty 2. Press Enter
value

Search claim 1. Select status Pend Claim records Claim records PASS
record by from ing where the where the
status dropdown status is status is
list “Pending” are “Pending” are
shown shown
 141

Search claim 1. Select status Clai Message “No Message “No PASS
record by from med record found” record found”
status which dropdown is shown is shown
is not match list
with all
records

Table 7.9: Unit Test Case – Test Archive Claim

Test Case ID: TC009 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Claim Module Test Executed by: Chin Yun Ting
Test Title: Test Archive Claim Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system as admin
User is required to select the “Claim Record” section from homepage
Test Case Test Steps Test Expecte Post- Actual Status
Summary Data d Result condition Result
Archive item 1. Click archive The The selected PASS
found with icon selected claim record
confirm 2. Click “OK” for “OK” claim is archived
confirmation box record is
archived
Archive item 1. Click archive No No claim PASS
found icon claim record is
without 2. Click “Cancel” “Cancel record is archived
confirm for confirmation ” archived
box

Table 7.10: Unit Test Case – Test View and Search Lost Case
Test Case ID: TC010 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Lost Case Module Test Executed by: Chin Yun Ting
 142

Test Title: Test View and Search Text Execution date: 24th August 2020
Lost Case
Pre-condition:
User is required to login into the system
User is required to select the “Lost Case” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
View lost 1. Click “Details” Item image, User is Item image, PASS
case details button of item item name, redirected item name,
item to item item
category, details category,
item page item
description, description,
date and date and
location location
lost and lost and
owner info owner info
are shown are shown
Search lost 1. Click “Show All “Key All items All items PASS
case by Categories” button s” under under
category 2. Select item “Keys” “Keys”
category category is category is
shown shown
Search lost 1. Click “Show All Message Message PASS
case by Categories” button “No record “No record
category 2. Select item “Bags found” is found” is
which is category & shown shown
not match Back
with all packs
records ”
Search lost 1. Click first calendar 08/10 All items All items PASS
case by icon and select date /2020 found found
date range from date picker within within
 143

2. Click second 18/13 08/10/2020 08/10/2020

calendar icon and /2020 and and
select date from 18/13/2020 18/13/2020
date picker are shown are shown

3. Click “Search”
button
Search lost 1. Click first calendar 12/01 Message Message PASS
case by icon and select date /2020 “No record “No record
date range from date picker found” is found” is
which is 2. Click second 12/31 shown shown
not match calendar icon and /2020
with all select date from
records date picker
3. Click “Search”
button
Search lost 1. Click first calendar “” No change No change PASS
case by icon and select date in the in the
date range from date picker number of number of
with empty 2. Click second “” lost cases lost cases
value calendar icon and
select date from
date picker
3. Click “Search” “”
button
Search lost 1. Enter keyword “bottl All items All items PASS
case by e” where the where the
keyword name name
2. Press “Enter”
matches matches
“bottle” are “bottle” are
shown shown
 144

Search lost 1. Enter keyword “Lapt Message Message PASS

case by which is not match op” “No record “No record
keyword with all records found” is found” is
which is 2. Press “Enter” shown shown
not match
with all
records
Search lost 1. Enter keyword “” No change No change PASS
case by with empty value in the in the
keyword 2. Press “Enter” number of number of
with empty lost cases lost cases
value

Table 7.11: Unit Test Case – Test Report Lost Case

Test Case ID: TC011 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Lost Case Module Test Executed by: Chin Yun Ting
Test Title: Test Report Lost Case Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system
User is required to select the “Report Your Lost” section from homepage
Test Case Test Steps Test Data Expected Post- Actual Status
Summary Result condition Result
Report lost 1. Enter valid item “Key”, New lost User is New lost PASS
case with all name, item “Keys”, case is redirected case is
valid value category, “With red created to “Lost created
description, keychain”, Case”
possible “KB100”, page
location, date “08/11/2020
lost ”
2. Upload item
image
 145

3. Click “Submit”
button
Report lost 1. Enter empty “” Error Error PASS
case with item name, item message message
empty value category, “The “The
description, field is field is
possible required” required
location, date is shown ” is
lost shown
2. Click “Submit”
button

Table 7.12: Unit Test Case – Test Archive Lost Case

Test Case ID: TC012 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Lost Case Module Test Executed by: Chin Yun Ting
Test Title: Test Archive Lost Case Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system as admin
User is required to select the “Lost Case” section from homepage
Test Case Test Steps Test Expecte Post- Actual Status
Summary Data d Result condition Result
Archive lost 1. Click archive The The selected PASS
case with icon selected lost case is
confirm 2. Click “OK” for “OK” lost case archived
confirmation box is
archived
Archive lost 1. Click archive No lost No lost case PASS
case without icon case is is archived
confirm 2. Click “Cancel” “Cancel archived
for confirmation ”
box
 146

Table 7.13: Unit Test Case – Test View and Search Item for Sale
Test Case ID: TC013 Test Designed by: Chin Yun Ting PASS
Test Priority: High Test Designed date: 21st August 2020
Module Name: Item for Sale Module Test Executed by: Chin Yun Ting
Test Title: Test View and Search Text Execution date: 24th August 2020
Item for Sale
Pre-condition:
User is required to login into the system
User is required to select the “Item for Sale” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
View item 1. Click “Details” Item image, User is Item image, PASS
for sale button of item item name, redirected item name,
details item to item item
category, details category,
item page item
description, description,
starting bid, starting bid,
current bid current bid
and bid end and bid end
date are date are
shown shown
Search item 1. Click “Show All “Clot All items All items PASS
for sale by Categories” hing” under under
category button “Clothing” “Clothing”
2. Select item category is category is
category shown shown
Search item 1. Click “Show All Message Message PASS
for sale by Categories” “No record “No record
category button found” is found” is
which is not 2. Select item shown shown
match with category
all records
 147

Search item 1. Enter keyword “jack All items All items PASS
for sale by et” where the where the
keyword 2. Press “Enter” name name
matches matches
“jacket” are “jacket” are
shown shown
Search item 1. Enter keyword “bottl Message Message PASS
for sale by which is not e” “No record “No record
keyword match with all found” is found” is
which is not records shown shown
match with 2. Press “Enter”
all records

Search item 1. Enter keyword “” No change No change PASS

for sale by with empty in the in the
keyword value number of number of
with empty 2. Press “Enter” items for items for
value sale sale

Table 7.14: Unit Test Case – Test Bid Item for Sale
Test Case ID: TC014 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Item for Sale Module Test Executed by: Chin Yun Ting
Test Title: Test Bid Item for Sale Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system
User is required to select the “Item for Sale” section from homepage
Test Case Test Steps Test Expected Post- Actual Result Status
Summary Data Result condition
1. Enter bid 40.50 User is PASS
amount redirected to
 148

Bid item 2. Click New bid with item for sale New bid with
with valid “Bid” RM40.50 is page RM40.50 is
bid amount button placed placed
Bid item 1. Enter bid 5.50 Error message Error message PASS
with bid amount “Your bid “Your bid
amount 2. Click amount must amount must
which is less “Bid” be more than be more than
than current button current bid” is current bid” is
bid shown shown
Bid item 1. Enter bid 35.00 Error message Error message PASS
with bid amount “Your bid “Your bid
amount 2. Click amount must amount must
which is “Bid” be more than be more than
same as button current bid” is current bid” is
current price shown shown
Bid item 1. Enter bid “” Error message Error message PASS
with empty amount “The bid “The bid
bid amount amount is amount is
2. Click
required” is required” is
“Bid”
shown shown
button

Table 7.15: Unit Test Case – Test Approve Item for Sale
Test Case ID: TC015 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Item for Sale Module Test Executed by: Chin Yun Ting
Test Title: Test Approve Item for Sale Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system as admin
User is required to click the “Approve for Sell” button in the “Item for Sale” page
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
 149

Approve the 1. Enter valid 10.00 The item is User is The item is PASS
item for sale starting bid approved for redirected approved for
with valid 2. Enter valid bid 09/30 sale to item for sale
starting bid end date /2020 sale page
and valid 3. Click “Submit”
bid end date button
Approve the 1. Enter valid 10.00 Error Error PASS
item for sale starting bid message message
with valid 2. Enter invalid bid 01/01 “The bid end “The bid end
starting bid end date /2020 date must be date must be
and invalid 3. Click “Submit” a date after a date after
bid end date button or equal to or equal to
today” is today” is
shown shown
Approve the 1. Enter invalid “ten” Error Error PASS
item for sale starting bid message message
with invalid 2. Enter valid bid 09/30 “The bid “The bid
starting bid end date /2020 starting starting
and valid price must price must
bid end date be a be a
3. Click “Submit”
number” is number” is
button
shown shown

Approve the 1. Enter invalid “ten” Both error Both error PASS
item for sale starting bid messages messages
with invalid 2. Enter invalid bid 01/01 “The bid “The bid
starting bid end date /2020 starting starting
and invalid 3. Click “Submit” price must price must
bid end date button be a be a
number” number”
and “The bid and “The bid
end date end date
must be a must be a
 150

date after or date after or

equal to equal to
today” are today” are
shown shown
Approve the 1. Enter empty “” Both error Both error PASS
item for sale starting bid messages messages
with empty 2. Enter empty bid “” “The bid “The bid
starting bid end date starting starting
and bid end 3. Click “Submit” price is price is
date button required” required”
and “The bid and “The bid
end date end date
field is field is
required” required”
are shown are shown

Table 7.16: Unit Test Case – Test Update Profile

Test Case ID: TC016 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Profile Module Test Executed by: Chin Yun Ting
Test Title: Test Update Profile Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system
User is required to select the “Profile” section from homepage
Test Case Test Steps Test Data Expected Post- Actual Status
Summary Result condition Result
Update 1. Enter valid name “Chin Yun Profile User is Profile PASS
profile with Ting” with new redirected with new
valid name, 2. Enter valid email “yting98@ name, to profile name,
email and 1utar.my” email and page email and
contact 3. Enter valid “01234567 contact contact
number contact number 89”
 151

4. Click “Submit” number is number is

button updated updated
Update 1. Enter valid name “Chin Yun Error Error PASS
profile with Ting” message message
valid name, 2. Enter valid email “yting98@ “The “The
and email 1utar.my” contact contact
but invalid 3. Enter invalid “zero one no must no must
contact contact number two” be a be a
number 4. Click “Submit” number” number”

button is shown is shown

Update 1. Enter valid name “Chin Yun Error Error PASS

profile with Ting” message message
valid name, 2. Enter invalid “yting98- “The “The
and contact email 1utar.my” email email
number but 3. Enter valid “01234567 must be a must be a
invalid contact number 89” valid valid
email 4. Click “Submit” email email
button address” address”
is shown is shown
Update 1. Enter empty “” Error Error PASS
profile with name messages messages
empty “The “The
name, 2. Enter empty “” name name
contact email field is field is
number and required” required”
email 3. Enter empty “” , “The , “The
contact number email email
field is field is
4. Click “Submit” required” required”
button and “The and “The
contact contact
no field is no field is
required” required”
 152

are are
shown shown

Table 7.17: Unit Test Case – Test Change Password

Test Case ID: TC017 Test Designed by: Chin Yun Ting
Test Priority: High Test Designed date: 21st August 2020
Module Name: Profile Module Test Executed by: Chin Yun Ting
Test Title: Test Change Password Text Execution date: 24th August 2020
Pre-condition:
User is required to login into the system as admin
User is required to select the “Profile” section from homepage
Test Case Test Steps Test Expected Post- Actual Status
Summary Data Result condition Result
Change 1. Enter valid “1234 Password is User is Password is PASS
password current 56” updated redirected updated
with valid password to profile
current 2. Enter new “new page
password password pass”
3. Enter re-enter “new
password pass”
4. Click “Update”
button
Change 1. Enter invalid “myp Error Error PASS
password current ass” message message
with invalid password “Your “Your
current 2. Enter new “new current current
password password pass” password password
3. Enter re-enter “new does not does not
password pass” match with match with
4. Click “Update” the the
button password password
you you
 153

provided. provided.
Please try Please try
again” is again” is
shown shown
Change 1. Enter valid “1234 Password is User is Password is PASS
password current 56” updated redirected updated
with the new password to profile
password 2. Enter new “new page
matches password pass”
with the
3. Enter re-enter “new
reenter
password pass”
password

4. Click “Update”
button

Change 1. Enter valid “1234 Error Error PASS

password current 56” message message
with the new password “Your new “Your new
password 2. Enter new “new password password
does not password pass” does not does not
match with 3. Enter re-enter “new match with match with
the re-enter password passw the re-enter the re-enter
password ord” password. password.
Please try Please try
4. Click “Update”
again” is again” is
button
shown shown

Change 1. Enter empty “” Error Error PASS

password current message message
with empty password “Please fill “Please fill
current 2. Enter empty “” out this out this
password, new password
 154

new 3. Enter empty re- “” field” is field” is

password enter password shown shown
and re-enter 4. Click “Update”
password button
 155

7.3 Integration Testing

Table 7.18: Integration Test Case

Test Case Test Steps Expected Result Status
Register New 1. User enters the system New account is PASS
Account 2. User clicks “Register” in navigation bar created. A
3. User enters “Chin Yun Ting” for name field verification email is
4. User enters “[email protected]” for email sent to user.
field
5. User enters 0128871268 for contact no field
6. User enters “123456” for password field
7. User enters “123456” for confirm password
field
8. User clicks “Register” button
Login 1. User opens email User account is PASS
2. User clicks the link inside email to redirect verified. User is
to the system redirected to the
3. User enters “[email protected]” for email homepage
field
4. User enters “123456” for password field
5. User clicks “Login” button
View 1. User logins into the system All announcements PASS
Announcement 2. User clicks the “Announcement” section are listed in table
from homepage format. User is
3. User clicks the announcement subject redirected to view
the content with
attachments when
the subject is
clicked.
Search 1. User logins into the system All announcements PASS
Announcement 2. User clicks the “Announcement” section which are posted on
by Date from homepage 08/17/2020 are
3. User clicks the calendar icon in search box shown
 156

4. User selects 08/17/2020 from datepicker

Search 5. User logins into the system All announcements PASS
Announcement 1. User clicks the “Announcement” section which contains
by Subject from homepage “student” in the
2. User enters “student” in the subject search subject are shown
box
3. User presses “Enter”
Search 1. User logins into the system All announcements PASS
Announcement 2. User clicks the “Announcement” section which contains
by Department from homepage “Safety” in the
3. User enters “safety” in the department department are
search box shown
4. User presses “Enter”
View Item 1. User logins into the system All items are PASS
Found 2. User clicks the “Item Found” section from shown. User is
homepage redirected to view
3. User clicks the “Details” button of item the item details
when the “Details”
button is clicked.
Search Item 1. User logins into the system All items under PASS
Found by 2. User clicks the “Item Found” section from “Keys” category
Category homepage are shown
3. User clicks “Show All Categories” button
4. User selects “Keys”
Search Item 1. User logins into the system All items found PASS
Found by Date 2. User clicks the “Item Found” section from within 08/10/2020
Range homepage and 08/13/2020 are
3. User clicks first calendar icon shown
4. User selects 08/10/2020 from datepicker
5. User clicks second calendar icon of the
search box
6. User selects 08/13/2020 from datepicker
7. User clicks “Search” button
 157

Search Item 1. User logins into the system All items where the PASS
Found by 2. User clicks the “Item Found” section from name matches
Keyword homepage “bottle” are shown
3. User enters “bottle” in the search box
4. User presses “Enter”
Claim Item 1. User logins into the system The item is PASS
2. User clicks the “Item Found” section from claimed.
homepage
3. User clicks the “Details” button of item
4. User clicks “Claim” button
5. User select 08/31/2020 from datepicker as
claim date
6. User clicks “Submit” button
View Lost 1. User logins into the system All items are PASS
Case 2. User clicks the “Lose Case” section from shown. User is
homepage redirected to view
3. User clicks the “Details” button of item the item details
when the “Details”
button is clicked.
Report Lost 1. User logins into the system A new lost case is PASS
Item 2. User clicks the “Report Lost” section from updated. User is
homepage redirected to “Lost
3. User enters “Wireless Mouse” for name Case” page
field
4. User selects “Computers & Electronic” for
category field
5. User enters “Logitech Wireless Mouse” for
description field
6. User enters “KB300” for possible location
field
7. User enters “08/17/2020” for date lost field
8. User uploads item image
9. User clicks “Submit” button
 158

Search Lost 1. User logins into the system All items under PASS
Case by 2. User clicks the “Lost Case” section from “Keys” category
Category homepage are shown
3. User clicks “Show All Categories” button
4. User selects “Keys”
Search Lost 1. User logins into the system All items found
Case by Date 2. User clicks the “Lost Case” section from within 08/10/2020
Range homepage and 08/14/2020 are
3. User clicks first calendar icon shown
4. User selects 08/10/2020 from datepicker
5. User clicks second calendar icon of the
search box
6. User selects 08/14/2020 from datepicker
7. User clicks “Search” button
Search Lost 1. User logins into the system All items where the PASS
Case by 2. User clicks the “Lost Case” section from name matches
Keyword homepage “bottle” are shown
3. User enters “bottle” in the search box
4. User presses “Enter”
View Item for 1. User logins into the system All items are PASS
Sale 2. User clicks the “Item for Sale” section from shown. User is
homepage redirected to view
3. User clicks the “Details” button of item the item details
when the “Details”
button is clicked.
Search Item for 1. User logins into the system All items under PASS
Sale by 2. User clicks the “Item for Sale” section from “Clothing”
Category homepage category are shown
3. User clicks “Show All Categories” button
4. User selects “Clothing”
Search Item for 1. User logins into the system All items where the PASS
Sale by 2. User clicks the “Item for Sale” section from name matches
Keyword homepage “jacket” are shown
 159

3. User enters “jacket” in the search box

4. User presses “Enter”
Bid Item for 1. User logins into the system A new bid is PASS
Sale 2. User clicks the “Item for Sale” section from placed. The current
homepage bid price of item is
3. User clicks the “Details” button of item changed to RM
4. User enters RM 50.00 as bid amount 50.00.
5. User clicks “Bid” button
6. User clicks “Confirm”
Update Profile 1. User logins into the system The profile with PASS
2. User clicks the “Profile” section from new contact
homepage number
3. User clicks edit icon “0123456789” is
4. User enters “0123456789” for contact updated.
number field
5. User clicks “Submit” button
Change 1. User logins into the system The password is PASS
Password 2. User clicks the “Profile” section from changed to
homepage “userpass”
3. User clicks “Change Password” button
4. User enters “123456” for current password
field
5. User enters “userpass” for new password
field
6. User enters “userpass” for re-enter password
field
7. User clicks “Update” button
Post New 1. User logins into the system as admin A new PASS
Announcement 2. User clicks the “Announcement” section announcement is
3. User clicks the “Post New Announcement” posted
button
4. User enters announcement subject for the
subject field
 160

5. User enters announcement content for the

content field
6. User uploads the attachment
7. User clicks “Post” button
Edit 1. User logins into the system as admin The selected PASS
Announcement 2. User clicks the “Announcement” section announcement is
3. User clicks edit icon updated
4. User enters new announcement subject for
the subject field
5. User clicks “Post” button
Archive 1. User logins into the system as admin The selected PASS
Announcement 2. User clicks the “Announcement” section announcement is
3. User clicks archive icon archived
4. User clicks “OK” for confirmation box
Create New 5. User logins into the system as admin A new item found PASS
Item Found 6. User clicks the “Item Found” section is updated
7. User clicks “Add New Item”
8. User enters “Key” for name field
9. User selects “Keys” for category field
10. User enters “A bunch of silver key” for
description field
11. User enters “KB500” as location found field
12. User enters “08/16/2020” as date found field
13. User enters “Lee Mei Hao” for person to
claim field
14. User enters “Library main counter” for
location to claim field
15. User clicks “Submit” button
Edit Item 1. User logins into the system as admin The item with new PASS
Found 2. User clicks the “Item Found” section location found
3. User clicks edit icon “KB300” is
4. User enters “KB300” for location found updated
field
 161

5. User clicks “Submit” button

Archive Item 1. User logins into the system as admin The selected item is PASS
Found 2. User clicks the “Item Found” section archived
3. User clicks “Confirm” for confirmation box
Archive Lost 1. User logins into the system as admin The selected lost PASS
Case 2. User clicks the “Lost Case” section case is archived
3. User clicks “Confirm” for confirmation box
Archive Claim 1. User logins into the system as admin The selected claim PASS
Record 2. User clicks the “Claim Record” section record is archived
3. User clicks “Confirm” for confirmation box
Approve 1. User logins into the system as admin The selected item is PASS
Expired Item 2. User clicks the “Item for Sale” section opened for user to
for Sale 3. User clicks “Approve for Sell” button place the bid
4. User enters “10.00” for starting bid field
5. User enters “09/31/2020” for bid end date
field
Edit Item for 1. User logins into the system as admin The bid end date of PASS
Sale 2. User clicks the “Item for Sale” section the item is changed
3. User clicks edit icon to “09/30/2020”
4. User enters “09/30/2020” for bid end date
field
5. User clicks “Submit” button
Archive Item 1. User logins into the system as admin The selected item is PASS
for Sale 2. User clicks the “Item for Sale” section archived
3. User clicks “Confirm” for confirmation box

7.4 User Acceptance Testing

User acceptance testing was conducted to evaluate whether the system design meets
user requirements. 15 users were selected to test on the web application as well as the
mobile application. During user acceptance testing, some comments were collected
from users. The result of the user acceptance test will be analyzed and discussed in this
section. The test cases for both admins and students were attached to Appendix D and
Appendix E respectively.
 162

Table 7.19: User Acceptance Test Result for Admins

Test Module Number of Tests Number of Comments Provided
Conducted Tests Passed
Login 15 15 -
Announcement 15 15 -
Item Found 15 15 -
Lost Case 15 15 -
Claim Record 15 15 -
Item for Sale 15 15 -
Profile 15 15 -

Table 7.20: User Acceptance Test Result for Students

Test Module Number of Tests Number of Comments Provided
Conducted Tests Passed
Register 15 15 - No email verification for
mobile registration
Login 15 15 -
Announcement 15 15 - No attachment in mobile
Item Found 15 15 - Suggest to search by
category, date and
keyword at the same time
Claim Item 15 15 -
Lost Case 15 15 - Suggest to search by
category, date and
keyword at the same time
Report Lost 15 15 -
Item for Sale 15 15 - Suggest to search by
category and keyword at
the same time
Bid Item 15 15 -
Profile 15 15 -
 163

CHAPTER 8

8 CONCLUSIONS AND RECOMMENDATIONS

8.1 Conclusions
UTAR lost and found management system contributes to all UTAR staff and students.
It digitalizes the manual process in managing and organizing the lost and found items.
Furthermore, it also provides a platform for UTAR staff and students to search for the
lost and found items efficiently and effectively.
For the department staff, they only require to insert the item details with an
image to post a new item in the system. The system will generate an item id once a
new item is updated so the department staff can have a clear identification for each
item. All data in this system will be up to date. If someone claims the item, the post
will be taken down as it is pending for the owner to claim back their item. Furthermore,
the department staff can also decide to sell the lost and found items if they have no
claim for a long time. It can prevent too many unclaimed items accumulate in the
department.
The other benefit of the system is item labelling and item categorization were
applied in the system for better searching. Thus, for anyone who lost an item in UTAR,
they can search items based on different options such as item category, date range or
keyword. It enables an accurate item can be delivered to users so they can get back
their items in a more efficient way. They can also submit the claims 24/7 rather than
only restricted to office hours so the item is reserved for them to claim back at the
department. If they claim the item, they will be able to know where their item is located
so they can get back the item without hassle.

8.2 Recommendations for Future Work

The system was developed based on the project specification stated in Chapter 4.
However, the system still has some limitations that can be improved in the future.
Table 8.1 shows the system limitations as well as the recommendations for future work.
 164

Table 8.1: System Limitations and Recommendations for Future Work

No Limitations Recommendations
1 No email notification The system currently does not have email notification
to inform users of the latest status. For example, when
users claim an item, the system can send an email to
remind them of the claim date as well as the location
to claim the item. Email notification can also be
applied when users report a new lost case or win an
auction item.
2 Users should contact If users found the item listed in the lost case section,
the owner of the lost they should contact the owner personally through
case personally email or contact number to return back the items. The
system can develop a chat box so users can
communicate directly with others in the system.
3 The system cannot The system can generate a PDF report to provide at-
generate report a-glance views of lost and found performance. It can
be a weekly, monthly, quarterly or yearly report.
System admin can view the number of claim cases,
total auction income, the most common lost items in
UTAR based on the system report.
4 Users cannot search The system can allow users to select more than one
items by category, search option to filter the item. It is useful to filter out
date range and a large number of items that are not related to users.
keyword at once For example, if a user wants to find a jacket which is
lost on 1st September 2020, he can:
1. Select “Clothing” for category
2. Select “01/09/2020” until today date from
date picker
3. Enter “Jacket” for keyword
4. Click “Search” button
It allows users to search the items accurately within a
short period of time.
 165

REFERENCES

Ahmad, S., Ziaullah, M., Rauniyar, L., Su, M. and Zhang, Y., 2015. How Does Matter
Lost and Misplace Items Issue and Its Technological Solutions in 2015 - A Review
Study. IOSR Journal of Business and Management Ver . I, 17(4), pp.2319–7668.

Aldaej, R., Alfowzan, L., Alhashem, R., Alsmadi, M.K., Al-Marashdeh, I., Badawi,
U.A., Alshabanah, M., Alrajhi, D. and Tayfour, M., 2018. Analyzing, Designing and
Implementing a Web-Based Auction online System. International Journal of Applied
Engineering Research, 13(10), pp.8005-8013.

Android Studio, n.d. [online] Available at: <https://developer.android.com/studio>

[Accessed 16 February 2020].

Atom, n.d. [online] Available at: <https://atom.io/> [Accessed 16 February 2020].

Casteren, W.V., 2017. The Waterfall Model and the Agile Methodologies: A
comparison by project characteristics. Academic Competences in the Bachelor 2,
pp.10-13. DOI: 10.13140/RG.2.2.10021.50403.

CollabNet VersionOne, 2019. The 13th annual SATE OF AGILE REPORT - 2018.
CollabNet | VersionOne 13, 16.

Crowdfind, n.d. [online] Available at:

<https://uiowa.v2.crowdfind.com/public/#/dps/items> [Accessed 13 February 2020 ].

Dennis, A., Wixom, B.H. and Tegarden, D., 2005. System Analysis and Design with
UML Version 2.0. 2nd ed. New York: John Wiley & Sons.

FidoFinder, n.d. [online] Available at: < https://www.fidofinder.com/> [Accessed 13

February 2020].

Hong, Y., Wang, C. and Pavlou, P.A., 2016. Comparing open and sealed bid auctions:
Evidence from online labor markets. Information Systems Research, 27(1), pp.49-69.
Ilonka, C., 2017. An Online Auction System for Selling Fiber Products. Master.
Johannes Kepler University Linz. Available at:
<http://www3.risc.jku.at/publications/download/risc_5873/Lenzing%20Global%20A
uction%20Portal%20-%20M.Sc.%20Thesis%20-%20Csaba%20Ilonka.pdf>
[Accessed 10 July 2020].

Kaluža, M., Kalanj, M. and Vukelić, B., 2019. A comparison of back-end frameworks
for web application development. Zbornik Veleučilišta u Rijeci, 7(1), pp. 317–332. Doi:
10.31784/zvr.7.1.10.

Laravel, n.d. [online] Available at: <https://laravel.com/> [Accessed 16 February

2020].
 166

Lei, H., Ganjeizadeh, F., Jayachandran, K. and Ozcan, P., 2017. A statistical analysis
of the effects of Scrum and Kanban on software development projects. Robotics and
Computer-Integrated Manufacturing. Elsevier, 43, pp. 59-67. DOI:
10.1016/j.rcim.2015.12.001.

Nacheva. R., 2017. Prototyping Approach in User Interface. 2nd Conference on

Innovative Teaching Methods, pp. 80-87.

Nicu, C.C., Maria, R.E., Pavel, I.D.D. and Pólkowski, Z., 2014. E-auctions from the
Automotive Perspective. Zeszyty Naukowe Dolnośląskiej Wyższej Szkoły
Przedsiębiorczości i Techniki. Studia z Nauk Technicznych, 3, pp.129-145.

Petersen, K., Wohlin, C. and Baca, D., 2009. The Waterfall Model in Large-Scale
Development. Lecture Notes in Business Information Processing, 32, pp.386-400.
DOI: 10.1007/978-3-642-02152-7_29.

Poe, L.F. and Seeman, E., 2019. An Empirical Study of Post-Production Software
Code Quality When Employing the Agile Rapid Delivery Methodology. pp. 1-8.

React Native, n.d. [online] Available at: <https://reactnative.dev/> [Accessed 16

February 2020].

RepoApp, n.d. [online] Available at: < https://www.repoapp.com/> [Accessed 13

February 2020].

Tunajek, S.K., 2009. A Place for Stuff : Clutter Can Be Hazardous to Your Health.
WELLNESS MILESTONES, [online] Available at:
<https://www.aana.com/docs/default-source/wellness-aana.com-web-documents-
(all)/a-place-for-stuff-clutter-can-be-hazardous-to-your-
health.pdf?sfvrsn=e12c4bb1_2> [Accessed 15 February 2020].

Yang, F., 2013. How to Migrate from Waterfall Development Approach to Agile
Approach. Master of Science. Chalmers University of Technology. Available at: <
https://odr.chalmers.se/bitstream/20.500.12380/188289/1/188289.pdf > [Accessed 24
February 2020].
 167

APPENDICES

APPENDIX A: Questionnaire
168
169
170
 171

APPENDIX B: Result of Questionnaire

172
173
174
175
176
 177

APPENDIX C: Storyboard
178
179
180
181
182
183
184
 185

APPENDIX D: User Acceptance Test Case for Admin

186
 187

APPENDIX E: User Acceptance Test Case for Student

188