You are on page 1of 39

Restaurant Management System

Contents
.................................................................................................................................... 1 1. PROBLEM STATEMENT.............................................................................................4 2. SRS Document........................................................................................................ 7 4. USE CASE DESCRIPTION........................................................................................17 5. Interface Description.............................................................................................27 6. Problem Domain Object.........................................................................................30 7. Analysis Model.......................................................................................................32 8. Interface Diagrams................................................................................................34

Problem Statement for Restaurant Management System

1. PROBLEM STATEMENT
Prepare Use Case diagram for Restaurant Management System. Software has been developed for Restaurant Management System. The system should be stand alone in nature. It should be designed to provide functionality as explained below:1) Login a) The login functionality allows any staff member(manager, chef, waiter, cashier) to login in to the system. b) All the users have an authorized login id and unique password. For manager, the login_id would begin with M. For cashier, the login_id would begin with CA. For chef, the login_id would begin with C. For waiter, the login_id would begin with W. c) Each user id after login would enter the check duty function. d) The check duty function enables all the staff members to enter their check-in time and check-out time. e) If any user logins after 9:15 AM, leave is considered. f) When a Staff member wishes to leave for the day, he should login again and enter the check-out time. This enables the facility of attendance as well.
2) Creation Of Bill

a) Only the cashier can create the bill. b) The waiter would interact with the cashier who in turn would tell about the food item ordered. c) The cashier would create a temporary bill first which would contain of all the items ordered, there corresponding rates and quantities. d) If at any point, the customers orders for a new item, the waiter would inform the cashier about it. e) The cashier would update the temporary bill of the same customer and edit the bill. f) Once the bill has been finalized the cashier would check if the customer is already the member of the restautrant. - If Yes, the customer points are checked, if points are >300, 15% of discount on total bill is given to the customer. - Else 10% of total bill is added as points to the points already earned by the customer. g) If the customer is not a member of the restaurant, then he is given option of membership. - If he Agrees, membership account is created with initial point equalts to 10% of his total bill. h) The bill consists of bill_id, date, waiter_id, item, price, quatity, customer_name, customer_points, total. i) The Final bill is created.

3) Update Item a) This function allows the manager(admin) to update any of the database. b) The system provides the manager with information like :- Checking the duty of all staff members. - Availability of raw materials. - Customer database. - Items on food list. - Leaves taken by staff members. - Duties assigned to them. - Salaries given to each staff member. c) The system should also be able to generate reports regarding the profits earned per week/monthly/quarterly. d) Corresponding print outs for each entry made in the system is generated. e) Security provisions like login authenticity is provided by the manager.

SRS for Restaurant Management System

2. SRS DOCUMENT
1. Introduction Software has been developed for Restaurant Management System. 1.1 Purpose

This specification document describes the capabilities that will be provided by the software application Restaurant Management System. It also states the various required constraints by which the system will abide. The intended audiences for this document are the development team, testing team and end users of the product. 1.2 Scope

The software product Restaurant Management System will allow owner or administrator to check duties, sales, reports, attendance, salaries, food items, leaves of the staff members and the customers information. The customer is identified by telling his name and membership number. The application will record the transaction details in the records for every visit made by the customer. It will provide the customer with a printed receipt for each successful transaction, showing the date, time, items ordered, amount payable and points collected. The application will greatly simplify and speed up the financial transactions process. 1.3 Definitions, Acronyms and Abbreviations

Following abbreviations have been used throughout this document: RMS: Restaurant Management System Info: Information M: Manager CA: Cashier C: Chef W: Waiter 1.4 References

(i) Restuarant: For information about services provided to customers. (ii)IEEE Recommended Practice for Software Requirements Specifications 1.5 Overview The rest of this SRS document describes the various system requirements, interfaces, features and the functionalities in detail.

Overall description 7

