9 Chapter 3-Goods

Findings of the Study 59
Chapter 3
FINDINGS OF THE STUDY
This chapter presents the findings of the study. The
researchers’ answer to the objectives of the study can be
found here. Other findings related to the objectives of the
study can also be seen here along with figures and tables
to further support the finding.
Drop-Up Information Requirements
This objective discusses the information
specifications of the proposed mobile application for the
users which are the dropping areas, sellers, and buyers.
Order Tracking Data. Order tracking data is
automatically received by the admin of the application for
the revenue streams that company will gain from the
transactions. This data consists of the transaction records
that the dropping area users and sellers have. This data
will be the basis of the company on how much they will
charge for the dropping area as well as the sellers.
User’s Information. User’s information shall comprise
the user’s full name, sim card number, Facebook account,
and address. Users are also required to post an ID and a
matching profile picture for more validation. User’s

information is required and must be visible for other users
to communicate with in case of transactions.
Hardware Requirement. Table 3 shows the minimum and
the recommended requirements to run the mobile application.
For the Central Processing Unit (CPU) Quad-Core is the
minimum and Octa-Core is the recommended requirement. For
the Random Access Memory (RAM), it is recommended to have
6GB, but the user can use a phone with 2GB as minimum.
These requirements must be met by the users in order for
them to install the application and avoid errors.
Table 3
System Requirements
Specification Minimum Recommended

Requirements Requirements
CPU QUAD-CORE OCTA-CORE
RAM 2GB 6GB
WI-FI YES YES
Android Android 9.0 Android 10.0(Q)

Version (Pie)
App permission Network and Storage Network and Storage
Software Requirement. The application is only limited
to smart phones that are run by Android operating system.
The android version shall comprise a minimum SDK version 29

(Android Pie) since the application is not so heavy that it
needs high specifications of the phone to run. The
researchers considered that the application should be
available for a lot of users.
App Permissions. Users must permit access to the
storage and network. Permitting access to storage enables
sellers to upload pictured items to the dashboard and to
send a request. The access to the network on the other hand
must also be permitted by the users for them to access
real-time updates on the applications like new
notifications and uploaded products.
These requirements must be met by the users to run the
application. Though users don’t have to use the recommended
specifications but also the minimum.
Drop-Up Architecture Framework
This finding provides detailed diagrams of the
system’s synopsis and presents the architecture framework
of the system’s design. The researchers used the 4+1 model
view architecture which consists of logical view, process
view, physical view, development view, and the use case
view. 4+1 model view architecture was used for the
researchers to organize the description of the architecture
of their system.
The logical view shows the components of the
researcher’s system as well as its interactions. Using
class, object, state machine and sequence diagrams the
logical view can also be modeled. The process view on the
other hand captures the concurrency and synchronization
aspects of the design and it can be modeled with UML´s
activity diagrams. Development view then describes the
organization of the software in its development environment
and it can be modeled using UML´s component and package
diagrams. Physical view describes the mapping of the
software onto the hardware. To model this view deployment
diagrams can be used. Finally, the use case view, it is
illustrated by selected use cases or scenarios. This view
contains diagrams describing what the system does from a
black box perspective and contains use case diagrams.
Though there are a lot of models to represent each
view, the researchers use Unified Modeling Language (UML)
diagrams to represent each model view. Before writing and
coding, UML diagrams will help the researchers to focus on
the structures and develop a clear understanding of what
shall be implemented. Errors then will also be recognized
easier with the help of the diagrams.
Figure 12
The 4+1 Architectural Framework.
The researchers used UML diagrams to represent the
different views. Use case diagrams are used to represent
use case view, sequence diagrams for logical view, logical
diagrams to represent the process view, package diagram for
the developmental view, and deployment diagrams for the
physical view.
Logical View. This view pertains to the end users and
is concerned with the system’s functionality. Sequence
diagrams are interaction diagrams that detail how
operations are carried out. It is also a type of
interaction diagram because it describes how—and in what
order—a group of objects works together. These diagrams are
usually used by software developers and business
professionals to understand requirements for a new system
or to document an existing process. Sequence diagrams have
two types, the UML diagrams, and code-based diagrams as for
the researchers they will use UML diagrams.

