Arab Academy for Science, Technology and Maritime Transport

College of Computing and Information Technology

Department 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|Page
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 models

o Data dictionary

 Business rules

 A suitable prototype for the system

Project Deliverables:

Deliverable Due Date

Project Draft January 5th

2|Page
Final Project January 18th
Prototype & presentation of the project January 18th

Table of Contents
Table of Contents...........................................................................................................................ii
Vision and Scope Document
1. Business Requiremnets.........................................................................................................4-5
1.1 Background,Business Opportunity and Customer needs.................................................................4
1.2 Business Objectives and Success Criteria.......................................................................................4
1.3 Business Risks................................................................................................................................5
2. Vision of Solution.....................................................................................................................5
2.1 Vision Statement.............................................................................................................................5
2.2 Assumptions and Dependencies......................................................................................................5
3. Scope and Limitations.............................................................................................................6
3.1 Scope of Initial and Subsequent Release.........................................................................................6
3.2 Limitations and Exculsions............................................................................................................6
4. Business Context...................................................................................................................6-7
4.1 Stakeholder Profiles........................................................................................................................6
4.2 Project Priorities.............................................................................................................................7
Use Cases...................................................................................................................................9-15
1.1 Use Case Diagram..........................................................................................................................9
1.2 Use Case Templates.................................................................................................................10-15
Software Requirements and Specification
1. Introduction............................................................................................................................16
1.1 Purpose.........................................................................................................................................16
1.2 Project Scope and Product Features..............................................................................................16
1.3 References....................................................................................................................................16
2. Overall Description...........................................................................................................16-19
2.1 Product Perspective.......................................................................................................................17
2.2 User Classes and Characteristics...................................................................................................17
2.3 Operating Environment.................................................................................................................18
2.4 Design and Implementation Constraints.......................................................................................18
2.5 User Documentation.....................................................................................................................19
2.6 Assumptions and Dependencies....................................................................................................19
3. System Features................................................................................................................20-21
3.1 Feature 1.......................................................................................................................................20
3.1 Feature 2..................................................................................................................................20-21
4. External Interface Requirements1..................................................................................21-22
4.1 User Interfaces..............................................................................................................................21
4.2 Hardware Interfaces......................................................................................................................21
4.3 Software Interfaces.......................................................................................................................22
4.4 Communications Interfaces...........................................................................................................22
5. Other Nonfunctional Requirements.....................................................................................23
5.1 Performance Requirements...........................................................................................................23
5.2 Safety Requirements.....................................................................................................................23
5.3 Security Requirements..................................................................................................................23
5.4 Software Quality Attributes..........................................................................................................23
Appendix A: Data Dictionary and Data Model...................................................................24-26

3|Page
Appendix B: Analysis Models................................................................................................27-29
Appendix C: Business Rules.......................................................................................................30
Appendix D: Task Distribution..................................................................................................31

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

4|Page
BO-4: Ability to order and pay for the meals online
SC-1: Cafeteria makes more profit and gains more customers

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 system
RI-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.

5|Page
  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

3.1 Scope of Initial and Subsequent Releases

Feature Release 1 Release 2 Release 3

FE-1 Employees can order Price of employee’s Employees pay for
their meals online and orders are automatically their orders online by
pay cash on delivery or deducted from the salary credit or debit cards
checks when placing the order
FE-2 Customer orders meal as Customer can customize
is, no substitutions their order
FE-3 Customers place their Customers are given an
orders daily according to option to plan their
what is served in the weekly meals ahead of
cafeteria that day time
FE-4 Employees can only Employees can order
order from cafeteria’s their meals from other
menu 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 Constraints

Interests
Cafeteria Staff There is a more Concerns with Job Trainings for
efficient use of possible down preservation employees for

6|Page
Stakeholder Major Value Attitudes Major Constraints
Interests
staff , higher sizing internet usage,
customer delivery staff and
satisfaction the transportation
needed for
delivery.
Patrons Save time and Impressed with Easy to use and Access to the
effort, better the fast service the delivery is system intranet
food selection, and the saving reliable. whenever it is
clear menu to time. needed
choose from,
convenient.
Payroll Department Payment with Recognizes the No change in No problems
credit or value of the the payroll
payroll company and applications.
deduction employees.
(needed to be
set up)
Restaurant New marketing careful Responsible Concern if there's
Managers techniques to for delivery not enough staff.
gain new meals and
customers. costs.

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.

7|Page
Dimension Driver Constraint Degree of Freedom
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

Primary Actor Use Cases

Employee 1. Login and Verification
2. Select and Set Weekly Order Plan
3. Order Meals
4. Request Delivery
5. Choose Payment
Employee Database 6. Login and Verification
Delivery Person 7. Deliver Food
8. Pick up food and Delivery Instructions
Cafeteria Staff 9. Track Inventory Status
10. Receive Orders
11. Print Delivery Instructions
12. 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.

8|Page
Use Case Diagram

9|Page
10 | 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 1. The system asks user for user name and password.
course of events: 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).

11 | 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.