2.1 Product Perspective The system should be stand alone in nature. It should be designed to provide functionality as explained below :Login g) The login functionality allows any staff member(manager, chef, waiter, cashier) to login in to the system. h) All the users have an authorized login id and unique password. For manager, the login_id would begin with M. For cashier, the login_id would begin with CA. For chef, the login_id would begin with C. For waiter, the login_id would begin with W. i) Each user id after login would enter the check duty function. j) The check duty function enables all the staff members to enter their check-in time and check-out time. k) If any user logins after 9:15 AM, leave is considered. l) When a Staff member wishes to leave for the day, he should login again and enter the check-out time. This enables the facility of attendance as well. Creation Of Bill j) Only the cashier can create the bill. k) The waiter would interact with the cashier who in turn would tell about the food item ordered. l) The cashier would create a temporary bill first which would contain of all the items ordered, there corresponding rates and quantities. m) If at any point, the customers orders for a new item, the waiter would inform the cashier about it. n) The cashier would update the temporary bill of the same customer and edit the bill. o) Once the bill has been finalized the cashier would check if the customer is already the member of the restautrant. - If Yes, the customer points are checked, if points are >300, 15% of discount on total bill is given to the customer. - Else 10% of total bill is added as points to the points already earned by the customer. p) If the customer is not a member of the restaurant, then he is given option of membership. - If he Agrees, membership account is created with initial point equalts to 10% of his total bill. q) The bill consists of bill_id, date, waiter_id, item, price, quatity, customer_name, customer_points, total. r) The Final bill is created.

Update Item f) This function allows the manager(admin) to update any of the database. g) The system provides the manager with information like :8

- Checking the duty of all staff members. - Availability of raw materials. - Customer database. - Items on food list. - Leaves taken by staff members. - Duties assigned to them. - Salaries given to each staff member. h) The system should also be able to generate reports regarding the profits earned per week/monthly/quarterly. i) Corresponding print outs for each entry made in the system is generated. j) Security provisions like login authenticity is provided by the manager. The application will be a windows-based, self-contained and independent software product.
Front End Client Application (with data entry/update/delet e/view and reporting facility)

Backend Database

2.1.1

System Interfaces

(i) Manager Console: The system will have a card slot to accept customers ATM card. (ii) Cashier Panel: The system will have a printer to print receipts for successful transactions. (iii) Chef Panel: Raw Materials Ordering and maintenance. (iv) Waiter Console: Check Duty. 2.1.2 User Interfaces

No interface for users as they do not interact with the system, They only avail the services provided by the restaurant. 2.1.3 Hardware Interfaces (i) Support for printer(dot-matrix/desk jet/inkjet etc-any will do)-that is, appropriate drivers are installed and printer connected computer will be required for printing reports (ii) Standalone system or network based-not a concern, as it will be possible to run the application on any of these. 2.1.4 Software Interfaces

(i) Any window-based operating system. (ii) MS Access 2000 as the DBMS-for database. (iii) Crystal Reports 8-for generating and viewing reports (iv)Visual Basic 6- for coding and developing the product.

Software mentioned in pts (iii) and (iv) above, will be required only for development of the application. The final application will be packaged as an independent setup program that will be delivered to the client (company in this case). 2.1.5 Communications Interfaces

The RMS will communicate with the different chains over an appropriate communication link. 2.1.6 Memory Constraints

At least 64 MB RAM and 2GB space on the hard disk will be required for running the application. 2.1.7 Operations This product release will not cover any automated housekeeping aspects of the database. The DBA at the client site will be responsible for manually deleting old/non-required data. Database backup and recovery will also have to be handled by the DBA.

2.1.8

Site Adaptation Requirements

The terminals at client site will have to support the hardware and software interfaces specifies in above sections. 2.2 Product Functions

The system will allow only the authorized users. A summary of the major functions that the software will perform: (i) (ii) (iii) A login facility for enabling only authorized access to the system. User (with the role Manager) will be able to start and shutdown the system. User (with the role Cashier) will be able to create bill and validate the transactions.