Sequence diagrams in UML are time focused for they
show the interaction visually using the vertical axis of
the diagram to represent time, what data are sent and when
and where the interaction takes place in a collaboration
that either realizes a use case or an operation.
Sequence diagrams are also used primarily to show the
interactions between objects in the sequential order that
those interactions occur. Much like the class diagram,
developers typically think sequence diagrams were meant
exclusively for them. However, an organization's business
staff can find sequence diagrams useful to communicate how
the business currently works by showing how various
business objects interact. Besides documenting an
organization's current affairs, a business-level sequence
diagram can be used as a requirements document to
communicate requirements for a future system
implementation.
During the requirements phase of a project, analysts
can take use cases to the next level by providing a more
formal level of refinement. When that occurs, use cases are
often refined into one or more sequence diagrams.
Figure 13
Sequence Diagram of Login and Registration

The figure shows the diagram for the process of admin
login and registration. For every time the user logs in,
the system will ask the user to input their mobile number.
The system then verifies the mobile number that the user
gave by giving a one-time pin (OTP) verification. A one-
time password (OTP) is an automatically generated numeric
or alphanumeric string of characters that authenticates a
user for a single transaction or login session. An OTP is
more secure than a static password, especially a user-
created password, which can be weak and/or reused across
multiple accounts. OTPs may replace authentication login
information or may be used in addition to it to add another
layer of security.
If the user did not receive any OTP verification, then
the number given by the user is either incorrect or
invalid, else the user will proceed to the next step. The
system will show a profile set up for the user to input
his/her name and address which automatically he/she will
become a registered buyer which the user will be directed
to the shopping dashboard.
On the other hand, if the user has already registered
before, he/she will only enter his/her registered number
for the process. The user will just receive an OTP to which
will serve as his/her password to login. Mobile numbers
that were registered and other information that the user
inputted will be automatically saved in the system’s
database.
Figure 14
Sequence Diagram Product Management

The figure shows the diagram for the sellers. Sellers
may post products for sale that will be shown on the
buyer’s dashboard. Input products will be automatically
stored on the system’s database upon posting. The seller
may edit his/her post depending on his/her own will. The
editing process updates the database record upon saving.
The process happens in real-time, but devices need to
refresh their dashboard to see the updates that have been
done.
Figure 15
Sequence Diagram Sales Invoice
The figure shows the diagram for the buyer’s process.
The process starts when the buyer will comment on the
seller’s post. The buyer may comment on anything to the
seller if the comment verifies the purchase. The seller

then verifies the purchase that the buyer made, after
verifying the seller will request for dropping in any of
the registered dropping areas. If the dropping area
approves the dropping request, the seller and buyer will
then be notified. The buyer then receives his/her own
invoice which contains the amounts to be paid and the
dropping area’s address.
Figure 16
Sequence Diagram Request Management
The figure shows the diagram for the dropping area’s
request management. Sellers may add dropping requests and
will be shown on the dropping area owner’s dashboard. Drop
requests will be automatically stored on the system’s
database upon posting. The dropping area owner may
approve/decline the seller's dropping request, send cash
out details and even penalize dropping requests sent by the
sellers depending on his/her post depending on his/her own

will. Every dropping area owner’s decision, regarding
approving, decline, sending cash out details, and penalize
will be stored in the database, and then will be loaded and
shown to the notifications panel of the seller. The process
happens in real-time, and devices need to refresh their
notifications to see the latest notification updates.
Process View. This view is concerned with the system's
dynamic aspects and its run-time behavior. It describes the
system’s processes and how they interact. The process view
addresses concurrency, distribution, integration,
performance, and scalability. Activity diagram is a
graphical representation of a system or process, depicting
the flow of activities from start to finish. It is a type
of behavior diagram in the UML that is used to model the
behavior of a system or process, focusing on the workflow
and the actions that take place.
Activity diagrams provide a visual representation of a
system or process, showing the flow of activities and the
relationships between them. They are useful for
understanding the behavior of a system or process,
identifying bottlenecks or areas for improvement, and
communicating the process to stakeholders.

The figure shows the activity flow of the login
process of the proposed mobile application. The diagram
visually shows the series of actions or flow of control on
how the users can log in in the application. The proposed
application requires users to register by using their
contact number to acquire an OTP pin for security and
verification purposes to avoid fraudulent activities within
the application. When the user successfully inputs the
correct pin the application dashboard is shown with all the
products that are being sold in the application.
Figure 17
Activity Diagram of Login Process

