Software Requirements Specifications
Content
Point of Sale System for Poker Royale Lounge
A Software Requirements Specification
presented to the
Faculty of the College of Computer Studies
De La Salle University
in Partial Fulfillment
of the requirements of the course
INTROSE
by
Ang, Sofia Indira Odessa G.
Bigtas, Nikko Miyagee C.
Tiam-Lee, Thomas James Z.
Mr. Miguel Angelo Cabral
Professor
October 7, 2010
1
Table of Contents
1. Introduction....................................................................................................................................3
1.1. Overview........................................................................................................................................3
1.1.1. Company Background...........................................................................................................3
1.1.2. Organizational Chart............................................................................................................. 3
1.1.3. Business Process................................................................................................................... 4
1.1.4. Problem Description............................................................................................................. 5
1.2. Objectives, Scope, and Limitations................................................................................................ 5
1.2.1. Objectives............................................................................................................................. 5
1.2.2. Scope and Limitations..……………………………………………………………………………………………………6
2. Functional Requirements......................................................................................................................6
2.1. Software Functions........................................................................................................................ 6
2.2. User Types and Their Descriptions.................................................................................................8
2.3. Data Files and Their Descriptions.................................................................................................. 9
2.4. Report Types and Their Descriptions........................................................................................... 10
2.5. Use Case Diagrams.......................................................................................................................11
2.6. Use Case Descriptions..................................................................................................................12
References..............................................................................................................................................17
2
1. Introduction
1.1. Overview
1.1.1. Company Background
On November 2009, a group of young entrepreneurs founded Poker Royale. Poker Royale
is a PAGCOR-registered gaming establishment located at 1712 Roxas Boulevard Pasay City, just
beside Traders Hotel and right across Star City. To give players an immersive experience, Poker
Royale runs a mini bar/restaurant within the establishment so that players could enjoy food and
drinks while they entertain themselves. The mini bar and restaurant was a success that it has
been expanded and now occupies the entire second floor besides the corner they have in the
ground floor. The mini bar/restaurant is now called Poker Royale Lounge.
This project proposal aims to propose a more efficient way of managing their
bar/restaurant’s expanding business. As such, all the business processes, issues, problems, and
descriptions within this document shall only pertain to those of the bar/restaurant and nothing
more.
1.1.2. Organizational Chart
The operations of Poker Royale Lounge are headed by the operations manager. Under
him are several other employees who have their designated tasks in running the establishment.
Shown here are the key people in the hierarchy which are relevant to the system described
within this document.
3
1.1.3. Busines Process
Being a relatively new establishment, the Poker Royale Lounge has not yet taken
advantage of technology and does most of its business processes manually. The following are the
business processes we wish to support in our point of sale system:
Taking Orders
Waiter hands the menu to the customer
The waiter’s name and the customer’s order are recorded in an order slip
The operations manager or higher may give discounts to regular customers
The waiter, cashier, kitchen, and bar requires a copy of the order slip
The waiter personally hands copies of the order slip to the departments
Sales are manually deducted from the inventory and recorded by each department
Serving Orders
Food preparation time: 10 to 15 minutes
Drinks preparation time: 5 minutes
Waiter manually keeps track of these time intervals to know when an order is
ready to be served
Bill Out
Waiter copy of order slips for a customer are compiled, total amount is computed,
and then presented to the customer
Payment received is forwarded to the cashier
Cashier receives the payment and notes that the order slips involved are settled
Sales Counterchecking and Analysis
Order slip copies of each department are checked against each other for integrity
Operations manager manually organizes data from the order slip records and
inventory records into a report
Report must include number of sales for each item, total sales, and number of
transactions served by the waiter
All documents are stored for reference
4
1.1.4. Problem Description
The company’s current business processes presents the following problems:
Problems
Keeping track of
all the purchases
made by the
customers
Root Cause
Copious items
purchased by the
customers lead to
confusion, disorder
and unsystematic
way of tracking the
items.
Filing all
There are countless
transactions with transactions to be
customers
filed on such a short
period of time.
Engendering
accurate and
comprehensive
report
Incompetent
employees
Symptoms and Frequency
Business Impact
Because it is not automated, Because of a very time
human errors are very evident consuming task, the
here and there. Also, because employees are less
of many purchases, it takes a productive. Hence, the
while to manage all the items abilities and efforts of
being purchased. This problem each employee are not
occurs very often.
maximized.
Besides the task is very time
Purchasing
consuming, manually filing all unnecessary resources
data calls for the purchase of diminishes the profit
unnecessary resources such as gain by the business.
notebooks, ledgers, and pens. Thus, it affects the
Moreover, doing it in a short selling price of each
period of time can lead to
item which contributes
inaccuracy. This problem occurs to the judgment of the
very often.
customers.
If the report is not
Generating reports for
comprehensive, it affects the evaluation purposes
future business processes such are not accurate giving
as the inventory and the like. the company and the
This problem occurs
business a slow growth
sometimes.
rate.
1.1. Objectives, Scope, and Limitations
1.1.1. Objectives
The general objective of the system is to provide an efficient and easy-to-use point of
sale system to hasten and improve their operations.
The specific objectives are as follows:
To keep track of all transactions including the items sold and the total sales for
each
To provide an effective way of tracking waiter performance
5
To provide a flexible sales report tool that can generate various views on the
same data
1.1.2. Scopes and Limitations
In recording the purchases made by customers, the following information are stored:
(1) a unique transaction number assigned to every transaction, (2) the name of the customer,
(3) the name of the waiter, (4) the items purchased and their prices, (5) the date and time of the
transaction, (6) discounts applied to the transaction (if any), (7) the total price of all the items
bought or ordered after applying the discounts (if any).
For the database of items, the system will only store information about the items
offered in the lounge. Data regarding the number of stock for each item is not covered since an
inventory system is no longer in our scope. The following information are stored for each item in
the database: (1) the unique product identification number, (2) the product name, (3) item type,
(4) category, (5) the price the item was bought, and (6) the selling price. The item type is either
Food or Drinks. The category may be any one of the following: appetizer, chef’s special, noodles,
starters, sandwich, sizzler, seafood, for Food item-type; Cocktail, beer, liquor, shooters, on-therocks, beverages, fruit shakes, for Drinks item-type.
In generating reports on sales, the system can show detailed reports on the sales made
on a daily, weekly, monthly, or cumulative basis. The user can view this report any time he
wishes. To do so, he or she must input a specific day (for daily), a starting day for a week (for
weekly), or a month (for monthly). All transactions are stored by the system for future
reference. Each transaction has (1) the waiter name, (2) the items purchased, (3) the discounts
applied, and (4) the prices.
2. Functional Requirements
2.1. Software Functions
Our point of sale system is divided into three modules: the Transactions module, the
Administration module, and the Reports module.
2.1.1. Transactions Module
The Transactions Module provides facilities for the waiter to record and manage
customer orders.
Add order. This function allows waiters to input the customer’s order in the
system by inputting an identifier for the customer or by selecting from the
6
suggested active customers, selecting which items from an existing list (with
filtering by item type, and sorting item name and price) or by inputting the item
name in the search input that instantly displays results as one types. The
customer order will be marked as “Active” and displayed in the list of active
orders.
Cancel order. This function allows items in an active order to be cancelled in
case the customer wishes to change what he has ordered provided that that
those items have not been prepared yet.
Bill out. This function computes the total amount to be paid by a customer
before leaving the restaurant. It will also display all the consolidated orders
made by the customer and their corresponding price, as well as the total
amount. Once the items have been paid for, the transaction is considered
complete and is stored in the database.
2.1.2. Administration Module
The Administration Module provides facilities for the administrator to manage
the menu and item details.
Add item. This function allows new items in the menu to be recorded in the
system. The admin must provide the following details: item name, item
description, and price. The admin must also specify an item type (food or drink)
and a category (appetizer, chef’s special, noodles, starters, sandwich, sizzler,
seafood for food and cocktail, beer, liquor, shooters, on-the-rocks, beverages,
fruit shakes for drinks) by selecting from the drop-down menu or by inputting a
new item-type if it doesn’t exist yet.
Edit item. This function allows the modification of an item’s name, description,
price, and type. Editing an item will not affect previous transactions.
Delete item. This function allows items to be deleted. Deleting an item will also
not affect previous transactions.
Create new account. Initially, there is only one account for one administrator.
An administrator account can add new accounts for new waiters and
administrators who would be using the system. The administrator must fill the
necessary information requested in the form to create a new account.
2.1.3. Reports Module
The reports module provides facilities for the administrator to view sales report,
view transactions log, and track waiter performance.
7
View sales report. This function generates sales report either on a daily, weekly,
monthly, or cumulative basis by selecting or inputting month, day, or year
involved. Report on the number of pieces sold for each item will be provided in
tabular format and graphical format (e.g. bar graph). Filters and sorting
functionalities (as discussed in the Transaction Module -> Add order) will also be
implemented here with the addition that the user can make a selection on
which particular products to generate report on. Consolidated daily, weekly, and
monthly reports are also supported.
View transaction log. This function displays the transaction history over a
specified period by selecting or inputting the start and end date. Each
transaction will display the waiter-in-charge, the items ordered, price, discounts
(if any), and total amount. Filters according to which waiter will also be
implemented to easily view transactions by each waiter.
View waiter performance report. This function generates waiter performance
report through deriving the number of transactions by each waiter. Similar to
the above functionality, reports may be on a daily, weekly, monthly, or
cumulative basis. Consolidation of reports is also supported.
2.2. User Types and Their Descriptions
These are the different users that will be using the system.
2.2.1. Administrator
The administrator is one of the two users of the system. In this case, the
administrator is the operations manager of the bar and restaurant. However, there can
be more than one administrator. Other users can also become administrators provided
that they are qualified and authorized. Administrators can access the administration
module and the reports module. They are permitted to add new item, edit and update
item details. Moreover, they are also allowed to generate sales and waiter performance
reports.
2.2.2. Waiter
The waiter is the second user of the system. The waiters are responsible for the
transactions made with the customers. Thus, they are limited to accessing transaction
module only. They can view, add, edit and cancel orders. They use the system for every
transaction created.
2.3. Data Files and Their Descriptions
These are the files that would be used in the system:
8
2.3.1. Item File
This file contains details about all the items and meals that could be sold in the
bar and restaurant. This includes the (1) unique identification number, (2) item name,
(3) item type, (4) category and (5) the selling price. The identification number
distinguishes the item from all the other items in the database. The item name contains
a string about the name of the product. The category contains a string to which a
particular item belongs to. The item type classifies each item as food or drink. The
possible values for the category field are: appetizer, chef’s special, noodles, starters,
sandwich, sizzler, seafood (for food), cocktail, beer, liquor, shooters, on-the-rocks,
beverages, fruit shakes (for drinks). Finally, the selling price is the amount the item is to
be sold to the customers.
2.3.2. Order File
The order file contains data about a single order. It contains the following
information: (1) the waiter who made received the order (linked to Waiter file), (2) the
item ordered (linked to Item file), (3) the date and time, (4) discounts applied, (5) and
(4) the status. The discounts applied simply tells the percentage of discount to be
applied to the particular order. The status can either be active or paid. Active means the
customer hasn't checked out of the lounge yet. When he pays for all the orders he
made, all of those orders' statuses will be changed to paid. All of these orders are then
linked to a single transaction tuple in the Transaction file.
2.3.3. Transaction File
A transaction is a single instance of all the orders of a particular customer for a
specific time in the lounge. The transaction is made every time a customer pays his bills
and checks out of the lounge. A transaction simply contains the (1) total amount of all
the orders made, and (2) the date and time of the payment.
2.3.4. Account File
The system allows multiple users to log in to the system. To do this, each of
them would need an account to log in. The account file simply stores information about
each user's (1) user name, and (2) password. The (3) type of the user (administrator or
waiter) is also stored. New accounts may be created by administrators. This file will
simply be used to validate log ins from the users of the system.
2.3.5. Waiter File
This file contains information about the waiters in the restaurant. This file stores
the following information: (1) unique identification number, (2) last name, (3) first
name, (4) middle initial, (5) address, and (6) birthdate. The unique identification is a
unique string assigned to each waiter. The last name, first name, middle name, address,
9
and birthdate are personal information which are needed for the particular waiter's
profile.
2.4. Report Types and Their Descriptions
2.4.1. Sales Report
The sales report aims to help the administrator analyze sales and adjust well to
demands. The system provides the administrator with a flexible sales reporting tool.
Sales report may be generated in a daily, weekly, monthly, or cumulative basis. The
report focuses on the items and how well they sell. Sales income is only secondary.
Reports are presented in tabular format and graphical format to provide detailed and
visual presentation of the data. Sales can be viewed by item type, or a user-selection of
items. Consolidation of daily, weekly, or monthly reports presents the trend and
enables the administrator to make wiser decisions.
2.4.2. Transaction Log
The transaction log simply provides the administrator a history of transactions.
Each transaction contains the customer identifier, items order, their prices, discounts (if
any), total amount, and the waiter-in-charge. The transaction log may be filtered
according to span of days, and the waiter responsible. The transaction log may be used
for counter-checking transactions against cashier and other department records, or
devising promo schemes.
2.4.3. Waiter Performance Report
The waiter performance report aims to provide the administrator an effective
way of tracking waiter performance by keeping track of the number of transactions
made by each. Tracking waiter performance allows the administrator to commend
waiters and award them incentives for good performance or provide more training if
they do not fare very well.
2.5. Use Case Diagram
10
2.6. Use Case Descriptions
Use Case: Log-in
Precondition:
11
1. The user must be on the log-in form.
Flow:
1. The user enters his / her user name.
2. The user enters his / her password.
3. The user clicks the Proceed button.
4. The system checks the database if the user
name and password are correct and match.
5. If the account is verified, the system will
direct the user to Administrator Main View if
the user is an administrator and to Waiter Main
View otherwise.
Alternative Flow: None
Exceptional Flow:
1. If the user name or the password is
incorrect, a form will be prompted to inform
the user that the account does not exist.
Administrator Module
Use Case: Create new account
Precondition:
1. The user must be logged-in as an
administrator.
2. The user must select create new account on
the Administrator Main window.
Flow:
1. The user must fill-up the necessary
information (user name and password).
2. The user must resolve the type of user he/
she is (whether the administrator or the
waiter).
3. The user must click the Submit button.
4. The system adds the new account to the
database and notifies the user that a new
account has been created.
5. After clicking the button, it will redirect the
user to Administrator Main window.
Alternative Flow: Back Option
1. User selects Back Option whether the form
is filled(complete) or not(incomplete).
2. It will redirect the user to the Administrator
Main window.
Exceptional Flow:
1. If the user creates an account whose user
name already exists in the database, a prompt
would appear telling the user that this is not
possible and the user will be taken back to the
create new account form.
2. If the user inputs an empty string in the user
name or password text fields and he clicks on
submit, a prompt would appear telling the user
that this is not possible and the user will be
taken back to the create new account form.
Use Case: Manage Items
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Manage Items
option from the Administrator Main window.
Flow:
1. The user selects an action by clicking (Add
New Item, Delete Item or Edit Item)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Administrator Main
window regardless the item is generated or
not.
Use Case: Add Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Add Item option
from the Manage Items menu form.
Flow:
1. The user inputs the necessary details for the
new item to be added. This include the item
name, description, price, type, and category.
2. The user clicks on Submit.
12
3. The system assigns a unique identification
number to the new item added.
4. The new item is stored in the database.
5. The user is notified that a new item has been
added.
6. The user is taken back to the Manage Items
menu form.
Alternative Flow: Back Option
1. If the user selects Back, the user will be
taken back to the Manage Items menu form.
Exceptional Flow:
1. If the user clicks on Submit while any of the
fields are left blank, the system will prompt the
user that this is not possible and the user will
be taken back to the Add New Item form.
2. If the user clicks on Submit and the price of
the item is invalid (e.g., zero or negative), the
system will prompt the user that this is not
valid and the user will be taken back to the Add
New Item form.
Use Case: Edit Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Edit Item option
from the Manage Items menu form.
Flow:
1. The list of all the items is generated from the
stored items in the database.
2. The user enters a word to search for a
particular item or uses the filters (by category,
type) to narrow down the list.
3. The user selects the item he would like to
edit.
4. The user clicks the Edit button.
5. A new window pops up, allowing the user to
edit the item name, description, price,
category, and type.
6. After editing, the user clicks Done.
7. The system notifies the user that the
changes have been made.
8. The changes made to the item is stored in
the database.
9. The user is taken back to the Edit Item form.
Alternative Flow: Back Option
1. If the user selects Back, the user will be
taken back to the Manage Items menu form.
Exceptional Flow:
1. If the user clicks on Done while any of the
fields are left blank, the system will prompt the
user that this is not possible.
2. If the user clicks on Done and the price of
the item is invalid (e.g., zero or negative), the
system will prompt the user that this is not
valid.
Use Case: Delete Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Delete Item option
from the Manage Items menu form.
Flow:
1. The user selects the item to be deleted
2. The user clicks on the Delete option to
remove the selected item.
3. The system updates the database by marking
the status of the order ‘removed’.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks the Delete Option without
selecting any item, the system will display a
pop-up window informing the user that there
is no selected item to be deleted.
Report Module
Use Case: View Reports
Precondition:
1. The user must be logged in as administrator.
13
2. The user must select the View Reports
option from the Administrator Main window.
Flow:
1. The user selects an action by clicking (View
Sales Report, View Transaction Log or View
Waiter Performance Log)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Administrator Main
window.
Use Case: View Sales Report
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Sales Report
option from the View Reports menu form.
Flow:
1. The user sets the filter for the report (daily,
monthly, annually, cumulative) or specifies a
specific start date and end date.
2. The user chooses the representation of data
(tabular or graphical).
3. The system retrieves the necessary data and
displays the sales report for the user to see.
The sales report includes the sales figures of
each of the items during the time frame and
other related data (see description of the
report above).
4. The user enters words or chooses categories
or types to filter the items that appear in the
sales report.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Use Case: View Transaction Log
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Transaction
Log Report option from the View Reports menu
form.
Flow:
1.The user sets the filter for the report (daily,
monthly, annually, cumulative) or specifies a
specific start date and end date.
2. The system retrieves the necessary data and
displays the report the user (see description of
the report above).
3. The user enters words to search for
transactions of a particular customer.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Use Case: View Waiter Performance Report
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Waiter
Performance Report option from the View
Reports menu form.
Flow:
1. The user sets the filter for the report (daily,
monthly, yearly, cumulative) or specifies a
specific start date and end date.
2. The user selects the waiter whose report
he / she would like to view.
3. The system retrieves the necessary data and
displays them for the user (see description of
the report above).
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Transaction Module
Use Case: Manage Orders
Precondition:
1. The user must be logged in as waiter.
14
2. The user must select the Manage Orders
option from the Waiter Main window.
Flow:
1. The user selects an action by clicking (Add
Order and Cancel Order)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Use Case: Add Order
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Add Order option
from the Manage Orders menu form.
Flow:
1. The user inputs the unique customer
identifier (determined by business rules).
2. The user inputs the orders made by the
customer from a list of all items stored in the
database.
3. The user clicks Submit.
4. The system assigns a unique order
identification number to the new order.
5. The system sets the order status as ‘active’.
6. The new order, along with the date and
time, is stored in the database*.
7. The system notifies the user that a new
order has been added.
*Please note that even though multiple items
can be done in a single order, internally in the
database each order is represented as having a
single item only. Thus, having multiple items
require adding multiple entries into the
database.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks Submit and the customer
identifier is blank, the system will prompt the
user that this is not possible.
2. If the user clicks Submit and there is no item
specified, the system will prompt the user that
this is not possible.
Use Case: Cancel Order
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Delete Order
option from the Manage Orders menu form.
Flow:
1. The user selects the order to be deleted
2. The user clicks on the Delete option to
remove the selected order.
3. The system updates the database by marking
the status of the order ‘removed’.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks the Delete Option without
selecting any item, the system will display a
pop-up window informing the user that there
is no selected item to be deleted.
Use Case: Bill Out
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Bill Out option from
the Waiter Main window.
Flow:
1. The user selects the customer identifier
associated with the customer who wants to bill
out.
2. The system displays all orders of the said
customer marked as ‘active’.
15
3. The system gets the individual price of each
order and totals the purchases.
4. The user clicks on the Bill Out button.
5. A new transaction containing all the
purchases of the customer is added to the
database.
6. The user is taken back to the Waiter main
window.
Alternative Flow: Cancel Option
1. If the user selects Cancel Option, the user
will be redirected to the Waiter Main window.
16
References
Ang, S. (21 September, 2010). CEO, Poker Royale. Interview.
A Software Requirements Specification
presented to the
Faculty of the College of Computer Studies
De La Salle University
in Partial Fulfillment
of the requirements of the course
INTROSE
by
Ang, Sofia Indira Odessa G.
Bigtas, Nikko Miyagee C.
Tiam-Lee, Thomas James Z.
Mr. Miguel Angelo Cabral
Professor
October 7, 2010
1
Table of Contents
1. Introduction....................................................................................................................................3
1.1. Overview........................................................................................................................................3
1.1.1. Company Background...........................................................................................................3
1.1.2. Organizational Chart............................................................................................................. 3
1.1.3. Business Process................................................................................................................... 4
1.1.4. Problem Description............................................................................................................. 5
1.2. Objectives, Scope, and Limitations................................................................................................ 5
1.2.1. Objectives............................................................................................................................. 5
1.2.2. Scope and Limitations..……………………………………………………………………………………………………6
2. Functional Requirements......................................................................................................................6
2.1. Software Functions........................................................................................................................ 6
2.2. User Types and Their Descriptions.................................................................................................8
2.3. Data Files and Their Descriptions.................................................................................................. 9
2.4. Report Types and Their Descriptions........................................................................................... 10
2.5. Use Case Diagrams.......................................................................................................................11
2.6. Use Case Descriptions..................................................................................................................12
References..............................................................................................................................................17
2
1. Introduction
1.1. Overview
1.1.1. Company Background
On November 2009, a group of young entrepreneurs founded Poker Royale. Poker Royale
is a PAGCOR-registered gaming establishment located at 1712 Roxas Boulevard Pasay City, just
beside Traders Hotel and right across Star City. To give players an immersive experience, Poker
Royale runs a mini bar/restaurant within the establishment so that players could enjoy food and
drinks while they entertain themselves. The mini bar and restaurant was a success that it has
been expanded and now occupies the entire second floor besides the corner they have in the
ground floor. The mini bar/restaurant is now called Poker Royale Lounge.
This project proposal aims to propose a more efficient way of managing their
bar/restaurant’s expanding business. As such, all the business processes, issues, problems, and
descriptions within this document shall only pertain to those of the bar/restaurant and nothing
more.
1.1.2. Organizational Chart
The operations of Poker Royale Lounge are headed by the operations manager. Under
him are several other employees who have their designated tasks in running the establishment.
Shown here are the key people in the hierarchy which are relevant to the system described
within this document.
3
1.1.3. Busines Process
Being a relatively new establishment, the Poker Royale Lounge has not yet taken
advantage of technology and does most of its business processes manually. The following are the
business processes we wish to support in our point of sale system:
Taking Orders
Waiter hands the menu to the customer
The waiter’s name and the customer’s order are recorded in an order slip
The operations manager or higher may give discounts to regular customers
The waiter, cashier, kitchen, and bar requires a copy of the order slip
The waiter personally hands copies of the order slip to the departments
Sales are manually deducted from the inventory and recorded by each department
Serving Orders
Food preparation time: 10 to 15 minutes
Drinks preparation time: 5 minutes
Waiter manually keeps track of these time intervals to know when an order is
ready to be served
Bill Out
Waiter copy of order slips for a customer are compiled, total amount is computed,
and then presented to the customer
Payment received is forwarded to the cashier
Cashier receives the payment and notes that the order slips involved are settled
Sales Counterchecking and Analysis
Order slip copies of each department are checked against each other for integrity
Operations manager manually organizes data from the order slip records and
inventory records into a report
Report must include number of sales for each item, total sales, and number of
transactions served by the waiter
All documents are stored for reference
4
1.1.4. Problem Description
The company’s current business processes presents the following problems:
Problems
Keeping track of
all the purchases
made by the
customers
Root Cause
Copious items
purchased by the
customers lead to
confusion, disorder
and unsystematic
way of tracking the
items.
Filing all
There are countless
transactions with transactions to be
customers
filed on such a short
period of time.
Engendering
accurate and
comprehensive
report
Incompetent
employees
Symptoms and Frequency
Business Impact
Because it is not automated, Because of a very time
human errors are very evident consuming task, the
here and there. Also, because employees are less
of many purchases, it takes a productive. Hence, the
while to manage all the items abilities and efforts of
being purchased. This problem each employee are not
occurs very often.
maximized.
Besides the task is very time
Purchasing
consuming, manually filing all unnecessary resources
data calls for the purchase of diminishes the profit
unnecessary resources such as gain by the business.
notebooks, ledgers, and pens. Thus, it affects the
Moreover, doing it in a short selling price of each
period of time can lead to
item which contributes
inaccuracy. This problem occurs to the judgment of the
very often.
customers.
If the report is not
Generating reports for
comprehensive, it affects the evaluation purposes
future business processes such are not accurate giving
as the inventory and the like. the company and the
This problem occurs
business a slow growth
sometimes.
rate.
1.1. Objectives, Scope, and Limitations
1.1.1. Objectives
The general objective of the system is to provide an efficient and easy-to-use point of
sale system to hasten and improve their operations.
The specific objectives are as follows:
To keep track of all transactions including the items sold and the total sales for
each
To provide an effective way of tracking waiter performance
5
To provide a flexible sales report tool that can generate various views on the
same data
1.1.2. Scopes and Limitations
In recording the purchases made by customers, the following information are stored:
(1) a unique transaction number assigned to every transaction, (2) the name of the customer,
(3) the name of the waiter, (4) the items purchased and their prices, (5) the date and time of the
transaction, (6) discounts applied to the transaction (if any), (7) the total price of all the items
bought or ordered after applying the discounts (if any).
For the database of items, the system will only store information about the items
offered in the lounge. Data regarding the number of stock for each item is not covered since an
inventory system is no longer in our scope. The following information are stored for each item in
the database: (1) the unique product identification number, (2) the product name, (3) item type,
(4) category, (5) the price the item was bought, and (6) the selling price. The item type is either
Food or Drinks. The category may be any one of the following: appetizer, chef’s special, noodles,
starters, sandwich, sizzler, seafood, for Food item-type; Cocktail, beer, liquor, shooters, on-therocks, beverages, fruit shakes, for Drinks item-type.
In generating reports on sales, the system can show detailed reports on the sales made
on a daily, weekly, monthly, or cumulative basis. The user can view this report any time he
wishes. To do so, he or she must input a specific day (for daily), a starting day for a week (for
weekly), or a month (for monthly). All transactions are stored by the system for future
reference. Each transaction has (1) the waiter name, (2) the items purchased, (3) the discounts
applied, and (4) the prices.
2. Functional Requirements
2.1. Software Functions
Our point of sale system is divided into three modules: the Transactions module, the
Administration module, and the Reports module.
2.1.1. Transactions Module
The Transactions Module provides facilities for the waiter to record and manage
customer orders.
Add order. This function allows waiters to input the customer’s order in the
system by inputting an identifier for the customer or by selecting from the
6
suggested active customers, selecting which items from an existing list (with
filtering by item type, and sorting item name and price) or by inputting the item
name in the search input that instantly displays results as one types. The
customer order will be marked as “Active” and displayed in the list of active
orders.
Cancel order. This function allows items in an active order to be cancelled in
case the customer wishes to change what he has ordered provided that that
those items have not been prepared yet.
Bill out. This function computes the total amount to be paid by a customer
before leaving the restaurant. It will also display all the consolidated orders
made by the customer and their corresponding price, as well as the total
amount. Once the items have been paid for, the transaction is considered
complete and is stored in the database.
2.1.2. Administration Module
The Administration Module provides facilities for the administrator to manage
the menu and item details.
Add item. This function allows new items in the menu to be recorded in the
system. The admin must provide the following details: item name, item
description, and price. The admin must also specify an item type (food or drink)
and a category (appetizer, chef’s special, noodles, starters, sandwich, sizzler,
seafood for food and cocktail, beer, liquor, shooters, on-the-rocks, beverages,
fruit shakes for drinks) by selecting from the drop-down menu or by inputting a
new item-type if it doesn’t exist yet.
Edit item. This function allows the modification of an item’s name, description,
price, and type. Editing an item will not affect previous transactions.
Delete item. This function allows items to be deleted. Deleting an item will also
not affect previous transactions.
Create new account. Initially, there is only one account for one administrator.
An administrator account can add new accounts for new waiters and
administrators who would be using the system. The administrator must fill the
necessary information requested in the form to create a new account.
2.1.3. Reports Module
The reports module provides facilities for the administrator to view sales report,
view transactions log, and track waiter performance.
7
View sales report. This function generates sales report either on a daily, weekly,
monthly, or cumulative basis by selecting or inputting month, day, or year
involved. Report on the number of pieces sold for each item will be provided in
tabular format and graphical format (e.g. bar graph). Filters and sorting
functionalities (as discussed in the Transaction Module -> Add order) will also be
implemented here with the addition that the user can make a selection on
which particular products to generate report on. Consolidated daily, weekly, and
monthly reports are also supported.
View transaction log. This function displays the transaction history over a
specified period by selecting or inputting the start and end date. Each
transaction will display the waiter-in-charge, the items ordered, price, discounts
(if any), and total amount. Filters according to which waiter will also be
implemented to easily view transactions by each waiter.
View waiter performance report. This function generates waiter performance
report through deriving the number of transactions by each waiter. Similar to
the above functionality, reports may be on a daily, weekly, monthly, or
cumulative basis. Consolidation of reports is also supported.
2.2. User Types and Their Descriptions
These are the different users that will be using the system.
2.2.1. Administrator
The administrator is one of the two users of the system. In this case, the
administrator is the operations manager of the bar and restaurant. However, there can
be more than one administrator. Other users can also become administrators provided
that they are qualified and authorized. Administrators can access the administration
module and the reports module. They are permitted to add new item, edit and update
item details. Moreover, they are also allowed to generate sales and waiter performance
reports.
2.2.2. Waiter
The waiter is the second user of the system. The waiters are responsible for the
transactions made with the customers. Thus, they are limited to accessing transaction
module only. They can view, add, edit and cancel orders. They use the system for every
transaction created.
2.3. Data Files and Their Descriptions
These are the files that would be used in the system:
8
2.3.1. Item File
This file contains details about all the items and meals that could be sold in the
bar and restaurant. This includes the (1) unique identification number, (2) item name,
(3) item type, (4) category and (5) the selling price. The identification number
distinguishes the item from all the other items in the database. The item name contains
a string about the name of the product. The category contains a string to which a
particular item belongs to. The item type classifies each item as food or drink. The
possible values for the category field are: appetizer, chef’s special, noodles, starters,
sandwich, sizzler, seafood (for food), cocktail, beer, liquor, shooters, on-the-rocks,
beverages, fruit shakes (for drinks). Finally, the selling price is the amount the item is to
be sold to the customers.
2.3.2. Order File
The order file contains data about a single order. It contains the following
information: (1) the waiter who made received the order (linked to Waiter file), (2) the
item ordered (linked to Item file), (3) the date and time, (4) discounts applied, (5) and
(4) the status. The discounts applied simply tells the percentage of discount to be
applied to the particular order. The status can either be active or paid. Active means the
customer hasn't checked out of the lounge yet. When he pays for all the orders he
made, all of those orders' statuses will be changed to paid. All of these orders are then
linked to a single transaction tuple in the Transaction file.
2.3.3. Transaction File
A transaction is a single instance of all the orders of a particular customer for a
specific time in the lounge. The transaction is made every time a customer pays his bills
and checks out of the lounge. A transaction simply contains the (1) total amount of all
the orders made, and (2) the date and time of the payment.
2.3.4. Account File
The system allows multiple users to log in to the system. To do this, each of
them would need an account to log in. The account file simply stores information about
each user's (1) user name, and (2) password. The (3) type of the user (administrator or
waiter) is also stored. New accounts may be created by administrators. This file will
simply be used to validate log ins from the users of the system.
2.3.5. Waiter File
This file contains information about the waiters in the restaurant. This file stores
the following information: (1) unique identification number, (2) last name, (3) first
name, (4) middle initial, (5) address, and (6) birthdate. The unique identification is a
unique string assigned to each waiter. The last name, first name, middle name, address,
9
and birthdate are personal information which are needed for the particular waiter's
profile.
2.4. Report Types and Their Descriptions
2.4.1. Sales Report
The sales report aims to help the administrator analyze sales and adjust well to
demands. The system provides the administrator with a flexible sales reporting tool.
Sales report may be generated in a daily, weekly, monthly, or cumulative basis. The
report focuses on the items and how well they sell. Sales income is only secondary.
Reports are presented in tabular format and graphical format to provide detailed and
visual presentation of the data. Sales can be viewed by item type, or a user-selection of
items. Consolidation of daily, weekly, or monthly reports presents the trend and
enables the administrator to make wiser decisions.
2.4.2. Transaction Log
The transaction log simply provides the administrator a history of transactions.
Each transaction contains the customer identifier, items order, their prices, discounts (if
any), total amount, and the waiter-in-charge. The transaction log may be filtered
according to span of days, and the waiter responsible. The transaction log may be used
for counter-checking transactions against cashier and other department records, or
devising promo schemes.
2.4.3. Waiter Performance Report
The waiter performance report aims to provide the administrator an effective
way of tracking waiter performance by keeping track of the number of transactions
made by each. Tracking waiter performance allows the administrator to commend
waiters and award them incentives for good performance or provide more training if
they do not fare very well.
2.5. Use Case Diagram
10
2.6. Use Case Descriptions
Use Case: Log-in
Precondition:
11
1. The user must be on the log-in form.
Flow:
1. The user enters his / her user name.
2. The user enters his / her password.
3. The user clicks the Proceed button.
4. The system checks the database if the user
name and password are correct and match.
5. If the account is verified, the system will
direct the user to Administrator Main View if
the user is an administrator and to Waiter Main
View otherwise.
Alternative Flow: None
Exceptional Flow:
1. If the user name or the password is
incorrect, a form will be prompted to inform
the user that the account does not exist.
Administrator Module
Use Case: Create new account
Precondition:
1. The user must be logged-in as an
administrator.
2. The user must select create new account on
the Administrator Main window.
Flow:
1. The user must fill-up the necessary
information (user name and password).
2. The user must resolve the type of user he/
she is (whether the administrator or the
waiter).
3. The user must click the Submit button.
4. The system adds the new account to the
database and notifies the user that a new
account has been created.
5. After clicking the button, it will redirect the
user to Administrator Main window.
Alternative Flow: Back Option
1. User selects Back Option whether the form
is filled(complete) or not(incomplete).
2. It will redirect the user to the Administrator
Main window.
Exceptional Flow:
1. If the user creates an account whose user
name already exists in the database, a prompt
would appear telling the user that this is not
possible and the user will be taken back to the
create new account form.
2. If the user inputs an empty string in the user
name or password text fields and he clicks on
submit, a prompt would appear telling the user
that this is not possible and the user will be
taken back to the create new account form.
Use Case: Manage Items
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Manage Items
option from the Administrator Main window.
Flow:
1. The user selects an action by clicking (Add
New Item, Delete Item or Edit Item)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Administrator Main
window regardless the item is generated or
not.
Use Case: Add Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Add Item option
from the Manage Items menu form.
Flow:
1. The user inputs the necessary details for the
new item to be added. This include the item
name, description, price, type, and category.
2. The user clicks on Submit.
12
3. The system assigns a unique identification
number to the new item added.
4. The new item is stored in the database.
5. The user is notified that a new item has been
added.
6. The user is taken back to the Manage Items
menu form.
Alternative Flow: Back Option
1. If the user selects Back, the user will be
taken back to the Manage Items menu form.
Exceptional Flow:
1. If the user clicks on Submit while any of the
fields are left blank, the system will prompt the
user that this is not possible and the user will
be taken back to the Add New Item form.
2. If the user clicks on Submit and the price of
the item is invalid (e.g., zero or negative), the
system will prompt the user that this is not
valid and the user will be taken back to the Add
New Item form.
Use Case: Edit Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Edit Item option
from the Manage Items menu form.
Flow:
1. The list of all the items is generated from the
stored items in the database.
2. The user enters a word to search for a
particular item or uses the filters (by category,
type) to narrow down the list.
3. The user selects the item he would like to
edit.
4. The user clicks the Edit button.
5. A new window pops up, allowing the user to
edit the item name, description, price,
category, and type.
6. After editing, the user clicks Done.
7. The system notifies the user that the
changes have been made.
8. The changes made to the item is stored in
the database.
9. The user is taken back to the Edit Item form.
Alternative Flow: Back Option
1. If the user selects Back, the user will be
taken back to the Manage Items menu form.
Exceptional Flow:
1. If the user clicks on Done while any of the
fields are left blank, the system will prompt the
user that this is not possible.
2. If the user clicks on Done and the price of
the item is invalid (e.g., zero or negative), the
system will prompt the user that this is not
valid.
Use Case: Delete Item
Precondition:
1. The user must be logged in as administrator.
2. The user must select the Delete Item option
from the Manage Items menu form.
Flow:
1. The user selects the item to be deleted
2. The user clicks on the Delete option to
remove the selected item.
3. The system updates the database by marking
the status of the order ‘removed’.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks the Delete Option without
selecting any item, the system will display a
pop-up window informing the user that there
is no selected item to be deleted.
Report Module
Use Case: View Reports
Precondition:
1. The user must be logged in as administrator.
13
2. The user must select the View Reports
option from the Administrator Main window.
Flow:
1. The user selects an action by clicking (View
Sales Report, View Transaction Log or View
Waiter Performance Log)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Administrator Main
window.
Use Case: View Sales Report
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Sales Report
option from the View Reports menu form.
Flow:
1. The user sets the filter for the report (daily,
monthly, annually, cumulative) or specifies a
specific start date and end date.
2. The user chooses the representation of data
(tabular or graphical).
3. The system retrieves the necessary data and
displays the sales report for the user to see.
The sales report includes the sales figures of
each of the items during the time frame and
other related data (see description of the
report above).
4. The user enters words or chooses categories
or types to filter the items that appear in the
sales report.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Use Case: View Transaction Log
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Transaction
Log Report option from the View Reports menu
form.
Flow:
1.The user sets the filter for the report (daily,
monthly, annually, cumulative) or specifies a
specific start date and end date.
2. The system retrieves the necessary data and
displays the report the user (see description of
the report above).
3. The user enters words to search for
transactions of a particular customer.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Use Case: View Waiter Performance Report
Precondition:
1. The user must be logged in as administrator.
2. The user must select the View Waiter
Performance Report option from the View
Reports menu form.
Flow:
1. The user sets the filter for the report (daily,
monthly, yearly, cumulative) or specifies a
specific start date and end date.
2. The user selects the waiter whose report
he / she would like to view.
3. The system retrieves the necessary data and
displays them for the user (see description of
the report above).
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the View Reports menu form.
Transaction Module
Use Case: Manage Orders
Precondition:
1. The user must be logged in as waiter.
14
2. The user must select the Manage Orders
option from the Waiter Main window.
Flow:
1. The user selects an action by clicking (Add
Order and Cancel Order)
2. The system will direct the user to the
designated form.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Use Case: Add Order
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Add Order option
from the Manage Orders menu form.
Flow:
1. The user inputs the unique customer
identifier (determined by business rules).
2. The user inputs the orders made by the
customer from a list of all items stored in the
database.
3. The user clicks Submit.
4. The system assigns a unique order
identification number to the new order.
5. The system sets the order status as ‘active’.
6. The new order, along with the date and
time, is stored in the database*.
7. The system notifies the user that a new
order has been added.
*Please note that even though multiple items
can be done in a single order, internally in the
database each order is represented as having a
single item only. Thus, having multiple items
require adding multiple entries into the
database.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks Submit and the customer
identifier is blank, the system will prompt the
user that this is not possible.
2. If the user clicks Submit and there is no item
specified, the system will prompt the user that
this is not possible.
Use Case: Cancel Order
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Delete Order
option from the Manage Orders menu form.
Flow:
1. The user selects the order to be deleted
2. The user clicks on the Delete option to
remove the selected order.
3. The system updates the database by marking
the status of the order ‘removed’.
Alternative Flow: Back Option
1. If the user selects Back Option, the user will
be redirected to the Waiter Main window.
Exceptional Flow:
1. If the user clicks the Delete Option without
selecting any item, the system will display a
pop-up window informing the user that there
is no selected item to be deleted.
Use Case: Bill Out
Precondition:
1. The user must be logged in as waiter.
2. The user must select the Bill Out option from
the Waiter Main window.
Flow:
1. The user selects the customer identifier
associated with the customer who wants to bill
out.
2. The system displays all orders of the said
customer marked as ‘active’.
15
3. The system gets the individual price of each
order and totals the purchases.
4. The user clicks on the Bill Out button.
5. A new transaction containing all the
purchases of the customer is added to the
database.
6. The user is taken back to the Waiter main
window.
Alternative Flow: Cancel Option
1. If the user selects Cancel Option, the user
will be redirected to the Waiter Main window.
16
References
Ang, S. (21 September, 2010). CEO, Poker Royale. Interview.
