TMS

					                           TMS
                     Ordering System




David Angi                         2/11/08
Ryan Egan
Glenn Morrow
Phivos Stylianides
Joe Venezia
Table of Contents
1. Introduction ................................................................................................... 3
  1.1 Purpose of System ................................................................................... 3
  1.2 Scope of the System ................................................................................ 3
  1.3 Objectives and success criteria of the project ......................................... 3
  1.4 Definitions, acronyms and abbreviations ................................................. 4
  1.5 Overview .................................................................................................. 4
2. Current System ............................................................................................. 5
3. Proposed System ......................................................................................... 6
  3.1 Overview .................................................................................................. 6
  3.2 Functional Requirements ......................................................................... 6
    3.2.1 Patron ................................................................................................ 6
    3.2.2 Manager ............................................................................................ 6
    3.2.3 Server ................................................................................................ 7
  3.3 Nonfunctional Requirements .................................................................... 7
    3.3.1 Usability ............................................................................................. 7
    3.3.2 Reliability ........................................................................................... 7
    3.3.3 Performance ...................................................................................... 8
    3.3.4 Supportability ..................................................................................... 8
    3.3.5 Implementation .................................................................................. 8
    3.3.6 Interface ............................................................................................ 8
    3.3.7 Packaging .......................................................................................... 8
    3.3.8 Legal .................................................................................................. 8
  3.4 System Models ........................................................................................ 8
    3.4.1 Use Case Scenarios .......................................................................... 8
    3.4.2 Use Case Model .............................................................................. 10
    3.4.3 Object Model ................................................................................... 13
    3.4.4 User Interface .................................................................................. 14
4. Costs, Benefits and Scheduling ................................................................ 15
  4.1 Estimated Costs ..................................................................................... 15
  4.2 Estimated Benefits ................................................................................. 15
  4.3 Tangible ................................................................................................. 15
  4.4 Intangible................................................................................................ 16
  4.5 Payback Period ...................................................................................... 16
  4.6 Project Schedule .................................................................................... 16
  4.7 Gantt Chart............................................................................................. 17
1. Introduction

1.1    Purpose of System
        The Touch Menu System (TMS) is designed to be a revolutionary new way for
restaurant patrons to order food. Using modern touch-screen technology, restaurant
patrons can browse a digitized version of a restaurant’s menu. By replacing the
traditional waiter/patron paper order system with a revolutionary digital version,
restaurant managers can avoid costly order inaccuracies and achieve greater
productivity with less staff.


1.2 Scope of the System

      The TMS system is designed to meet the needs of three key stakeholders of many
traditional restaurants. These people are patrons, hosts/hostesses and restaurant
managers. Each has individual needs and interacts with the TMS differently.

     A patron using the system will be able to browse a digital interactive menu and
choose their food items along with any toppings or extras that they may like. Using the
system, the patron will also be able to specify how they would like their food to be
prepared. As an order is being generated, the system will output a running tally of the
items selected along with their total price. Tax will be calculated based on the state in
which the restaurant resides in. Once the order is complete, it will be reviewed by both
the host/hostess and the patron to ensure accuracy before it is digitally sent off to the
kitchen. Once received by the kitchen’s computer, it will be automatically printed for
queuing and preparation.

      Managers will have a separate role apart from the traditional ordering process.
While managers won’t interact with the ordering process, they will be able to edit the
digital menu items and prices through a separate user interface. Managers will have
administration privileges which will allow them to create and delete other managers.



1.3 Objectives and success criteria of the project

Some system objectives and success criteria include:

             To improve the quality and accuracy of restaurant ordering
            Waiter/waitress staff will be cut by 90 percent when the system is fully
             integrated into a full dining room

            A patron will be able to view the price of their entire meal as soon as they
             order, with a running tab as the meal is being put together

            Patrons will be more aware of what foods are out of stock

            Deaf patrons will have the entire menu including sauces, dressings and
             extras

            A visually impaired person will have options to view the menu at different
             sizes taking away the difficulty of trying to read small font on a menu

            Updating the menu becomes easy by only updating one source in real
             time

            A patron will be able to review their entire order before submission.



1.4 Definitions, acronyms and abbreviations

            Touch Screen: The patron taps the screen to select each item they want
             to order.

            TMS: Touch Menu System

            Accuracy: This measures the difference between ordering and receiving
             the correct meal, verses ordering and receiving the wrong meal.