The figure shows the activity flow as a seller of the
proposed mobile application. The diagram visually shows the
series of actions or flow of control on how the seller can
access the seller category of the application. The proposed
application would ask the seller to input his/her contact
number and the OTP pin that was sent to log in in the
account. If the credentials are correct the seller’s
dashboard is shown showing his/her products that he/she
posted to be sold.
The seller then checks his/her products if the product
has been mined by buyers who are willing to buy. The seller
then processes a request dropping of the item to the chosen
dropping area by the buyer. If the dropping area approves
the request the seller, then notifies the buyer that the
item was approved for dropping by the buyers chosen
dropping area and details as to when the item will be
dropped. If the dropping area was not approved the seller
will notify the buyer that the chosen dropping area cannot
accommodate the item and must choose a different dropping
area from the choices to secure the business transaction.
Figure 18
Activity Diagram of Seller

The figure shows the activity flow as a dropping area
of the proposed mobile application. The diagram visually
shows the series of actions or flow of control on how the
dropping area user can access the dropping area dashboard
of the application. The proposed application would ask the
dropping area user to input his/her contact number and the
OTP pin that was sent to log in in the account. If the
credentials are correct the dropping area dashboard will

show. The user then checks if his/her dropping area has
some dropping or cash out request to be approved or
declined. If the user can still accommodate some dropping
request made by sellers, the user then approves the request
thus this will notify the seller about the approval of the
said request. The business transaction then will end when
the dropping area notifies the seller that dropped item has
been claimed by the buyer and payment has been made. The
user can decline any dropping request if his/her physical
store cannot accommodate any more items as it reaches its
holding capacity thus this will inform the seller of
request being reject for the capacity of the dropping area
has reached its capacity. By declining the dropping request
the transaction with the seller ends.
Figure 19
Activity Diagram of Dropping Area

The figure shows the activity flow as a buyer of the
proposed mobile application. The diagram visually shows the
series of actions or flow of control on how the buyer can
access the main dashboard of the application. The proposed
application would ask the buyer to input his/her contact
number and the OTP pin that was sent to log in in the
account. If the credentials are correct the dashboard will
be shown.
The buyer can view different products from the
dashboard that were posted by different sellers. If the
buyer took a liking from one of the products, the buyer
then comments mine on the comment section for the seller to
see that the buyer is willing to buy the seller’s item.
After completing these requirements, the buyer then waits
for a notification from the seller whom he/she is
transacting with. If the purchase was successful, the buyer
will receive a notification from the seller that the chosen
dropping area approved the dropping request and he/she will
receive details about the dropping date and payment. The
transaction will end when the buyer picks up his/her item
from the dropping area and payment has been completed.
Figure 20
Activity Diagram of Buyer

Development View. This view describes the organization
of the development process and the development environment
for the system. It includes the tools and techniques used
to build, test, and deploy the system, as well as the
development process itself. The development view is
concerned with the development process and the organization
of the development team. It also ensures that the system is
built in a way that is maintainable, scalable, and
reusable, which is essential for long-term success.
Package diagram shows the dependencies and
relationships between packages in a software system. A
package is a container for related elements, such as
classes, interfaces, and other packages. In a UML package
diagram, packages are represented as rectangles with the

package name at the top. The contents of the package are
listed inside the rectangle. Dependencies between packages
are shown as arrows pointing from the dependent package to
the independent package. The arrows may include labels that
indicate the type of dependency, such as "uses" or
"inherits from".
The diagram which is shown in figure 20 shows the
package diagram for the proposed mobile application. The
data package, logic package, and presentation package are
the three sub-packages that make up the Drop Up
application. The data package identifies Firestore as the
application’s database provider. The logic package is made
up of business logic and the Firebase authentication
technique that was employed in the application.
Figure 21
Package Diagram
Physical View. This view describes the system's
hardware components, such as servers, network devices, and
storage devices, and their connections and configurations.
It also includes software components, such as operating
systems, middleware, and application servers, and their
interactions with the hardware. The physical view is
concerned with issues such as performance, scalability,
reliability, and availability, and it helps ensure that the
system meets its non-functional requirements. The physical
view is also important for understanding how the system can
be deployed and maintained, and how it can be integrated
with other systems. It provides a blueprint for the
system's physical implementation, and it helps ensure that
the system can be built and maintained in a cost-effective
and efficient manner. Overall, the physical view provides a
comprehensive understanding of the system's physical
structure and its relationship to the software components,
and it helps ensure that the system meets its functional
and non-functional requirements.
The deployment diagram is a key component of the
physical view in the 4+1 architectural framework. It
provides a visual representation of the physical deployment
of the software system, showing how the software components