2.3 User Characteristics

Education level: At least graduate should be comfortable with English language. Experience: Should be well versed/informed about the working system of RMS. Technical expertise: Should be comfortable using general-purpose applications computer.

2.4 Constraints

(i) Since the DBMS being used is MS Access 2000, which is not a very powerful DBMS it will not be able to store a very huge number of records. (ii) Due to limited features of DBMS being used performance tuning features will not be applied to the queries and thus the system may become slow with the increase number of records being stored. (iii) Due to limited features of DBMS being used, database auditing will also n< provided. 2.5 Assumptions and Dependencies 10

(i) The RMS will communicate each transaction to the bank and obtain verification that it was allowed by the Cashier. Ordinarily, a transaction will be considered complete when the payment of the bill is received. (ii) Bill is created by the Cashier and any changes to the bill is notified by the Waiter. (iii) Once the bill reaches the cashier, the Cashier checks whether the customer is a member and also whether there are customer points which can be used. 2.6 Apportioning of Requirements

Not Required. 3 Specific Requirements This section contains the software requirements to a level of detail sufficient to enable designers to design the system, and testers to test that system. 3.1 External Interface Requirements 3.1.1 User Interfaces The following screens will be provided: Check Duty: This is the first screen that comes before every user who enters the restaurant. It contains of the Check In Time and the Check Out Time. All the users of the system have to both the activities before and after they leave the restaurant. Login screen: This screen appears when the particular user(Manager, Cashier, Chef, Waiter) initializes the system and the system asks for the user type and the associated password. (i) Username: Alphanumeric of length upto 10 characters. Report Screen: The system should also be able to generate reports regarding the profits earned per week/monthly/quarterly. Corresponding print outs for each entry made in the system is generated. Security provisions like login authenticity is provided by the manager.

Status Screen: Checking the duty of all staff members. Availability of raw materials. Customer database. Items on food list. Leaves taken by staff members. Duties assigned to them. Salaries given to each staff member.

11

Raw Materials screen: This screen is divided into two parts. The first part is responsible for the placing the orders for the raw materials as per the restaurant requirements. The second part of this screen consists the details of the raw materials that are present in the restaurant for usage. These raw materials are required to prepare the various dishes in the restaurant. Billing screen: (i) This screen consists of the details of the bill of a particular customer and the cashier after all the notifications from the waiter prepares the bill and finally prints the bill. 3.1.2 Hardware

Interfaces As stated in Section 2.1.3. 3.1.3 Software Interfaces As stated in section 2.1.4. 3.1.4 Communications Interfaces As stated in section 2.1.5 3.2 System Features 3.2.1 Transaction Details Maintenance Description The system will maintain the details of all the members of the restaurant and also maintain a database for each of them which will consists of all the bill payments and the customer points. Customer points are earned on every visit to the restaurant. Special discounts are given to the members on their respective bills. Bill consists of Bill No. Bill Type, Bill ID Date and amout. (i) (ii) (iii) Validity checks Membership No. cannot be blank. Bill Type cannot be blank. Date cannot be blank. (iv) Time cannot be blank. (v) Bill no. cannot be blank. (vi) Bill ID cannot be blank. Sequencing information Customers membership is checked before the bill is generated. Error handling/response to abnormal situations

12

If any of the above validations/sequencing flow does not hold true, appropriate error message will be prompted to the user for doing the needful. 3.2.2 Report Generation

Bill Generation Bill Date: Items: Member Name: Customer Points: Amount: Time: Bill ID:

3.3 Performance Requirements None 3.4 Design Constraints None 3.5 Software System Attributes 3.5.1 Security The application will be Password protected. Users will have to enter correct Password in order to access the system. 3.5.1 Maintainability The application will be designed in a maintainable manner. It will be easy to incorporate new requirements in the individual modules. 3.5.1 Portability The application will be easily portable on any windows based system that has MS-Access 2000 installed. 3.6 Logical Database Requirements The following information will be placed in the database: (i) Transaction Details: Bill type, date, time, amount, Bill No., Bill ID. 3.7 Other Requirements None

