The document provides details about the Virtual Waiter app project including team members, contents, proposal, feasibility analysis, benchmark products, comparison of features, diagrams (context, data flow, activity, use case), use case descriptions, and references. The app will allow customers to browse menus, order food, pay bills and provide reviews on an Android device, while also allowing management to update menus, generate reports, and maintain the system through a desktop app. It compares Virtual Waiter favorably to other menu apps in terms of features.

1. Virtual Waiter
1

2. TEAM MEMBERS
 Rafid Asrar Prottoy
ID : 011 132 124
 Amit Ghosh
ID : 011 132 134
 Hamudi Hasan Sonet
ID : 011 132 033
2

3. TABLE OF CONTENTS
 Project proposal
 Feasibility Analysis
 Benchmark products
 Comparison
 Features
 Context Diagram
 Data flow diagram
 Activity Diagram
 Use case Diagram
 Use case Description
 Visualization
 References
3

4. PROJECT PROPOSAL
Visualize the restaurant menu according to your
restaurant that evokes the brand and introduces your
menus in the most interactive manner with an Android
App. We offers robust features that not only help your
restaurant to update the menu anytime but also
improves the overall dining experience.
 Make lasting connections with customers that drive revenue and
profitability .
4

5. FEASIBILITY ANALYSIS
• Over 189
Restaurants in
Dhaka City
• 8.2 millions Smart
Phone User In
Bangladesh (2015)
5

6. BENCHMARK PRODUCTS
eZee iMenu
DynaMenu
Restro
Signage live
Mvix digital
6

7. eZee iMenu
7

8. DynaMenu
8

9. Restro
• Operation Management anytime, anywhere.
• Stun your guests not only with stylish and beautiful
menus, but also entice them with Wine/Food selectors
9

10. Signage live
• VIDEO BACKGROUNDS BRING DIGITAL MENU BOARDS TO LIFE
• ADD AN IMAGE OVERLAY WITH TRANSPARENT SECTIONS TO
ALLOW YOUR VIDEO TO SHINE THROUGH
• SCHEDULE DIGITAL MENUS TO CHANGE AT THE SAME TIME
YOU DO
10

11. Mvix digital
• Increase sales by maximizing upsell opportunity and ensuring daily specials
have a prominent place on the menu.
• Improve ambiance by providing integrated music and visuals that can be
controlled remotely.
• Entertain patrons while they wait for their food.
• Green friendly — eliminate printing costs.
• Manage and update menu items and prices.
• Display different menus at different times of the day.
11

12. Comparison
NO.
Features eZee
iMenu
Dyna
Menu
Amazing
orders
Restro Signage
live
Mvi
x
digit
al
V.A
Virtual
Waiter
1. E-Manu System        
2. Fully Customizable        
3. Auto Generated Billing        
4. Analytics
       
5. Social Media Sharing
       
6. Order to kitchen directly
       
7. Music and Visuals
       
12

13. Comparison (Continue …)
NO.
Features eZee
iMenu
Dyna
Menu
Amazing
orders
Restro Signage
live
Mvi
x
digit
al
V.A
Virtual
Waiter
8. Promote specials items        
9. Highlight hot offers        
10. Bill include Vat And Tax        
11. Operation Management
anytime        
12. Stylish and Beautiful
       
13. Foods details with image
       
14. Scheduling orders
       
13

14. Comparison (Continue …)
NO.
Features eZee
iMenu
Dyna
Menu
Amazing
orders
Restro Signage
live
Mvix
digital
V.A Virtual
Waiter
15. Daily Offers        
16. Daily discounts        
17. Bill include Vat And Tax        
18. Keep logs
       
19. Credit or debit card payment
       
20. Central Desktop App
       
21 User and Time based Food
suggestion
       
14

15. Comparison (Continue …)
NO.
Features eZee
iMenu
Dyna
Menu
Amazing
orders
Restro Signage
live
Mvi
x
digit
al
V.A
Virtual
Waiter
22. Order cancelation        
23. Online backup database        
24. Food Review and Rating        
25. Auto Generated offer coupon
       
15

16. Features
 Android Application
 Desktop Application
16

17. 1. Simple, easy to use and user friendly.
2. Tablet Based E-Menu System.
3. Order Easily.
4. Dynamic Menu Pricing.
5. Order Directly to kitchen.
6. Fully Customizable.
7. Highlight daily or limited hot offers.
8. Easy to Manage and update the system
anytime.
9. Auto Generated Billing system.
10.App Based Payment System.
11.App Based Review and Rating
systems.
12.Social Media Sharing.
Android Application
17

18. 1. Received order details.
2. Store order details.
3. Generate bill slip.
4. Generate Reports (Daily /Monthly /Yearly).
5. Send daily report to Owner via Email.
6. Delete, Update, Edit any kind of Order or
Menu.
Desktop Application Features
18

19. Context Diagram
19

20. 20

21. Data Flow Diagrams
21

22. 22

23. Activity Diagram
23

24. 24

25. Use Case Diagram
25

26. 26

27. Use Case Description
27