are distributed across hardware nodes or servers. The
deployment diagram is particularly useful for system
administrators and infrastructure teams, who are
responsible for configuring and maintaining the system's
hardware components. It allows them to understand how the
software components are deployed across the system's nodes
or servers, and how they are connected and communicate with
each other. This understanding is essential for ensuring
that the system is configured correctly and that it is
running efficiently and reliably.
In addition to showing the physical deployment of the
software system, the deployment diagram can also be used to
model the relationships between the system's hardware and
software components. For example, it can show how the
software components are deployed on specific servers or
nodes, and how they interact with other components on those
servers or nodes. This understanding is crucial for
ensuring that the system's hardware resources are used
optimally and that the system meets its performance and
scalability requirements.
Overall, the deployment diagram is a powerful tool for
visualizing the physical deployment of the software system
and understanding the relationships between its hardware

and software components. It helps ensure that the system is
configured and deployed correctly and that it meets its
functional and non-functional requirements.
Figure 22
Deployment Diagram
This figure shows Drop-Up’s deployment diagram. The
figure shows the Android mobile device, the program server,
that is in three key nodes of Drop-Up's mobile
application.
Use Case View. This view is one of the five views in
the 4+1 architectural framework, and it focuses on
capturing the functional requirements of a software system
from the perspective of its users. It provides a high-level
description of the system's functionality by identifying

the different types of users, their goals, and the
interactions they have with the system. The use case view
is often used to communicate the system's functionality to
stakeholders and to drive the development of test cases.
The use case view consists of a set of use case
diagrams and corresponding use case descriptions. A use
case diagram is a visual representation of the system's
functionality, showing the different types of users and the
interactions they have with the system. The use case
descriptions provide a textual description of each use
case, including the steps involved, the actors involved,
and any preconditions or post-conditions.
The use case view helps ensure that the software
system meets the needs of its users by capturing their
requirements in a clear and concise manner. It provides a
common language for developers, stakeholders, and users to
communicate about the system's functionality, which can
help avoid misunderstandings and miscommunications. The use
case view can also be used to identify gaps or
inconsistencies in the system's functionality, which can be
addressed early in the development process.
Overall, the use case view is a critical component of
the 4+1 architectural framework, as it ensures that the

software system meets the functional requirements of its
users. By capturing the system's functionality in a clear
and concise manner, the use case view helps ensure that the
system meets its intended goals and provides value to its
users.
Figure 23
Drop Up Use Case Diagram
This figure shows the use case diagram of the proposed
application, Drop-Up. As seen above, every oval shape
indicates each user's functionalities. Every user has
different roles and functionalities. Buyers can login, view
products and buy products in the application. Meanwhile,

sellers are able to login, view products, buy products,
create posts, publish posts, add a dropping request,
request cash out details and notify buyers. Lastly,
dropping area owners can view drop requests, approve or
decline dropping requests sent by the seller, also dropping
area owners have the authority to penalize droppers and
send their cash out details, depending on his/her own will.
Drop-Up Key Features
This finding discusses the key features that the
mobile application possesses.
Figure 24
Drop Up’s OTP Verification
This figure shows the OTP verification of the
application. The app’s OTP Verification feature is used for

security purposes. OTP authentication sends a unique code
to a user's smartphone, which they must input to validate
their identity and perform a task. OTP verification offers
a range of benefits that can help to enhance security,
prevent fraud, and improve user experience. Upon opening
the application, the user is requested to input their
cellphone number to receive the unique 6-digit OTP. The
user input the OTP to begin accessing the application.
Figure 25
Buyer Feature: Invoice Notification
This feature shows the notifications panel feature of
the application. Buyers would have two different tabs of
notifications which are: a. Dropped - the first section of
the notification panel contains the seller's sales invoice,

buyer name and where the item was dropped. b Feedbacks -
the second section of the notification panel contains the
feedback of the seller, sent to the buyer. Lastly, every
notification has two buttons: search and order received.
Figure 26
Buyer Feature: Mine
This figure shows the comment section feature of the
application. This feature is intended for buyers to
purchase products they intend to buy via ‘Mine’ basis.
Also, this feature is intended for the sellers to sell
items to buyers who want to buy their posted products via
‘Yours’ basis. In conclusion, the comment section runs on
‘Mine-Yours’ basis, which is commonly used in online thrift
shops.
Figure 27
Buyer Feature: Pick You Up
This figure shows the mapping feature of the
application. This feature works like a search engine, where
the buyer must put the name of the establishment on the
search box indicated on the notification sent by the
seller. After which, the buyer must click the search
button, then the application would open the ‘Google Maps’
app, and search the establishment written on the search
box.
Figure 28
Buyer Feature: Gotchu