13

Use Case Diagrams Use Case Descriptions

14

3. USE CASE DIAGRAM

C h e c k _ S t a t u s _ r a w m a t e r ia l L o g in CH EF P la c e _ o r d e r <<in w lumd a >> r ia l _ ra c e te A d d _ D a ta STA F F <<in c lu d e >> C h e ck _ o u t MA N A GER

d E d it _ D a<<inbc alu se e >> ta D e le t e _ D a t a

<<in c lu d e >> C h e ck _ D u ty C h e c k _ in

C h e c k _ le a v e s _ t a k e n C A S H IE R

W A IT E R C h e c k _ c u s t o m e r _ p o in t s <<in c lu d e >> T a k e _ o rd e r C r e a t e _ b ill <<in c lu d e >>


15

A d d _ it e m <<in c lu d e >>

D e le t e _ it e m

C h e c k _ S t a t u s _ r a w m a t e r ia l L o g in CH EF P la c e _ o r d e r <<in w lumd a >> r ia l _ ra c e te A d d _ D a ta STA F F <<in c lu d e >> C h e ck _ o u t MA N A GER

d E d it _ D a<<inbc alu se e >> ta D e le t e _ D a t a

<<in c lu d e >> C h e ck _ D u ty C h e c k _ in

C h e c k _ le a v e s _ t a k e n C A S H IE R

W A IT E R C h e c k _ c u s t o m e r _ p o in t s <<in c lu d e >> T a k e _ o rd e r C r e a t e _ b ill <<in c lu d e >> D e le t e _ it e m A d d _ it e m <<in c lu d e >>

16

4. USE CASE DESCRIPTION


1. NAME: LOGIN

1.1 Description This use case allows all the users to login in the restaurant management system All the staff members use this particular use case It is a generalized use case

1.2 Actors Manager (Administrator), Chefs, Waiters, Cashier 1.3 Flow of Events 1.3.1 Basic Flow This use case starts when the actor wishes to login to the Restaurant Management System The system requests that the actor enters his/her name, password and role. The role can be of Manager (Administrator), Chefs, Waiters, Cashier. The actor enters his /her name, password and role. The system validates the entered name, password, role and logs in the system. Alternate Flow If in the Basic Flow, the Actor enters invalid name, password or role, the system displays an error message.

1.3.2

1.4 Special Requirements None 1.5 Pre-Conditions All the users must have a system account (i.e. User Id, Password & Role) created by the Manager(Admin) 1.6 Post-Conditions If the use case was successful, the actor is logged into the system. If not, the system state is unchanged. If actor is Manager(Admin) he/she will access the entire database. Manager can reset any value in any of database. If the actor is Cashier, he/she will access to the customer database, Bill database & food_item database. Only one screen will be present having all details. Cashier can print the bill generated. If Actor is Chef, he/she will access the raw material database. Chef can reset any change he/she wants to make. If the Actor is Waiter, he/she will have access to check duty screen. 17

1.7 Associated Usecases None

18

2. NAME: CHECK DUTY 2.1 Description The use case allows all the staff members to put their check-in time & the Check-Out time. All the staff members use this particular use case. Its an generalised use case. 2.2 Actors Manager(Admin), Cashier, Chef, Waiters. 2.3 Flow of Events 2.3.1 Basic Flow The use case starts once the user has logged in the system. The system would require the user to put his/her check-in time. Whenever the user leaves, he should re-enter & write his check-out time. Alternate Flows If in the basic flow, the actor enters wrong time, the system would give the error message.

2.3.2

