Arab Academy for Science, Technology and Maritime TransportCollege of Computing and Information TechnologyDepartment of Computer Science

Software Requirements and Specifications

Project Final Report for Cafeteria Ordering System

Lecturer: Dr. Walid Abdelmoez

Group Members :

Olla Ahmed Aya Mohallel Shaimaa Ahmed Marwa Tareq Huda Medhat

1 | P a g e

Cafeteria Ordering System

A majority of Process Impact employees presently spend an average of 60 minutes per day going to the cafeteria to select, purchase, and eat lunch. About 20 minutes of this time is spent walking to and from the cafeteria, selecting their meals, and paying for their meals by cash or credit card. When employees go out for lunch, they spend an average of 90 minutes off-site. Some employees phone the cafeteria in advance to order a meal to be ready for them to pick up. Employees don't always get the selections they want because the cafeteria runs out of certain items. The cafeteria wastes a significant quantity of food that is not purchased and must be thrown away. These same issues apply to breakfast and supper, although far fewer employees use the cafeteria for those meals than for lunch.

Many employees have requested a system that would permit a cafeteria user to order meals on-line, to be delivered to a designated company location at a specified time and date. Such a system would save those employees who use the service considerable time and it would increase the chance of them getting the food items they prefer. This would improve both their quality of work life and their productivity. Knowing what food items customers want in advance would reduce wastage in the cafeteria and would improve the efficiency of cafeteria staff. The future ability for employees to order meals for delivery from local restaurants would make a wider range of choices available to employees and provide the possibility of cost savings through volume purchase agreements with the restaurants. It might also permit Process Impact to have the cafeteria handle only individual lunches, relying on restaurants to fill orders for breakfasts, dinners, special events, and weekend meals.

You are required to produce the following artifacts:

A vision and scope document A list of use cases and several use-case descriptions Software requirements specification

o Analysis modelso Data dictionary

Business rules A suitable prototype for the system

Project Deliverables:

Deliverable Due DateProject Draft January 5th Final Project January 18th Prototype & presentation of the project January 18th

2 | P a g e

Table of ContentsTable of Contents...........................................................................................................................iiVision and Scope Document1. Business Requiremnets.........................................................................................................4-5

1.1 Background,Business Opportunity and Customer needs..................................................................41.2 Business Objectives and Success Criteria.........................................................................................41.3 Business Risks..................................................................................................................................5

2. Vision of Solution.....................................................................................................................52.1 Vision Statement...............................................................................................................................52.2 Assumptions and Dependencies.......................................................................................................5

3. Scope and Limitations.............................................................................................................63.1 Scope of Initial and Subsequent Release..........................................................................................63.2 Limitations and Exculsions..............................................................................................................6

4. Business Context...................................................................................................................6-74.1 Stakeholder Profiles..........................................................................................................................64.2 Project Priorities................................................................................................................................7

Use Cases...................................................................................................................................9-151.1 Use Case Diagram.............................................................................................................................91.2 Use Case Templates...................................................................................................................10-15

Software Requirements and Specification1. Introduction............................................................................................................................16

1.1 Purpose............................................................................................................................................161.2 Project Scope and Product Features................................................................................................161.3 References.......................................................................................................................................16

2. Overall Description...........................................................................................................16-192.1 Product Perspective.........................................................................................................................172.2 User Classes and Characteristics....................................................................................................172.3 Operating Environment...................................................................................................................182.4 Design and Implementation Constraints.........................................................................................182.5 User Documentation.......................................................................................................................192.6 Assumptions and Dependencies.....................................................................................................19

3. System Features................................................................................................................20-213.1 Feature 1..........................................................................................................................................203.1 Feature 2....................................................................................................................................20-21

4. External Interface Requirements1..................................................................................21-224.1 User Interfaces................................................................................................................................214.2 Hardware Interfaces........................................................................................................................214.3 Software Interfaces.........................................................................................................................224.4 Communications Interfaces............................................................................................................22

5. Other Nonfunctional Requirements.....................................................................................235.1 Performance Requirements.............................................................................................................235.2 Safety Requirements.......................................................................................................................235.3 Security Requirements....................................................................................................................235.4 Software Quality Attributes............................................................................................................23

Appendix A: Data Dictionary and Data Model...................................................................24-26Appendix B: Analysis Models................................................................................................27-29Appendix C: Business Rules.......................................................................................................30Appendix D: Task Distribution..................................................................................................31