This figure shows the feedback and rating of the
application. This feature is intended for buyers to send
feedback of the product, rate the product and to automate
the pick-up notification that would be sent to the seller
after clicking the submit button.
Figure 29
Seller Feature: My Cashout

This feature shows the request cash out details
feature of the application. This feature allows the sellers
to send cash out details regarding the status of items they
dropped on the dropping area where they dropped their
items.
Figure 30
Seller Feature: Dropped
This figure shows a seller feature that enables
sellers to marked their products as dropped and declare
them as sold. Upon clicking the button. The seller would be
prompted to fill up the necessary information to notify the
buyer which he/she sold his/her item to. This would create
a sales invoice notification which will see on the buyer
side.
Figure 31
Dropping Area Feature: Request Response
This figure shows the request response function that
provides a number of activities a dropping area owner may
do. These actions include accepting drop requests,
declining drop requests, penalizing drop requests, and
marking an item that has been sold in order to alert the
seller of the item. This gives the dropping area freedom to
control the number of items he or she is accepting for
quantity control.
Figure 32
Dropping Area Feature: Your Cashout

This figure shows the dropping area receives a cash
out detail sent by the seller, he or she would be obliged
to send the cash out details of the seller which includes
the seller’s current money stored inside the dropping area.
This feature allows the dropping area owners to send the
status of the items that the seller dropped.
Drop-Up Usability Test
This section discusses the extent of the usability of
the application from the questionnaire given to the users
during the usability testing.
Based on the purpose of the study, the respondents of
the usability testing were from the residents of Baguio
city. To calculate the sample size for the usability

testing, the researchers employed the use of Slovin’s
formula:
𝑁 318,676
𝑛 = : 𝑛 = = 99.96
1+𝑁𝑒 2 1+318,676(0.12 )
= 100 respondents.
With the population of 318,676 residents and a 90%
confidence level which has margin error of 0.1, the sample
size(n) was the 100 number of respondents which are the
identified users of the application.
To determine the subjective usability of the
applications, the USE questionnaire was used as a usability
survey instrument which is a 30-item question that examines
the four dimensions of usability: usefulness, ease of use,
ease of learning, and satisfaction. The USE usability scale
was chosen by the researchers for the usability testing for
its simplicity and accuracy. In conducting the usability of
the system, the researchers gained the result based on the
survey of the system.
After the completion of the questionnaires and the
analysis of the responses, the researchers have produced
their findings about the utility, satisfaction,
learnability, and simplicity of use of the suggested
system. The researchers determined the usability result
based on the feedback from the participants. Using a

numerical rating scale ranging from 1 to 7, the users were
asked to assess the degree to which they agreed with the
statement.
After collecting all the sheets with the answers on
them, the researchers were able to determine the outcomes
for the proposed system in terms of its utility,
satisfaction, learnability, and convenience of use. The
researchers determined the usability result based on the
feedback from the participants. Using a numerical rating
scale ranging from 1 to 7, the users were asked to assess
the degree to which they agreed with the statement.
Table 4
Weighted Mean Description
Weighted Mean Interpretation
1.00 - 1.85 Strongly Disagree
1.86 - 2.71 Disagree
2.72 - 3.57 Somewhat Disagree
3.58 - 4.43 Neutral
4.44 - 5.29 Somewhat Agree
5.30 - 6.15 Agree
6.16 - 7.00 Strongly Agree
For the usability of Usefulness dimension, the table
below shows that the potential users of the application

agreed with the system’s usefulness with 5.76 as the mean
level of agreement. This means that the majority of the
respondents became more efficient with their activities by
using the application.
Table 5
Buyer Usability Result: Usefulness
USEFULNESS Frequency Weighted

