Familiarisation with MetaEdit Method Workbench



[pic]

SOFTWARE REQUIREMENT SPECIFICATION

Online Reservation and Food Ordering System

|VERSION: [1.0] |REVISION DATE: [27/08/09] |

|Approver Name |Title |Signature |Date |

| | | | |

| | | | |

| | | | |

SCHOOL OF COMPUTER ENGINEERING

NANYANG TECHNOLOGICAL UNIVERSITY

Contents

1. Product Description 1

1.1 Product Vision 1

1.2 Business Requirements 1

1.3 Stakeholders and Users 1

1.4 Project Scope 1

1.5 Assumptions 1

1.6 Constraints 1

2. Functional Requirements 2

2.1 Requirement X 2

2.1.1 Requirement X1 2

3. Data Requirements 3

3.1 Requirement Y 3

3.1.1 Requirement Y1 3

4. Non-Functional Requirements 4

4.1 Requirement Z 4

4.1.1 Requirement Z1 4

5. Interface Requirements 5

5.1 User Interfaces 5

5.2 Hardware Interfaces 5

5.3 Software Interfaces 5

6. Use Case Model 6

6.1 Use Case Diagram 6

6.2 Use Case Description 6

7. Glossary 7

8. References 8

9. Revision History 9

Online Reservation and Food Ordering System (ORFO)

1. Product Description

Gamici is one of Singapore’s most prestigious and stylist Italian restaurant which served authentic Italian cuisine. With its simple, elegant yet friendly and vibrant environment, Gamici has become a common social gathering place for many friends and families. Therefore, this has helped to boost the growth of its business.

Currently, Gamici is using a completely manual based system to carry out some of their day to day operations. Due to the business growth, this system has become inadequate to meet its business requirements.

Some problems it encountered using a manual system when its business is getting busier each day:

• More manpower is needed to serve the customers which lead to space constraint in the restaurant.

• Servers complained that they have too much to do within the fastest time possible else customers will get impatient with their service. This may lead to more human error such as carelessness.

• Inefficiency caused returning customers to decrease as the wait time for seats, food to be served, servers’ response and billing are getting too long.

• Food quality degrades as food processing time is shortened to satisfy customers’ impatience.

• Customers can only reserve seats and order food through phone calls and this means that payment cannot be made beforehand. Some of the food ordered by customers may have special ingredients that need advance purchasing. Last minute cancellation by customers or customers who do not turn up, result in wastage of food and staff effort is put to a waste. Thus, the restaurant will eventually make loses.

• High expenses incurred.

With the aim for solving the above problems, Gamici has decided to engage UPz to develop a portal to

1) Reduce the workload of the staff.

2) Have online payment via credit/debit card.

3) Receive order in real time

Therefore, UPz software development team will introduce an Online Reservation and Food Ordering System (ORFO) whereby customers can browse the food menu online, which order can be placed and payment can be made through the system and reserve seats based on restaurant floor plan to pick the exact seat location in the restaurant that the customers prefer to dine at.

1.1 Product Vision

The new system (ORFO) aims to increase efficiency to smoother work flow of the restaurant so as to provide top-notch dining experience and service to the customers. It also aims to reduce overheads caused by the manual system and solve the current problems mentioned in Section 1 – Product Description.

1.2 Business Requirements

The first version of the ORFO must be available within three months.

ORFO must demonstrate cost saving of at least 20% on labor within a year after the introduction. The reduction of manpower would mean that the restaurant need not have to activate as many staff as before during peak hours or days of the week.

Labor productivity must be improved by 15% at least.

Revenue must result in 20% increase after a year.

New and existing customers patrolling the restaurant must result in 15% increase at least.

1.3 Stakeholders and Users

Management – The Board of Directors as the controlling interest in ORFO. Weekly status update meeting will be held to communicate the progress of the project to the management.

Purchaser – Upz who invest money to develop the system.

User – Customers who use ORFO to interact with Gamici.

