Skip to content
Fadhil Muhammad
All work

Dapur360System analysis

Ordering, kitchen and stock for a vegan restaurant

A restaurant system designed around the table QR code: customers order from their phone, the cashier confirms, the kitchen works a queue, and every sale draws ingredients from stock through the menu's recipe.

Role
Systems analyst: use case diagram and class diagram
Status
Design and analysis
Dapur360 design board: customer, cashier, kitchen and owner with their use cases, the core data model linking tables, orders, menu recipes, ingredients and stock, and the order status from created to done
  • 4roles: customer, cashier, kitchen, owner
  • 14use cases, sign-in included
  • 14classes in the data model

The deliverables are the use case diagram and the class diagram, so there are no usage numbers.

Context

The problem

In a restaurant, orders, payments, kitchen work and ingredient stock easily end up in separate places. Dapur360 is a design for keeping them in one system, so the owner can see what each sale uses and what needs restocking.

Solution

What we built

One system for four roles. Each table has its own QR code, so customers open the menu, order, edit and pay without an account. The cashier confirms the order and forwards it to the kitchen, which works through a queue and marks each order done. Behind the menu, every item has a recipe of ingredients, so sales draw stock automatically, while purchases from suppliers come in as stock batches.

  • System analysis
  • Use case diagram
  • Class diagram
  • POS
  • QR self-ordering

Workflow

From table to stock

  1. Scan the tableThe QR code carries the table's token, so the order is tied to the table without a login.
  2. Order and payThe customer builds the order, can still edit it, and pays. The transaction stores the payment method and prints a receipt.
  3. ConfirmThe cashier accepts and confirms the order, or cancels it.
  4. Kitchen queueConfirmed orders are forwarded to the kitchen, which updates each one until it's done.
  5. Stock outEach order item draws its ingredients through the menu's recipe, taken from a specific stock-in batch.
  6. RestockThe owner records purchases from suppliers and uploads the receipt; purchased ingredients come in as stock in.

Scope

What's in it

Roles and use cases

  • Customer: scan the QR and view the menu, place, edit and pay for an order
  • Cashier: accept and confirm orders, forward them to the kitchen
  • Kitchen: see the order queue, update order status
  • Owner: purchasing, inventory, menu data, reports and user accounts

Data model

  • Tables with a generated QR token
  • Orders, order items and transactions with payment method
  • Menu categories, menus with availability, and recipes
  • Ingredients with a minimum stock level
  • Suppliers, purchases with receipts, and purchase items
  • Stock in and stock out, linked by batch

Business rules

Rules the system enforces

  • Customers have no account in the data model; staff and the owner sign in, and each user has a role.
  • An order moves from created to confirmed, to the kitchen, to done, and can be cancelled along the way.
  • A menu item can be switched off and has an availability check.
  • Each ingredient has a minimum stock level that the system checks.
  • Stock out always points to the stock-in batch it was taken from, and a batch is marked empty when it runs out.
  • Purchases keep the receipt and are checked for price changes.

Decisions

Decisions and trade-offs

The table is the customer's identity

There is no customer account in the data model. The order carries the table, which keeps self-ordering to one scan and nothing to sign up for.

Recipes connect sales to stock

Menus don't hold stock. A recipe lists the ingredients and quantities per menu item, so one sale can reduce several ingredients without anyone counting by hand.

Stock is tracked by batch

Every purchase line becomes a stock-in batch, and every stock-out record points back to one. So every unit that leaves stock can be traced to the purchase it came from.

Orders and payments are separate

An order describes what the table wants; a transaction records the payment, the cashier who handled it and the payment method.

My role

What I owned

  • Defined the roles and use cases for customer, cashier, kitchen and owner.
  • Designed the class diagram: 14 classes with their attributes, operations and relationships.
  • Modelled the order status flow and the stock rules behind recipes and batches.

Artefacts

Use case diagram of Dapur360: the customer scans the table QR, orders, edits and pays; the cashier confirms orders and forwards them to the kitchen; the kitchen sees the queue and updates status; the owner manages purchasing, inventory, menu data, reports and users.Open full sizeClass diagram of Dapur360 with 14 classes: table, user, order, order item, transaction, menu category, menu, recipe, ingredient, supplier, purchase, purchase item, stock in and stock out.Open full size
Next case studySales, purchasing and stock for a wholesale shop

Have a process that should be a system?

I'm not looking for a new role, but I'm always up for a conversation about a system, a process or a collaboration.

Contact me
fadhilmuhammad.mdev@gmail.com