2.4 Special Requirements None 2.5 Pre-conditions All the users must have a User Account(i.e. User id, password, Role). The users should have logged in. 2.6 Post Conditions Once any user has logged in, the required user should enter his check in time. And, when the user would leave the system, he/she should enter his check-out time. 2.7 Associated Usecases Check-in time. Check-out time.

3. NAME: PLACE ORDER RAW MATERIAL

3.1 Description The use case allow the actor with role of chef to maintain the raw material database. It allows the chef to place orders for any raw material required. 3.2 Actors Chef actor would interact & participate in the use case. 19

3.3 Flow of Events

3.3.1

Basic flow The use case begins when the chef has logged in the RMS The system would display the screen to the chef consisting of all the items present in the database. The system would have all the rate list & the quantity in the database. Alternate Flow If in the basic flow, the chef enters wrong data or exceed a limit the screen would remain unchanged.

3.3.2

3.4 Special Requirements None 3.5 Pre-conditions Only the user with chef role & the authorized username & password would be allowed. 3.6 Post-conditions Once the chef has placed order by putting the request of the quantity required. It would be displayed in the database. 3.7 Associated Usecases None

4. NAME: CHECK STATUS RAW MATERIAL

4.1 Description The use case allows the actor with role of chef to maintain the raw material database. It allows the chef to check status for any raw material required. 4.2 Actors Chef actor would interact & participate in the use case. 4.3 Flow of Events 4.3.1 Basic flow The use case begins when the chef has logged in the RMS The system would display the screen to the chef consisting of all the items present in the database. 20

4.3.2

The system would have all the rate list & the quantity in the database.

Alternate Flow If in the basic flow, the chef enters wrong data or exceed a limit the screen would remain unchanged

4.4 Special Requirements None 4.5 Pre-conditions Only the user with chef role & the authorized username & password would be allowed 4.6 Post-conditions Once the chef has placed checked the status of the entire database the system remains unchanged. 4.7 Associated Usecases None

5. NAME : CREATE BILL

5.1 Description This use case allows cashier to generate a bill. It allows to add, delete items from the bill. The bill is generated from the order taken by the waiter. 5.2 Actors Cashier actor would interact & participate in this use case. Waiter actor would interact & participate in this use case. 5.3 Flow of Events 5.3.1 Basic Flow The use case starts once the cashier has logged in the system. Once the cashier provides requested information, one of the subflows is executed. If the cashier selects take orders, the take order subflows is executed. If the cashier selects update order, the update item subflow is executed.

5.3.1.1 Take orders The waiter would interact with the cashier about the order taken. 21

The cashier would open the bill screen consisting of :1. Bill no. 2. Date 3. Cust_name 4. Cust_no. 5. Food_item_code 6. Food_item_rate 7. Quantity 8. Total_price Once, the cashier enters all these details, a temporary bill is generated & appropriate message is displayed.

5.3.1.2 Update Item Whenever an item is to be added in the bill, this subflows is executed. The Billno is retrieved from the database. The cashier makes desired changes to the information. This includes any of information specified in the take orders subflow. The final bill is thus generated. The cashier can go to the customer database. The points of the customers are retrieved. 5.3.2 Alternate Flow

5.3.2.1 If the item is not found, an error message is displayed. The cashier should enter a different code. 5.3.2.2 Update cancelled If in the update item, the cashier decides not to update the bill information, the update is cancelled and the basic flow is restarted in the beginning. 5.4 Special Requirements None
5.5 Precondition

The cashier must be logged on to the system. 5.6 Post Condition If use case was successful, bill is generated. If required the items are updated(added/deleted) from the system. Otherwise, the system stste is unchanged. 5.7 Associated Usecases None

22

6. NAME : CHECK CUSTOMER POINTS 6.1 Description