Developers – The eight-member development team which includes one project manager, two programmers, two software engineers, two database analysts and one designer.

Staff – Restaurant Manager and Restaurant Supervisor who maintain and update the portal such as adding new items to the menu, making changes to the prices, introducing promotions. Administration Clerk and Waiters are only able to retrieve information.

1.4 Project Scope

The scope of this project is to develop an Online Reservation and Food Ordering System which will be integrated on Gamici website. This system allows reservation making and food ordering services that will provide a convenient dining experience to the customers. Customers can also raise special requests to cater to their needs. In addition, the ORFO system allows customers to choose their desire seats online based on the restaurant floor plan and order food. Then, payment can also be done online through ORFO system. Database will be created to keep track of customers’ information and requests.

1.5 Assumptions

Order ID will be issued to customers after each transaction with Gamici.

The payment modes will be through credit/debit cards or internet banking.

An invoice will automatically be generated after each transaction.

6 Constraints

The system should support various payment modes.

Functional Requirements

1. General

1. The user shall only be able to perform the following operations:

i. For customer:

a. Make a reservation

b. Browse menu

c. Special request

d. Make payment

e. Modify/cancel reservation

ii. For restaurant personnel:

a. View database

2. The ORFO must have a “Back button” to go back to previous page.

2. Make a Reservation

1. When the user initiates ‘Make a Reservation’, he/she must be taken to the ‘Make a Reservation’ page.

2. The user must be able to enter the following information

a. Time and date

b. Number of people

3. Once the user submits the information, he/she will be taken a page that shows the floor plan of the restaurant.

4. The page must show all the available table(s) that fit the requirements in 2.2.2 in yellow. Unqualified table(s) will be in red.

5. The user must be able to choose the table(s) in yellow only and using the mouse by clicking on the table. The selected table will be in green.

6. The user must be able to deselect the table by clicking the selected table again and the table will be in yellow again.

7. Once the requested table(s) is selected, the user must be able to click the ‘Confirm’ button to proceed.

8. The user must be able to enter the following information:

a. Name (between 1 to 32 characters)

b. Contact number

9. Once the information is submitted, the selected table(s) and the information must be updated in the database.

10. If the update fails, the ORFO must show an error message to the user notifying him/her of the failure.

3. Browse Menu

1. The ORFO must display the menu that is updated to the current day and must be coherent to the menu used in the restaurant.

2. The menu page must display the menu in tabs with the following categories:

i. Main course

ii. Appetizers

iii. Beverages

iv. Dessert

3. Each tab page must display a list of 10 items at a time.

4. User must be able to navigate through the items using various navigational links provided at the bottom of the page:

a. Clicking “next” will list the next 10 products in the menu. (If more available)

b. Clicking “previous” will list the previous 10 products in the menu. (If previous exists)

c. Click on individual page numbers will display the selected page.

5. The ORFO must allow the user to view the following about a single item from the menu by clicking on the item:

a. Item name

b. Item image

c. Item description

d. Item price

6. The user must be able to select the item by double clicking on the item and the item will be added to cart, refer to 2.3.7.

7. The ORFO must display a cart that contains the items selected by the user at the bottom of the page.

8. The cart must contain the following information

a. Item name

b. Item price

c. Total price (with GST)

d. Total price (with GST)

9. The user must be able to delete the item from the cart by selecting the item and click on the “Remove” button at the side.

10. If there is at least one item in the cart, the user must be able to click the “Proceed” button to proceed.

11. Once the “Proceed” button is clicked, the selected items information must be updated in the database.

12. If the update fails, the ORFO must show an error message to the user notifying him/her of the failure.

4. Special Request

1. The ORFO must display a list of default special request with tabs with the following categories:

a. Birthday

b. Date

c. User defined

2. For tabs a and b, the page must display a list of 10 items at a time.

3. User must be able to navigate through the items using various navigational links provided at the bottom of the page:

a. Clicking “next” will list the next 10 products in the menu. (If more available)

b. Clicking “previous” will list the previous 10 products in the menu. (If previous exists)