1.5 Overview

       Section 3 of this Requirements Analysis Document will give a brief overview of
the proposed system and describe the functional and non-functional requirements of the
system as well as provide some system models such as Use-Case and Object
diagrams. Section 5 of this document will include specifications regarding the costs,
benefits and the scheduling of our proposed system.
2. Current System
Using Traditional Paper Menus

       In most restaurants today, dinner menus are made of paper which are either
presented to a patron in a lose leaf laminated format or bound into a covered book.
After a patron(s) is seated at his/her table, a waiter/waitress will dispense a restaurant’s
menu to each person at the table. The waiter/waitress will then usually leave the table
and give the patrons a minute or so to review the menu options and decide on drinks.

        The waiter/waitress will then return to place drink and/or food orders. Each
patron will then be asked in turn what they would like for food or drink. The
waiter/waitress will scribble each patron’s order onto a notepad which is usually carried
on the person. At many sophisticated restaurants, the waiter or waitress will rely solely
on memory to remember all the orders at the table. After each order is taken, it is
usually read back to each person to verify its accuracy. If a patron has any special
requests or extras to add, they will usually inform their waiter/waitress at the time of
ordering. Once all the orders are collected, they are either entered into a computer for
digital sending to the chief, or are compiled and then given to the chief directly.

        As one can clearly see, there are many complicated steps to this process. It is
easy to see how the process can become skewed or muddled. The TMS aims to
simplify this process by minimizing ordering time, confusion and reduce the need for
staffing.
3. Proposed System

3.1    Overview

The Touch Menu System will be implemented into restaurants as a replacement for the
conventional paper menu. Instead of restaurant patrons ordering from a menu and
relaying their orders to a waiter/waitress, they will digitally input their order into a TMS
tablet to be sent directly to the kitchen. This process will cut down on the amount of
errors in the food service industry by giving the customer power over his/her own order
and thus transferring the liability from the wait staff to the ordering patron.


3.2    Functional Requirements


       3.2.1 Patron
       A patron that comes to the restaurant, individually or within a party to eat a meal.

              3.2.1.1 – Order Meal
              The customer will choose what he/she wants to eat and then
              place the order through the TMS.


              3.2.1.2 – Get Invoice
              The customer will receive a digital bill on a TMS Tablet. This is just a
              confirmation of the order so they will know how much they owe. Payment
              won’t be possible without the help of a server.

       3.2.2 Manager
       An administrative user that will be able to modify the menu as well as add users
       such as new servers, cooks, and supervisors, etc.

              3.2.2.1 – Update Menu
              This function will allow the manager to edit the menu in real time to
              mitigate scenarios where a meal is out of stock. It’ll also enable them to
              add a new item or remove an item that is being discontinued.

              3.2.2.2 – Update Users
              A manager will be able to add and update other manager as staffing
              changes inside the restaurant.
      3.2.3 Server
      An employee user that will seat the customer and provide each patron with a
      TMS tablet.

             3.2.3.1 – Verify Order
             Once the party has completed and submitted their order, the server will
             return to the table to review it for validity and send the order to the kitchen.

             3.2.3.2 – Change Order
             By request of the customer, the server may modify the order either during
             the “Review Order” phase.

             3.2.3.3 – Void Order
             The server has the ability to void an order in case of a major mistake or
             external influence which causes the customer to leave.

              3.2.3.5 – Get Invoice
             Once the order has been submitted, the waiter/waitress will print an
             invoice for the party.