This use case allows the Cashier to check the customer points of the existing customers in the database 6.2 Actors Cashier actor would interact & participate in the use case. 6.3 Flow of Events 6.3.1 Basic Flow The use case starts once the bill is finally created. The Cashier would check the customer database to check if the customer exists or not. If the cashier finds the customer nzme in the database,10% of the otal bill is added to customer points. Alternate flow When the Cashier enters the customer database & the customer is not found,then new account is created with Initial points=10% of the total bill

6.3.2

6.4 Special Requirements None 6.5 Pre Condition 6.6 Post condition The Cashier must be logged on to the system. The Customer should exist in the database. The bill screen appears & according to the Customer Points discount is given. If points>300 , 15% discount is given Else points added in the database. If the Customer oesnt exist in the database,new record is created.

6.7 Associated Usecases None

7. NAME : UPDATE DATABASE

7.1 Description This use case allows the Manager to check all the databases of the restaurant Management System. 23

The Manager an add,modify,delete any data in the database.

7.2 Actors Manager would interact & participate in this use case. 7.3 Flow of Events 7.3.1 Basic Flow The use case starts once the Manager has logged in the system. The Manager can view any Database Can generate reports. Once the manager provides requested information , one of the sub-lows is executed. - If the manager selects add item, add item sub flow is executed. - If the manager selects deletes item, delete item subflow is executed.

7.3.1.1 Add item - Manager(administrator) can add any item for any database. - For staff he can add: New Member Member Details Salary(change , if any) Duty For food_item he/she can Add new item Add rates For Raw_Materials Add new raw material Add the quantity 7.3.1.2 Update Item Manager(administrator) can update any item for any database. For staff he can add: Update Member Update Member Details Update Salary(change , if any) Update Duty For food_item he/she can Update new item Update rates For Raw_Materials Add new raw material Update the quantity 7.3.2 Alternate flow If the database is not found, the screen remains the same. 24

If the data not found, error message displayed.

7.4 Special Requirements None 7.5 Pre condition The manager should be logged on to the system. 7.6 Post Condition Manager screen displayed All databases exists on the screen Any changes can be made. Otherwise system remains unchanged. 7.7 Associated Usecases None

25

Interface Discription of Restaurant Management System

26

5. INTERFACE DESCRIPTION
Various Interfaces used: Manager Interfaces: I. Login Screen

II.

Status Screen:
Checking the duty of all staff members. Availability of raw materials. Customer database. Items on food list. Leaves taken by staff members. Duties assigned to them. Salaries given to each staff member.

III.

Report Screen:
The system should also be able to generate reports regarding the profits earned per week/monthly/quarterly. Corresponding print outs for each entry made in the system is generated. Security provisions like login authenticity is provided by the manager.

IV.

Update Database Update Member Details Update Salary Update Duty

Cashier Interface:
I. II. III. Create Bill. Check Customer Points. Login Screen Chef Interfaces I. Place order of Raw Material

II.

Check status of Raw Materials

27

III.

Login Screen

IV.

Check Duty

Check in Time Check Out Time

Waiter Interfaces I. II. Login Screen Check Duty Check in Time Check out Time

28

Problem Domain Object of Restaurant Management System

29

6. PROBLEM DOMAIN OBJECT

Login

Chef Staff

Login s

Notifie s Order s

Manager

Modifies / Checks

Updat es Databas e

Cashi er

Informs cashier

Waite r

Recei pt

Custom er

Receipt

30

Analysis Model of Restaurant Management System

31

7. ANALYSIS MODEL

32

Interface Diagrams of Restaurant Management System

33

8. INTERFACE DIAGRAMS
1.

INTERFACE DIAGRAM FOR LOGIN

34

2.

INTERFACE DIAGRAM FOR CASHIER

35

3.

INTERFACE DIAGRAM FOR CUSTOMER

36

4.

INTERFACE DIAGRAM FOR MANAGER

37

5.

INTERFACE DIAGRAM FOR MANAGER/ADMIN

38

6.

INTERFACE DIAGRAM FOR CHEF

39

You might also like