3 | P a g e

Vision and Scope Document

1. Business Requirements

1.1 Background, Business Opportunity, and Customer Needs

Opportunity Statement

Customers' current state:

Some employees go to the cafeteria to select, purchase, and eat lunch and others phone the cafeteria in advance to order a meal to be ready for them to pick up which wastes their time. Employees don't always get the selections they want because the cafeteria runs out of certain items. The cafeteria wastes a significant quantity of food that is not purchased and must be thrown away. These same issues apply to breakfast and supper, although far fewer employees use the cafeteria for those meals than for lunch

Desired state:

Permit user to order meals on-line, to be delivered to a designated company location at a specified time and date.

Reduce wastage in the cafeteria and would improve the efficiency of cafeteria staff.

Ability for employees to order meals for delivery from local restaurants , which would make a wider range of choices available to employees

Provide the possibility of cost savings through volume purchase agreements with the restaurants.

Customers can design their weekly meal plans in advance increasing the chance of them getting the food items they prefer.

Cafeteria handles only individual lunches, relying on restaurants to fill orders for breakfasts, dinners, special events, and weekend meals

1.2 Business Objectives and Success Criteria

BO-1: Reduce cafeteria operating costs

BO-2: Reduce cafeteria food wastage

BO-3: Increase work time by 20 minutes per employee per day

BO-4: Ability to order and pay for the meals online

SC-1: Cafeteria makes more profit and gains more customers

4 | P a g e

1.3 Business Risks

RI-1: Local restaurants might not agree to offer price reductions to justify employees using the system

RI-2: A few employees might use the systemRI-3: Limited resources

2. Vision of the Solution

2.1 Vision Statement

Our vision is about meeting consumers' needs and making food an easier, healthier, more enjoyable part of life. We created an internet-based application for employees who would like to order meals from the cafeteria or from local restaurants. The cafeteria ordering system allows Employees to order personal or group meals, process payments and to deliver meals to a certain location. Our employees will not have to go to the cafeteria to get their meals. This allows them to save time and will increase the food choices that are available to them.

2.2 Major Features

Requesting meals from the cafeteria menu that are available Ordering meals from the cafeteria menu or restaurants to be delivered Change the meal order Cancel meal order Register for meal payment options Request meal delivery

2.3 Assumptions and Dependencies

There will be a menu available on the computer system for the employees to see what he or she would like to order and if that item is available or not. This will be beneficial for the employees who want to purchase fast meals.

The cafeteria staff will be working on the ordering system so see employees requests and make sure that their meal are delivered quickly.

The staffs that are in charge of the delivery will be in charge of all orders to be sent within the delivery time.

3. Scope and Limitations

5 | P a g e

3.1 Scope of Initial and Subsequent Releases

Feature Release 1 Release 2 Release 3

FE-1 Employees can order their meals online and pay cash on delivery or checks

Price of employee’s orders are automatically deducted from the salary when placing the order

Employees pay for their orders online by credit or debit cards

FE-2 Customer orders meal as is, no substitutions

Customer can customize their order

FE-3 Customers place their orders daily according to what is served in the cafeteria that day

Customers are given an option to plan their weekly meals ahead of time

FE-4 Employees can only order from cafeteria’s menu

Employees can order their meals from other local restaurants’ websites that are linked to the cafeteria’s website

3.2 Limitations and Exclusions

LI-1: Employees can’t track the current status of their order s

LI-2: Employees can’t view the history of their orders

4. Business Context

4.1 Stakeholder Profiles

Stakeholder Major Value Attitudes Major Interests

Constraints

Cafeteria Staff There is a more efficient use of staff , higher customer satisfaction

Concerns with possible down sizing

Job preservation

Trainings for employees for internet usage, delivery staff and the transportation needed for delivery.

Patrons Save time and effort, better food selection, clear menu to choose from,

Impressed with the fast service and the saving time.

Easy to use and the delivery is reliable.

Access to the system intranet whenever it is needed

6 | P a g e

Stakeholder Major Value Attitudes Major Interests

Constraints

convenient.

Payroll Department Payment with credit or payroll deduction (needed to be set up)

Recognizes the value of the company and employees.

No change in the payroll applications.

No problems

Restaurant Managers

New marketing techniques to gain new customers.

careful Responsible for delivery meals and costs.