28. Use Case Number : 1
Use Case Name: Order Food
Primary Actor: Customer
Interest:
Customer: Browse Menu and order food with
quantity .
Precondition:
1. Menu item will be visible with price of items.
2. Device will be set-up by management.
3. Configure the device by management.
28

29. Success Scenario:
1.Menu will show with menu item to the
customer .
2.Customer will order from items.
3. Order will go to the kitchen.
Alternate Scenario:
1.Wifi connection will be lost
1.a: Reconnect
2.If customer wants to change the order
2.a:Will change the order .
29

30. Post-Condition:
1.Order is went to the Kitchen.
2.Oerder details is shown to the
customer.
3. Inventory updated.
4. Tax is correctly calculated.
30

31. Use Case Number : 2
Use Case Name: Payment System
Primary Actor: Customer
Interest:
Manager: Generate the bill properly.
Customer : Get the accurate bill.
Waiter: Take the bill to the customer
Precondition:
1. Correctly generated bill with service charge and
tax.
2. Sent the bill to proper customer.
31

32. Success Scenario:
1.Bill will successfully generated .
2.Send the bill to the customer .
3. Received the payment by card or cash .
Alternate Scenario:
1.If bill has printing mistakes
1.a: Generate bill again
2.If card has payment error
2.a: Request to pay in cash
32

33. Post-Condition:
1.Bill is received.
2.Inventory updated.
3.Tax is correctly calculated.
33

34. Use Case Number: 3
Use Case Name: Serve food
Primary Actor: Waiter
Interest:
Customer : Get the food in minimum time .
Waiter: Take the food to the customer when the food
is ready to serve in minimum time
Precondition:
1. Take the food from kitchen timely.
2. Take correct food to the correct customer.
34

35. Success Scenario:
1. Chef will call the waiter when food is ready.
2. Take the food from kitchen when the food is
ready to serve to the customer .
3. Serve correct food to the correct customer.
Alternate Scenario:
1.Chef make any mistake to make the food.
1.a: Make the food again
2.Waiter take food to the wrong customer.
2.a:Serve correct food to the customer.
35

36. Post-Condition:
1.Food is Made correctly.
2.Served the food to customer.
3.Bill is correctly calculated.
4.Tax is correctly calculated.
36

37. Use Case Number: 4
Use Case Name: Cook Food
Primary Actor: Chef
Interest:
Chef: Make the food correctly and in
minimum time
Customer :Get the food in minimum time .
Waiter: Take the food from the chef and serve in
minimum time
Precondition:
1. Give the correct food order.
2. Receive the order and make food correctly .
37

38. Success Scenario:
1. Chef will receive the order in the kitchen.
2. After receiving the order chef will start
making the food.
3.After making chef will call the waiter to serve
it.
Alternate Scenario:
1.Chef make any mistake to make the food.
1.a: Make the food again
2.Comunication problem of the system.
2.a:Solve the problem and order again.
38

39. Post-Condition:
1.Order is received.
2.Food is Made by chef.
39

40. Use Case Number: 5
Use Case Name: Maintenance
Primary Actor: Developer
Interest:
Developer: Make the system error free and
maintain the system properly and take
payment.
Manager : If the system shows any problem then
manager will call the developer to fixed
that give the payment properly.
Precondition:
1. Deploy the system properly and try to make
error free.
2. Make agreement with developer for maintaining
the system .
40

41. Success Scenario:
1.System will run properly and smoothly.
Alternate Scenario:
1.System shows any error .
1.a: Manager call the developer and
developer fix the problem.
Post-Condition:
1.System is updated.
2.Developer get the payment.
41

42. Visualization
42

43. 43

45. 45

46. 46

47. 47

48. 48

49. 49

50. 50
Desktop Application

51. 51
LAB -7

52. TABLE OF CONTENTS
 User Interface and It’s Golden Rules
 Entity Relationship Diagram
 State Diagram
 Class Diagram
 Sequence Diagram

53. USER INTERFACE

55. USER INTERFACE
Definition : In information technology, the user interface (UI) is
everything designed into an information device with which a
human being may interact .
Including : Display screen, keyboard, mouse, light pen, the
appearance of a desktop, illuminated characters, help messages,
and how an application program or a Web site invites
interaction and responds to it.

56. 3 GOLDEN RULES OF USER
INTERFACE
 Place Users in Control
 Reduce Users’ Memory Load
 Make the Interface Consistent

57. PLACE USERS IN CONTROL
 Provide flexible interaction.
 Allow user interaction to be interruptible and undoable.

58. PROVIDE FLEXIBLE
INTERACTION.

59. INTERRUPTIBLE AND
UNDOABLE INTERACTION

60. PLACE USERS IN
CONTROL
 Hide technical internals from the casual user.
 Direct interaction with objects that appear on the screen.

61. REDUCE USERS’ MEMORY
LOAD
 Reduce demand on short-term memory.
 Establish meaningful defaults.
 Define shortcuts that are intuitive.
 The visual layout of the interface should be based on a real-world
metaphor.
 Disclose information in a progressive fashion.

62. ESTABLISH MEANINGFUL
DEFAULTS.