c. Click on individual page numbers will display the selected page.

4. The ORFO must allow the user to view the following about a single item from the menu by clicking on the item:

e. Item name

f. Item image

g. Item description

h. Item price

5. The user must be able to select the item by double clicking on the item and the item will be added to cart under refer to 2.3.7.

6. To delete the selected item refer to 2.3.9.

7. For tab c, the user must be able to enter in a short description of the special request and must provide the following information:

i. Item name

ii. Place to buy

8. If there is at least one item in the cart, the user must be able to click the “Proceed” button to proceed.

9. Once the “Proceed” button is clicked, the selected items information must be updated in the database.

10. If the update fails, the ORFO must show an error message to the user notifying him/her of the failure.

11. The ORFO must inform the user via the contact provided in 2.2.8 within 24 hours about the user defined special requests.

5. Make Payment

1. The ORFO must allow the user to look through all the items in the cart with information provided in 2.3.8.

2. The user must be able to confirm the order(s) by clicking the “Confirm” button.

3. The ORFO must display the modes of payment as shown:

i. By cash at the restaurant

ii. By credit card via online

4. If the user selects a, proceed to 2.5.5. If the user selects b, proceed to 2.5.8.

5. The ORFO must generate a transaction ID, the user must produce this ID at the restaurant for verification during the day of reservation.

6. The user must click the “Proceed” button to verify that he/ she has noted the transaction ID.

7. The ORFO must proceed to 2.5.14.

8. The user must be brought to a secured page to make the payment via credit card.

9. The user must be able to enter his/her credit card number.

10. After valid credit card number is entered, the user must be able to proceed by clicking the “Proceed” button.

11. Once “Proceed” button is clicked, the ORFO must verify the credit number.

12. If verification fails, the ORFO must show an error message to the user to notify him/her of the failure.

13. If verification is successful, the ORFO must generate an invoice and a link must be provided to the invoice for printing.

14. The ORFO must display the following information.

a. Transaction ID

b. Invoice ID (if any)

c. Time and Date

d. Number of people

e. Table(s) reserved

f. Food ordered

g. Special request(s) (if any)

15. The reservation is completed, the user must be able to exit the page or proceed with another transaction by clicking the “Finish” button.

6. Modify/ Cancel Reservation

1. The ORFO must allow the user to modify or cancel reservation at “Modify/Cancel Reservation” Page.

2. The user must enter the following information for verification:

a. Transaction ID

b. Credit card (for payment via credit card only)

3. If the verification fails, the ORFO must show an error message to the user notifying him or her of the failure.

4. If the verification is successful, the ORFO must check the time of this adjustment and the time of reservation.

5. If the duration is more than 24 hours, the ORFO must show a message to the user notifying him/her that it is too late for the adjustment and 2.6.20.

6. If the duration is shorter than 24 hours, the user must be able to proceed to the page to make the adjustment.

7. The ORFO must display the following:

a. Modify reservation

b. Cancel reservation

8. If the user selects a, proceed to 2.6.9. If the user select selects b, proceed to 2.6.17.

9. The ORFO must allow the user to modify the reservation as shown below:

i. Change reserved table, refer to 2.2

ii. Modify ordered food, refer to 2.3

iii. Modify special requests, refer to 2.4

10. If the net payment after the adjustment is less than the previous payment, no refund must be given.

11. If the net payment after the adjustment is more than the previous payment, additional payment must be made, refer to 2.5.

12. The ORFO must update the database with the adjustments.

13. If the adjustment fails, the ORFO must show an error message to the user notifying him or her of the failure.

14. If the update is successful, the ORFO must display the following information.

a. New Transaction ID

b. Invoice ID (if any)

c. Time and Date

d. Number of people

e. Table(s) reserved

f. Food ordered

g. Special request(s) (if any)

15. The ORFO must display the following information of the reservation:

a. Transaction ID

b. Invoice ID (if any)

c. Time and Date

d. Number of people

e. Table(s) reserved

