Assignment+3+-+Fall+2010

Due at the beginning of class (2:30pm) on Wednesday, November 10, 2010
[Note: Deadline extended by one day]  Due at 4:00pm on Thursday, November 11, 2010. Hand in hard-copy at Professor Monroe's office (CMU-Q 2122) no later than 4:00pm.

Overview:
Congratulations, your stakeholder and requirements analysis for Quick 'n Tasty were a success and the restaurant's management team has decided to move forward with the smartphone app that will display the menus and allow customers to order for take-away. This is the first step in a larger BPI project. The restaurant managers want to try a smaller step towards automation before taking a giant leap for a full kitchen and restaurant ordering management system. As a reward for your good work in the analysis stage of the project, you have been asked to do some of the project's data modeling. Specifically, you need to create data models for for the parts of the system described in the scenarios below.

As with the previous assignment, the description of the restaurant, its processes, and the project requirements are not perfectly and completely defined. This is partly due to the fact that the use of a fictional scenario requires a bit of imagination, and partly to reflect the ambiguity present in many IS projects. When you come to a point where you are unsure exactly how the business process does or should work, or whether the system needs to support a requirement that seems to make sense but is not written down, you should use your experience, business judgement, and common sense to fill in the gaps in the scenarios and come up with reasonable data models. You may also ask for clarification on the Assignment 3 clarifications page, where I will post responses to questions for all students to see. It is ok to make assumptions as you are doing this exercise. If the assumptions are not obvious then it is probably a good idea to state them clearly in the documents you submit.

You may work on the assignment individually, or in teams of 2 or 3 people.

Background:
As we learned in Assignment #2, Quick n' Tasty is a chain of five restaurants located in Doha Qatar. Quick n' Tasty (QnT) offers both sit-down restaurant service and curbside take-away service at each of the restaurants. As their name indicates, the restaurant's value proposition is to provide good food and very fast service. The restaurants are very popular and during the dinner rush they often have a line of people outside waiting for a table and a dozen or more cars idling outside the take-away curb waiting to place an order or receive their food.

The QnT managers have created such a successful restaurant that they are having trouble keeping up with demand and serving customers quickly enough. They have even begun to hear stories from some of their customers that they are not coming to QnT as often because of the crowds, lines, and amount of time they need to wait to get a table or their order. Some disgruntled (former) customers have even taking to calling the restaurant 'Slow n' Tasty'.

Having recently completed a Business Process Improvement analysis, the QnT managers have decided to move forward with the first phase of a Kitchen and Order Management System (KOMS). In the first phase of the project, they have decided to focus on making the take-away ordering and pickup processes faster, more efficient, and easier for customers. To do so, they are going to create a smartphone-based ordering system for take-away customers. The details of this system are described in the next section.

Your group needs to produce an entity-relationship diagram that captures the data needs for the take-away ordering module. You also need to produce a set of relational tables that capture the required data and relationships between the data. If you feel it would be helpful to do so, you may also provide an appendix with a written explanation of any important assumptions you made in completing your models. This written appendix is optional.

System description
The system that you create will consist of a smartphone application that runs on iPhones and BlackBerrys, and a web-based server system that keeps track of orders and forwards them to the QnT waiters, who print out the orders as they come in and pass the slips.