12 | P a g e
Use Case Template 2:

Name: Pick up food

Description/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 desires
6. 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 time
12. 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 assumptions
Exceptions: The cafeteria has many orders so pick up is delayed a
couple of minutes
Related Business Rules: Business rule 1 and 3
Author: Hoda Medhat Negm
Date: January 14,2010

13 | P a g e
Use Case Template 5:

Request Meal Delivery :Use Case Name

Olla Ashour Last Updated By: Olla Ashour :Created By
th
18 Jan 2010 Date Last Updated: 10th Jan 2010 :Date Created
Employee :Actors
An employee accesses the Cafeteria Ordering System from the corporate :Description
intranet or from home, orders meal, then optionally requests for meal to
be delivered at a certain time and location.
1. Employee is logged into COS. :Preconditions
2. Employee has ordered food either through daily menu or weekly
order plan.
1. Remaining delivery capacity for the requested time window is :Post conditions
updated to reflect this delivery request.
1.0 Request Meal Delivery :Normal Flow
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.
1. :Alternative Flows
1.0.E.1 Current time is after order cutoff time (at step 1) :Exceptions
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).

None :Includes
High :Priority
BR-1, BR-2, BR-3, BR-4, BR-5, BR-11, BR-12, BR-13 :Business Rules
1. Employee shall be able to cancel the meal order at any time prior to Special
confirming the order. :Requirements
2. Employee can request for delivery instead of him pick up the meal as
14 | 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.
1. Assume that 45% percent of Employees will request for delivery. :Assumptions
1. The default date is the current date if the Employee is using the :Notes and Issues
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.

15 | 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
password
Pre-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 18. The employee goes onto the cafeteria’s online
course of events: 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 order
27. System then send the employee’s order to the
cafeteria
28. Cafeteria staffs checks the order and start preparing
meals and arranging their delivery
Alternative 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 transaction
2. System sends order to cafeteria.
Assumptions: none
Exceptions:  User name and password are invalidated
 System prompts the user to re-enter his username
and password
Author: Shaimaa Ahmed
Date: 8th January,2010

16 | 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.doc
3. Final Document For CLS Proposal Submission Website
4. Software Requirements Specification for RIT Peer Evaluation System
5. 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
17 | 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

18 | 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

19 | 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
20 | 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

21 | 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

22 | 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

23 | 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

24 | 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
25 | P a g e
 +Order Time
+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:

26 | P a g e
Appendix B: Analysis Models
1. State Chart Diagram for Employee Order Request

27 | P a g e
2. Decision Tree
a. Decision Tree for Cafeteria Staff Prepare meal and Print delivery
Instructions.

28 | P a g e
3. Activity Diagram

29 | P a g e
Appendix C: Business Rules
30 | P a g e
ID Rule Definition Type of Rule Static or Source
Dynamic
BR-1 Users cannot order unless Constraint Static Cafeteria
they are employees. Manager
BR-2 For each customer there Constraint Static Cafeteria
must be at least 2 hours Manager
between each order.
BR-3 A customer cannot order Constraint Static Cafeteria
more than 3 times a day. Manager
BR-4 Daily orders must be Constraint Static Cafeteria
between 8:30 am and 5 pm. Manager
BR-5 Session will expire after 15 Fact Static Cafeteria
minutes idle time. Manager
BR-6 Order price is calculated as Computation Dynamic Cafeteria
total price + 3% tax and 2% policy
delivery charge.
BR-7 Only menu manager can edit Constraint Static Cafeteria
and establish menus. policy
BR-8 Only full time employees Constraint Static Accounting
choose payroll deduction as Manager
a payment method.
BR-9 An employee cannot use Constraint Dynamic Human
payroll deduction unless resource
there exists 50% of his manager
salary.
BR-10 A customer can only order Fact Static Cafeteria
meals that are available in Manager
the inventory.
BR-11 A customer can delete his Constraint Dynamic Human
order if delivery time resource
exceeds half an hour. manager
BR-12 Special event meals must be Constraint Static Cafeteria
ordered before hand with at Manager
least one week.
BR-13 Customer cannot change or Constraint Static Cafeteria
cancel meal if it’s already Manager
prepared.

Appendix D: Task Distribution

Project Tasks Group Member Name Notes

31 | P a g e
Vision and Scope Document
1.Business Requirements Shaimaa
2.Vision of Solution Hoda
3.Scope and Limitations Marwa
4.Business Context Hoda
Use Cases
Use Case Diagram All of Us
Use Case Template 1 Aya
Use Case Template 2 Hoda
Use Case Template 3 Marwa
Use Case Template 4 Marwa
Use Case Template 5 Olla
Use Case Template 6 Shaimaa
Software Requirements and Specification
1. Introduction Olla
2.Overall Description Olla
3.System Features Aya
4.External Interface Requirements Aya
5.Other Nonfunctional Requirements Shaimaa
Appendix A
Data Dictionary  Hoda
 Marwa
 Olla
 Shaimaa

Data Model: ERD Aya

Appendix 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

32 | P a g e