1 2 3 4 5 6 7 mean
1. It helps me to be
0 0 1 11 35 20 18 5.50
more effective.
2. It helps me be more
0 0 2 8 22 37 16 5.55
productive.
3. It is useful. 0 0 0 8 11 26 40 6.05
4. It gives me more
control over the
0 0 1 15 30 26 13 5.33
activities in my
life.
5. It makes the things
I want to
0 0 1 3 18 37 26 5.98
accomplish easier
to get done.
6. It saves me time
0 0 0 5 20 40 20 5.82
when I use it.
7. It meets my needs. 0 0 1 5 23 35 21 5.82
8. It does everything
I would expect it 0 0 0 3 17 42 23 6.00
to do.
Mean Level of Agreement for Usefulness Dimension 5.76
When it comes to the ease of Use dimension, table 6
below discussed that the mean level of agreement is out 6
of 7. This means buyers agreed that the system is easy,
simple, and flexible to use.

Table 6
Buyer Usability Result: Ease of Use
EASE OF USE Frequency Weighted

1 2 3 4 5 6 7 mean
1. It is easy to use. 0 0 0 3 13 42 27 6.12

2. It is simple to
0 0 2 1 18 44 22 6.03
use.
3. It is user
0 0 0 4 5 33 43 6.42
friendly.
4. It requires the
fewest steps
0 0 1 15 30 26 13 6.02
possible to
accomplish.
5. It is flexible. 0 1 0 1 19 43 21 5.92
6. Using it is
0 0 0 1 21 46 17 5.91
effortless.
7. I can use it
without written 1 0 2 8 9 41 23 5.76
instructions.
8. I don’t notice
inconsistencies as 0 0 1 0 20 46 18 5.88
I use it.
9. Both occasional and
regular users would 0 0 0 2 12 49 22 6.03
like it.
10. I can recover
from mistakes 0 0 0 3 16 43 23 6.03
quickly and easily.
11. I can use it
successfully every 0 0 0 1 22 44 18 5.85
time.
For the learnability of the system, the potential
buyers agreed that the application is very easy to

understand and is very flexible to use. It has a 6.08 mean
level of agreement for the ease of learning dimension.
Table 7
Buyer Usability Result: Ease of Learning
EASE OF LEARNING Frequency Weighted

1 2 3 4 5 6 7 mean
1. I learned to use it
0 0 0 1 18 47 19 5.97
quickly.
2. I easily remember
0 0 0 0 15 47 62 6.09
how to use it.
3. It is easy to
0 0 0 0 16 30 39 6.26
learn.
4. I quickly became
0 0 0 3 17 44 21 5.98
skillful with it.
For the Satisfaction dimension, the computed mean
level of agreement was 6.04 which shows that the potential
buyers agreed that they are satisfied with how the system
works and they wanted to use it.
Table 8
Buyer Usability Result: Satisfaction
SATISFACTION Frequency Weighted

1 2 3 4 5 6 7 mean
1. I am satisfied with 0 0 0 1 22 44 18 5.98
it..
2. I would recommend 0 0 1 2 14 50 18 5.89
it to a friend.
3. It is fun to use. 0 0 0 2 19 31 33 5.98
4. It works the way I 0 0 0 0 11 52 22 6.12
want it to work.
5. It is wonderful. 0 0 0 0 11 50 24 6.06
6. I feel I need to 0 0 0 0 19 40 26 6.03
have it.
7. It is pleasant to 0 0 0 1 11 35 38 6.21
use.
With an overall mean of 5.97 this means that the
usability of the application is effective to use especially
in the field of the buyers.
Table 9
Overall Mean Level of Agreement: Buyer
Dimension in USE Questionnaire Mean Score
Usefulness 5.76
Ease of use 6.00
Ease of Learning 6.00
Satisfaction 6.04
Overall Mean Level of Agreement 5.97
below shows that the sellers that use the application
agreed with the system’s usefulness with 5.89 as the mean
level of agreement. This means that the majority of the
sellers agreed that the application is somewhat useful.
Table 10
Seller Usability Result: Usefulness

1 2 3 4 5 6 7 mean
1. It helps me to be 0 0 0 0 4 1 5 6.10
more effective.
2. It helps me be more 0 0 3 1 2 4 5.70

productive.
3. It is useful. 0 0 1 0 1 3 5 6.10
4. It gives me more 0 0 0 0 4 4 2 5.80
control over the
activities in my
life.
5. It makes the things 0 0 0 0 3 3 4 6.10
I want to
accomplish easier
to get done.
6. It saves me time 0 0 1 0 2 1 6 6.10
when I use it.
7. It meets my needs. 0 0 0 1 3 4 2 5.70
8. It does everything 0 0 1 0 4 3 2 5.50
I would expect it
to do.
When it comes to the ease of Use dimension, table 5
below discussed that the mean level of agreement is 5.67
out of 7. This means sellers agreed that the system is
easy, simple and flexible to use.
Table 11
Seller Usability Result: Ease of Use