The smartphone application can be downloaded to an iPhone or a Blackberry. The smartphone application will allow customers to perform the following functions:
 * Smartphone application:**
 * Retrieve information about each Quick 'n Tasty restaurant. This information includes each restaurant's phone number and business hours (each restaurant's business hours can be different), restaurant location in the form of both an address and a map location. The map location can be used with the iPhone and BlackBerry GPS systems to show the restaurant location on the phones' built-in mapping applications. You do not need to create your own maps. Your application only needs to provide each restaurant's location information in a format that the phone's built-in mapping software can use.
 * Create and edit a Customer Profile. Each customer's profile should include that customer's name, mobile phone #, and e-mail address. A customer may have up to three mobile phone #'s associated with their profile. A customer's profile should also store information about the customer's vehicles. Each Vehicle stored in the profile should include the vehicle make and model, color, and license plate #. A customer profile does not need to have a vehicle associated with it, but a customer may add information for an arbitrarily large number of vehicle to their customer profile. The customer should also be able to store information for zero or more credit cards for payment. Credit card information should include type of card (Visa, Mastercard, Discover), the credit card number, and expiration date. The customer profile should record whether the customer prefers to receive information from the restaurant in English or Arabic. The customer profile should include a history of all of the orders that the customer has placed with Quick 'n Tasty previously.
 * View the complete Quick 'n Tasty menu. A Menu consists of a collection of Menu Items. Each Menu Item includes an item name, a description of the item, and an item price. Each item on the menu should have its name and description stored in both English and Arabic. For the first release of the system, you may assume that the Qatari Riyal is the only currency you need to support. The customer using the smartphone application should be able to select whether to view the menu in English or Arabic.
 * Ordering. The customer should be able to use the smartphone app to place an order for take away. The specific operations that the customer should be able to do with respect to ordering include:
 * Selecting items from the menu to add to the order
 * Removing items from the order
 * Adding any special instructions for the order (such as "extra sauce on the shwarma").
 * The application should display a running total of the cost of all items selected thus far
 * Specify the desired time to pick the order up (which will default to 'as soon as possible')
 * Select the restaurant at which he or she would like to pick the order up
 * Instead of building a new order, the customer should be able to retrieve a previously placed order and start a new order by copying all of the items on the old order over to the new order.
 * Submit the order
 * Cancel an already submitted order
 * View current order status
 * Payment. The customer should be able to pay for the order with cash or by credit card. For cash, the payment will be provided to the waiter when the food is received. For credit card, the customer can select one of the credit cards in his or her profile and the restaurant will process payment as soon as the order is placed so that the customer can simply pick the food up right away upon arrival to the restaurant.

Each restaurant will have a single machine located inside the restaurant that will be operated by the QnT waiter responsible for take-away orders (there may be many waiters working for take-away customers, but only one is responsible for receiving and handling smartphone orders). When a take-away order is sent to the restaurant, that order appears on the in-restaurant system screen, and a small piece of paper is printed out with the order time and date, the desired pick up time (as soon as possible by default) and the name, phone number, license plate, and vehicle description for the customer who placed the order. The slip of paper also includes the contents of the order -- a list showing each item ordered and the quantity of that item in the order (for example, "6 cheese fatayer"). The order slip also lists any special order requests that the customer entered when they placed the order with their smartphone (for example, "please include ketchup packets with the cheese fatayer"). Customers can only order items that are available on the current menu.
 * In-restaurant system:**

Once the order slip is printed out, the waiter responsible for take-away acknowledges the order in the system by clicking the 'received' button on the application for that order, then physically carries that order slip of paper to the kitchen where the order is prepared. At this point two things happen. The first is that an SMS message is sent back to the customer who placed the order letting them know that the order has been received. The second is that the take-away waiter delivers the order slip to the kitchen. At this point the order moves from the state 'submitted' to the state 'in process'. [Note for future reference: in later releases, QnT plans to expand KOMS with an in-kitchen order management system that will receive the orders directly and display them on a video screen in the kitchen. For this phase of the project, though, QnT managers have decided to focus only on the take-away ordering process first. Updating the kitchen-based workflow will need to wait until all of the problems have been resolved with the implementation of the phase-1 system].

Once the cooks in the kitchen receive the slip of paper with the order on it, they cook the food and package it together using the same process that they used previously with the paper-based orders. That is, from the cooks' perspective, there is no change to the ordering and food cooking process. When the order is prepared, the cooks place the order on the counter for delivery by the waitstaff, identifying the order with the slip of order paper sitting on top. The take-away waitstaff then use the in-restaurant system to update the order status to 'order ready for pickup'. The in-restaurant system then sends an SMS message to the smartphone that ordered the system indicating that their order is now ready for pickup and listing the total price of the order and the location of the restaurant (just as a reminder).

When the customer arrives to pick up their order, the waiter delivers the order to the customer in his or her vehicle (or at the counter if the customer comes inside). The waiter collects payment (if it is a cash payment) or gets a signature or PIN (if it is a credit card or debit payment). The waiter then marks the order as 'picked up' on the in-restaurant system, the status of the order is changed to 'picked up' and the amount paid for the order, and the method of payment for the order, are recorded in the system for future reference.

Deliverables:
You need to hand in a paper copy of your data models to Professor Monroe no later than 4:00pm on Thursday, November 11, 2010. You may produce the document with a computer or by drawing it by hand on paper. You are likely to find that it is quicker and easier to draw the diagrams by hand on A3 paper than with a computer. Regardless of how you decide to produce the document, please make sure that it is clear, clean, and legible. Documents that are illegible will be graded accordingly.

Your submitted document should contain two distinct data models the E-R Diagram and the Relational Model for your system. The ER diagrams should contain all of the entities and attributes identified in the scenario descriptions, plus any additional entities and/or attributes that you feel need to be included in the model for Quick n' Tasty to make proper use of the database that will be created based on this data model. All appropriate relationships between the entities should also be included in the diagram. Likewise, the relational models should capture and represent all of the data identified in the scenario, and also any additional data that you included in your ER diagram. Your relational model should clearly identify each table's name, the names and data types of each of columns, as well as all primary keys and foreign keys.

Grading Criteria:
There are 110 points possible on the assignment. I will use the following criteria when grading your submission:
 * Submitting your document on time and according to the submission and deliverables specification is worth 10 points.
 * The E-R Model is worth 50 points
 * The Relational Model is worth 50 points

Statement on Collaboration:
The document you submit may be done individually, or in teams of two or three people. You may not work in teams larger than three people - if you have a group of more than three people who would like to work together you will need to break the group into separate teams.

You are free to discuss the assignment, the restaurants' needs, stakeholders, and general ideas about the case and assignment with your classmates on other teams. Each team will, however, need to create, write down, and submit their own data models. The document submitted needs to represent the work of the team submitting it - your team needs to synthesize the discussion and come to their own conclusions regarding what should be in the data model.

You should not discuss specific details about your data model with people on other teams, only general ideas. In general, if you find that after discussing the assignment with your classmates you produce very similar data models then you are probably discussing the assignment in too much detail. If you find that you are just copying the ideas from another group then you have probably stepped over the line that separates a constructive discussion about the assignment from cheating. You would be surprised how much variation there will be in the data models that different teams submit, and how much two data models that have been done together, even with minor variations, will stand out when looked at in the context of all of the assignments submitted.

The names of all team members should be on the single document that you submit. If your team has spent so much time discussing the case with another team that it is likely the instructor will be concerned about copying between the teams then you should list the names of the other people in the class with whom you have discussed the assignment as well. These people should be identified as participants in your discussions rather than team members. Those identified on an assignment only as participants will not be graded or get credit for that team's submission but they will also be much less likely to get in trouble for academic integrity problems if their participation is called out clearly in the submission.