3.3   Nonfunctional Requirements

      3.3.1 Usability
      The TMS is designed to be easily used by anyone. There will be minimal training
      required to train managers for administrative tasks of the system. The human
      server will lend aid if necessary. The overall design of the interface will be to limit
      the need for the user to learn the interface. A major goal for TMS is for the
      system to be as easy to use as a conventional menu, while at the same time,
      introducing enhanced functionality and convenience.
      The software will operate on a touch sensitive screen that can be integrated into
      the table, or exist as a stand alone tablet like device. The GUI will feature
      interface controls with touch interaction in mind. Buttons will be large, and the
      use of small text minimal.

      3.3.2 Reliability
      TMS should be highly reliable. It utilizes a database to keep track of available
      menu items. As per good practice, a backup of the database should be
      maintained to ensure the prevention of data loss. The entire system will not fail if
      any one menu unit should fail.

      The hardware, on which the system will run, will be specialized industrial
      computers that have a very low rate of failure. They are also designed to run for
      long periods of time, with the potential ability to use solid state memory.
  3.3.3 Performance
  There will be limited functions of the system that will require high levels of
  computation on the menu unit. The load should not exceed those of a normal
  web browser. There should be limited network overhead, as the menu units will
  be able to cache preview pictures and limit the need for the server to repetitively
  transmit it to each device as it is requested.

  3.3.4 Supportability
  The system will be supported by telephone and email. Remote and on site
  support is also available for server based troubleshooting.

  3.3.5 Implementation
  The system will be run as a web application on the client side. It is written C++,
  ASP, and JSP. The server, which runs the database, the client menu devices
  query will run MySQL Server.

  3.3.6 Interface
  The system will run on a web based platform. The browser will be customized to
  prevent the user from attempting to redirect the web browser to a different site.
  The system will also operate on a local network and will not be afforded a remote
  connection to the internet.


  3.3.7 Packaging
  The system will be distributed via a cd package as well as the option for in house
  setup and configuration along with remote setup option for the database. The
  menu devices will be designed to require minimal to no configuration so as to
  limit having to configure each device individually.

  3.3.8 Legal
  The TMS will be sold under a site license. The license price is variable
  depending on the number of units in operation.



3.4 System Models

  3.4.1 Use Case Scenarios

     3.4.1.1    DistributeMenu
     Participating Actor instances   Joe: Host, Sue: Patron

     Flow of Events:
        1. Sue enters restaurant and is seated at her table by Joe.
        2. Joe distributes a TMS tablet.

     3.4.1.2    SelectMeal
     Participating Actor instances   Sue: Patron

     Flow of Events:
   1. Sue reviews menu options.
   2. The application instructs Isaac which text that he is to type.
   3. Once Sue has found an entrée that she likes, she can select the option
      by touching the menu.
   4. With the entrée selected, TMS will display any additional options for
      the dish. Sue can then select any extras that she would like to add with
      the meal.
   5. TMS will display a running total of the menu items selected, along with
      their options, extras and prices.

3.4.1.3    AcceptOrder
Participating Actor instances   Joe: Host, Sue: Patron

Flow of Events:
   1. Now that Sue is about to place an order, it will be reviewed by both her
      and Joe.
   2. Once the order is determined to be correct, Joe will submit the order to
      the kitchen for preparation.
   3. A receipt will then be printed and handed to Sue.


3.4.1.4    UpdateMenu
Participating Actor instances   Carl: Manager

Flow of Events:
   1. If the menu needs to be updated to reflect a price change or or other
      difference, Carl will log into the web management interface for the
      restaurant.
   2. Carl can then browse through the plate options and select the one he
      wishes to edit.
   3. After clicking, “update” all information will be written back to the
      database and each menu updated simultaneously

3.4.1.5    UpdateManagers
Participating Actor instances   Carl: Manager

Flow of Events:
   4. If staffing changes occur in the restaurant, Carl will need to update the
      managers in the TMS.
   5. Carl can then browse through the database using the built-in interface.
   6. According to needs, Carl can either add, update or delete manager
      information to give access to the system.
3.4.2 Use Case Model




  3.4.2.1   Use Case Name: View Items
            Participating Actor: Patron

            Entry Condition: None
            Exit Condition:    None
            Quality Condition: System should have an uptime of 99%

            Flow of Events:
               1. Patron receives TMS
               2. Patron can browse and scroll through menu options


  3.4.2.2   Use Case Name: Add Toppings
            Participating Actor: Patron

            Entry Condition:   None
          Exit Condition:    None
          Quality Condition: System should have an uptime of 99%

          Flow of Events:
             1. As the patron reviews the menu, he/she will have the
                option of adding toppings or extras
             2. Patron will select food item which will then present the
                patron with extra options


3.4.2.3   Use Case Name: Review Order
          Participating Actor: Patron, Host

          Entry Condition: None
          Exit Condition:    None
          Quality Condition: System should have an uptime of 99%

          Flow of Events:
             1. Patron and host will review the entire order to ensure
                accuracy

3.4.2.4   Use Case Name: Submit Order
          Participating Actor: Host

          Entry Condition: None
          Exit Condition:    None
          Quality Condition: The host and patron have reviewed the
          order and checked accuracy

          Flow of Events:
             1. Once order is reviewed it will be submitted to the
                kitchen
             2. A bill will then be printed