f. Food ordered

g. Special request(s) (if any)

16. The user must be able to cancel the reservation by clicking “Cancel Reservation”.

17. Once the user selects “Cancel Reservation”, the ORFO must update the database with the adjustments.

18. If the adjustment fails, the ORFO must show an error message to the user notifying him or her of the failure.

19. If the update is successful, the ORFO must inform the user how to get the refund.

20. The adjustment is completed, the user must be able to exit the page or proceed with another reservation by clicking the “Finish” button.

7. View Database

1. The user must choose the time and date in a drop down menu.

2. The ORFO must display the database in tabs with the following categories:

a. Tables reserved

b. Food ordered

c. Special Orders

3. If the user selects a, proceed to 2.7.4. If the user selects b, proceed to 2.7.6. If the user selects c, proceed to 2.7.9.

4. The ORFO must display the floor plan showing the status of the table:

a. Green table means reserved

b. Red table means not reserved

5. The ORFO must allow the user to view the following about a reserved table from the floor plan by clicking on the table:

a. Customer name

b. Customer contact number

c. Number of people

d. Link to the ordered food

e. Link to the special request

f. Mode of payment

6. The ORFO must display the ordered food in tabs based on the reserved tables.

7. When the user selects one of the tabs, the ORFO must display the ordered food in a table, with the following format:

a. Main course

b. Appetizers

c. Beverages

d. Dessert

8. The ORFO must display the quantity of the ordered food beside the item in the table.

9. The ORFO must display the special requests in tabs based on the reserved tables.

10. When the user selects one of the tabs, the ORFO must display the special requests in a table, with the following format:

a. Birthday

b. Date

c. User define

11. The ORFO must display the quantity of the special requests beside the item in the table.

12. Once viewing of the database is done, the user must be exit the database by clicking on the “Exit” button.

3. Data Requirements

Data requirements describe the format, structure, type, and allowable values of data entering, leaving, or stored by the product.

1. The system will only accept data which are correct and not ambiguious. E.g Mobile number should only be 8 digits long and credit card numbers should be 16 digits long.

2. The booking can only be submitted and processed by the system when all required fields of data have been filled up.

3. The system should display all times in the 24-hour clock format.

4. The system must store customer names in fields recording first and last name.

5. When a customer has selected a table of choice for booking but has not yet confirmed his booking, the system will lock out that particular table to other customers.

4. Non-functional requirements

There are requirements that are not functional in nature. Specifically, these are the constraints the system must work within.

1. Compatiblity

1. The website should be compatitible with both Internet Explorer and Mozilla Firefox, the 2 most widely used browser currently.

2. User interface

1. The user interface should be as familiar as possible to users who have used other web applications and Windows desktop applications. E.g., we will follow the UI guidelines for naming menus, buttons, and dialog boxes whenever possible.

3. Security

1. Access will be controlled with usernames and passwords

2. Only administrator users will have access to administrative functions, average users will not.

3. Database should be reasonably secured to prevent leak or loss of confidential information such as credit card details from customers..

4. Performance

1. The system should be up and running 24/7.

2. It should support at least 100 users using the online booking concurrently without any lag.

5. Backup and Recovery

1. There should be a backup server and database to prevent service interuption or loss of data when the main server and database are down.

2. Downtime should not last more then 30sec when switching from main server to the backup server in case of a breakdown.

6. Reliability

1. The whole online booking system should achieve a 99% sucess rate. i.e downtime should not be more then 1% of its total operating time.

2. System review will take place monthly. Any lack in performance or reliability will be addressed and improved on after each review.

7. System Maintainence

1. Maintainence of the system will be conducted weekly. Maintainence will be conducted during off-peak hours e.g between 12am - 6amz

5. Interface Requirements

Overview

The user interface of this restaurant booking system is a web site which can be viewed using popular web browsers. This high accessibility made it easier and more convenient for users to use the system. Users don't need to set up any additional software for the purpose of running the system. As long as an Internet co

