Home
Project Home
Developers
Features & Benefits
Download
ScreenShots
Contact
EasyPOS Related Project
|
![](spacer.gif) |
![](spacer.gif) |
System Requirements Specification
SRS as of Mon Jan 15 21:59:13 CST 2001
Scope: Definition of a Requirements Specification
This document describes the requirements and capabilities that the gShop program is aimed at.
The aim of the requirements document is to list all of the capabilities of the system. That is,
the requirements document is strictly a statement of _what_ the system can do, and not a discussion
of _how_ it will acheive this.
Each requirement is a standalone item that can be demonstrated and tested on its own. Requirements,
by their standalone nature, cannot include or refer to other requirements. Requirements can however
be grouped into functional areas.
The purpose of having a formal requirements specification is as follows :
- To identify all of the capabilities of the system before getting too deep into the design phase.
This assists in the production of the design document later on.
- To clearly itentify what the system can do. This is a valuable resource for prospective users/buyers
of the system, so they can see what the system can do, and what needs to be modified. This also
assists in the preparation of tenders - where a list of requirements is given by the customer, and
the tender document must then tick or cross each one.
- The requirements list provides a definitive list of what functions and capabilities need to be
tested. Later on a formal System Test Document is created, which effectively develops test cases which
cover all of the requirements.
- Requirements traceability. The design document and the test document includes a table which cross
references back to the requirements, so that it can be seen that all requirements are covered by
a section of the design, and have an appropriate test case.
Historical overview:
gShop is heavily based on the gtkPizza program, which has laid the foundation at least for
the business rules and real-life experience of supporting such applications.
gShop however IS NOT gtkPizza, gShop in particular attempts to address the following weaknesses
of gtkPizza :
- Easy to install, based upon standard linux tools such as Glade, autoconf, etc.
- More graphically intense : gShop makes maximum use of graphical elements for selection and
data entry. One-handed order entry is the aim here.
- Portable. gShop aims to be portable across a wider range of systems, front ends, and databases.
- Speed. gShop aims to address some of the speed issues in gtkPizza.
gShop requirements overview:
gShop shall be : Feature-rich, Fast, and Free.
The quick outline is that gShop intends to provide a complete point of sale system for use in :
- Small Stores.
- Pizza Bars / take away food stores.
- Restaraunts and Bistros.
- Wide area chains of businesses listed above.
- Large stores that carry thousands of items.
- Wide area chains of large stores.
The sorts of business requirements between small stores with a small product line, and a large
chain of stores with massive product lines is radically different.
The gShop project aims to analyse the business requirements of these range of shops, and determine
the common ground that all of these businesses share.
Where the requirements diverge (and become mutually exclusive), gShop aims to provide a variety
of transaction processing front-ends to meet these differing requirements.
The intention is that when gShop is configured for installation at a certain type of business,
parameters about the operation of the business are entered in the setup/configuration screen,
and then gShop will only present the transaction interfaces that are relevant for this business.
Any feature of gShop which is not relevant for a particular business can be simply disabled
from the configuration menu.
In order to acheive a level of reality in the requirements study, the gShop project will
focus on 3 hypothetical businesses, each of which has differing requirements. The success of the
adaptability of gShop can be tested by the way in which gShop can be configured for each of these
sets of business requirements.
Hypothetical cases :
1 - Roccos Pizzeria. (Typical suburban Pizza Bar / Restaraunt)
- Roccos Pizzeria has a small catalog of items, each with a complex pricing grid.
- Customers phone in orders for delivery, or pickup.
- The in-store computer also runs a web site that takes orders for delivery and pickup.
- All delivery and pickup orders receive a tax-invoice / docket delivered with the goods.
- Rocco's also has a bistro section with 10 tables. Customers come in off the street
and take a table, and a waiter takes orders. Customers in the bistro pay for their
meals and drinks at the end of the meal, so the system has to keep an open tab
on each table.
- All orders (pickup, delivery & table customers), print a separate ticket in the
kitchen area, so the cook can see what is required next.
- Rocco's also has a nightclub section, with a computerised drinks counter. This just
uses a touchscreen to record drinks sold - no keyboards here at all.
- Stock levels are tracked on drinks, but are not tracked on pizza raw materials.
- Rocco's staff are mostly casual employees who need to enter timesheet data on a
fortnightly basis.
- There is 1 single POS terminal dedicated to phone orders, another POS terminal
dedicated to table based customers, and 1 touchscreen POS terminal in the nightclub
for the drinks counter.
2 - Felicity's Florist. (Franchised Florist Shop)
- Felicity's Florist is a successful florist shop franchise, with 10 stores spread
across the state. They sell a large range of flowers, cards and chocolates which are most
often sold as special made-up 'gift packs' .
- Felicity's Florist has a small catalog of items, each with a complex pricing grid.
- Items sold are made up from a number of raw materials.
- Items are assembled out of raw components on an as-need basis.
- All inventory levels on raw materials are tracked.
- There are 3 POS terminals in each store. Orders entered into any POS terminal
need to be displayed on all 3 terminals in real time.
- Most sales are over the counter sales.
- Felicity's Florist takes telephone orders for pickups and deliveries,
as well as internet orders.
- Most phone orders are for delivery to anonymous customers, using credit card
numbers over the phone.
- Felicity's have a number of corporate clients who have regular deliveries of
products on a weekly or fortnightly basis.
- The franchise head office sets all pricing and product line information from a
central location, and wishes to receive consolidated transactions on a daily basis.
3 - Crazy Dave's Discount Superstore. (Chain of large general stores)
- Crazy Dave's is a chain of 50 stores spread across 3 continents.
- There are 10,000 product lines in the catalog, all of which require inventory
level tracking in each store.
- All sales are point of sale at the cash register.
- Head office requires real-time transaction updates from all stores, so that
inventory levels can be synchronised in real time.
- There are 20 POS terminals in each store. Each POS terminal needs to record
only the transactions and cash summaries for this terminal.
- Each store has a management terminal in the back office which displays to
consolidated trading summary for this store in real time.
- Corporate headquaters sets all item code and pricing information at a global
level, which is performed on a weekly basis. Setting prices at head office
must immediately reflect back on the prices in individual stores.
- Individual stores are free to run discounts on selected product lines
as required, otherwise, head office pricing is required.
- Each store performs a cursory stocktake on a weekly basis. Every 3 months (Quarterly),
there is a full audited stocktake on all product lines.
Help Screens :
The system shall provide a number of context sensitive help screens to match the current
screen.
There are also a number of global system variables present in the system which radically
affect the behaviour of the system (see items on cash-till vs store-wide mode, smorgasbord
vs ala-carte mode, etc). In these cases, the help screens displayed by the system shall only
incorporate those features and capabilities which are present in the current configuration.
It may be appropriate in this case to deliver the HTML help screens from a PHP or cgi based
server, rather than use static HTML.
1. System Requirements.
The system shall cover all operations for a typical small shop. By configuring various items in the
database, the system shall provide facilities for a number of different business activities.
1.1 System Transaction Capabilities.
The system shall be able to process the following types of transactions :
1.1.1 Point of Sale Transactions with on-screen touch catalogs (small inventories).
1.1.2 Point of Sale Transactions with scanned product ID's (huge inventories).
1.1.3 Pickup Order Transactions. (Anonymous customers)
1.1.4 Delivery Order Transactions. (Known customers)
1.1.5 Table Account Transactions. (Temporary customers)
1.1.6 Internet Delivery Order Transactions. (eCommerce customers)
1.1.7 Purchase Transactions.
1.1.8 Employee Timesheets.
1.1.9 Drinks Counter Transactions.
1.2 GUI Requirements.
The system shall be a GUI based application that runs on XWindows based machines.
The requirements for the GUI are as follows :
1.2.1 GNOME/GTK+ Based.
1.2.2 Built using Glade, to allow for easy customisation.
1.2.3 Extensive use of mouse / touch screen selections.
1.2.4 Operate in full-screen / maximized mode.
1.3 Database Requirements.
The system shall use a standard, GPL'ed SQL database for all storage. This includes :
1.3.1 A database virtualisation layer.
1.3.2 Only portable SQL will be allowed through the virtualisation layer.
1.3.3 Support for PostgreSQL and MySQL.
1.4 Networking Requirements.
The system shall make full use of Networking facilities. Networking capabilities
are to include :
1.4.1 Realtime broadcasts of shop status to all terminals.
1.4.2 Full replication between stores.
1.4.3 Internet ordering built in to the base system.
1.5 Security Requirements.
The system shall provide basic security protection to data.
1.5.1 Maintenance of user accounts which are separate from Unix accounts.
1.5.2 Access control profiles which determine access to various functions.
1.5.3 Automatic logout after an elapsed period of no activity.
1.6 Reporting Requirements.
The system shall provide reasonable reporting facilities with the base product, but
allow for easy customisation to create new reports.
1.6.1 All reporting shall be performed through the intranet interface, using PHP.
The customer can then (easily ?) add more reporting facilities using PHP.
1.7 Marketting Requirements.
1.8 Internationalization Requirements.
2. System startup requirements.
2.1 The system shall display a splash screen on startup.
2.2 The system shall then lookup the terminal information from the database for the
terminal in use, using the current hostname as the key. Based on the database
information, the following global variables shall be set :
a) Spooler settings for local receipt printer.
a) Spooler settings for local report printer.
c) If this terminal can accept incoming sockets, a socket shall be
opened, and listened to in the background.
d) If this terminal is music enabled, the music controls shall be displayed,
otherwise they shall be hidden.
e) The local timeout for auto-logout shall be set.
f) If this terminal has a barcode reader, the barcode device shall be enabled.
f) If this terminal has a caller id reader, the caller id device shall be enabled.
2.3 The system shall require that the user login using a valid name and password
combination before proceeding any further.
2.4 The system shall setup various global variables depending on the security
profile of the user that just logged in.
2.5 The system shall then display the usercode of the user who just logged in under the
'logged in as' field.
2.6 The system shall then proceed to the default screen for the user who just logged in.
2.7 If the current user has auto-logout disabled, the auto-logout timeout shall be disabled.
2.8 The system shall interogate the database for the version number of the running
database, and add this to the text messages of the about box.
3. Toolbar / Global GUI based option requirements.
The fullscreen GUI for gShop shall include a toolbar which is available at all
times.
This section of the requirements describes what commmon features are to be found on
the toolbar.
3.1 Login button. This button will cause the current user session to be terminated, and
the system shall proceed to the login screen.
3.2 Print button. This button will cause a printout of the information on the currently
displayed screen. The actual contents of this printout is then dependent on the current
screen, and data being displayed.
3.3 Music button. This button allows the user to define the settings for the ambient music
options. The system allows for the computer to control the playing of ambient music (from
MP3 archives), which may be useful for a small shop. The music button only appears if the
user profile AND terminal profile allow for this.
3.4 Current date and time. This text field displays the current date and time, updated in
real time.
3.5 Who button. This button will display a list of who is currently logged in to the system,
how long they have been logged in for, and what their telephone extension number is.
(The telephone extension details are associated with the terminal).
3.6 Email button. This button will proceed to the email subsystem. When there are new un-read
messages for either this user or this terminal, the email button will animate, until the
new messages have been read.
4. Transaction View and Selection Requirements.
As the system can process a number of different types of transaction, it is
useful to provide a screen which shows a daily summary of all transactions, with
some built in search capabilities.
From here, the user can launch new transactions, or easily find older transactions
for modifications.
4.1 The Selection screen shall display all recent transactions in a list which
match a set of selection criterior. These selection criterior shall include :
4.1.1 By type of transaction. (Default = all transaction types)
4.1.2 By Individual store. (Default = this store)
4.1.3 Show transactions for all stores.
4.1.4 By range of dates, including :
a) Today only (default).
b) Yesterdays orders.
c) Current week.
d) Future orders.
4.2 The selection screen shall display a trading summary for the selected period.
This trading summary shall include the following information :
a) Number of transactions in the trading period.
b) Total value of transactions in the trading period.
c) Average value of transactions in the trading period.
d) Cash taken in the trading period.
4.3 When any of the selection criterior for the selection screen are changed
(Requirements 4.1.1 - 4.1.4), then both the transaction list and the trading
summary information shall be updated.
4.4 As other terminals on the network enter transactions, the transaction list and
trading summary information for this terminal shall be updated in real time.
4.5 The system shall be able to be configured to operate in 'store-wide' or 'cash-till' modes.
4.5.1 In 'store-wide' mode, all transactions that are entered on any terminal are
broadcast to all other terminals. Therefore, from the selection screen, all
terminals will show 'store-wide' transactions in real time. The trading summary
details for 'this-store' will then show the trading summary for the entire
store. This is suitable for small shops, but unsuitable for large shops.
4.5.2 In 'cash-till' mode, each terminal shall be treated as a 'store' in it's own
right, so transaction updates are not displayed in real time to all other terminals.
The trading summary displayed on each terminal will show the details for this
terminal only. Other terminals (in the back office ?) can be set to view
'all-stores', and therefore display a consilidated view for the entire store.
This is suitable for large shops, but unsuitable for smaller shops.
4.6 The user shall be able to click on any transaction in the transaction list. Clicking
on a transaction will cause the system to proceed to the transaction/order details
screen for the selected transaction.
4.6.1 The user shall be able to click on any transaction with the right mouse button,
or by holding down the shift key whilst clicking (to allow touchscreen access
for example). In this case, the system will proceed to the customer details
screen for the selected transaction instead of the transaction details. If there
is no customer record associated with this transaction, then an error shall be
displayed instead.
4.7 The user shall be able to enter a phone number, and hit OK. This will cause the system
to lookup the customer record associated with the phone number, and respond accordingly.
4.7.1 If exactly 1 customer record exists which matches this phone number, then the
system shall proceed to the customer maintenance screen in modify mode. The
customer details for the existing customer shall be displayed.
4.7.2 If 0 customer records exist with this phone number, then the system shall proceed
to the customer maintenance screen in insert mode. The customer details screen
shall be blank, save for the phone number (which is transferred from the selection
screen).
4.7.3 If more than 1 customer records exist for this phone number, then the system shall
proceed to the customer selection screen. This screen will display the customer
records which match, and can then be used to select the correct customer, or
proceed to add a new customer.
4.8 The system shall be able to interface to caller-id hardware via a serial port. When a
call comes in from a customer, the caller-id hardware will send the caller's phone number
through the serial port. The system shall treat this caller-id supplied phone number as if
the user had entered the phone number into the selection screen and hit OK.
4.9 The user shall be able to enter a customer name, and hit OK. This will cause the system
to lookup the customer record associated with this name, and respond accordingly.
4.9.1 If exactly 1 customer record exists which matches this name, then the
system shall proceed to the customer maintenance screen in modify mode. The
customer details for the existing customer shall be displayed.
4.9.2 If 0 customer records exist with this name, then the system shall proceed
to the customer maintenance screen in insert mode. The customer details screen
shall be blank, save for the name (which is transferred from the selection
screen).
4.9.3 If more than 1 customer records exist for this name, then the system shall
proceed to the customer selection screen. This screen will display the customer
records which match, and can then be used to select the correct customer, or
proceed to add a new customer.
4.10 The user shall be able to enter an order/transaction id and hit OK. The system will
then lookup the transaction and proceed to the transaction details screen matching this
transaction id (if found). If no such transaction exists, then an error is presented.
4.11 The user shall be able to hit OK without having entered a phone number, name or transaction
id. In this case, the system shall proceed to the pickup order transaction (see section 6.2)
5. Point Of Sale transaction Requirements.
Point of Sale transactions typically occur with the customer directly dealing
with the data entry operator. Items are then entered into the system, a total
is presented, and payment / change is entered.
This means that (because the customer is present), speed and accuracy are vital.
There are 2 modes of Point of Sale transaction covered by the system, these are :
a) On-screen catalogs, from a small inventory.
b) Scanned product ID's, from a large inventory.
A shop that has a relatively small number of inventory items (such as a Pizza bar),
can have all of the available products displayed on the screen in a touchscreen panel.
By overlaying several panels broken down by category, the whole product catalog can
be placed on-screen.
For larger stores that carry hundreds or thousands of line items, this approach is
not possible. In this situation it is more common to have barcode scanning equipment
interfaced to the system. The free space (that is normally used for the touchscreen
pricelist grid), can then be used for customer displays, such as product advertising.
5.1 Common Point of Sale Transaction Requirements.
5.1.1 The system shall allow the user to process an entire transaction via the
keyboard.
5.1.2 The system shall accept an item code from the keyboard. When validated :
a) The description shall be displayed.
b) The unit type shall be displayed.
c) The Qty shall be set to 1
d) The unit price shall be displayed
e) The line item price (qty * unit price) shall be displayed
f) The line item price shall be protected, unless both the item
5.1.3 The system shall allow an item on this transaction to be modified. When an existing
line item is selected from the displayed list, the details of the selected item
shall be transfered to the edit area, and the screen shall then allow the current item
to be modified.
5.1.4 The system shall allow an item on this transaction to be deleted. When an existing
line item is selected from the displayed list, the user may hit the delete button
in order to remove this line item from the current transaction.
5.1.5 The system shall allow the user to cancel / void the entire transaction.
5.1.6 During the entry of a transaction there shall be 2 phases :
a) Line item entry phase.
b) Receipting phase.
5.1.7 The system shall allow the user to signal that the item entry phase is
complete, and proceed to the receipting phase. The receipting phase shall
be performed on the same screen (ie - by changing the entry focus from the
item fields to the receipting fields).
5.1.8 The receipting shall shall require the following data to be entered :
a) The type of payment (cash / eftpos / credit card)
b) If cash is selected, then the amount tendered shal be entered and the
change amount shall be calculated and displayed.
c) If credit card, then the credit card number shall be entered. Entry of
the card number can be either via the keyboard, or by scanning the card
in a simple card reader.
5.1.9 Once both the line entry and receipting phases have been complete, the system
shall allow the user to commit the transaction. At this point, the system shall
print a duplicate copy of the docket - one copy going to the customer and the
other being withheld for accounting purposes.
5.2 On-Screen Touch Panel for POS transactions.
5.2.1 The system shall provide a graphical panel which can be activated by either
mouse click and/or touchscreen press. This panel shall show all categories
that are available on the menu.
5.2.2 The system shall also provide a graphical panel which can be a activated by
either mouse click and/or touchscreen press. This panel shall show a 2 dimensional
grid of the prices for all items in this category.
5.2.3 When a selection is made in the categroies panel, the contents of the items pricing
panel shall be updated to show the items for the selected category.
5.2.4 The items pricing category can operate in 2 modes :
a) Without the optional 3rd dimension (Z axis)
b) With the optional 3rd dimension (Z axis)
5.2.4.1 When there is no 3rd dimension in this catgory, clicking on an item in
the 2D pricing grid will cause 1 item of the selected type to be added to
the current transaction.
5.2.4.2 When there is a 3rd dimension in this category, the user has to select
both 1 of the pricing items as well as 1 of the 3rd dimension options in
order to add an item to the current transaction.
5.3 Large inventory / scanned ID POS transactions.
5.3.1 When an item is scanned via a barcode scanner, the scanned barcode shall be
looked up in the database, and the item matching this barcode shall be displayed.
5.3.1.1 This infers that the items database shall provide a barcode ID as a
secondary key field, whilst still retaining the shop's item code for the
same item. The system shall allow for item codes which are different from
the printed barcode, and yet still identify the same item by different
methods.
5.3.1.2 When a match is found, processing proceeds as per 5.1.2
5.3.1.3 When no match is found, and error is displayed, and manual input
via the keyboard is forced.
5.3.1.4 All barcode matching errors are to be saved in a management exception
database, which can be viewed and reported on elsewhere in the system.
5.3.1 The graphical panel, which is not required for a large scanned inventory, can
be used for displaying advertisements for other related products.
6. Pickup Order transaction Requirements.
Pickup Orders occur when a customer phones in an order (say for a couple of
family size Pizzas), and then comes to the store some time later to collect the order.
Once again, speed of the data entry are most important, since the customer is on the phone.
Once the order has been entered into the system, there is no further contact with the
customer until the customer comes in to collect the order. Accuracy of the data entry
is therefore very important. However, since the customer will appear at the store in
person, any discrepencies can be resolved at that time.
Another aspect is that the customer may ring back before the pickup time and change the
order. It is important in this situation to be able to quickly locate the order and
bring the details up for amendment.
6.1 The system shall allow for the processing of phone-in delivery orders.
6.2 A new pickup order transaction shall be launched by hitting OK from a blank set
of selection criterior on the transaction selection screen.
6.3 The pickup order screen shall first require the entry of the customer's name which
is later used as a reference when they come in to pickup their order. The customer's
name is not validated against any database.
6.4 The system shall calculate an E.T.A for the collection of the order, being based on
a global system variable. (ie - a pizza bar may quote a standard 30 minutes for a
pickup order). The system shall allow the user to change this time, in the case where
the customer requires a longer delay.
6.5 The remainder of the pickup order processing shall be identical to a delivery order
transaction.
6.6 When the comes in to deliver the goods, the user must select the transaction from the
transaction selection screen. At this point, the system shall proceed to the point of
sale screen, and display the existing order details. The system shall then immediately
enter receipting mode to receipt the money from the customer.
7. Delivery Order transaction Requirements.
A Delivery order occurs when a customer phones in and orders a product, which the
customer wants delivered to their address.
Once again, the customer is on the phone, so speed is vital.
In the delivery situation however, there is no direct contact with the customer
(unlike a pickup order where you get to see the customer face to face). This means
that by the time that the goods are delivered, it is too late to resolve any
discrepencies in the order - accuracy and validation of the order is most vital.
The system shall accumulate a database of delivery customers and addresses, and
allow for features such as interfacing to caller-id equipment in order to bring up
customer details automatically.
7.1 The system shall allow for the processing of delivery orders to phone-in, validated
customers.
7.2 A new delivery order is launched from the customer details screen. By hitting OK
on the customer screen, the system shall proceed to the delivery order screen.
7.3 The delivery order screen shall display the customer name and delivery address.
The customer name shall remain locked, however the customer delivery address shall
be allowed to be changed by the user. If the delivery address is changed, then the
system shall save the new delivery details against the customer database.
7.4 The system shall calculate the E.T.A for the delivery based upon a global system variable
(ie - a pizza bar may define a standard 30 minutes for a delivery from the time of order).
The system shall allow the user to change this ETA for the case where the customer
requests a delayed delivery.
7.5 The system shall accept an item code from the keyboard. When validated :
a) The description shall be displayed.
b) The unit type shall be displayed.
c) The Qty shall be set to 1
d) The unit price shall be displayed
e) The line item price (qty * unit price) shall be displayed
f) The line item price shall be protected, unless both the item
7.6 The system shall allow an item on this transaction to be modified. When an existing
line item is selected from the displayed list, the details of the selected item
shall be transfered to the edit area, and the screen shall then allow the current item
to be modified.
7.7 The system shall allow an item on this transaction to be deleted. When an existing
line item is selected from the displayed list, the user may hit the delete button
in order to remove this line item from the current transaction.
7.8 The system shall allow the user to cancel / void the entire transaction.
7.9 The system shall allow the user to modify the total price of the transaction, by clicking
on the set_total_price button. When this occurs, the system shall add a standard discount item
to the order in order to balance the items against the new total.
7.10 The system shall allow the user to signal that the entry of the order is complete.
In this case, the system shall print the docket for the transaction, and commit the
transaction to the database. The system shall ensure that there are in fact 2 dockets
printed - either by using duplex paper, or by printing 2 separate copies of the docket.
One docket is to be sent to the kitchen and retained for accounting purposes, the other
is to be delivered with the order to the customer.
7.11 The delivery order screen shall implement the same touch screen functionality as
described in section 5.2.
7.12 The delivery order screen shall implement the same large item scanned inventory
functionality as described in section 5.3.
8. Table Account transaction Requirements. (For restaraunts/bistros only)
A table account occurs most typically in a restaraunt or bistro. In this situation, a pool
of available tables in maintained by the system.
A customer comes in and is allocated a table number. This creates an account upon which
items are charged as the meal progresses. When the customer is finished, the account is
totalled, the bill is paid, and the table is then free for the next customer.
In this situation, the most important aspect is the customer service, and accurate
tracking of the items.
Table accounts should also be able to process orders on a pay-as-you-go basis.
8.1 The system shall provide a temporary table-based order processing system.
8.2 The system shall display a graphical layout that represents the actual table
layouts in the restaraunt.
8.3 The graphical display shall show which tables fall into which status :
a) Are free
b) Are in use
c) Are booked in the next period of time.
8.3.1 Free tables are displayed using a certain free-table icon. The seating capacity
of the table shall be displayed with the icon.
8.3.2 In use tables shall display a number of details about the table :
a) The table number
b) The current bill assigned to the table
c) The number of hours : minutes that the table has been occupied
d) The number of guests at the table
8.3.3 Booked tables shall display a number of details about the table :
a) The table number
b) The time that the booking is due
c) The name that the table is booked under
d) The number of guests that the table is booked for
8.4 The system shall operate in 2 modes for table accounts :
a) Pay before the meal. This option is suitable for fixed price smorgasbord restaraunts.
b) Pay after the meal. This option is suitable for non-smorgasbord restaraunts.
Smorgasbord Mode :
8.4 The system shall allow the user to select a free table and create a new account
for this table.
8.4.1 A table number is assigned when a free table is marked as taken. A new blank
account is created. The system then proceeds to the point of sale screen to
create the account, and perform the receipting.
8.5 The system shall allow the user to select a booked table. The booking details for the
table shall be displayed. The user may then select the 'use-table' button, which will
convert this table from a booked table to an in-use table.
8.6 The system shall allow the user to select an in-use table. A dialog describing the table
is then displayed. The system shall allow the user to select the 'clear-table' button,
which will then return the table to the pool of free tables.
Ala-Carte Mode:
8.7 The system shall allow the user to select a free table and create a new account for this
table. The temporary table number is assigned at this point. A new blank account is then
created for this table.
8.8 The system shall allow the user to select a booked table. The booking details for the
table shall be displayed. The user may then select the 'use-table' button, which will
convert this table from a booked table to an in-use table.
8.9 The system shall allow the user to select an in-use table. When this occurs, the system
shall proceed to the point of sale screen, where the current order can be modified.
8.9.1 Items can be added to the order. When committed, the system may be configured via
a global variable to print the new items on the kitchen area printer.
8.8.2 Items can be changed on the order. When committed, the system may be configured
via a global variable to print the amendment on the kitchen area printer.
8.8.3 Items can be deleted from the order. When deleted, the system may be configured
via a global variable to print the deletion on the kitchen area printer.
8.8.4 The order can be marked as complete, in which case the point of sale screen shall
proceed to the receipting entry fields, enter the receipt, and then mark the
table as free.
Global Capabilities :
8.x The tables screen shall display the trading summary details for all table for the
day, which includes :
a) Total number of tables
b) Total number of free tables (as of now)
c) Average time spent per table (averged over the last month)
d) Total current bill (for all currently used tables)
9. Internet Delivery Order Requirements.
The system shall provide 2 levels of internet ordering :
a) Simple email based internet orders.
b) Full e-commerce based internet orders.
Simple email based internet orders are applicable for small shops which have a
dial-up internet account, which may only be active for short periods of time (2-3 hours
per day).
Ideally, we should use fetchmail / procmail to extract order information from incoming
email streams, however, many people like to use things like Netscape, and allow netscape
to drag down POP emails in a polled fashion, which is simple from the user's point
of view, but difficult to process with procmail.
Without getting too heavily into the implementation details here (this is a requirements
spec, not a design doc), we can say that the system needs to be flexible in handling
incoming email, with default options to provide no-brainer access.
...
Full e-commerce internet orders are applicable for larger shops which have a
permanent internet connection, and domain name. The e-commerce server can then be
run from main gShop database server, through the firewall.
Full e-commerce internet orders enable the following functions :
Internet Delivery Orders are orders where a customer has connected to the shop's web site,
and constructed and validated an order in their own time.
The customer then commits the order, and this gets added to the system as an order to be
delivered.
It is important in this instance to correctly validate that the customer is real, and that
they really want to pay for the delivery. The system may be configured to allow for
'auto validation' - where all internet orders are assumed to be OK, or 'manual validation',
where internet orders are placed in a holding state until a human operator reads the order
and marks it as valid.
From that point on, internet orders are treated the same as any delivery order.
..
Note - this means that we can easily integrate e-commerce benefits into installations
no matter how small. Even in third-world bandwidth-challenged nations (such as Australia),
all a shop needs is a modem and a casual dial-up account to be able to 'electronically
process internet orders'.
Having paid lip-service to e-commerce, gShop can also provide serious e-commerce
integration. All gShop servers (be they Linux, BSD, Solaris, OSX, NT, etc) include the
basic raw materials for e-commerce :
- Apache + PHP connected to same database engine that the GUI uses.
gShop will provide a set of core classes in PHP to drive the e-commerce engine, and then
provide a couple of example implementations for different types of shops. Being standard
Apache + PHP + SQL, any site can easily customise this for their own business.
Getting this working though requires a good deal of investment at the customer end,
such as getting permanent connections, static IP addresses, domain names, artwork,
web design & development sorted out, all of which are well outside the scope of gShop.
The requirement for gShop is that it shall be able to easily integrate into whatever
internet facilities a shop has, be they casual dialup accounts through to complete
dynamic website hosting.
..
9.1 Email based internet orders.
9.1.1 The system shall require that an incoming email file be defined. The
system will then poll this file at 1 minute intervals to see if it grows.
9.1.2 When the incoming email file has been detected as changed, the system shall
animate an icon on the toolbar (pulsating email light, etc). When the user
then clicks on this animation, the widget returns to it's normal state, and
the polling of the email inbox begins again.
9.1.3 It is the responsibility of the user to then read the actual email using
whatever external program they normally use. The user must then manually
transcribe information from the email message into the ordering system.
9.2 Full e-commerce based internet orders.
9.2.1 Each customer entered into the customer database becomes a valid e-commerce
user. This requires the following information stored against the customer
(over and above the regular customer information) :
a) Internet password
b) Email account
c) Various marketting information (TBD - but see the gshop-create.sql file for
more info)
9.2.2 The system shall provide, via PHP, a web interface for internet customers
to place orders.
9.2.2.1 Before being allowed to process orders, the internet user must first
login, using their email address and password.
9.2.2.2 The login screen shall provide a 'forgot your password' button which
will email the user's password to their email account. If there is no
internet user defined with this email account, then an error shall be
displayed on the web page.
9.2.2.3 The web page shall provide a register user screen, where the user can
enter their email account, and press the register button. An email shall
then be sent to the user's account, which includes the generated password
associated with the user's account.
9.2.2.4 The first time that a user logs in, they need to fill out a questionaire
that is used to gather marketting information. The questionaire then
also requires that they XXX
9.2.2.1 The Internet selection screens shall closely resemble the graphical
selection panels shown on the order screens (see sections 6 & 7), both in
look, and in behaviour.
9.2.2.2 The internet user shall be able to add items, modify items, delete items
to the order, or cancel the order altogether.
9.2.2.3 The internet user shall be able to commit the transaction, at which point
the transaction will appear immediately on the internet orders screen of
the system. At this point the PHP screen shall inform the internet user
that the order has been accepted.
9.2.2.4 Upon accepting the order, the PHP screen shall create a new window on
the internet user's screen which displays the order details, the order
reference number, and the estimated time of arrival. If Java or Javascript
is supported on the internet user's terminal, then the new window shall
also include a graphical clock which counts down the minutes and seconds
until the delivery is due, otherwise, a 1 Minute refresh tag is sent
to the internet user, so that the internet user's machine can pull down
a new status page every 1 minute.
9.2.2.5 Where the system is operating in Internet validation mode (see 9.2.3.b below)
then the system shall inform the internet user when the order has been
validated, in real time. In cases where are real-time connection is not
feasible (ie - no Java), then a refresh tag shall be issued to the new
window to get the internet user's terminal to pull down a new status page
every 1 minute.
9.2.3 The system shall operate in 2 modes for processing internet orders :
a) Immediate acceptance. Internet orders are moved immediately to the valid orders
section, and can be seen from the transaction selection screen.
b) Requires validation. Internet orders are moved immediately to the internet orders
section, In this mode, an icon on the toolbar is highlighted whenever internet
orders are present, which must be manually validated by a user.
9.2.3.1 The system shall provide an internet orders screen which displays all un-validated
internet orders.
9.2.3.2 The system shall allow the user to select an un-validated internet order, which
will cause the system to proceed to the order details screen. The order details
as entered by the customer are then displayed. The user can at this point either
reject the order, or commit the order. If committed, the order is moved to the
valid orders section, and is visible from the transaction selection screen.
10. Purchase transaction Requirements.
All shops that sell things have to buy things as well.
gShop shall include a simple creditors, purchase orders and stock control package
for tracking all purchase requirements.
The aim of this is to allow for periodic comparison to turnover figures to produce
simple financial statements for a shop.
11. Employee Details & Communications Requirements.
A lot of shops that gShop is targetted at use casual staff who work odd hours.
gShop shall be able to be used to enter employee timesheets, produce employee wages
reports, and perform simple rostering.
It is beyond the scope of gShop to perform payroll processing - such as tax witholdings,
leave accruals, etc.
gShop also includes it's own separate user database with password validation, and
a simple database driven email system.
11.1 Employee Database Requirements
11.2 Employee Timesheets. The system shall include a timesheets subsystem, which
can be used for maintaining timesheet data for casual employees.
12. Drinks counter Requirements.
A lots of restaraunts have a dedicated drinks counter, where transactions are handled
slightly differently.
The drinks counter screen aims to cover the POS screen functionality without the need
for keyboard input. A complete drinks order transaction, including simplified receipting
can be performed using only a mouse / touchscreen.
It is assumed that the drinks counter will use a special 'drinks' login code, which
should enable only the drinks screen. In order to remain keyboard independant, this
requires that the system allow a command line argument to specify the login name and
password when the system is first invoked.
13. Customer Details Tracking Requirements.
Many shops need to track details on customers, especially cases where delivery orders
are concerned, and customers represent long-term repeated businesses.
gShop shall maintain details of each valid customer, including the ability to
report orders against customers, and implement customer loyalty schemes.
14. Terminal / Printer database Requirements.
The gShop application is intended to be a multi-user application, with several
terminals, printers, input devices, etc scattered across a single store.
These devices all need to communicate with one another, so the gShop database
includes the layout of all of the hardware making up the gShop installation.
14.1 The system shall include a database of terminals that are part of each
installation.
14.2 The system shall include a database of printers that are part of each
installation.
14.2.1 The system shall define 2 types of printers :
a) Receipt printers for printing dockets / receipts.
b) Report printers capable of printing graphics.
14.2.2 Receipt printer requirements. Receipt printers have a number
of flags which determine their capabilities. Each capability
has a boolean flag, and a text field which is a string of
hex digits required to activate that capability.
14.2.2.1 Receipt printers shall have a 'can cut' flag which says
whether or not the printer can cut the docket paper.
If cut capable, the system shall automatically issue
a cut paper command after the printing of each docket.
14.2.2.2 Receipt printers shall have a 'can color' flag which
says whether or not the printer can do colour output.
If color capable, the system shall automatically issue
color-on and color-off codes when printing a docket.
14.2.2.3
15. Large inventory stock level Requirements.
Some types of shops use a large catalog inventory method, with a requirement
to record inventory and stock takes.
Although large stores may already have existing IT infrastructures which include
stock control, gShop can at least assist in this task, if not replace it.
Smaller stores which also use a large catalog model may also require comprehensive
stock control procedures on a single-PC system.
The pricing model for large inventory stores is completely different to the 2D
pricing grid model. Large stores use a historical pricing method, where prices
are set at a point in time for a particular quantity level. This way, quantity
discounts can be expressed in the basic pricing of each item, and revisions to
pricing can be tracked indefinately.
16. Database Maintenance Requirements
The system uses a number of SQL tables collected together into an SQL database
at the backend. Many of the tables used by the system need to be maintained by the
users over a long period of time (as item codes change, prices change, etc).
In all cases, the user shall be able to add records, modify records and delete records,
as well as enter search criterior and find lists of records which match.
The tables which are allowed to be modified in this manner include :
16.1 Categories. Items that are sold by the shop are divided into categories.
Each category includes the following information :
a) Category code
b) Description
c) Discount allowed ?
d) Tax Rate
e) Icon
f) Names for the X and Y axes of the pricing grid
g) Optional - name of the Z axis of the pricing grid
16.2 Items. Items are the items that are sold by the shop. Each item has the
following information :
a) Category
b) Item code
c) Barcode
d) Prices for the 2D pricing grid
e) Options which add to the price (the optional Z axis of the pricing grid)
16.3 Suburbs. Suburbs are used to categorise customers and set various sales
conditions for customers that relate to how far they are from the shop. Each
suburb has the following information :
a) Suburb name
b) Postcode
c) Map reference
d) Minimum order amount
e) Delivery charge
f) Which branch is closest to this store
16.4 Stores. Each store has the following information :
a) Store name
b) Address
c) Suburb
d) Postcode
e) Name of manager
f) Store ID (numeric field)
g) Modem number and time of the day for update
h) Phone number
i) Country, state and GMT time zone adjustment
16.5 Music. The music database is made up of 3 tables :
16.5.1 Songs. Each song contains the following data :
a) Song ID
b) Song name
c) Artist
d) Duration
16.5.2 Play Lists. Each playlist contains a list of songs
that are in a fixed sequence.
16.5.3 Times. This specifies that at a certain time of the day,
a particular playlist should commence.
16.5.4 A background task shall operate on those terminals which
are deemed as music-capable. This background task shall
play the song MP3's
16.6 Tables. The tables database defines which tables are present
in a restaraunt / bistro. Each table has the following information :
a) Table ID
b) X & Y locations on the canvas
c) Seating Capacity
d) Current number of guests at the table
e) Status (free, booked, in-use)
f) Start Time (if in-use, what time was it taken - so the time elapsed
can be derived)
16.7 Printers. The system maintains a database of all printers attached to the
network. Printers are defined as either receipt printers or report printers.
The database is also used to define the escape codes for various actions
on the printers, which are stored as strings of hex digits. This allows
for complete portability between various operating systems and printing
sub-systems. Each printer record in the database shall contain the following
information :
a) Printer ID
b) Store - which store is the printer in
c) Description (may include serial number, make, model, warranty details, etc)
d) Spooler name (for passing to Unix lpr command)
e) Number of columns available
f) Double paper flag (does this printer have duplicate copy paper ?)
g) Cut paper command
h) Can color flag, colour on command, colour off command
i) Can this printer open a cashdraw ?
j) Open cashdraw command (typically Ascii BEL)
k) Can this printer be used for receipting ?
l) Can this printer be used for reports ?
16.8 Terminals. The system maintains a database of all terminals attached to
the network, so that any connected terminal can find other terminals
in an operating system indendant fashion. Each terminal record contains
the following information :
a) Terminal ID
b) Store - which store is the terminal in
c) Description (may include serial number, make, HW config, etc)
d) Receipt printer ID - which printer to spool receipts to
e) Report printer ID - which printer to spool reports to
f) Can accept sockets ?
h) Hostname and Port to reach this terminal on
i) Operating system
j) Phone extension
k) Can this terminal play music
l) Logout timeout for this terminal
m) 2 sets of start and end times, between which this terminal is available
n) Does this terminal have a barcode reader attached ?
o) Which device / port is the barcode reader attached to
p) Does this terminal have a caller ID input ?
q) Which device / port is the caller ID hardware attached to
16.9 Internet. The customer records contain information on all customers who
have received deliveries. The system shall also allow additional details
to be recorded, which will allow customers to be validated over the internet.
The internet database shall include the following fields :
a) Customer ID to relate back to the customer details
b) Password
c) Email
d) Various fields of marketting information.
In addition to this, a small table of marketting questions can be maintained
on the same screen. Each marketting question shall contain the following fields :
a) Question ID
b) Question text
c) Is an answer to this question required ?
d) Enable this question
16.10 Users. Users are assigned to profiles which determine what capabilities the particular
user is allowed to perform. Each profile contains the following information :
a) Profile name
b) Default screen - main screen that the system defaults to after these users
have logged in
c) Bad customer flag - can these users set/unset the bad customer flag
d) Alter customer flag - can these users change customer details
e) POS flag - can these users enter the POS screen
f) Tables flag - can these users access the tables screen
g) Internet flag - can these users authorise internet orders
h) Drinks flag - can these users access the drinks screen
i) Timesheet Auth flag - can these users authorise timesheets
j) View Purchases flag - can these users view the purchase orders
k) Purchase flag - can these users enter purchase order information
l) Bookings flag - can these users set or change bookings
m) Reports flag - can these users run reports
n) Maintenance flag - can these users maintain database records in the
maintenance menu
o) Music flag - can these users control the playing of music in the store
p) Cancel order flag - can these users cancel an order that has already been entered
q) Change order flag - can these users change the details of an order that
has already been entered
h) Quit flag - can these users quit out of the application
In addition, each user has the following information :
a) Username
b) Password
c) Profile (16.10 a-p)
16.11 Setup. This area stores all of the global settings for the system. These include :
a) Store ID of this store
b) Cash till vs store wide mode
c) Large inventory vs small inventory flag
d) Internet mode (email, e-commerce, autp vs manual validation)
17. Security requirements.
The gShop system uses its own user database, so all login names and passwords
are stored inside the database.
Each user belongs to a security profile, which determines which aspects of the
system are available for each group of users.
p) Cancel order flag - can these users cancel an order that has already been entered
q) Change order flag - can these users change the details of an order that
has already been entered
h) Quit flag - can these users quit out of the application
17.1 A user can only toggle the bad_customer flag if they have the bad_cust flag set.
17.2 If the user does not have access to a certain screen, then the option shall not
appear on the menu or notebook. These include :
a) The POS screen.
b) The tables screen.
c) The drinks counter screen.
d) The purchase screen.
e) The maintenance screen.
f) Report screens.
g) Music control screen.
17.3 When viewing an existing customer record, the user can only update / modify the
record if they have the correct priviledge.
17.4 All users can view the incoming internet orders, but only those with the correct
priviledge can authorise the internet orders.
17.5 All users can edit the timesheet information for their own user account. If a user
has timesheet authorisation access, then they can also view the timesheets for other
accounts, and authorise them.
17.5.1 The authorising user may select 'Next', which will display the next un-authorised
timesheet waiting to be authorised. When no more un-authorised timesheets are
available, a warning message will be displayed.
17.5.2 The authorising user may select a user name and a period of time, and view
the timesheet for that user during that period.
17.5.3 The non-authorising user may not select a different username (username combo
field shall be read-only / disabled)
17.6 Only certain users can access the purchase order screen. Of these users, only certain
users may update (insert / delete / modify) any records. If the user has read-only access
then the buttons related to changing the data shall not be displayed.
17.7 All users can view booking information. Only certain users may update (insert / delete /
modify) booking information. If the user has read-only access then the buttons related
to changing the data shall not be displayed.
17.8 All users can view existing orders (delivery / pickup / POS). Only certain users may
change the details of an existing order.
17.8.1 In cases where an existing order is changed, the system shall maintain an
audit trail of the changes.
17.8.2 If an order has been changed, a 'history' button shall be displayed on the
order details screen. Clicking on this button will produce an on-screen report
showing the changes that were made, by whom and when. A textual comment field
shall be stored along with the audit record, to allow the user the add an
explanation for the change.
17.8.3 Only certain users have cancel order priviledge. These users may view an
existing order, and cancel the entire order. The system shall maintain an
audit trail of the cancelled order, along with information on who cancelled
it, and when. A textual comment field shall be stored along with the audit trail
to allow theuser to add an explanation for why the order was cancelled.
17.9 All users can receive email. Only certain users can send email.
17.10 All users may logout of the system, at which point the system returns to the login screen.
Only certain users may exit the application.
17.11 Some terminals may be configured to automatically logout after an elapsed time
period of no activity. Certain users may override this terminal related flag, such that
when they login, they are never automatically logged out after a time period.
18. In-Store advertising requirements.
Many sophisticated POS systems in large stores now take the opportunity to use that extra
little bit of screen space on the new POS displays to show adverts for customers.
In the case where a store has a huge inventory line, it is not practical to use the
on-screen catalog method, so we can use the canvas areas to display adverts.
We can also use adverts as a sort of 'screen saver' on the login screen.
18.1 The system shall allow for advertisements to be defined, and stored in the database.
18.2 The system shall overlay adverts on the login screen after an inactivity timeout,
so as to act as a 'screen saver'.
18.3 Adverts shall be cycled though with a fixed delay between each ad.
18.4 As adverts are cycled, a randomly selected method shall be employed to
cycle in the new advert. These methods include :
a) Scroll in from right to left.
b) Scroll in from top to bottom.
c) Explode from center.
d) Radar sweep the mew image onto the display.
e) Alpha transparecy fade out the old image, and fade in the new image.
19. Wide area database, transaction, and email replication and propagation.
20. Exotic Hardware Interfacing Requirements.
20.1 Barcode Readers.
20.2 Caller-ID Hardware.
20.3 Touchscreen Hardware.
20.4 Laser Scanner.
20.5 EFTPOS Terminals.
20.6 Receipt Printer Interfacing.
20.7 Touch Tablet Hardware.
20.8 Laser / Report Printer.
21. Interface to external Accounting System databases.
22. User documentation requirements.
23. Developer documentation requirements.
24. Marketting documentation requirements.
|