FIPOS: Food Industry Point Of Sale

Final Project Presentation

April 26, 2011

Presentation Team Initial Idea Scope of the project Iteration Process System Architecture Use Cases

Our Team John Gleason Nick Mallard Kevin Hagood Michael Shrove Ashley Chafin

Our Initial Idea All businesses have a need for a Point of Sale

system to run efficiently. The software should be open source, so it can

be modified and continually improved. This should be role based, with users having

only required privileges. The system should use an external database.

The Scope Evolution Initially we started out very ambitious!

Initial Thoughts: One stop shop for all POS systems everywhere Customers broken down into two broad groups:

Retail Industry Food Industry

Main design goals: Flexible Functional

The Scope Evolution (cont.) We brainstormed our initial idea and goals.

… until we ran into a major problem: Our team had experience with the food industry, but

NOT with the retail industry. So, we didn’t have any prior knowledge or experience to

base our “customer needs” from. We developed a comprehensive set of requirements for the

food industry area, but the retail industry area was bare.

In the end, we did not have enough knowledge/experience on the retail side to build a good set of “customer needs.” Too many unknowns

The Scope Evolution (cont.) We decided to scope down from our original idea We sorted out our “customer needs” and

requirements Core Needs

Things needed for the system to be functional. Nice to Have

Things that were important enough, but were not core needs. Trash Fluff

We prioritized the core needs and nice to have’s. Then, we tasked our iterations. Everything else was put in a possible future release.

The Scope Evolution (cont.) An example of a requirement that we had to push

off to our future idea list: Plug-in architecture

It would allow users to add a specific set of functionality to the system

Good idea, but… The added benefit was limited The implications it would have on design were too

complicated for the limited time we had

In the end, we removed it from our core mission and marked it for future consideration.

The Scope Evolution (cont.) Having the ability to narrow down our scope

prevented us from “biting off more than we could chew.”

Once we started the analysis and design process, we realized our iteration tasks were not as simple as we had thought they would be.

Scoping down the project gave us: Clear, unambiguous requirements More time to focus on the analysis and design of the

main components of the system, rather than spreading our time over a variety of things

Simple and thought out framework Which results in an easier system maintenance down the road

Final Project Scope Point of sale system specifically for the food

industry with a restaurant focus

Focus on: Recording individual sales Managing menus Managing discounts Tracking orders Generating reports based on the POS system data

Open source – most current POS systems are out dated and proprietary

Final Project Scope (cont.) Data to be maintained in a database (external

to POS system)

The system needs to be: Reliable Fast Easy to use Role based:

The view of the system will be tailored to the role of the person using the system at that time.

Functional RequirementsFR1: System shall authenticate a user and

record “login” and “logout” times.FR2: Register and Management User’s shall

be able to view, create, and modify Orders.FR3: Management User’s shall be able to void

orders and manage reports, users, discounts, and menu items.

FR4: Service Line User’s shall be able to view a static representation of an Order and mark an order as completed.

FR5: System shall provide searching and sorting functionality for orders, discounts, menu items, and users.

FR6: System shall have the ability to back up data.

Non-Functional RequirementsNFR1: The Database shall manage the system

data.NFR2: Database shall not store authentication

information in plain text.NFR3: Database shall provide an interface for

manipulating system data.NFR4: System shall be accessible to all

authorized users from anywhere within the restaurant intranet.

NFR5: System shall be accessible from a computer with an intranet connection using a web browser.

NFR6: System shall provide a role hierarchy in order to limit user privileges and keep the system secure.

Actors

The General User is allowed to login and logout of the system. All other roles in the system are built off this user.

The Register User is allowed to Create/Modify Orders and List/Search Menu Items.

The Service Line User is only allowed to list the pending orders that need to be built and mark the order completed.

The Management User is allowed full reading and write access to the system. They are the only ones that can Void an order, perform a no-sale operation, and generate reports.

Top Level Use Case Diagram

To Backup slides (Use Cases)

Top Level Architecture Things we wanted to keep in mind while

designing architecture

Top Level Architecture (Revision: )

Top Level Architecture (Revision: )

Top Level Architecture (Revision: )

Top Level Architecture (Revision: )

Top Level Architecture (Revision: )

Top Level Architecture Add text about top

level package view here.

Top Level Architecture (Revision: 171)

Top Level Architecture (Revision: 179)

Top Level Architecture (Revision: 180)

Top Level Architecture (Revision: 204)

User Package Evolution

Future Capabilities Below is a list of possible future capabilities

that did not make our iteration schedule: Plug-in Framework for more specialized menu

items Restaurants may develop their own plug-ins for specific

menu items. Capabilities for retail customers

Example: Barcode lookup, Item bar-coding, etc. More user defined roles

Example: Inventory User Making the menu items and menu more flexible to

the user Inventory system

Lessons Learned Start small Start simple Do not be afraid to just let go

We designed, designed, and designed. Eventually, having to let go some old designs for improved ones.

Abstraction is your friend Abstraction allowed us to work top down, giving

clarity and consistency as we worked. Abstraction helped the team to not feel

overwhelmed.

Project Evaluation Accomplished our revised idea

Created a Point of Sale system to be used in the restaurant industry

System architecture revised but not radically changed

Met or exceeded goals at each iteration Clearer, more concise use cases and diagrams Refined actor roles and responsibilities Designed a good foundation architecture

Further analysis and design is still possible and needed!

Questions?

Backup Slides

Activation Use Case (UCD-1) Text about UCD-1

Manage Users Use Case (UCD-2) Text about UCD-

2

Manage Store Data Use Case (UCD-4) Text about UCD-4

Mange Order Use Case (UCD-5) Text about

UCD-5

Manage Reports Use Case (UCD-6) Text about UCD-6

Manage Register Use Case (UCD-7) Text about UCD-7

Back to Main Presentation