INTRODUCTION
The urgency of the project
As technology advances, mobile phones are becoming ubiquitous, with people relying on them for various tasks While POS (Point of Sale) applications are typically designed for websites or desktop systems, managing these systems can be challenging in large stores with numerous employees and customers, as well as in small stores with limited resources Developing a solely PC-based system can hinder smooth operations, making mobile solutions increasingly essential for effective management.
Despite the abundance of POS apps available globally, few effectively support shop owners in connecting with their customers This gap in the market is why we have chosen to focus on this topic.
Creating a mobile-centric system is the most effective solution, as it significantly saves time and resources for both developers and customers Since its launch in 2018, Google's Flutter framework has enabled developers to build applications more quickly and efficiently, supporting multiple platforms, including iOS, Android, and the web.
Objective
- Building the system connect the end user and coffeeshop owner to allow to make the drink, food using the Mobile application
- Support POS application for Coffee Shop.
Technology
- Mobile UI/UX: Flutter Framework
- Backend: NodeJS with Express framework
- Frontend web: React library with Sematic UI kit.
Scope
Client application (Mobile): where show coffeeshop’s product to the end user (who login with google or facebook) can make the order, check status the order and tracking shipper location
Shipper application (Mobile): allow to the shipper can receive and delivery the order
POS (Point of sales) application (Mobile): building modules management to support the coffeeshop such as: tables, orders, merge/split table, area, drink/food, payment, kitchen
CMS (Content management system) application (Web): allow admin and coffeeshop owner can:
- Coffeeshop owner: manage the employee, the product, the shipper
- Admin: manage the customer (coffeeshop owner), track system status
APPLICATINON & TECHNOLOGIES REVIEW
Application review
The digital management system is essential for any store, offering features such as table management, area organization, and multiple payment methods including credit cards, cash, and digital wallets It enables users to place quick manual orders and includes a notification system that allows bartenders to alert waitstaff when an order is ready, waitstaff to notify bartenders about long service times, and customers to request payment from cashiers.
2.1.2 GrabFood, GoJek Food, Now Food
- GrabFood, GoJek Food, Now Food provides food delivery:
- It is the intermediary application that is connect the customer with the store The customers can make the order for the store by the mobile application
- It provides the promotion, voucher for the customer
- It provides the tracking location shipper feature for the customer to easy check status the order
Currently, coffee shop owners rely on two separate applications—a POS application and a delivery application—from different providers to support their business operations This lack of synchronization complicates management tasks, creating challenges for efficient business oversight.
- We will build the system connect the end user and the coffeeshop owner to allow to make the drink, food using the Mobile application
- We just focus on the coffee shop, but with the other business, the system still works well.
Technologies
- Flutter is an open-source mobile SDK developer
- Flutter can use to build native-looking Android and iOS applications from the same code base
- Flutter has been released since 2018
- Flutter is developed by Google
- Flutter is now the top 11 software repos based on GitHub stars
- Flutter use Dart programming language
- Flutter is faster than many other application development frameworks With its
“hot reload” feature, you can experiment, build UIs, add/remove features, testing and fix bugs faster Thus, reducing the overall app development time
Flutter enables developers to create stunning applications with a user experience comparable to native apps Its layered architecture provides precise control over every pixel on the screen, making customization straightforward Additionally, Flutter's robust compositing capabilities allow for limitless overlaying and animation of graphics, text, video, and other elements, enhancing the overall visual appeal and interactivity of the apps.
Discover a collection of widgets that provide flawless experiences on both Android and iOS, fully embodying the principles of Material Design Material.io, an initiative by Google, aims to create aesthetically pleasing and user-friendly products through its Material Components, enhancing digital interactions.
- Flutter’s widgets incorporate all critical platform differences such as scrolling, navigation, icons and fonts This provides a native performance experience on both iOS and Android.[1]
Node.js is an open-source, cross-platform JavaScript runtime environment that allows developers to execute JavaScript code outside of a web browser It enables the creation of command line tools and server-side scripting, which generates dynamic web page content before it reaches the user's browser This approach promotes a "JavaScript everywhere" paradigm, streamlining web application development by using a single programming language for both server-side and client-side scripting.
Express.js, commonly known as Express, is a free and open-source back-end web application framework for Node.js, released under the MIT License It is specifically designed for developing web applications and APIs, and is widely regarded as the de facto standard server framework for Node.js.
React is the most popular JavaScript library for building user interfaces (UIs)
ReactJS, developed by Facebook and launched as an open-source JavaScript engine in 2013, offers exceptional response speed to user input through its innovative web page rendering method A standout feature of React is its ability to render data at both the server and client layers, enhancing performance and user experience.
- Easy to use, create lightweight components: React supply an easy to use and fast development, it fits the current situation of the project
- Reusable component: with crud purpose, this is a big advantage for fast development
- Huge open-source: React has big community support with various of thirst- party.[4]
REQUIREMENT SPECIFICATION
Description
A Coffee shop have the common construct following below:
- Manager (coffeeshop owner) has responsibility for manage the user, who is grant login into the system, can block account, reset password, edit information, tracking order, statistic
- Waiter has responsibility for tracking table, status of food/drink, status of order, create, update the order, merge/split the table, take care the customer
- Cashier has responsibility for make a payment when customer or waiter ask, see the order need to pay, add voucher(optional) in the bill
- Bartender has responsibility for processing food/drink and update status of order, status of food and notify when done
The end user is responsible for placing orders through the app and can easily track order history, shipment status, and the location of the shipper They can browse products by category and access an overview of popular items on the home screen, which includes filters for options like free shipping, cakes, drinks, food, and nearby stores Additionally, users have the ability to search for specific products to enhance their shopping experience.
A CMS is the key to POS app to run, so it will be required structure below:
The admin holds the highest role within the app, possessing the authority to block primary users and reset their passwords Additionally, the admin is responsible for creating product categories, which enable primary users to efficiently develop products based on these classifications Furthermore, the admin can establish a system shipper to enhance logistics and delivery processes.
The primary user, often referred to as the store manager or owner, begins by registering an account on the CMS Once registered, they can name their store and utilize the application to create products, manage employees, generate in-app vouchers, and set up tables within the POS app.
Shipper application is a small app and has only one shipper role This application requires these contents:
- Shipper can belong to the system or can be shipper of the POS application
Shipper can take an order around 5km and can track this order When shipper received one order, they must update every state of delivery progress to user.
Functional requirements
3.2.1.1.1 User can login with some roles and logout, take attendance
User can login with defined role, take attendance, logout
3.2.1.1.2 Waiter can manage tables, make an order for customers
Waiters can efficiently manage customer orders by placing them directly through the system, merging orders for tables, and splitting them as needed They can also communicate seamlessly with bartenders via notifications When customers request the bill, waiters can notify the cashier to facilitate the payment process.
3.2.1.1.3 Bartender can watch the orders state, change state to processing or ready to server
Bartenders have the ability to monitor and modify the status of orders, as well as search for specific orders by their ID They can easily see the total number of dishes included in each order and view all dishes on a screen This screen also organizes dishes by their preparation time, enabling bartenders to prioritize which dishes need to be made first.
3.2.1.1.4 Cashier have responsible for pay the bill for the customers
Cashier have responsible for pay the bill for the customers They can manage the statistic of the shop, view the chart of sales rate
3.2.1.2 Manager can access all roles
Manager have full access to all route, can manage users
The end user can login with social network and make the order
Users can log in using Facebook or Google to easily share their location and place orders from any store Once an order is placed, they can track its status and view the shipper's location once the order is accepted Additionally, users have access to their order history and shopping cart for a seamless shopping experience.
Shipper application is an application that can help shipper to obtain order from Pos application This application has only one role
Shippers can pick up orders within a 5km radius and track them using a Google Map interface on the tracking screen Upon accepting an order, shippers can update the delivery status, which notifies clients of their order's location Additionally, shippers have access to their delivery history and can update their profiles in the settings.
- CMS is application for users to manage their POS application This CMS includes two roles: Admin and primary user
The Admin role in the CMS is the highest authority, responsible for managing the primary user's access by blocking or changing their password Additionally, the Admin oversees categories within the POS application system and has the capability to create shippers for the shipper app, which are integrated into the CMS system.
The primary role of the CMS app is to serve as the manager of the POS application once it is created The primary user can effectively monitor employees, including bartenders, waiters, cashiers, and shippers Employees receive their POS app via SMS sent by the primary user Additionally, the primary user has the ability to create and manage store products based on categories provided by the admin Furthermore, the primary user can oversee vouchers and manage the store area, including tables.
• Manager (Coffeeshop owner): who can access all roles
• Waiter: who manage area and make the order
• Cashier: who make the payment of the order
• Bartender: who make the product of the order
• The end user: who login by social network and can make the order from anywhere
• Shipper: shipper is the core role of the shipper app, this user can accept order and make delivery that order to customer on client application
• Admin: Admin is the main role of CMS which can control user access to CMS, manage category in POS application and system shipper
• Primary: Primary user is a store owner which can control resource of store like products, areas, tables and employees
Table 3.1 POS use case table
System Functions Main Use Cases Use Case #
Unauthorized user can login with roles
User can logout and get attendance
Waiter can manage tables, make an order for customers
Make order based on table UC_1.4
View state of the table UC_1.9
Bartender can watch the orders state, change state to processing or ready to serve
Change state of the order UC_1.10
Find order by Id UC_1.11
Change to dish view UC_1.12
Sort dishes by duration UC_1.13
Cashier has responsible for pay the bill for the customers
Watch statistical (daily income) UC_1.16 Watch statistical (monthly income) UC_1.17
Admin who can access all roles
Table 3.2 Shipper use case table
System Functions Main Use Cases Use Case #
Unauthorized user can login with roles
User can logout and get attendance
Navigate to call dial SA 1.4
Table 3.3 Client app use case table
System Functions Main Use Cases Use Case #
Unauthorized user can login with roles
View the product by categories CA 1.8
View the order history CA 1.6
Estimate duration time and distance CA 1.13
Table 3.4 CMS use case table
System Functions Main Use Cases Use Case #
Unauthorized user can login with roles
Primary user can monitor their store
Figure 3.1 POS use case diagram
Figure 3.2 Client app use case diagram
Figure 3.3 CMS use case diagram
Figure 3.4 Shipper app use case diagram
3.2.2.4.1 POS app use case description
Figure 3.5 Use case login Table 3.5 Use case description login
Use Case No UC_1.1 Use Case Version 1.0
• Employee that wants to access the system
• Allow user to login to the system
• Employee can login to the system in one defined role
• UI changes for each role accessed to the system
• Employee must fill the username and password
• Success: Employees will be redirected to their work screen
• Fail: User can’t login to the system
Step Actor Action System Response
1 User type username a password to the text field
The system set password to private char
2 User tap on login button The system will redirect user to main working screen, depends on user role
No Actor Action System Response
1 User types wrong password or username
The system will pop-up an error
Figure 3.6 Use case logout Table 3.6 Use case description logout
Use Case No UC_1.2 Use Case Version 1.0
• Employee that wants to logout of the system
• Allow user to logout of the system
• Employees can logout after they have finished their work
• Redirect to main login screen
• Employee must login the system
• Success: Employees will be redirected to login screen
Step Actor Action System Response
1 User return to the main screen on app
The system redirect user to main screen
2 User tap on login button The system will redirect user to main working screen, depends on user role
Figure 3.7 Use case get attendance Table 3.7 Use case description get attendance
Use Case No UC_1.3 Use Case Version 1.0
Use Case Name Get attendance
• Employee that wants to get attendance when started the work time
• Feature allow user to take attendance
• Employee can take attendance in or the end of their work time
• Employee must login the system
• Success: Employees will be attended and prompted successfully attendance
• Fail: Employees can’t get attendance if the app offline
Step Actor Action System Response
1 User tap on “hamburger bar” on the top left of the screen
The system shows a modal on the left of the screen
2 User tap on get attendance button
The system saves employee’s working days to the server database then pops a notify: “attendance successfully”
3.2.2.4.1.4 Use case make order based on table
Figure 3.8 Use case make order based on table Table 3.8 Use case description make order based on table
Use Case No UC_1.4 Use Case Version 1.0
Use Case Name Make order based on table
• Employee that at role waiter
• Allow waiter to make order based on the table
• Waiter can make orders for customers who already have their table.
• Redirect to select product screen
• Employee must login the system as role waiter
• Success: Order will be created, and the table will have people
Step Actor Action System Response
1 Waiter choose the table where the customers have chosen
The system redirects the waiter to product screen
2 User tap on the product users have ordered
The system will show which products have been selected and increase the cart number
3 User tap on save button The system will save the product on that table and change state of that table from open to closed
Figure 3.9 Use case search food Table 3.9 User case description search food
Use Case No UC_1.5 Use Case Version 1.0
Use Case Name Search food
• Employee that at role waiter
• Allow waiter to search food
• Searched foods/drinks show in screen
• Employee must login the system as role waiter
Step Actor Action System Response
1 Waiter tap on “search” button in app bar
The system show a textfield to typing
2 Waiter type product name in texfield and type enter in keyboard
The system will show searched products
Figure 3.10 Use case merge order Table 3.10 Use case description merge order
Use Case No UC_1.7 Use Case Version 1.0
Use Case Name Merge order
• Employee that at role waiter
• Allow waiter to merge order based on the table
• When customer want to merge order in to one table.
• Server will merge two orders into one
• Employee must login the system as role waiter
• User enter the serve screen
• Can only select tables that have orders
• Success: Order will be merged
Step Actor Action System Response
1 Waiter tap on floating button The system will show 2 option:
2 Waiter tap on merge button The system allow user to choose 2 table
3 Waiter choose 2 tables where the customers want to merge
The system will merge 2 orders into one
3.2.2.4.1.7 Use case view state of table
Figure 3.11 Use case view state of table Table 3.11 Use case description view state of table
Use Case No UC_1.8 Use Case Version 1.0
Use Case Name View state of table
• Employee that at role waiter
• Allow waiter to state of table
• State of table show in screen
• Employee must login the system as role waiter
• Success: Order will be merged
Step Actor Action System Response
1 Waiter tap on service or login The system show list table based on area and show state (is/isn’t) empty
Figure 3.12 Use case split order Table 3.12 Use case description split order
Use Case No UC_1.8 Use Case Version 1.0
Use Case Name Split order
• Employee that at role waiter
• Allow waiter to split order based on the table
• When customer want to split merged order in to one table.
• Server will split merged orders
• Employee must login the system as role waiter
• User enter the serve screen
• Success: Order will be merged
Step Actor Action System Response
1 Waiter tap on floating button The system will show 2 option:
2 Waiter tap on split button The system allow user to choose table which has merge text on the top of the table
3 Waiter choose a table then tap on confirm button
The system will split the order and pops up a success prompt
3.2.2.4.1.9 Use case find order by Id
Figure 3.13 Use case find order by Id Table 3.13 Use case description find order by Id
Use Case No UC_1.11 Use Case Version 1.0
Use Case Name Find order by Id
• Employee that at role bartender
• Allow a bartender to find order with its ID
• Bartender can find an order and watch dishes in that order.
• Update on other devices at bartender screen
• Employee must login the system as role bartender
• User enter the kitchen screen
• Success: bartender can view all order in the screen and change its state
Step Actor Action System Response
1 Bartender tap on kitchen screen The system will show kitchen screen with 3 section: open, processing and ready state
2 Bartender tap on the magnifier icon
The system shows a text field and cancel icon
3 Type an Id on the text field The system filters the order list and show on the screen result that match with value in the text field
No Actor Action System Response
1 User types not invalid Id The system will not show any orders
3.2.2.4.1.10 Use case sort dish by duration
Figure 3.14 Use case sort dish by duration Table 3.14 Use case description change dish by duration
Use Case No UC_1.12 Use Case Version 1.0
Use Case Name Change dish view
• Employee that at role bartender
• Allow a bartender change from orders view to Dishes view
• Bartender can find an order and watch dishes in that order.
• Update on other devices at bartender screen
• Employee must login the system as role bartender
• User enter the kitchen screen
• Success: bartender can view all order in the screen and change its state
Step Actor Action System Response
1 Bartender tap on kitchen screen The system will show kitchen screen with 3 section: open, processing and ready state
2 Bartender tap on the navigation(dish icon) in the bottom right of the screen
The system will navigate to dishes screen Show dishes of all orders available
3 Type an Id on the text field The system filters the order list and show on the screen result that match with value in the text field
No Actor Action System Response
1 User types not invalid Id The system will not show any orders
3.2.2.4.1.11 Use case change state order
Figure 3.15 Use case change state order
Table 3.15 Use case description change state order
Use Case No UC_1.10 Use Case Version 1.0
Use Case Name Change state order
• Employee that at role bartender
• Allow a bartender to watching state of the order
• Bartender can change state, view state to process the dishes on that order.
• Update on other devices at bartender screen
• Employee must login the system as role bartender
• User enter the kitchen screen
• Success: bartender can view all order in the screen and change its state
Step Actor Action System Response
1 Bartender tap on kitchen screen The system will show kitchen screen with 3 section: open, processing and ready state
2 Bartender can long tap on the order Or can tap Arrow button(on process or ready tab) to change its state
The system will push tapped order to processing or ready state(depend on the tab bar that currently at) The system also will change the state of
29 that order in all devices access kitchen screen
3.2.2.4.1.12 Use case sort dish by duration
Figure 3.16 Use case sort dish by duration Table 3.16 Use case description sort dish by duration
Use Case No UC_1.13 Use Case Version 1.0
Use Case Name Sort dish by duration
• Employee that at role bartender
• Allow a bartender to sort dish based on duration
• Help the bartender know which dish should be made first.
• Employee must login the system as role bartender
• User enter the kitchen screen
• Change screen to dish view
• Success: bartender can view all order in the screen sorted by duration (time
30 make one dish) and change its state
Step Actor Action System Response
1 Bartender tap on kitchen screen The system will show kitchen screen with 3 section: open, processing and ready state
2 Bartender tap on the navigation(dish icon) in the bottom right of the screen
The system will navigate to dishes screen Show dishes of all orders available
3 User tap on the hamburger button on the top right
The system will show two options: sort by dish, sort by dish duration
4 User tap on sort by dish duration
The system will show the dishes on all orders and also sort by its duration
3.2.2.4.1.13 Use case view order detail
Figure 3.17 Use case view order detail
Table 3.17 Use case description view order detail
Use Case No UC_1.14 Use Case Version 1.0
Use Case Name View order detail
• Employee that at role bartender
• Allow a bartender view all dishes in one order
• Help the bartender know which dish should be made in one order.
• Employee must login the system as role bartender
• User enter the kitchen screen
• Success: bartender can view all dishes in the order
Step Actor Action System Response
1 Bartender tap on kitchen screen The system will show kitchen screen with 3 section: open, processing and ready state
2 Bartender tap on one order The system will show a modal with dishes, icon name , amount of product
Figure 3.18 Use case make a payment Table 3.18 Use case description make a payment
Use Case No UC_1.15 Use Case Version 1.0
Use Case Name Make a payment
• Employee that at role cashier
• Allow cashier to make a payment for custom order
• Pay the bill for customer when they leave.
• Employee must login the system as role cashier
• User enter the statistic screen
• Success: Cashier successfully pay the customer’s order
• Fail: The system pops up an error message when payment failed
Step Actor Action System Response
1 Cashier tap on statistic screen The system will navigate to payment screen
2 Cashier choose an order which customer want to pay
The system will show all dishes and total money
3 Cashier need to type in tendered money from customer
System will automatically calculate change
When the cashier clicks the "Pay" button, the system records the order and the payment amount in the database A notification will then appear to inform whether the payment was successful or not.
No Actor Action System Response
1 User tap “Pay button” The system pops up a snack bar with fail payment message
3.2.2.4.2 Shipper app use case description
Figure 3.19 Use case login Table 3.19 Use case login description
Use Case No SA 1.1 Use Case Version 1.0
• User open the shipper application
• Allow user to login to the system
• User who wants to login to the system
• Success: User login successfully as Shipper role
• Fail: a notification with fail message will showed up
Step Actor Action System Response
1 User open the application The system will show a splash
34 screen then it will navigate to login screen
2 User input username (phone number) and password User can obtain username and password in SMS or ask the admin
3 User tap on login button The system will login and navigate to the home page Alternative Scenario:
No Actor Action System Response
1 User tap on login button The system show a dialog with fail message
Figure 3.20 Use case logout Table 3.20 Use case description logout
Use Case No SA 1.2 Use Case Version 1.0
• User login to the system
• Allow user to logout system
• Allow user to logout system when the job is done
• User must login to the application
• Success: User return to login screen
Step Actor Action System Response
1 User goes to dashboard screen The system show actions on dashboard screen
2 User tap on logout screen Confirm logout dialog will shown up
3 User tap on ok The system will navigate to login screen
Figure 3.21 Use case accept order
Table 3.21 Table use case description accept order
Use Case No SA_1.3 Use Case Version 1.0
Use Case Name Use case register account
• User can get one order to delivery
• Help shipper get their job
• User must login at shipper role
• User must turn on location on phone
• Success: User will be navigated to track delivery screen
Step Actor Action System Response
1 Users Tap to ‘pick-up request’ button
The system show a list of orders available around shipper within 5km
2 Users need to choose one order from the list
The system will show detail of selected order (include store location, delivery location, products and its cost)
3 Users accept order on the top right of the screen
The system will pop out a confirm dialog asking user to confirm
4 Users confirm the dialog The system will navigate to tracking delivery screen
3.2.2.4.2.4 Use case change delivery state
Figure 3.22 Use case change delivery state Table 3.22 Table use case description change delivery state
Use Case No SA_1.4 Use Case Version 1.0
Use Case Name Use case register account
• User can change status of delivery order to notify end user of client known how their order going
• Change delivery state help end-user of client application knew their order and how long it will arrive
• User must login at shipper role
• User must have one delivery order currently
Step Actor Action System Response
1 Users Tap to track button on bottom right of the screen
The system show a Google map, showing their own location
2 User tap on my progress The system will show a bottom sheet where shows a timeline of delivery progress with 4 milestones:
1 On the way to store
4 On the way to delivery destination
3 User press on ‘next state’ on the left of timeline tree
The system will notify users via their mobile devices and update the order tracking status within the client application This will allow users to seamlessly progress to the next milestone in the timeline, while the current milestone remains displayed with accompanying text.
4 When user tap to final next state button to complete delivery
The system will show a success dialog and clean the order just complete and send to history delivery screen
3.2.2.4.2.5 Use case Navigate to call dial
Figure 3.23 Use case navigate to call dial Table 3.23 Table use case description navigate to call dial
Use Case No SA_1.5 Use Case Version 1.0
Use Case Name Navigate to call dial
• User can call to end-user of client application
• Through this function, user can call end-user of client application to confirm their order
• User must login at shipper role
• User must have one delivery order currently
Step Actor Action System Response
1 Users Tap to track button on bottom right of the screen
The system show a Google map, showing their own location
When users tap on "My Progress," a bottom sheet appears displaying a timeline of delivery progress Additionally, at the top of the screen, essential client information, including phone number and username, is prominently featured.
3 User press on phone button on top of the screen
The system will ask user for a permission to access dial on phone
4 When user accept to grant permission
The system will navigate to dial screen with provided phone number on tracking screen
3.2.2.4.2.6 Use case view history delivery
Figure 3.24 Use case history delivery Table 3.24 Use case description history delivery
Use Case No SA_1.6 Use Case Version 1.0
Use Case Name View history delivery
• User can view their history deliveries
• User can review how many orders they have done and its status
• Success: User can view their history delivery
• Fail: connect error will make use case fail
Step Actor Action System Response
When a user taps on the delivery history, the system displays a list of past orders, including details such as order ID, delivery time, store location, and delivery destination If the user has not made any previous deliveries, this screen will appear empty.
Step Actor Action System Response
1 User tap on deliver history If the internet interrupt while loading data, the system will not display history order
3.2.2.4.3 Client app use case description
Figure 3.25 Use case login social network Table 3.25 Use case description login social network
Use Case No UC_1.0 Use Case Version 1.0
Use Case Name Login social network
• The unauthenticated user that wants to access the system
• Allow the unauthenticated user to login to the system
• The unauthenticated user can login to the system
• The unauthenticated user must open the app
• Success: The end user will be redirected to their work screen
• Fail: The unauthenticated user can’t login to the system
Step Actor Action System Response
1 The unauthenticated user tap on
The system pop-up list device account
2 The unauthenticated user chooses one in list
The system will login with the selected account
3 If the selected account is new in database
The system navigates to adding the phone number and address screen
4 The unauthenticated user fills out the phone number and address
The system shows the typing information
5 The unauthenticated user taps on “Ok”
The system will save the data into database and navigates to the home screen
Figure 3.26 Use case view profile Table 3.26 Use case description view profile
Use Case No UC_1.1 Use Case Version 1.0
Use Case Name View profile
• Allow the end user can view his information
• The end user can view his information
• The end user must login in the system
• Success: The system navigates to profile screen
Step Actor Action System Response
1 The end user taps on “person” icon button on the bottom navigation
The system navigates to profile screen and response his information
Figure 3.27 Use case view the cart Table 3.27 Use case description view the cart
Use Case No UC_1.3 Use Case Version 1.0
Use Case Name View the cart
• Allow the end user can view the cart
• The end user can view the cart
Triggers: When the cart is not empty, the system will estimate duration time and delivery fee
• The end user must login in the system
• Success: The system response the cart screen
Step Actor Action System Response
1 The user taps on “cart” icon button on the app bar
The system navigates to the cart screen and response the cart item
Step Actor Action System Response
2 The user taps on “cart” icon button on the app bar, but cart is empty
The system navigates to the cart screen and response “the cart is empty”
Figure 3.28 Use case add to cart Table 3.28 Use case description add to cart
Use Case No UC_1.4 Use Case Version 1.0
Use Case Name Add to cart
• Allow the end user can add any product to cart
• The end user can add any product to cart
Triggers: Display total item in the cart
• The end user must login in the system
• The end user must navigate to product by categories screen
• Success: The system adds the item to the car
Step Actor Action System Response
1 The user taps on “add to cart” button on the product component
The system adds the item to the cart, display the total item in app bar and change “add to cart” button to increase/decrease the item
Step Actor Action System Response
1 The cart has more than a product The user taps on “add to cart” button on the product component from the other store
The system warning: “The product doesn’t belong the store Please try again”
Business rule: The list item cart must along a store
Figure 3.29 Use case view map Table 3.29 Use case description view map
Use Case No UC_1.5 Use Case Version 1.0
Use Case Name View map
• Allow the end user can view the map and his location
• The end user can view the map and his location
• The end user must login in the system
• Success: The system navigates to the map screen and mark the current
Step Actor Action System Response
1 The user taps on “map” icon button on the app bar
The system navigates to the map screen and mark the current location in the map
Figure 3.30 Use case view the order history Table 3.30 Use case description view the order history
Use Case No UC_1.6 Use Case Version 1.0
Use Case Name View the order history
• Allow the end user can view his order history
• The end user can view his order history
• The end user must login in the system
• Success: The system navigates to histories screen
Step Actor Action System Response
1 The end user taps on “histories” icon button on the bottom navigation
The system navigates to histories screen
2 The end user taps on the history tab
The system response a list order history data
Figure 3.31 Use case make the order Table 3.31 Use case description make the order
Use Case No UC_1.7 Use Case Version 1.0
Use Case Name Make the order
• Allow the end user can make the order from the anywhere
• The end user can make the order
• The end user must login in the system
• The cart must not empty
• Success: The system response “The order has been created successfully”
Step Actor Action System Response
1 The end user taps on “cart” icon button from the app bar
The system navigates to cart screen
2 The end user can edit the address in the screen
The system response the new address
3 The end user chooses the voucher
The system shows the selected voucher
4 The end user chooses the payment method
The system shows the payment method
5 The end user taps on “Purchase” button
The system call the api and response
“The order has been created successfully”
Step Actor Action System Response
1 The end user taps on “Purchase” button But the item in the cart list belongs more than one store
The system response “The order has been created unsuccessfully”
Business rule: The item in the cart list must along one store
Figure 3.32 Use case view product by categories
Table 3.32 Use case description view product by categories
Use Case No UC_1.8 Use Case Version 1.0
Use Case Name View product by categories
• Allow the end user view the product by categories
• The end user can make the order
• The end user must login in the system
• The end user must in store screen
• Success: The system response list product by categories
Step Actor Action System Response
1 The end user taps on any store from the store screen
The system navigates to product screen and response store name, address to name and list product by categories
Figure 3.33 Use case track order status Table 3.33 Use case description track order status
Use Case No UC_1.9 Use Case Version 1.0
Use Case Name Track order status
• Allow the end user can track the order status
• The end user can track the order status
• The end user must login in the system
• The order has been created
• Success: The system response real-time the order status for the end user and
Step Actor Action System Response
1 The use taps on “Navigate the coming page” or taps on
“Histories” button on the bottom navigation
The system navigates to the coming pages and response real-time the status order
Figure 3.34 Use case view the store Table 3.34 Use description view the store
Use Case No UC_1.10 Use Case Version 1.0
Use Case Name View the store
• Allow the end user can view the store list
• The end user can view the store list
• The end user must login in the system
• Success: The system navigates to the store screen
Step Actor Action System Response
1 The user taps on the any icon button in the top component
The system navigates to the store screen follow by the content of icon Alternative Scenario: N/A
3.2.2.4.3.11 Use case track shipper location
Figure 3.35 Use case track shipper location Table 3.35 Table use case description track shipper location
Use Case No CSM_1.11 Use Case Version 1.0
Use Case Name Use case track shipper location
• Allow the end user to track the shipper location
• The end user can know the shipper current location
• The end user has login by the social network
• The order has been placed and has not been successful
• Success: Server response the shipper location real-time
• Fail: Socket fail, user don’t know where the shipper
Step Actor Action System Response
1 The end user tap icon “Histories” in bottom navigation or tap “Go to coming page” button after create the order
The system will response real-time of the shipper location using socket
3.2.2.4.3.12 Use case estimate duration time and distance
Figure 3.36 Use case estimate time and duration order Table 3.36 Table use case description estimate duration time and delivery fee
Use Case No CSM_1.12 Use Case Version 1.0
Use Case Name Use case estimate duration time and delivery fee of the order
• Allow the end user estimate duration time and delivery fee
• The end user can know duration time and delivery fee
• The end user has login by the social network
• Success: Server response duration time and delivery fee
Step Actor Action System Response
1 The end user click icon “cart” button
The system will get your location and call the “openstreetmap” api to estimate duration time and delivery fee
3.2.2.4.3.13 Use case view store near me
Figure 3.37 Use case view store near me Table 3.37 Table use case description view store near me
Use Case No CSM_1.12 Use Case Version 1.0
Use Case Name Use case view store near me
• Allows end users to search for nearby stores
• The end user can view list nearby store
• The end user has login by the social network
• The end user touches the icon “near me” on dashboard screen
• Success: Server response list stores have the choose category and product
Step Actor Action System Response
1 The end user click icon “near me” on dashboard
The system will get your location and calculate to response list the store with the distance
3.2.2.4.4 CMS app use case description
Figure 3.38 use case login Table 3.38 Use case description login
Use Case No CSM 1.0 Use Case Version 1.0
Use Case Name Use case view store near me
• The user wants to login to the system
• The user wants to login to the system Login to the system to identify who the user is
• The user must go to https://hieuit.tech:3001/login page
• Success: User login to the system successfully
• Fail: user can’t login to the system, fail notification will be popped up Main success scenario:
Step Actor Action System Response
1 The user type in email, password
Upon clicking the login button, the system verifies the username If the username is valid, it proceeds to check the password Once both credentials are confirmed, the user is directed to their dashboard according to their specific role, and a success notification appears.
Step Actor Action System Response
1 The user type in email, password
The user clicks on login If the username is invalid or the password is incorrect, the system will show a fail notification
Figure 3.39 Register account Table 3.39 Use case description register account
Use Case No CSM_1.1 Use Case Version 1.0
Use Case Name Use case register account
• Allow unauthorized user to register account to web portal
• User can create their own account
• User need to go to register page
• Fill all required information in the form
• Success: System Will send mail to user Then user can login to web portal via created account
• Fail: The system will show a notification on top of screen show that the action where fails
Step Actor Action System Response
1 Users access to register page The system shows register UI, include all information user must fill in
2 Users Need to fill in: “mail”,” password”, “age”, “location”, …
The system will automatically send mail to your registered mail
3 Users need to go to mail to confirm the arrived mail
The system will allow users to login with their created account
4 Users return to login page and login into the system
The system will navigate to home page
Figure 3.40 Use case create category Table 3.40 Use case description create category
Use Case No CSM 1.2 Use Case Version 1.0
Use Case Name Use case create category
• Admin can create category on web portal application
• User as admin can create category account
• Fill all required information to the category create form
• Success: Admin create category successful
• Fail: Admin create category fail Fail notification will be shown
Step Actor Action System Response
1 Admin click management navigation then click on
The system shows category management
2 Users click on “Create” button The form is shown for user to fill
3 Users need to fill: ‘category name”, and click “Create”
The system will popup fail or success notification Then the category table will be refreshed Exception scenario:
Step Actor Action System Response
1 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘shipper name, age, address gender, shipper info and click “Create”
The system will show fail notification “create shipper fail Please try again”
Figure 3.41 Use case update category Table 3.41 Use case description update category
Use Case No CMS 1.3 Use Case Version 1.0
Use Case Name Use case update category
• User login as admin role
• User can update category name
• The system must have created category before
• Success: User update category successful
• Fail: a notification with fail message will showed up when updated fail
Step Actor Action System Response
1 User tap on Management navbar button, them tap on “category”
The system will navigate to category page
2 User select one category need to update, then tap on edit icon
The form dialog will appear with one text box require category name
3 User can change name on the input field (default value of input is the current name of selected category)
4 User click on update when done changing
The system will update category and show success notification Then the data table will be refreshed
No Actor Action System Response
1 User click on update when done changing
The system shows a fail notification
Figure 3.42 Use case delete category Table 3.42 Use case description delete category
Use Case No CMS 1.4 Use Case Version 1.0
Use Case Name Use case delete category
• User login as admin role
• The system must have created category before
• Success: User delete category successful
• Fail: If category has one or more products, it can’t be deleted
Step Actor Action System Response
1 User tap on Management navbar button, them click on
The system will navigate to category page
2 User select one category need to delete, then tap on delete icon
The confirm form appear ask user to confirm delete category
3 User click on “OK” The system will show a success notification Alternative Scenario:
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
Figure 3.43 Use case block user Table 3.43 Use case description block user
Use Case No CMS 1.5 Use Case Version 1.0
Use Case Name Use case Block user
• User login as admin role
• User can block one user
• Admin can block user violate some permission in the system
• There must have user as primary in the system
• Success: User selected will be blocked
• Fail: User will not be blocked and fail notification will show up
Step Actor Action System Response
1 User Selects on user need to block
The system will show a confirm dialog
2 User click on “OK” The system will block selected user
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
3.2.2.4.3.7 Use case create shipper account
Figure 3.44 Use case create shipper account Table 3.44 Use case description create shipper account
Use Case No CSM 1.6 Use Case Version 1.0
Use Case Name Use case create shipper account
• Admin can create shipper on web portal application
• User as admin can create shipper account
• Fill all required information to the shipper create form
• Success: Admin create shipper successful
• Fail: Admin create shipper fail Fail notification will be shown
Step Actor Action System Response
1 Admin click management navigation then click on
The system shows shipper management
2 Users click on “Create” button The form is shown for user to fill
3 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘shipper name, age, address gender, shipper info and click “Create”
The system will popup fail or success notification If success, the system will send SMS to registered phone number
Step Actor Action System Response
1 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘shipper name, age, address gender, shipper info and click “Create”
The system will show fail notification “create shipper fail Please try again”
3.2.2.4.3.8 Use case update shipper account
Figure 3.45 Use case update shipper account Table 3.45 Use case update shipper account
Use Case No CMS 1.7 Use Case Version 1.0
Use Case Name Use case update shipper account
• User login as admin role
• User can update shipper account to change information
• The system must have created shipper before
• Success: Information of shipper updated successfully
• Fail: a notification with fail message will showed up when updated fail
Step Actor Action System Response
1 User tap on Management navbar button, them tap on “Shippers”
The system will navigate to shippers page
2 User select one shipper need to update, then tap on edit icon
The form dialog will appear with all current information of selected shipper
3 User can change any information on the input fields
The system will validate if user input is invalid
4 User click on update when done changing
The system will update shipper and show success notification Then the data table will be refreshed
No Actor Action System Response
1 User click on update when done changing
The system shows a fail notification
Figure 3.46 Use case create employee Table 3.46 Use case description create employee
Use Case No CSM 1.8 Use Case Version 1.0
Use Case Name Use case create employee
• Primary user can create employee on web portal application
• User can create their own account
• Users must login with primary role
• Fill all required information to the form
• Success: Users create their employee successfully
Step Actor Action System Response
1 Users access to employee management page
The system show create employee
2 Users click on “Create” button The form is shown for user to fill
3 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘role’… and click “Create”
The system will popup fail or success notification If success, the system will send SMS to registered phone number
Step Actor Action System Response
1 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘role’… and click “Create”
The system will show fail notification “create employee fail
Figure 3.47 Use case update employee Table 3.47 Use case description update employee
Use Case No CMS 1.9 Use Case Version 1.0
Use Case Name Use case update shipper account
• User login as primary role
• User can update employee in POS application
• User can update employee account to change information
• The system must have created at least before
• Success: Information of employee updated successfully
• Fail: a notification with fail message will showed up when updated fail
Step Actor Action System Response
1 User tap on “My employee” navbar button
The system will navigate to employee page
2 User select one employee that need to be updated, then tap on edit icon
The form dialog will appear with all current information of selected employee
3 User can change any information on the input fields
The system will validate if user input is invalid
4 User click on update when done changing
The system will update employee and show success notification Then the data table will be refreshed
No Actor Action System Response
1 User click on update when done changing
The system shows a fail notification
Figure 3.48 Use case delete employee Table 3.48 Use case description delete employee
Use Case No CMS 1.10 Use Case Version 1.0
Use Case Name Use case lock employee
• User login as primary role
• User can lock employee from accessing POS application
• The system must have employee in the store
• Success: User lock selected employee successful and that employee cannot login to POS app
Step Actor Action System Response
1 User tap on “My employee” The system will navigate to
2 User select one category need to lock, then tap on lock icon
The confirm form appear ask user to confirm to lock employee
3 User click on “OK” The system will lock selected employee and show a success notification
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
3.2.2.4.3.12 Use case send SMS to employee
Figure 3.49 Use case send SMS to employee Table 3.49 Use case description send SMS to employee
Use Case No CSM_1.11 Use Case Version 1.0
Use Case Name Use case send SMS to employee
• Primary user can send SMS to employee on web portal application
• User send SMS to supply employee their account to access POS application Preconditions:
• Users must login with primary role
• Must have one employee in user POS application
• Success: users successfully sent SMS
Step Actor Action System Response
1 Users access to employee management page
The system shows list of employee
2 Users click on “Send SMS” button
Then the system will show confirm notification
3 User confirm to send SMS The system will send SMS to clicked employee
Figure 3.50 Use case create product Table 3.50 Use case description create product
Use Case No CSM 1.12 Use Case Version 1.0
Use Case Name Use case create product
• User login as primary user
• Primary user can create product on CMS
• User can create their product in POS application
• Users must login with primary role
• Fill all required information to the form
• Success: Users create their product successfully
• Fail: Product cannot be created because some invalid values
Step Actor Action System Response
1 Users access to product management page
The system show create product UI
2 Users click on “Create” button The form is shown for user to fill
3 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘role’… and click “Create”
The system will popup fail or success notification If success, the system will refresh data table and new product will appear on the product table
Step Actor Action System Response
1 Users need to fill: ‘mail’, ‘phone number’, ‘password’, ‘role’…
The system will show fail notification “create product fail
75 and click “Create” Please try again”
Figure 3.51 Use case update product Table 3.51 Use case description update product
Use Case No CMS 1.13 Use Case Version 1.0
Use Case Name Use case update product
• User login as primary role
• User can update product in POS application
• User can update product to change information
• The system must have product to update
• Success: Information of product updated successfully
• Fail: a notification with fail message will showed up when updated fail
Step Actor Action System Response
1 User tap on “My store” navbar button Then tap on “Products” button
The system will navigate to product page
2 User select one product that need to be updated, then tap on edit icon
The form dialog will appear with all current information of selected product
3 User can change any information on the input fields
The system will validate if user input is invalid
4 User click on update when done changing
The system will update product and show success notification Then the data table will be refreshed
No Actor Action System Response
1 User click on update when done changing
The system shows a fail notification
Figure 3.52 Use case delete product Table 3.52 Use case description delete product
Use Case No CMS 1.14 Use Case Version 1.0
Use Case Name Use case delete product
• User login as primary role
• The system must have product in store
• Success: User delete product successful
Step Actor Action System Response
1 User tap on “My store” navbar button Then tap on “Products” button
The system will navigate to product page
2 User select one product need to delete, then tap on delete icon
The confirm form appear ask user to confirm delete product
3 User click on “OK” The system will delete product and show a success notification Alternative Scenario:
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
Figure 3.53 Use case create voucher Table 3.53 Use case description create voucher
Use Case No CSM 1.15 Use Case Version 1.0
Use Case Name Use case create voucher
• User login as primary user
• Primary user can create voucher on web portal application
• User can create voucher base on some event
• Users must login with primary role
• Fill all required information to the form
• Success: Users create voucher successfully
Step Actor Action System Response
1 Users access to my store The system show create employee
2 Users click on “Create” button The form is shown for user to fill
3 Users need to fill title, description, discount, date and click “Create” button
The system will popup fail or success notification If success, the system will refresh data table and new voucher will appear on the table
Step Actor Action System Response
1 Users need to fill title, description, discount, date and click “Create” button
The system will show fail notification “create voucher fail
Figure 3.54 Use case update voucher Table 3.54 Use case description update product
Use Case No CMS 1.16 Use Case Version 1.0
Use Case Name Use case update product
• User login as primary role
• User can update voucher in POS application
• User can update voucher to change information
• The system must have voucher to update
• Success: Information of voucher updated successfully
• Fail: a notification with fail message will showed up when updated fail
Step Actor Action System Response
1 User tap on “My store” navbar button Then tap on “Vouchers” button
The system will navigate to vouchers page
2 User select one voucher that need to be updated, then tap on edit icon
The form dialog will appear with all current information of selected voucher
3 User can change any information on the input fields
(date range of voucher, title)
The system will validate if user input is invalid
4 User click on update when done changing
The system will update voucher and show success notification Then the data table will be refreshed and if success, new voucher will appear on the table
No Actor Action System Response
1 User click on update when done changing
The system shows a fail notification
Figure 3.55 Use case delete voucher Table 3.55 Use case description update voucher
Use Case No CMS 1.17 Use Case Version 1.0
Use Case Name Use case delete voucher
• User login as primary role
• User can delete voucher may be when it out of date
• The system must have voucher in store
• Success: User delete voucher successful
Step Actor Action System Response
1 User tap on “My store” navbar button Then tap on “voucher” button
The system will navigate to voucher page
2 User select one voucher need to delete, then tap on delete icon
The confirm form appear ask user to confirm delete voucher
3 User click on “OK” The system will delete voucher and show a success notification
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
Figure 3.56 Use case create area Table 3.56 Use case description create are
Use Case No CSM 1.18 Use Case Version 1.0
Use Case Name Use case create area
• User login as primary user
• Primary user can create area and table on web portal application
• User can create their own account
• Users must login with primary role
• Fill all required information to the form
• Success: Users create area and table successfully
Step Actor Action System Response
1 Users access to my store navigation, then click on
The system show creates area UI
2 Users click on “Add area” button
The form is shown for user to fill
3 Users need to fill area name and click “Create” button
The system will popup fail or success notification If success, the system will refresh data table and new area will appear on the screen
4 User can create table by click on add table
A modal form will appear for user to fill (table name)
5 User click on “Create” button The system will show a success notification and the table will show on
Step Actor Action System Response
1 Users need to fill area name and click “Create” button
The system will show fail notification “create voucher fail
Figure 3.57 Use case delete area Table 3.57 Use case description delete area
Use Case No CMS 1.19 Use Case Version 1.0
Use Case Name Use case delete area
• User login as primary role
• The system must have area in store
• Success: User delete area successful
• Fail: If there any table left on an area, it cannot be deleted
Step Actor Action System Response
1 User tap on “My store” navbar button
The system will navigate to area page
2 User click on cross icon on tab bar that you want to delete
The confirm form appear ask user to confirm delete area
3 User click on “OK” The system will delete area and show a success notification, the selected tab will be closed
No Actor Action System Response
1 User click on “OK” The system shows a fail notification
“delete area fail due to existing table!”
Non- functional requirements
- The employee can use essay the system
- The system design, which have a little bit defect
Security: Each employee just has one account to access into the system with differently role
- The system uses and maintain once/2week
- If the system has any heavy problem, will be maintain immediately
- If system have error, which must be the small error
- Time for payment with an order must be maximum 10s and minimum 0.5s
- Transaction’s amount at a moment is 10 transactions
- Resource: The system work stable with network speed > 1Mbps and available ram >1Gb
- Maintain easily: When I add the new feature, the old feature must be work stable
- Software writes in IDE Visual Studio 2019 Community or Android Studio or any IDE support coding with Flutter SDK
User interfaces must beautiful and useful with icons, button, label is explicit
It helps the user can easily use the system
The software must be use with:
▪ iPhone/iPad with 6 inch or higher
Software use any portable UI in flutter package such as: material, cupertino, thirdly party UI in flutter.dev