Concern if there's not enough staff.

4.2 Project Priorities

Dimension Driver Constraint Degree of Freedom

Schedule Finish 1 planned to be done by 15/1/2010, check and update by 18/1/2010.

Features Every feature that is ready must be completely operational

Quality The user acceptance tests must succeed with passing scores, an estimate of 95% should pass.

Staff There should be project team, project manager, developers, and testers if necessary.

Cost Budget should not be exceeded by more than 15%

Use Cases

The various user classes identified the following use cases and primary actors for the Cafeteria Ordering System:

7 | P a g e

Primary Actor Use Cases

Employee 1. Login and Verification2. Select and Set Weekly Order Plan3. Order Meals4. Request Delivery5. Choose Payment

Employee Database 6. Login and Verification

Delivery Person 7. Deliver Food8. Pick up food and Delivery

Instructions

Cafeteria Staff 9. Track Inventory Status10. Receive Orders11. Print Delivery Instructions12. Prepare Meals

Inventory System 13. Track Inventory Status

Payroll system 14. Deduction from Payroll

Local Restaurants 15. Provide Website Links

Menu Manager 16. Establish/Maintain Daily Menu’s.

Use Case Diagram

8 | P a g e

9 | P a g e

Use Case Templates

Use Case Template 1:

Name: Payment system.Description/Summary: -It’s the system that is used by customers in COS by

which they can choose from different payment methods.

Actors: -Cafeteria ordering system.-Employees.-Cafeteria staff.

Triggers: -User name and password are validated.-User order meal.-User chooses one of three payment methods.-User can choose to pay by cash and pay by cash.-User can choose to pay by credit card.-User enters credit card information.-User pays by credit card.-User's credit card information is validated.-User can choose deduction from payroll method.-There exists more than 50% of user's salary.-Meal cost is deduced from user's salary.

Pre-Conditions: -A user login to the system, chooses to order meal, and then chooses payment method.

Successful Path/ Basic course of events:

1. The system asks user for user name and password.2. User inserts user name and password.3. System checks if user has inserted right user name

and password.4. System displays three choices for user to choose

from (Order meal, Do weekly plan, and Local restaurant).

5. If user chooses Local restaurant system display restaurants website links.

6. User chooses one of these restaurants to order from.

7. If user chooses Do weekly plan, system allow user to set his weekly plan.

8. If user chooses Order meals, system show cafeteria daily menu for user to choose from.

9. User chooses the meal he wants.10. System displays three different payment methods

for user to choose from (Pay by cash, Pay by credit card, Deduce from payroll).

10 | P a g e

11. If user chooses Pay by cash, System notifies him of his choice.

12. If user chooses pay by credit card System asks user to prompt and enter credit card information.

13. System checks that the entered information is right.

14. System notifies user of his transaction.15. If user chooses Deduce from payroll, System

checks that that user has at least 50% of his salary remaining.

16. System does the deduction from payroll.17. System notifies the user of his transaction and his

remaining salary.

Alternative Path: *If user enters wrong user name or password:-User will not be able to login.-An error message occurs.

*If an employee chooses "Deduction from payroll" payment method and he has less than 50% available of his salary:-User will not be able to pay for the meal by that payment method.-System inform user that he has to choose one of the other two payment methods.

Post-Conditions: -Meal's price is deduced from employee's salary if he chooses "Deduction from payroll" method.-User is notified of the payment method he chooses and notified of his transaction.

Assumptions: -Assume that all users are company employees.Exceptions: -User name is invalid: system displays "Invalid user

name".- Password is invalid: system displays "Invalid password".

Author: Aya Mohallel.

11 | P a g e

Use Case Template 2:

Name: Pick up foodDescription/Summary: Patron requests meals from the Cafeteria Ordering

System, and choose to go to the cafeteria and pick up the meal

Actors: Patron, cafeteria, cafeteria ordering system,Triggers: -Patrons goes to cafeteria

-signs his/her signature on the computer system- picks up meal

Pre-Conditions: - Patron is a member of the cafeteria's ordering system

- Patron placed the order he/she wants - Patron chose the time to pick up the meal

Successful Path/ Basic course of events: 1. Patron view menu to select the meal to be picked up

2. System displays menu of available food items.3. Patron selects one or more food items from menu.4. Patron indicates that meal order is complete.5. patron select the payment he/she desires6. System displays ordered menu items, individual

