POS client and back office suite



Andrew Urhausen

Josh Mitchell

POS client and back office suite

Project features:

1. Operational Concepts

• Implementing a point of sale client and back office server to assist in sales and transactions in a small business or restaurant/bar.

• The program will be easy to use, reliable, and secure. It also will be fully customizable by the administrator. Customizable buttons, menus, and users.

• Records of all sales will be recorded as well as inventory and overall history of who made the transaction.

• It will be a tool to ring customers up and create a simple way of receiving money.

• Easy way of transmitting data to and from a database holding inventory, prices, to sending information to the kitchen.

• The suite will include a back office server to control the users, menus, prices, and print or view all wanted reports.

Who will be using this system?

We are designing this to be used in bars, restaurants, and small retail shops. The ability to have security, ease of use, and power over how they want the application to function will be our selling point.

What makes this system different from the rest?

Because of the quick employee turnover rate, our system will be different because the interface will fairly intuitive. It will be easy to learn and customize.

What are some limitations?

The program will not make credit card charges. An addition machine will be required to do this.

2. System Requirements

The minimum requirement for the suite is two computers. One computer is running the back office server. The other is the client workstation. An optional feature is to have PDA’s running the client software. Another optional feature is a Kitchen display to present orders to staff.

Back Office System Server (BOSS) Features:

1. Add new items to the database. Assign unit prices and place items into inventory. Appropriate menus such that the client machine can browse for items and select them with the press of a button.

2. Edit existing items in database: (i.e. change prices, change descriptions).

3. Print single users, daily, weekly, monthly, and yearly reports. This feature gives the manager information on day to day sales helping in planning and monitoring what sells and what does not. It can also monitor transactions.

4. Inventory: can view inventory of items and give an optional reminder if quantity of a certain item goes below a preset amount.

5. Add users to the system giving them unique login codes.

6. Customer tracking: names, addresses, and customer histories.

Client Workstation (CWS) Features:

1. Easy to use menus to browse and select items to include in an order or transaction.

2. Editablity: at anytime the employee wants to change an order, he or she can select the item they want to edit and delete or modify it.

3. Option of scanning barcodes to ring things up.

4. Option of entering a SKU number to ring things up as well.

5. GUI split into a 2 x 2 grid. Bottom right is the number pad to enter quantities, amount of money received from customer, and other helpful information. Bottom left will include a summary of all items added to the transaction with quantities, prices, descriptions as well as a total before tax. The top will have a main menu.

6. Also able to browse inventory.

7. Send orders into the optional kitchen workstation.

PDA Features:

1. Same functionality as the terminal but portable.

Kitchen Information Display (KID) Features:

1. Only used to display orders.

3. System and software architecture

Feasible:

• The system can be implemented in java or c#. The advantage of using java is that it can run on Linux, reducing the cost of the system. The GUI would take a little bit more time though. Also there is known support for mobile devices (i.e. PDA’s). C# would be a good platform to develop the GUI in, but the systems would need to have windows to run the application.

• We would also need to use some sort of database server and client for the application. MySQL will be our first choice. Known interfaces for Java/C# for accessing data using MySQL. The system will also be linked together via wireless networking.

• Output: receipt printer

Challenges:

• Input: bar code scanners and card readers.

Challenge: Is there support in either language for these devices?

4. Lifecycle plan

We have chosen to use the Evolutionary Prototyping Model. An advantage of using it in our case since we have a very GUI motivated system that it is good to have an evolution of prototypes to be able to convey to our clients what they are getting and to get input about the system.

• Who wants it? Designed for the retail/restaurant/bar market

• Who will develop and support it? The members of our team will develop and create support for future releases. We imagine it will take us the entire quarter to complete our prototyping model so that it is no longer a prototype but a finished project.

• Major Stakeholder’s:

Users: Employees/Managers of retail shops, bars and/or restaurants.

Architects: Members of the team that created the initial model

Developer’s: Individuals who join the team to make this project a reality.

Project Breakdown

Start:

Assignment of project parts to smaller teams of 2 or 3.

Layout the ideas of the Prototyping Model and start work on initial prototype.

There will be weekly meetings with periodic progress checks with groups.

Beta Release:

Aimed release around May 5, most features already implemented.

Main-phase Testing:

Debugging and testing final feature set for the final release.

Final Release:

Aimed final release on June 1, all features implemented.

5. Feasibility Rationale

Assumptions:

• Java/C# has support for input from barcode and scanners.

• It will actually be easy to use.

• Waiter/Waitresses will actually want to use PDA’s rather than traditional methods (i.e. using paper pads or remembering orders).

Risks:

• Does the team have enough GUI programming knowledge?

• Does the team have enough database programming experience?

• Does any member of the team have actual experience using a POS system?

• Clients may be using a POS client already and unwilling to change because are satisfied with features and have already learned how to operate it sufficiently.

• Anything else that may come up

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download