nnection is available, the system can be easily accessed using their mobile devices. Multi-platforms operation is also an additional advantage of this design.

One more advantage of this design is the power of the Hyper Text Markup Language (HTML). HTML provides nicer features with simple modification and configuration compared to the GUI of other languages. HTML language supports the use of other languages and technique to make dynamic objects, which can improve the vividness of the application.

5.1 User Interfaces

These are the fundamental features of the GUI that should be included in the websites:

A login box comprises of an account and a password textfield. Users can sign in using their NRIC to check their bookings. We can provide the sign up function for long-term users so that they don't have to refill the information everytime booking is made.

A dynamic menu including the links to the homepage, the menu page, the booking page and the information page.

the menupage will have the list of food with its respective image.It can be divided into many pages to ease up the navigation. The booking page will have a shopping cart function for the booking of food and a clickable map for the reservation of seats. After booking is submitted, the webpage will automatically redirect to the payment page. The information page will provide additional information about the restaurant.

A slideshow or a flash of the images of the restaurant.

Images of the top ordered dishes and their respective information (e.g price, ..).

A panel for advertisements coming from our own restaurant or from other parties.

5.2 Hardware Interfaces

Describe how the software application interfaces with hardware that exists outside the scope of the system.

5.3 Software Interfaces

The use of web design tools such as Adobe Dreamweaver is employed to make a more professional and nicer design of the system. The code editor and the design editor is integrated in one tool, which allows easy modification as well as addition of elements onto the web pages. Interactive and dynamic objects can be created more easily within a few clicks. The platform to implement the webpage is php and mysql with the support of Apache. Another platforms to be considered are jsp, serverlet using netbean, and C# using Visual Studio. However, PHP is chosen due to its popularity, ease in coding and the availability of free scripts online.

To edit the images and make the flash, it is recommended to utilize Adobe Photoshop, Flash SlideShow maker and Adobe(Macromedia) Flash Player. This requires some Actionscript code to make the dynamic contents. It's also used to create icons and graphics to enhance the interface.

5.4. Difficulties Encountered and Solutions Applied

Since most of the languages used is new to the development team. It takes time to get familiar with these languages. Another problem confronted by the team is the inconsistency in designs and layout since different components and different pages are developed seperately by different people. These components are later merged together to form the complete system.

Confronting these problems, our team has come up with appropriate solutions and applied it successfully. For instance, we have searched online and found plenty of free pieces of code and software that is applicable to our system. This simplifies the process of coding and developing some interactive components. To name it, we use Flash SlideShow maker to generate the slideshow in the flash format simply by adding pictures and choose the skin of the layout. A lot of PHP codes, Javascript to do some complicated tasks or to make dynamic menus features can be found easily on the websites and tutorials. They give us an idea of how the job is done and save us a lot of hard work.

About the inconsistency matter, the Cascading Style Sheet (CSS) is applied to enhance the flexibility and accessibility of the elements by defining the common element property seperately and concretely. These properties are specified in the style sheet, which determines the appearance of all the pages that are linked to it. The point is that these properties only need to be entered once and then they are applied automatically to all the elements, which save a lot of coding. Another remarkable advantage displays itself when it comes to managing big and sophisticated websites. CSS make it possible for the whole systems and organizations to share and reuse a small number of style sheets. Beside ensurement of consistency across the site, CSS also favors the updating and modifying of the web layouts to conform to the changes in system requirement. Instead of editting individual components, we can edit all together in one go by modifying the style sheet.

6. Use Case Model

Provide the top-level use case diagram, followed by the use case description for each use case.

6.1 Use Case Diagram

6.2 Use Case Description

7. Glossary

Define all terms and acronyms required to interpret the SRS properly. This is the (problem) domain dictionary.

8. References

Provide a list of all documents and other sources of information referenced in the SRS and utilized in developing the SRS. Include for each the document number, title, date and author.

|Document No. |Document Title |Date |Author |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

9. Revision History

Identify changes to the SRS.

|Version |Date |Name |Description |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download