prices, and total price, including any taxes and delivery charge.

7. System displays available delivery times for the delivery date.

8. Patron selects a delivery time and specifies the delivery location.

9. System confirms acceptance of the order.10. System stores order in database, sends e-mail to notify

Cafeteria Staff, sends food item information to Cafeteria Inventory System, and updates available delivery times.

11. patron comes to pick up the meal in the delivery time12. patron signs that meal is complete and picked up

Post-Conditions:- Inventory of food chosen is available- Meal is ready to be picked up- Payment is chosen (credit, cash, deduction from

payroll)Assumptions: No assumptionsExceptions: The cafeteria has many orders so pick up is delayed a

couple of minutesRelated Business Rules: Business rule 1 and 3Author: Hoda Medhat NegmDate: January 14,2010

12 | P a g e

Use Case Template 5:

Use Case Name: Request Meal DeliveryCreated By: Olla Ashour Last Updated By: Olla AshourDate Created: 10th Jan 2010 Date Last Updated: 18th Jan 2010Actors: EmployeeDescription: An employee accesses the Cafeteria Ordering System from the corporate

intranet or from home, orders meal, then optionally requests for meal to be delivered at a certain time and location.

Preconditions: 1. Employee is logged into COS.2. Employee has ordered food either through daily menu or weekly

order plan.Post conditions: 1. Remaining delivery capacity for the requested time window is

updated to reflect this delivery request.Normal Flow: 1.0 Request Meal Delivery

1. System displays available delivery times for the delivery date.2. Employee selects a delivery time and specifies the delivery location.3. Employee specifies payment method.4. System confirms acceptance of the order.5. System sends Employee an e-mail confirming order details, price,

and delivery instructions.6. System stores order in database, sends e-mail to notify Cafeteria

Staff, sends food item information to Cafeteria Inventory System, and updates available delivery times.

Alternative Flows: 1.Exceptions: 1.0.E.1 Current time is after order cutoff time (at step 1)

1. System informs Employee that it’s too late to place an order for today.2a. Employee cancels the meal order.2b. System terminates use case.3a. Employee requests to select another date.3b. System restarts use case.

1.0.E.2 No delivery times left (at step 1)1. System informs Patron that no delivery times are available for the

meal date.2a. Patron cancels the meal order.2b. System terminates use case.3. Employee requests to pick the order up at the cafeteria (skip steps 1-

3).

Includes: NonePriority: HighBusiness Rules: BR-1, BR-2, BR-3, BR-4, BR-5, BR-11, BR-12, BR-13

Special Requirements:

1. Employee shall be able to cancel the meal order at any time prior to confirming the order.

2. Employee can request for delivery instead of him pick up the meal as

13 | P a g e

long as it’s not peak hour.3. Employee can cancel/change meal at any time as long as status of the

meal is not prepared otherwise he can’t cancel or change order.4. If Delivery time exceeds 30 minutes, employee has right to cancel

order.Assumptions: 1. Assume that 45% percent of Employees will request for delivery.Notes and Issues: 1. The default date is the current date if the Employee is using the

system before today’s order cutoff time. Otherwise, the default date is the next day that the cafeteria is open.

2. If Patron doesn’t want to have the meal delivered, the precondition requiring registration for payroll deduction is not applicable.

3. Peak usage load for this use case is between 8:00am and 10:00am local time, and 12:00-2:00pm.

14 | P a g e

Use Case Template 6:

Name: Ordering online meals from Impact Process Cafeteria online website

Description/Summary: The Impact Process employee feels hungry. He submits his order. His order’s placed in the system.

Actors: Impact Process employees Cafeteria System

Triggers: The employee has an Impact Process ID The system validates the employees ID and

passwordPre-Conditions: The employee decides to see what he’s having for lunch and

when he chooses his meal he submits his order.

Successful Path/ Basic course of events:

18. The employee goes onto the cafeteria’s online website.

19. Employee inserts his Impact Process ID and password in the cafeteria’s online log in form

20. The systems checks if the ID and password are correct.

21. After ID and password are validated the employee is logged into the main website.

22. The system displays options for the user to choose from.

23. The customer chooses whether he wants to make a weekly plan or if he wants to make one order for the day.

24. The customer chooses his meal/weekly meals.25. Employee then chooses his way of payment and