3.4.2.5   Use Case Name: Update Menu
          Participating Actor: Manager

          Entry Condition: Manager has correct credentials
          Exit Condition:    System will display administrative page
          Quality Condition: System should update within 4 seconds.

          Flow of Events:
             1. Manager proceeds to the management section of the
                menu
             2. Once manager has logged in, the management menu
                will be displayed
             3. The manager can select any menu item via a drop down
                list and update the menu’s information
             4. All changes will be processed when the manager clicks
                “update”


3.4.2.6   Use Case Name: Add Managers
          Participating Actor: Manager

          Entry Condition: Manager must have valid credentials
          Exit Condition:    System will display management menu
          Quality Condition: Changed managers should be reflected in
          the system immediately

          Flow of Events:
             1. Manager proceeds to the management section of the
                menu
             2. Once manager has logged in, the management menu
                will be displayed
             3. The manager can select any manager from the drop
                down list and update/add/delete that manager from the
                system
             4. All changes will be processed when the manager clicks
                “update”
3.4.3 Object Model
3.4.4 User Interface
4. Costs, Benefits and Scheduling


   4.1 Estimated Costs

Resource             Description                           Time             Costs
                                                                            ($)
Research             Software development and                   4 weeks
                     research
                     Development Team of Three                                 9,600
                     $20.00/hr.
                     Research Team of Two                                      5,760
                     $18.00/hr.
Developers           Coding and implementation                    36 days
                     Programmers Team of Three                                15,000
                     Testers                                                   8,000
Miscellaneous        Unexpected expenses                                       3,000
Total Costs:                                                                  41,360



   4.2 Estimated Benefits

Benefits                                                                    Cash ($)
Revenue from Software Sales                                                 250,000
Total Revenue:                                                              250,000

   4.3 Tangible

   The tangible benefits will result in a software web application that will be sold to any
restaurant of any size. The package price will vary depending on the size of each
restaurant. We estimate that 30 packages will be sold within 22 months after
deployment.
   4.4 Intangible

   The intangible results from this system will be the satisfaction of the customers by
creating a sure fire way that every order is correct every time. It will also create an
easier atmosphere for the managers and wait staff which can spend more time verifying
the quality and satisfaction of food that goes out to customers. Also, managers will have
an easier time updating menus which saves time and money.

   4.5 Payback Period

   The payback period will be between 8-14 months after the deployment of our
application.
Many restaurants are likely to switch to this system to save money on paying staff and
getting customers in and out quicker while making them want to come back time after
time. Our Marketing campaign will be focused around cities and other fast paced and
high traffic areas.


   4.6 Project Schedule

Task Name        Assigned         Task              Input           Output
                 Role             Description
Project          Project                                            Proposal
Proposal         Leader                                             Document
TMS              System           Elicits           Team liaisons   Requirements,
Requirements     Architect        requirements                      API,
                                  from team                         documentation,
                                  about                             and object
                                  persistent                        model
                                  objects, their
                                  attributes, and
                                  relationships
TMS Design       System           Design of         API             UML diagram
                 Designer         system
TMS              Implementer      Implements        Sub design      Source code
Implementation                    the API
TMS Test Dev. Tester              Develops a        Subsystem       Tests plan
                                  test suite for    API,
                                  the subsystem     Subsystem,
                                                    Source code
TMS Test         Tester           Executes the      Subsystem,      Test results,
                                  test suite for    Test plan       Log file
                                  the database
                                  subsystems
   4.7 Gantt Chart

GANTT CHART - TMS Time Line
                  Tasks                             January                February          March                     April
            Project Proposal (Jan 3-Jan 14)
        TMS Requirements (Jan 10 -Feb 12)
              TMS Design (Jan 15-Jan 24)
TMS Implementation (Feb 2-Feb-March 20th)
         TMS Test Plan (Feb 5- MArch 27)
                 TMS Test (Feb 8- April 21)




                                       Key Dates
KEY                                      1/7   Form team                              1/16    Start Development
                                        1/12   Create project ideas                   2/21    Test
             Gantt Bar                  1/14   Map process                            2/28    Systgems and software design
                                        1/20   Identify solutions                     4/11    implementation and QA testing
                                        1/27   Develop improvement plant
                                        1/29   Set budget

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:5/29/2012
language:
pages:17