CS 509 Term Project Page

The term project assignment for CS 509 is to design and build a web-based pizza ordering system. The system will consist of a customer part, where the user can order pizzas, subs, etc. from a web page, and a restaurant part, where the pizza shop can manage orders placed over the web.

This page will describe more details about the term project as the course progresses.

In class on 3/23/06 we began to identify functional and non-functional requirements for the pizza ordering project. The list of requirements we came up with can be found below.

Phase 1, Due 3/30/06
The first assignment for the term project deals with requirements. For Phase 1, students will identify names of 5 to 10 use cases for the system, and choose the top 5 requirements from the list below to explore in more detail for the first iteration. In class on 3/30/06, we will begin to further develop the use cases, so they need not be fully specified for this assignment. The "top 5" requirements should be ones that are either high risk in some way, or of high value to an eventually functional system.

The remaining set of project phases were briefly planned out in class on 3/23/06. As we get closer to the due dates, these assignments will be spelled out in more detail, and may change depending on how far along we are able to get in the project plan.

Phase 2, Due 4/13/06
The second assignment for the term project will deal with design.

In class on 4/6/06, the class identified a subset of requirements to implement for our first iteration of the term project. Those requirements are specified below in more detail. The Phase 2 assignment is to create designs for the implementation of those requirements.

Student groups will at a minimum create high-level subsystem designs with interfaces specified between subsystems, and then will begin work on lower level class and database schema designs. The assignment to turn in may consist of UML diagrams either drawn by hand or using one of many available tools to draw UML diagrams. The diagrams should be augmented by text which explains the design.

In class on 4/13/06 each group will have an opportunity to present their design to the rest of the class. The rest of the class will review the designs to ensure that they satisfy the requirements for the project, to point out weaknesses and to suggest improvements.

Phase 3, Due 4/27/06
The third assignment for the term project will deal with implementation.

For this phase of the assignment, students will turn in code (which the instructor will review) and instructions for running unit tests (which the instructor will execute) for each of the three subsystems: User Interface, Business Logic, and Database. To facilitate turning in code, students will put source documents in the following directories on the WPI server for the course (cs509.cs.wpi.edu) created for this purpose:

/usr/local/tomcat5.5/webapps/ROOT/src/ui
/usr/local/tomcat5.5/webapps/ROOT/src/bl
/usr/local/tomcat5.5/webapps/ROOT/src/db

1. Email a document to the instructor
2. Place a document in the appropriate directory above
Turn in hard copy in class

Phase 4, Due 5/11/06
The fourth assignment for the term project will deal with integration.

For this phase of the assignment, students will test and debug the system for the purpose of validating the integration. Each group will develop plans to test the entire system (not just their group's functionality). Students will run the tests, report and fix problems, and keep track of test results.

Each group will turn in a document describing the set of test cases that their group developed, in addition to a report of the testing results:

• The test cases document should name each test case; describe it in terms of how to execute the test and what functionality it intends to exercise, and the expected results of the test.
• The report should include for each test case, the name of the test (referring to the test cases document), the date and time the test was run, and the results of the test (pass or fail).

If a test fails, a bug report should be written up and sent to the class mailing list. When a bug is fixed, the group or person who fixed the bug should send an email to the class mailing list indicating that the bug has been fixed, and the test(s) that previously failed should be re-run to verify the fix.

Phase 5, Due 5/25/06
The fifth assignment for the term project will deal with Iteration.

It was decided in class on 5/4/06 that this phase will focus on the design of the next set of requirements for the project. See the section below entitled "Iteration 2 Requirements".

Each project group will work on a design for the requirements listed below for Iteration 2 as they apply to their group's assigned functional area (User Interface, Business Logic and Database). The assignment to turn in will document the designs using whatever diagrams are appropriate (UML Sequence, State, Class diagrams, database schema diagrams, user interface mock-ups, etc.) The diagrams should be augmented by text which explains the design.

The following is a list of functional and non-functional requirements identified in class in 3/23/06. Students should feel free to add to this list if they think of anything that's missing. In other words, the Phase 1 assignment above does not have to come exclusively from this list. The order of the list is just how we came up with the ideas in class and is not meant to imply anything meaningful.

1. Provide ability for customer to place order
2. Make menu (food) items available for selection on web page
3. Allow restaurant to receive customer's order
4. Allow customer ability to see summary of items ordered and cost
5. Allow customer to specify quantity of items ordered
6. Provide special requests field
7. Provide a way to select toppings, ingredients (dynamic attributes)
8. Provide a way for restaurant to acknowledge customer's order
9. Provide payment method - C.O.D. or credit card
10. Allow restaurant to customize web page with store graphics, logo, specials
11. Allow customer to check order status
12. Allow restaurant to specify response and/or delivery time
13. Allow dynamic menu updates (for example, if restaurant runs out of some food item)
14. Web-based applications on both customer and restaurant sides
15. Allow customer to choose pick-up or delivery
16. Allow customer to create user account: remember address, phone, previous orders, etc.
17. Provide mechanism for restaurant to specify terms of service, legal disclaimers, etc.
18. Allow restaurant to review open orders
19. Allow restaurant to close orders
20. Allow restaurant to tally orders
21. Allow customer to enter coupon code

The following is a more detailed specification of the requirements identified in class on 4/6/06 that we will tackle for the first iteration.

• Allow customer to place order
• Provide display of menu (food items)
• Allow selection of menu items
• Allow customer to order at least one pizza
• Allow customer to choose pizza size (small or large)
• Allow customer to specify pizza toppings
• (Optional) Allow customer to order "house special" pizza with pre-configured toppings
• Present total cost of order
• Allow choice of pickup or delivery
• For pickup, allow customer to enter name
• For delivery, allow customer to enter name, address and telephone number
• Allow customer to submit or cancel order
• Allow system to acknowledge customer's order
• Provide acknowledgement to customer that system has received order
• Allow restaurant to receive customer's order
• Provide list of open orders for restaurant to view
• Upon arrival, add new order to list of open orders
• Provide some mechanism to indicate to restaurant that a new order has arrived
• Allow restaurant to close an order
• Remove closed order from list of open orders

The following is a more detailed list of requirements identified in class on 5/11/06 that will be tackled for the 2nd iteration (Phase 5).

1. User account
• Allow customer to create user account, consisting of:
• Username & password
• Real name
• Address
• Phone number
• Ensure username is unique when creating new account
• Allow login of existing customers
• Allow existing customer to enter username & password
• Use customer account information for current order
• Validate password when existing user logs in
2. Check restaurant open / closed
• If restaurant is closed, customer can see this on 1st page, along with menu
• Restaurant has control over indicating open / closed
3. Organization of menu items
• Provide categories for menu items, e.g., pizzas, subs, dinners, side orders, etc.
• Display menu items in hierarchy, e.g., toppings appear under pizza.
4. Client-side validation
• Ensure, as much as possible, that user cannot enter invalid data
5. Better order id
• Ensure order id is unique for each order
• Display order id to customer

Students in the class have arranged themselves in the following functional groups for work on the term project. We reserve the right to change the organization of the groups as needs arise.

Back to home page.