delivery.26. Employee finally submits and confirms his order27. System then send the employee’s order to the

cafeteria 28. Cafeteria staffs checks the order and start preparing

meals and arranging their deliveryAlternative Path: 1. Employee goes to the cafeteria to place his order

2. Employee decides to have lunch from local restaurants 3. Employee brings his lunch with him from home

Post-Conditions: 1. Customer is notified of the transaction2. System sends order to cafeteria.

Assumptions: noneExceptions: User name and password are invalidated

System prompts the user to re-enter his username and password

Author: Shaimaa AhmedDate: 8th January,2010

15 | P a g e

Software Requirements Specification

1. Introduction

1.1 Purpose

This Document describes the Requirements needed for the Cafeteria Ordering System to work. It describes the Functional, Non-Functional, and Performance Requirements. It also illustrates Design Constraints and Quality Attributes. This document is intended for designers to know what the system must do so they can ultimately build and implement it.

1.2 Project Scope and Product Features

The Purpose of the Cafeteria Ordering System is to allow employees at Process Impact to order meals on-line whether from the cafeteria or from local restaurants, to be delivered to a designated company location at a specified time and date.

The objective of the Cafeteria Ordering System is save those employees who use the service considerable time and it would increase the chance of them getting the food items they prefer. It is meant to both benefit the employee and the cafeteria.

It also relates to company policy at Process Impact for Full Benefits to Employee’s, allowing them to enjoy their work. Also in the process of saving the 90 minute-60 minute for lunch, more time is allocated for employees to finish their work and thus increasing productivity at Process Impact. Refer to Vision and Scope document for more details. The section in that document titled “Scope of Initial and Subsequent Releases” lists the features that are scheduled for full or partial implementation in this release.

1.3 References

1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope Document, www.processimpact.com/projects/COS/COS_vision_and_scope.doc

2. Process Impact Templates, srs_template.doc3. Final Document For CLS Proposal Submission Website4. Software Requirements Specification for RIT Peer Evaluation System5. Introduction to Systems Analysis and Design, Whitten and Bentley, McGraw-Hill

International Edition.

2. Overall Description

2.1 Product Perspective

The Cafeteria Ordering System is a system to be built to replace and enhance the old manual existing system of Employee’s walking to the cafeteria to select, purchase, their lunch or going offsite for any meal at any time a day. So it is basically a new self

16 | P a g e

contained product. The COS is to evolve on several releases, subsequently later on connecting the system online to local restaurants.

2.2 User Classes and Characteristics

User Class Description

Employee (Favored) Is a process Impact Employee. There are at least 500 Employees at the Company. At Least 450 of them order lunch, they will use the Cafeteria ordering System an average of 4 times per week each (source: current cafeteria usage data). Employees will want to order multiple meals for groups and events. They will also like to pre-order meals. Some Employees may request special meals not available on the menu at special prices. Some Employee’s will wish to set up meal subscriptions, either to have the same meal to be delivered every day or to have the day’s meal special delivered automatically. Employees may also require their meals in a certain way at an extra charge. Employees should be able to over ride (whether to change meal or cancel order) at least two hours before. Also Employees would like to be able to see the menu for following days in case of events or such.

The Employees should be able to access and Order through the Company’s Intranet from their offices. They should be only able to view the Menu through the Internet at anytime.

Most of the Users have strong technical skills in using computers and ordering online but regardless, a leaflet will be distributed among the staff upon launch of the system.

Cafeteria Staff The Process Impact cafeteria currently employs about 20 Cafeteria Staff, who will receive orders from the Cafeteria Ordering System, prepare meals, and package them for delivery, print delivery instructions, and request delivery .There will be Staff who are in charge of each respective task.Some in charge of only receiving and writing down orders from the system, other for preparing meals, and other for packaging them and others for writing delivery instructions.Each Order will have an order and deliver ID for Staff ease of use .

Most of the Cafeteria Staff will need to be trained in the use of the computer, the Web browser, and the Cafeteria Ordering System.

Delivery Person(s) As the Cafeteria Staff prepare orders for delivery, they will print delivery instructions and issue delivery requests to the Delivery Person, who is a contractor whose main job is only to deliver

17 | P a g e

User Class Description

meals. The Delivery person will pick up the food and delivery instructions for each meal and deliver it to the Employee. For Staff Simplicity, meals will be delivered only on hourly basis, several meals at the same time, The Delivery Person primary interactions with the system will be to reprint the delivery instructions on occasion and to confirm that a meal was (or was not) delivered. There will be 5 Delivery Persons.