1 2 3 4 5 6 7 mean
1. It is easy to use. 0 0 0 1 4 3 2 5.60

2. It is simple to 0 0 0 2 1 3 4 5.90
use.
3. It is user 0 0 1 1 2 1 5 5.80
friendly.
4. It requires the 0 0 0 0 4 4 2 5.80
fewest steps
possible to
accomplish.
5. It is flexible. 0 1 0 0 2 4 3 5.70
6. Using it is 0 0 0 1 3 3 3 5.80
effortless.
7. I can use it 0 0 1 0 3 3 3 5.70
without written
instructions.
8. I don’t notice 0 0 0 0 5 3 2 4.90
inconsistencies as
I use it.
9. Both occasional and 0 0 1 1 2 3 3 5.60
regular users would
like it.
10. I can recover 0 0 0 0 3 6 1 5.80
from mistakes
quickly and easily.
11. I can use it 0 0 0 1 3 3 3 5.80
successfully every
time.
sellers agreed that the application is very easy to
level of agreement for the ease of learning dimension. This
signifies that the sellers agreed that the application is
easy to learn.
Table 12
Seller Usability Result: Ease of Learning

1 2 3 4 5 6 7 mean
1. I learned to use it 0 0 1 0 2 3 4 5.80
quickly.
2. I easily remember 0 1 0 0 3 4 2 5.50
how to use it.
3. It is easy to 0 0 0 1 3 2 4 5.90
learn.
4. I quickly became 0 0 0 0 3 3 4 6.10
skillful with it.
seller agreed that they are satisfied with how the system
works and they wanted to use it.
Table 13
Seller Usability Result: Satisfaction

1 2 3 4 5 6 7 mean
1. I am satisfied with 0 0 0 2 3 0 5 5.80
it.
2. I would recommend 0 1 0 1 1 3 4 5.70
it to a friend.
3. It is fun to use. 0 0 1 1 2 4 2 5.50
4. It works the way I 0 1 0 1 2 5 1 5.30
want it to work.
5. It is wonderful. 0 0 0 2 1 3 4 5.90
6. I feel I need to 0 0 1 1 1 5 2 5.60
have it.
7. It is pleasant to 0 0 0 0 1 5 4 6.20
use.
in the field of the sellers.

Table 14
Overall Mean Level of Agreement: Seller

Usefulness 5.89
Ease of use 5.67
Satisfaction 5.71
below shows that the potential dropping area’s users of the
application agreed with the system’s usefulness with 5.55
as the mean level of agreement. This means that the
majority of the respondents became more efficient with
their activities by using the application.
Table 15
Dropping Area Usability Result: Usefulness

1 2 3 4 5 6 7 mean
1. It helps me to be 0 0 0 0 1 1 3 5.40
more effective.
2. It helps me be more 0 0 1 0 0 4 0 5.40
productive.
3. It is useful. 0 0 0 0 2 2 1 5.80
4. It gives me more 0 0 0 1 1 3 0 5.40
control over the
activities in my
life.
5. It makes the things 0 0 0 1 1 3 0 5.40
I want to
accomplish easier
to get done.
6. It saves me time 0 0 0 0 3 0 2 5.80

when I use it.
7. It meets my needs. 0 0 0 1 0 4 0 5.60
8. It does everything 0 0 0 1 0 4 0 5.60
I would expect it
to do.
When it comes to the ease of Use dimension, table #
below discussed that the mean level of agreement is 5.60
out of 7. This means dropping area’s users agreed that the
system is easy, simple and flexible to use.
Table 16
Dropping Area Usability Result: Ease of Use

1 2 3 4 5 6 7 mean
1. It is easy to use. 0 0 0 0 1 2 2 6.20

