[ Current Status ]   |   [ CVS ]   |   [ Mail List ]   |   [ Files ]   |   [ Jobs ]

SourceForge Logo
Home

Project Home

Developers

Features &
Benefits

Download

ScreenShots

Contact

EasyPOS
Related Project

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.