Cafeteria Manager The Cafeteria manager is responsible for establishing and maintaining daily menus of the food items available from the cafeteria and the times of day that each item is available. Some menu items may not be available for delivery. The Menu Manager will also define the cafeteria’s daily specials. The Menu Manager will need to edit the menus periodically to reflect planned food items that are not available or price changes. Also he will be responsible for ordering food items based on the most meal requested, making sure that food items don’t run out for the daily menu meals. He will have full access privilege and has strong technical skills.

System Manager Is responsible for updating and maintaining the Cafeteria Ordering System. Also in case of troubleshoot and too much traffic on the server.

2.3 Operating Environment

OE-1: The Cafeteria Ordering System shall operate with the following Web browsers: Internet Explorer, Opera, Safari, Mozilla Firefox, and Google Chrome.

OE-2: Should be able to work on Unix, Linux, Apple and Microsoft Platforms.

OE-3: The Cafeteria Ordering System shall permit user access from the Companies Intranet and if a user is authorized for outside access, then from anywhere through the Internet.

2.4 Design and Implementation Constraints

CO-1: The system’s design, code, and maintenance documentation shall conform to the Process Impact Intranet Development Standards.

CO-2: The System Should you the Current Existing Oracle Database.

CO-3: All HTML code shall conform to the HTML 4.0 standard.

CO-4: All Scripts will be written in PHP and MySQL for any database

18 | P a g e

modifications.

CO-5 The System should be available in several languages, as not all users speak English. It should be available in Arabic, English and Spanish.

CO-6 Process Impact will not be responsible for maintaining the system, it would have to be maintained by the Cafeteria Staff.

2.5 User Documentation

UD-1: The Cafeteria Ordering System shall have an online help to be accessed at any time through the system that describes and illustrates all system functions.

UD-2: The first time a new user accesses the system and on user demand thereafter, the system shall provide an online tutorial to allow users to practice ordering meals.

UD-3 Leaflets would also be distributed among all employees.

UD-4 A User Manual will be distributed among the Cafeteria Staff for step by step use.

2.6 Assumptions and Dependencies

AS-1: The cafeteria is open for breakfast, lunch, and dinner every company business day in which employees are expected to be on site.

AS-2: Process Impact will be the one to design the Cafeteria Ordering System, but it would not be in charge of maintaining it.

AS-3 Employees would use the system for at least 4 days a week.

AS-4 There will be an estimate of 450 Employee’s using the system.

As-5 Special Events and Weekend Meals are chosen from Local Restaurants which have their own website and have no relation with COS except provide links to website and discount for process Impact Employees.

DE-1: The operation of the COS depends on changes being made in the Payroll System to accept payment requests for meals ordered with the COS.

DE-2: The operation of the COS depends on changes being made in the Cafeteria Inventory System to update the availability of food items as COS orders are accepted.

DE-3: An Employee cannot use payroll deduction as a payment method unless there exists at least 50% of the salary.

3. System Features

19 | P a g e

3.1 Feature (1)

Order meals

3.1.1 Description and Priority

Clients have the ability to order meals either to a specific company location or to be prepared for them where they can go and get it from the cafeteria.

Also they have the ability to change or cancel meals that are not yet prepared.

3.1.2 Stimulus/Response Sequences

Stimulus: User requests to order one or more order

Response: System inform user by details of meals, their costs, and time for delivery

Stimulus: User requests to change one or more order

Response: If status is accepted (meal is not prepared yet) System allow user to edit previous order

Stimulus: User requests to delete one or more order

Response: If status is accepted (meal is not prepared yet) System deletes user's meal order

3.1.3 Functional Requirements

F.R1: Order meal.

F.R2: Change meal.

F.R3: Cancel meal.

3.1 Feature (2)

Payment

3.1.1 Description and Priority

When client specify certain quantity and then confirm order they will be able to see how much will they pay and choose between different methods of payment.

3.1.2 Stimulus/Response Sequences

Stimulus: User specify quantity of order they will have

Response: System save quantity and ask user to confirm order

20 | P a g e

Stimulus: User confirm order

Response: System specify the amount of dollars he will pay

Stimulus: System displays three methods of payment.