2. It is simple to 0 0 0 0 2 1 2 6.00
use.
3. It is user 0 0 0 1 1 1 2 5.80
friendly.
4. It requires the 0 0 0 1 1 3 0 5.40
fewest steps
possible to
accomplish.
5. It is flexible. 0 0 0 1 1 3 0 5.40
6. Using it is 0 0 0 1 1 3 0 5.40
effortless.
7. I can use it 0 0 0 1 2 2 0 5.20
without written
instructions.
8. I don’t notice 0 0 0 1 1 3 0 5.40
inconsistencies as
I use it.
9. Both occasional and 0 0 0 1 1 3 0 5.40
regular users would
like it.
10. I can recover 0 0 0 1 0 3 1 5.80
from mistakes
quickly and easily.
11. I can use it 0 0 0 1 1 2 1 5.60
successfully every
time.
dropping areas agreed that the application is very easy to
level of agreement for the ease of learning dimension.
Table 17
Dropping Area Usability Result: Ease of Learning

1 2 3 4 5 6 7 mean
1. I learned to use it
0 0 0 1 2 1 1 5.40
quickly.
2. I easily remember
0 0 0 0 2 3 0 5.60
how to use it.
3. It is easy to learn. 0 0 0 0 2 3 0 5.60
4. I quickly became
0 0 0 0 3 2 0 5.40
skillful with it.

dropping area’s users agreed that they are satisfied with
how the system works and they wanted to use it.
Table 18
Dropping Area Usability Result: Satisfaction

1 2 3 4 5 6 7 mean
1. I am satisfied with
0 0 0 0 2 3 0 5.60
it.
2. I would recommend
0 0 0 0 0 4 1 6.20
it to a friend.
3. It is fun to use. 0 0 0 0 2 3 0 5.60
4. It works the way I
0 0 0 0 2 3 0 5.60
want it to work.
5. It is wonderful. 0 0 0 0 2 3 0 5.60
6. I feel I need to
0 0 0 0 2 3 0 5.60
have it.
7. It is pleasant to
0 0 0 1 2 3 0 5.60
use.
in the field of the dropping area’s users.
Table 19
Overall Mean Level of Agreement: Dropping Area

Usefulness 5.55
Ease of use 5.60
Satisfaction 5.69

9 Chapter 3-Goods

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9 Chapter 3-Goods

Uploaded by

Copyright:

Available Formats

Findings of the Study 59

FINDINGS OF THE STUDY

This chapter presents the findings of the study. The

researchers’ answer to the objectives of the study can be

found here. Other findings related to the objectives of the

to further support the finding.

Drop-Up Information Requirements

This objective discusses the information

specifications of the proposed mobile application for the

users which are the dropping areas, sellers, and buyers.

Order Tracking Data. Order tracking data is

automatically received by the admin of the application for

the revenue streams that company will gain from the

transactions. This data consists of the transaction records

will be the basis of the company on how much they will

charge for the dropping area as well as the sellers.

User’s Information. User’s information shall comprise

the user’s full name, sim card number, Facebook account,

and address. Users are also required to post an ID and a

matching profile picture for more validation. User’s

information is required and must be visible for other users

to communicate with in case of transactions.

Hardware Requirement. Table 3 shows the minimum and

the recommended requirements to run the mobile application.

For the Central Processing Unit (CPU) Quad-Core is the

minimum and Octa-Core is the recommended requirement. For

the Random Access Memory (RAM), it is recommended to have

These requirements must be met by the users in order for

them to install the application and avoid errors.

Specification Minimum Recommended

CPU QUAD-CORE OCTA-CORE

RAM 2GB 6GB

WI-FI YES YES

Android Android 9.0 Android 10.0(Q)

App permission Network and Storage Network and Storage

Software Requirement. The application is only limited

to smart phones that are run by Android operating system.

The android version shall comprise a minimum SDK version 29

(Android Pie) since the application is not so heavy that it

needs high specifications of the phone to run. The

researchers considered that the application should be

available for a lot of users.

App Permissions. Users must permit access to the

storage and network. Permitting access to storage enables

sellers to upload pictured items to the dashboard and to

send a request. The access to the network on the other hand

must also be permitted by the users for them to access

real-time updates on the applications like new

notifications and uploaded products.

These requirements must be met by the users to run the

application. Though users don’t have to use the recommended

specifications but also the minimum.

Drop-Up Architecture Framework

This finding provides detailed diagrams of the

system’s synopsis and presents the architecture framework

of the system’s design. The researchers used the 4+1 model

view architecture which consists of logical view, process

view, physical view, development view, and the use case

view. 4+1 model view architecture was used for the

researchers to organize the description of the architecture

The logical view shows the components of the

researcher’s system as well as its interactions. Using

class, object, state machine and sequence diagrams the

logical view can also be modeled. The process view on the