Case Study: Restaurant System 1. Problem statement The system is intended to support the day-to-day operations of a rest
758 44 163KB
M E N U RESTAURANT SALADES/SALADS/SALATE SALADE CESAR Caesar Salad / Caesar Salat 21 SALADE FRUITS DE MER Seafood Sa
182 104 352KB Read more
Case Study: Restaurant System 1. Problem statement The system is intended to support the day-to-day operations of a restaurant by improving the processes of making reservations and allocating tables to customers. The Restaurant system provides the facilities like •
The new system can offer diners eat at the restaurant without making an advance booking, if a free table is available. This is known as Walk-in. The new system should display the same information as the existing booking sheet and in same format, to make it easy for restaurant staff to transfer, to the new system. When new bookings are recorded or changes made to existing bookings, the display should be immediately updated, so that restaurant staff is working with the latest information available.
2. Vision Document The vision document describes the higher level requirements of the system, specifying the scope of the system. The vision document of restaurant system might be •
It is a support system for restaurant
The restaurant makes bookings, cancel bookings, record arrivals and table transfers of the customers.
The receptionist is the employee of the restaurant who interacts with the customer whose work is supported by the system.
The customer rings up to make a booking there is a suitable table free at the required day and time and the required day and time and the receptionist enters customer’s name, phone no. and records booking. 1
When the customer arrives, his arrival is updated in the system and waiter attends to them.
The customer can also cancel booking what he made or transfer the booking to another day or time.
The receptionist can easily record , update and cancel the information about the bookings and customers
The customers eat in restaurants even with out any reservations or bookings called Walk-in.
3. Glossary This document is used to define terminology specific to the problem domain, explaining terms which may be unfamiliar to the reader. This document can be used as informal data dictionary capturing data definitions, key terms. Booking: An assignment of a table to a party of dinners for a meal Covers: The number of diners that a booking is made for Reservation: An advanced booking for a table at a particular time Places: The number of diners that can be seated at a particular table Walk-In: A booking that is not made in advance. Actors: Customer: The person making a reservation Diner: A person eating at the restaurant
4. Supplementary Specification Document 4.1 Objective The purpose of this document is to define the requirements of the restaurant system. The supplementary specification lists the requirements those are not readily captured in the use cases of the use case model. The supplementary specification and the use case model together capture a complete set of requirements of the system.
4.2 Scope This specification defines the non-functional requirements of the system such as reliability, usability, performance, supportability and security. As well as functional requirements that are common across a no. of use cases.
4.3 References 2
4.4 Common Functionalities •
Multiple customers can be able to visit a restaurant.
Customers who have recorded booking must be notified.
4.5 Usability The desktop user interface shall be Windows NT and Windows 2000 complaint.
4.6 Reliability The system shall be available 24 hrs a day, 7 day a week to no more than 10% downtime.
4.7 Performance The system shall support up to 1000 simultaneous users against the central data base of any time.