Response: User chooses the payment method he wants.

3.1.3 Functional Requirements

F.R1: Specify quantity.

F.R2: Confirm order.

F.R3: Choose payment method.

4. External Interface Requirements

4.1 User Interfaces

UI-1: *The home page of the Cafeteria Ordering System shall provide buttons for selection (view menu, Do weekly plan, Local restaurant, Exit)

*If user chooses view menu, menu is viewed, and an Order meal button is displayed to allow user to order meal.

-If user chooses Order meal, system provides quantity button to enable user to choose quantity of food items, and item button to choose food item.

*If user chooses Do weekly plan button, a set weekly plan button is displayed that allow user to set his weekly plan.

*If user chooses Local restaurant button website links are displayed for user to choose the restaurant he wants.

*If user chooses exit button the web page is closed.

UI-2: The system should provide a return to home button is to enable user to return to home page at each page.

The system shall provide a help link from each page to explain how to use that page.

UI-3: The Web pages shall permit complete navigation also selection can be using the keyboard alone, in addition to using mouse and keyboard combinations.

4.2 Hardware Interfaces

-None

4.3 Software Interfaces

SI-1: Cafeteria inventory system

21 | P a g e

-COS shall communicate with CIS through a programmatically interface to do following operations:

SI-1.1: -Cafeteria ordering system shall inform whether food items ordered is present or not in cafeteria inventory system.

SI-1.2: -If items ordered is present cafeteria ordering system must inform cafeteria inventory system that this item will be delivered to customer.

SI-1.3: -If item ordered is not present cafeteria ordering system must inform cafeteria inventory system that this item is not found so that the COS remove that item for current date.

SI-2: Sales order

-COS shall communicate with Sales order system through a programmatically interface to do following operations:

SI-2.1: Save what each user buys.

SI-2.2: Save items and quantities bought.

SI-2.3: Calculate profits from each order.

SI-2.4: Calculate total number of profits

SI-3: Payroll system

-COS shall communicate with Payroll through a programmatically interface to do following operations:

SI-3.1: Allow a user to register for payroll deduction.

SI-3.2: Allow a user to unregister for payroll deduction

SI-3.3: Check whether a user is registered for payroll deduction.

SI-3.4: Submit a payment request for a purchased meal.

SI-3.5: Reverse all or part of customers money because customer deleted or changed a meal, or because the meal was not delivered per the specific delivery time.

4.4 Communications Interfaces

CI-1: When accepting order cafeteria shall send user an email to conform that they accepted his order

CI-2: If there is any problems cafeteria shall send user an email about this problem and suggest how to solve it

5. Other Nonfunctional Requirements

5.1 Performance Requirements

22 | P a g e

PE-1: The system sends a conformation email within 15 seconds of placing the order

PE-2: The system can handle up to 500 users during official work hours from 8:00 am to 6:00 pm

PE-3: When clicking on any link the system responds within 2 seconds

PE-4: The system validates the employees credit card within 10 sec

5.2 Safety Requirements

SE-1: All food must come pass food tests.

SE-2: Food can only be bought from quality assessed companies.

SE-3: No Sick cafeteria staff would prepare meals.

SE-4: Each Cafeteria Staff who handles food must have gloves on.

5.3 Security Requirements

SE-1: All transactions that include personal or financial information are encrypted

SE-2: Cafeteria staff members are the only people authorized to alter the cafeteria menus

SE-3: Logging in is required for placing orders

SE-4: Each employee is given a user name and password

5.4 Software Quality Attributes

Availability-1: The system is available for usage 24 hours a day, 7 days a week.

Robustness-1: Not only should the system work in a correct way in each situation, it should also resist against any possible user-misbehavior or error in its surroundings.

Appendix A: Data Dictionary and Data Model

Data Dictionary

23 | P a g e

User Name = *Employee ID given by Process Impact, 12 Character String* Password = *secret system access code, 8 character String* Weekly Order Plan = * Week Order plan decided by employee*

+ Day, 10 character string + Meals, Varchar(200)

+ Delivery Instruction Menu = Meal name

+ Meal price+Meal Category

+Meal Description Meal Name = * Name of meal, maximum of 50 characters* Meal Description = *Text Description of the meal, maximum of 200 characters* Meal Price = *Describes the price of each meal, maximum of 4 characters* Meal Category = *describes the type of the meal* Delivery Instruction =