63. DEFINE
SHORTCUTS
THAT ARE
INTUITIVE.

64. DISCLOSE INFORMATION IN A
PROGRESSIVE FASHION.

65. MAKE THE INTERFACE
CONSISTENT
 Allow the user to put the current task into a meaningful
context.
 Maintain consistency across a family of applications.
 If past interactive models have created user expectations, do
not make changes unless there is a compelling reason to do so.

66. MAKE THE
INTERFACE
CONSISTENT
 Drawer on every Page.
 Visible Cart .
 Same Header and footer
 Same Settings on Every Page.

67. DESKTOP USER
INTERFACE

68. ENTITY RELATIONSHIP
DIAGRAM

69.  Definition:
An entity relationship diagram (ERD)
shows the relationships of entity sets stored in a
database. An entity in this context is a component of
data. In other words, ER diagrams illustrate the
logical structure of databases.

70. Entity
Weak
Entity
Relationsh
ip

71. Attribute
Multivalue
d Attribute
Derived
Attribute

72. ERD of Virtual Waiter

74. STATE DIAGRAM

75. STATE DIAGRAM
Definition: A state diagram is a diagram used in computer science to
describe the behavior of a system considering all the possible states of
an object when an event occurs. Sometimes it's also known as a Harel
state chart or a state machine diagram

76. BASIC SYMBOLS AND
NOTATIONS
State A Simple state
State
Activity
/Method
s
A state with
Internal Activity

77. BASIC SYMBOLS AND
NOTATIONS
Transition
Initial State/
Starting point
Final State

78. BASIC SYMBOLS AND
NOTATIONS
State 1
State 2
Fork

79. BASIC SYMBOLS AND
NOTATIONS
State 1
State 2
Join
State 3

80. STEPS TO DRAW A STATE
DIAGRAM
Step 1 : Define States
Step 2 : Describe States
Step 3 : Draw Transitions
Step 4 : Define Transition Triggers
Step 5 : Define Guard Conditions

81. STEP 1 : DEFINE STATES
#Condition
#Situation
A state is a condition or situation an object might be in during
it’s life time in a system.
State

82. STEP 2: DESCRIBE STATES
 Give the information of the state what it will do
//When a new open
Account
With
funds

83. STEP 3: DRAW
TRANSITIONS
 We draw a directed line to
Indicate a change to one state
To another
State 1
State 2

84. STEP 4 : DEFINE TRANSITION
TRIGGERS
 We will specify what is to happen
In that transition
Ask for PIN
Number
INSERT Card

85. STEP 5: DEFINE GUARD
CONDITIONS
User Account
Zero Balance
 We will give a condition to go
one state to another. If condition
become true then go to next state.
If(Balance==0)

86. STATE DIAGRAM EXAMPLE

87. STATE DIAGRAM
idle
Show
Men
u
Start app
Given
order
Bill
generato
r
Kitche
n
Waiter
Customer
Ready food
Calculated bill
Serve
foodGive bill
Verificatio
n
If pay in card
Take
Payment
Verification complete
Cash pay
Card failure
Or other problem
Cash pay
If pay in cash
Rating
food
Social
media
Shearing
If want to rate the food
If want to make social
media shearing

88. CLASS DIAGRAM

89. CLASS DIAGRAM
 Graphical way to illustrate relationship between classes in an
object oriented system
 Appearance varies between different drawing tools
 Describe responsibilities of a system.
 Base for component and deployment diagrams.

90. CLASSES
 Represented by a box
 In the simplest case , a class might be a box
with the name of the class included within it Hello UIU

91. CLASS FIELDS
 Fields ( data members ) of a class
added to the box between two lines
 First character in the field name
gives scope
o +for public
o - for private
Hello UIU
Message : SAD LAB

92. METHODS
 Methods ( member functions) go below
the class fields section
 Same scoping and typing conventions
used
- Actual semantics vary from tool to
tool
Hello UIU
Message : SAD LAB
+setMessage( m : SAD LAB)
+getMessage (): SAD LAB
+ display ()
+HelloWorld() – constructor

93. RELATIONSHIPS
BETWEEN CLASSES Drawn using arrows to connect classes together
-Two Categories of this Relations :
1. Generalization : Can represent relationships between the classes
themselves.
2. Association : Can represent relationships between instances of the
classes
 Multiplicity :
- Specific number ( e.g. 1)
- Range of numbers , separated by two dots (e.g. 0..1)
-Unbounded ranges ( e.g. 0..* or 1..*)

94. GENERALIZATION (
INHERITANCE) Shows “is-a” relationship between
classes
 Used for languages that supports
inheritance
 Child Class is a subclass of parent
class
Message
-text : String = “SAD LAB”
+getMessage(): String
SimpleMessage
+SimpleMessage (s: String)

95. AGGREGATION
 Weak type of : has a “ relationship
 One class contains a collection of
instances of other classes
 Key Idea : the instances of the
other class can exist independently
of the collection
MultiMessage
Message: List<Message>
+addMessage(m :Message)
SimpleMessage
+SimpleMessage (s: String)

96. 96
Any Question ?