* Location and Time of where Employee would like meal to be delivered*+ Employee Name+Employee Location

+Employee Phone Number+Delivery Date

+Delivery Time Employee = + Employee Name

+ Employee ID + Employee Location

+ Employee Email + Employee Phone Number

Employee Name = * States the name of the employee to which the meal will be delivered, 24 Characters*

Employee Id = *Unique Identification Number of Employee* Employee Location = *The Employee office number, maximum of 12 character

string* Employee Email = * Email Address of the Employee, 50 character string* Employee Phone Number = *An Integer Data Type that states the phone number

of the employee* Delivery Date = *The date for the meal to be delivered, its put in a date format,

MM/DD/YYYY* Delivery time= *Time for the meal to be delivered, in HH:MM time format* Order = *Describes Employee Order*

+Order Status+Order Date

+Order Time

24 | P a g e

+Meals+Delivery Instructions

Order Date = * Date of which the order was placed, in date format MM/DD/YYYY*

Order Time = *Time of which Meal order was placed in HH:MM time format* Meal Price = * States the total Price of the Meal and method to pay*

+ Total Price + Payment Method

Total Price = * Float Data Type that states the total price of the meal inclusive of 5% tax*

Payment Method = * Means of which the Employee will pay for meal* + Cash Payment

+ Credit Card Payment + Salary Deduction Payment

Credit Card Payment = + Credit Card Type + Card Issue Date

+ Card Expiry Date Salary Deduction Payment = + Employee ID

+ Password

Data Model

Entity-Relationship Diagram:

25 | P a g e

Appendix B: Analysis Models

1. State Chart Diagram for Employee Order Request

26 | P a g e

2. Decision Treea. Decision Tree for Cafeteria Staff Prepare meal and Print delivery

Instructions.

27 | P a g e

3. Activity Diagram

28 | P a g e

Appendix C: Business Rules29 | P a g e

ID Rule Definition Type of Rule Static or Dynamic

Source

BR-1 Users cannot order unless they are employees.

Constraint Static Cafeteria Manager

BR-2 For each customer there must be at least 2 hours between each order.

Constraint Static Cafeteria Manager

BR-3 A customer cannot order more than 3 times a day.

Constraint Static Cafeteria Manager

BR-4 Daily orders must be between 8:30 am and 5 pm.

Constraint Static Cafeteria Manager

BR-5 Session will expire after 15 minutes idle time.

Fact Static Cafeteria Manager

BR-6 Order price is calculated as total price + 3% tax and 2% delivery charge.

Computation Dynamic Cafeteria policy

BR-7 Only menu manager can edit and establish menus.

Constraint Static Cafeteria policy

BR-8 Only full time employees choose payroll deduction as a payment method.

Constraint Static Accounting Manager

BR-9 An employee cannot use payroll deduction unless there exists 50% of his salary.

Constraint Dynamic Human resource manager

BR-10 A customer can only order meals that are available in the inventory.

Fact Static Cafeteria Manager

BR-11 A customer can delete his order if delivery time exceeds half an hour.

Constraint Dynamic Human resource manager

BR-12 Special event meals must be ordered before hand with at least one week.

Constraint Static Cafeteria Manager

BR-13 Customer cannot change or cancel meal if it’s already prepared.

Constraint Static Cafeteria Manager

Appendix D: Task Distribution

Project Tasks Group Member Name Notes

30 | P a g e

Vision and Scope Document1.Business Requirements Shaimaa2.Vision of Solution Hoda3.Scope and Limitations Marwa4.Business Context Hoda

Use CasesUse Case Diagram All of UsUse Case Template 1 AyaUse Case Template 2 HodaUse Case Template 3 MarwaUse Case Template 4 MarwaUse Case Template 5 OllaUse Case Template 6 Shaimaa

Software Requirements and Specification1. Introduction Olla2.Overall Description Olla3.System Features Aya4.External Interface Requirements Aya5.Other Nonfunctional Requirements Shaimaa

Appendix AData Dictionary Hoda

Marwa Olla Shaimaa

Data Model: ERD AyaAppendix B: Analysis Models

State chart Diagram Hoda Marwa Olla Shaimaa

Decision Tree Aya Olla

Activity Diagram Aya Olla

Prototype Hoda Marwa Shaimaa

Power Point Presentation Aya Olla

Final Report Documentation Olla

31 | P a g e