restaurantbillingsystem-4103-03a.weebly.com€¦ · web viewatmpin the atm pin of ... the...

3.1 SOFTWARE REQUIREMENTS SPECIFICATION

3.1.1 INTRODUCTION

The purpose of this chapter is to describe the software requirement for the

Restaurant Billing System that will serve as a foundation for the final product.

This chapter define what are the uses of the software should be expected.

Restaurant Billing System is one of the software wherein it is automatically

generating reports once the user registers the needed information. Every time the

other sub-system enters the Restaurant Billing System it will automatically recorded

the date and time to monitor the changes in every transaction.

A stand-alone or LAN based system will be delivered so that users can access

the system. By designing around a standardized language like Java Indigo the

application will run on the most popular computer platforms. In addition, a

centralized computerized database connection will allow some sub-system that

connected to their perspective system will more easily share information.

The Restaurant Billing System is intended to provide a computer based

system that assist in managing a billing system. Many of the typical functions

involved in operating a billing system will be automated through software to improve

the operational workflow within a facility. For instance, activities like registering the

Senior Citizen and Person with disabilities, creditor’s information will be performed

by the computer system so that the user can spend time to do some work. In addition,

task like processing billing adjustment and printing reports using the everyday

transaction of the credit card bill will be available within the program to minimize the

time that the manager must spend creating these documents.

This requirement specification will describe these as well as many other

features of the software in greater detail.

RESTAURANT BILLING SYSTEM 5

3.1.1.1 GOALS AND OBJECTIVES

The goals and objectives are to enhance, develop and construct a

computerized system that suitable to the Restaurant Billing System (RBS) and

help them to improve or minimize their manual basis/system.

a. Senior Citizen/Person with Disabilities

To enhance and develop a computerized Restaurant Billing System

that can registered and view the SC and PWD I.D’s for the convenience of

user and the customer, it is easily for the user to check the I.D’s of the person

to get and record their discount.

b. Creditor’s Information


that can register and view and verify the creditor’s information that contains

the credit amount to be rendered of the customer, it is easily for the user to

record the unlisted person into the database and for the customer to know their

current information at the same time.

c. Billing Adjustment


that can easily generate the adjustment of the customer bills regarding of

cancellation of the reservation and updating the basic information about the

payment process..

d. Search Engine


that can easily search the important data needed of the user.

e. Generating Reports

To develop a computerized restaurant billing system that can generate

reports and it can use by the authorized person for business purposes.

The Restaurant Billing System automatically generates report in every

transaction. Reports are frequently formatted in a manner that is consistent

from one reporting period to another, that information can be compared. With

RESTAURANT BILLING SYSTEM Page 16

these reports the management can use it as a primary reference to

communicate information and communicate to the other system.

f. Back-up and Recovery

All the transaction that happened in the R.B System it implemented the

back-up and recovery database which once the electricity or human error

occur there is a strategy to protect and recovered the database to avoid data

loss and to make back-up data for the reports.

3.1.1.2 STATEMENT OF THE SCOPE

This section contains a general description of the software

functionality followed by detail requirements that will be traced throughout

the project.

Before gaining access to the RB System an employee will be required

to enter their username and password in POS System before accessing the

Billing system. An employee’s access privileges within the system are

determined by their job classification. The administrators will have unlimited

access to some sub-system especially in billing whereas managers have

unlimited privilege in billing system and cashiers will have fewer privileges as

described below.

Restaurant Billing System has a feature of Billing Adjustment wherein

the staff of Reservation System sends their adjustment of amenities or charges

of the reservation. RBS only update the billing adjustment that includes

charges or penalties and payments of the customer.

RBS has a database for SC/PWD information wherein the cashiers

enter to the Billing System to confirm if the SC/PWD has already register or

not yet.

The RBS has also a feature of Creditor’s Information wherein it covers

information of the creditors. Using the Credit Card number, cashier will look

for the information of the creditors by using the search engine to verify the


basic information that includes the date issued and the expiration of the credit

card.

The cashier or staffs that assigned has a responsible to save all

information they register in Billing System so that all the information will be

automatically updated to the next transaction. It will also serve as back-up for

the assurance of the company.

All the transaction happened everyday will generate reports using the

Restaurant Billing System that connected to the Point of Sale System.

The following table groups user requirements into various categories.

Each requirement is assigned a priority to indicate whether it must be

implemented (High) or may be left out (Low). Low priority requirement may

be eliminated if it helps meet the scheduled delivery date. Medium priority

requirements are not essential and their implementation will be determined as

program progress.

User Requirement for the Restaurant Billing System

Req. No. Priority Reference DescriptionAccess PrivilegesR1 High User There shall be four levels of access;

one for manager and one for

administrator.R2 High User The Administrator shall only be

allowed to view the information of

the database reports.R3 High User The Manager shall be allowed to

enter or edit all data same as Cashier.R4 High User There shall be two levels of viewing

the reports; one for managers and one

for administrators.

Security


R5 High User Each user shall be required to enter

their name before using the system.

Senior Citizen/Persons with DisabilitiesR6 High User When the user search for SC/PWD

ID that information shall view in a

list.R7 High User The Senior Citizen/PWD shall

contain the following information:

1. SC/PWD_FName

2. SC/PWD_MName

3. SC/PWD_LName

4. SC/PWD_Address

5. SC/PWD_GenderR8 High User The software shall support the ability

to enter and store the basic

information of SC/PWD.R9 High User When the user registers the unlisted

SC/PWD customer, it shall be

recorded/save in the database.

Creditor’s InformationR10 High User When user searches the Credit Card

number, the information shall view in

a list, together with the information

needed.


R11 High User The Credit Card Verification shall

contain the following information:

1. Card No.

2. Full Name

3. Card Name

4. Bank Name

5. Date of Birth

6. Phone Number

7. Country

8. Expiration

9. Atm Pin

10. Credit

R12 High User The software shall support the ability

to store and save the basic

information.

R13 High User When user registers the unlisted

creditor, the information shall save

first before closing the system.

Billing AdjustmentR14 High User A Billing Adjustment

history/summary for each reserved

customer shall contain all the

important information.


R15 High User The Billing Adjustment shall contain

the following information1. OR No.

2. Customer id

3. Time

4. Place

5. Reserve Description

6. Total Amount

7. Sub Total

8. Vat able Amount

9. Amount Tender

10. Changes

11. Remarks

User InterfaceR16 High User The system should be stand-alone but

database integration.

R17 High User The default background colour of all

windows shall be colours red, black,

yellow and white, but it can be

customized.R18 High User The button shall contain picture

together with the name of the button

to be understandable.

Table 3.1.1.2 Shows the User Requirements for the Restaurant Billing System

3.1.1.3 SOFTWARE CONTEXT

Most of the system made by programmer, they improve the system and

complete the needed requirements. But in the Restaurant Billing System, it is

a subsystem that connected to the other sub system where in it is integrated to

use it as a whole useful system.

The Restaurant Billing System is one of the sub systems of the

Restaurant System which is also connected to the sub system Point of Sale


(POS). POS captures important information in the billing system to make

reports for the company and register at the same time. The Reservation

System sub system is also a sub system of a Restaurant System that connected

to the billing system, where in the verify important information using a credit

card number to see if it has expired or it can be used of the customer. It can

also register information if the creditor’s information is unlisted.

The R.B.S is efficient and user friendly which maintains the database

of every billing transaction. Billing system is more on database information

which provides the important data to the connected sub system. This software

is less expensive and also reduces complexity. Restaurant Billing System uses

Net Beans IDE version 7.3 Program Language and MySQL(yog) for the

database uses and mysql-connector-java-5.1.22-bin.jar for the database

connection.

3.1.1.4 MAJOR CONSTRAINTS

The Restaurant Billing System has several major constraints to be

considered such as follows.

Search Engine

- When the user can easily search the needed information into the system.

Back-up and Recovery

- When the transaction recorded by the user, it will be the back-up data of

the company.

- When the electricity shut down, there is a strategy to protect and recover

the database to avoid data loss.

3.1.2 USAGE SCENARIO

3.1.2.1 USER PROFILES

The following definitions describe the actors in the system.


Admin Staff

Has the responsibility to view the report of the system. He has the

authority to check and compared the information of the soft copy to the hard

copy reports.

Managers

Has the biggest responsibility in the system. He has to monitor, add

information and update the system at the same time, view and print the report.

He has the authority to file and print the billing transaction of RBS so that he

can submit a report to the Accounting System for the current status of the

transaction that generated by the user.

Cashier

Has the fewer and major but important responsibility in the system.

She/he has to save, edit, view and enter the important information into the

database. She/he has the responsible and authorizes to produce an output of

the billing transaction. She/he has assigned to record all the billing transaction

leaving or logging off.

Reservation Staff

Has the responsibility in the system to add the information of Creditor

into the database and verify at the same time. He has the authority to add the

bill adjustment so that Restaurant Billing System will update the Billing

Adjustment with Charges, Penalties and payment option.

3.1.2.2 USE-CASES

The following use-cases are typical interactions between the external

environment and the internal software system. Each use-case is described in

section 3.1.2.2.2.

1. Enter the name

2. Enter/register the information

3. Verify information

4. Display information


5. View information

6. Record/Update information

7. View report

8. Display report

9. Print report

10. File report

11. Submit report

12. Check and compare report

13. Exit the system


3.1.2.2.1 USE-CASE DIAGRAM

Figure 1: Use-case diagram of Restaurant Billing System

The use-case diagram is governed by responsible users where

they perform their task of responsibility. Cashier is the person who


MANAGER

CASHIER

Verify Information

Display Information

Enter /Register Information

View Information

Record/Update Information

View Report

File Report

USE-CASE OF

RESTAURANT

BILLING SYSTEM

Enter their name

Print Report

Display Report

Submit Report

Compare / Cheeck Report

Exit the System

ADMIN STAFF

RESRVATION STAFF

made a daily transaction. The manager is capable of manipulating

reports to be done by the user/s, such as Cashier, and reservations

staff. Admin Staff is also capable of viewing and checking the reports

verify and print by the manager.

3.1.2.2.2 USE-CASE DESCRIPTIONS

Use-case: Enter the name

Primary Actor: User (Cashier, Manager, Admin Staff,

Reservation Staff)

Goal in context: To gain access to the system

Preconditions: The user has a valid username and password

before enter their name

Trigger: The user needs to access to the system to

perform their job

Scenario: 1. The system prompts the user for their name.

2. The user enters their name.

3. The user is given access to the System to

perform their job.

Exceptions:

Use-case: Enter/Register Information

Primary Actor: User (Cashier & Reservation Staff)

Goal in context: To enter/ register the SC/PWD and Creditor’s

Information and Billing Adjustments.

Preconditions: The user shall access the system. The user is

enter their name

Trigger: The user needs to add unlisted information into

the database.

Scenario: The user selects the SC/PWD and Creditor’s


Information and Billing Adjustments from the

main menu.

Exceptions:

Use-case: Verify Information

Primary Actor: User

Goal in context: To verify the Information of SC/PWD,

Creditor’s Information, and Billing Adjustment

Preconditions: The Information of SC/PWD, Creditor’s

Information, Billing Information and Billing

Adjustment.

Trigger: A user needs access to the system to perform

their job.

Scenario: 1. The system prompts the user to enter

their name.

2. The user enter their name

3. The user selects the SC/PWD, Creditor’s

Information, Billing Information and

Billing Adjustment.

4. The user searches the id or primary key

of every table to display the information

in the database.

5. The user verifies the information

recorded in the database/system.

6. The user is given the option to close or

display or view the Information.

Exceptions: The information doesn’t exist

Use-case: Display/View Information

Primary Actor: User


Goal in context: To Display or View the Information ogf

SC/PWD, Creditor’s Information, Billing

Information and Billing Adjustment.

Preconditions: The user is enter their name

Trigger: The user needs to access to the system to

perform their job.

Scenario: 1. The system prompts to enter their name.

2. The user enter their name

3. The user selects the SC/PWD, Creditor’s

Information, Billing Information and

Billing Adjustment from the menu.


display or view the information

Exceptions: The user doesn’t enter the Id or primary key on

the search engine.

Use-case: Record Information

Primary Actor: User

Goal in context: To record the transactions made by the user.

Preconditions: The user is enter for their name

Trigger: The user needs to access the system to perform

their job.

Scenario: 1. The system prompts the user to enter

their name.

2. The user enters their name.

3. The user selects the save button from the

button in the system.

4. The system display confirmation of

saving information.


display or view the information


Exceptions:

Use-case: View/Display Report

Primary Actor: Admin Staff/Manager

Goal in context: To view and display the Information recorded by

the user into the database.

Preconditions: The user is entering the name or primary key &

the report exist.

Trigger: The Admin Staff/Manager needs information

from one of their transaction.

Scenario: 1. The system prompts the Admin

Staff/Manager to enter their name.

2. The Admin Staff/Manager enters their

name.

3. The Admin Staff/Manager selects the

SC/PWD, Creditor’s Information, Billing

Information and Billing Adjustment from

the menu.

4. The system prompts for the id, or primary

key of the transaction.

5. The system requests the record form the

database server.

6. The report of the record is displayed on

the screen

7. The Admin Staff/Manager is given the

option to close or display or view the

information

Exceptions: The report does not exist. The Manager tries to

print the report at the end of the transaction of

the month.


Use-case: File & Submit Report

Primary Actor: Manager

Goal in context: To file & submit the report to the accounting.

Preconditions: The manager is enter their name

Trigger: The Manager needs information from one of

their transaction.

Scenario: 1. The system prompts the Manager to enter

their name.

2. The Manager enters their name.

3. The Manager selects the SC/PWD,

Creditor’s Information, Billing


the menu.




database server.

6. A report of the record is displayed on the

screen.

7. The Manager is given the option to close

or display or view the information

8. The manager File the collected report

9. The manager submit the report into the

accounting Dept.

10. The manager is close the system.

Exceptions:

Use-case: Check and Compare the Report

Primary Actor: Admin Staff


Goal in context: To Check and Compare the softcopy to the hard

copy report.

Preconditions: The user has a valid username and password

before enter their name

Trigger: The user needs to access the system to perform

their job.

Scenario: 1. The system prompts the Admin Staff to

enter their name.

2. The Admin Staff enters their name.

3. The Admin Staff selects the SC/PWD,

Creditor’s Information, Billing


the menu.




database server.

6. A report of the record is displayed on the

screen.

7. The admin staff is comparing and &

checking the report submitted by the

manager.

8. The admin staff is given the option to

close or display or view the information

Exceptions:

3.1.2.3 SPECIAL USAGE CONSIDERATIONS

Billing Adjustment charges and penalty cannot be changed.


3.1.2.4 ACTIVITY DIAGRAM

Figure 2: Activity diagram for entering on the system


User enter their name

Retype the name

Access Granted

[Correct]

[Incorrect]

Log-in activity diagram

Before gaining the Restaurant Billing System, user is needed first to

log-on to the Point of Sale sub-system before accessing the Billing system. To

grant the request in entering the Billing system, user must enter their name



Access Granted

Select SC/PWD Information, Credit Card Verification and Billing Adjustment from the

menu

Enter/Register the Information

[Correct]

[Incorrect] Prompt for the user to supply the unfilled-up information needed

Record into the database/system

Display, view the SC/PWD. CC Verification

and Billing Adjustment

Registering of Information of sc/pwd, creditor, billing

information and billing adjustment Activity

Diagram.

Figure 3: Activity diagram for entering/registering information of

SC/PWD, Creditor’s Information and Billing Adjustment.

SC/PWD, Creditor Information and Billing Adjustment shows how the

user required to fill-up all the needed information before saving or record the

data into the database/system.



Access Granted

Select SC/PWD Information, Credit Card Verification and Billing Adjustment from the menu

Search the name or ID to display information

[Correct]

[Incorrect] User confirm the verify information to the

customer

Display, view the SC/PWD, CC verification and Billing

Adjustment

Verify the recorded data/information in the database/system

Prompt to the user to enter the name

Figure 4: Activity diagram for verifying information of SC/PWD,

Creditor’s Information and Billing Adjustment.

Show the step on how the user can verify information needed using

search engine of the Restaurant Billing System.



Access Granted

Select SC/PWD Information, Credit Card Verification and Billing Adjustment from the

menu

Search the name or ID to display information

[Correct]

[Incorrect] User confirm the

verify information to the customer

Display, view the SC/PWD, CC verification

and Billing Adjustment

Verify the recorded data/information in the

database/system

Prompt to the user to enter the name

Verifying of Information of sc/pwd, creditor,

billing information and billing adjustment Activity Diagram.

Figure 5: Activity diagram for display and view information of SC/PWD,

Creditor’s Information and Billing Adjustment.

Show the process or step on how the user can display and view the

information requested on the database.


Enter their name

Prompt for the Admin to enter their name

Display and view the recorded information into the screen

Select the Report from the menu

Search the date to display information

[Incorrect] The system prompts for the day, month and year of the report[Correct]

The system request the record from the Database Server

Print or Close the Report

File the collected Report

Submit the Report into the Accounting

View and Display of Information of sc/pwd,

creditor, billing information and billing adjustment

Activity Diagram.

Figure 6: Activity diagram for view and display report

Every view and display of report, user must know the date of the

report to enable the user to access the information.


Enter their name

Prompt for the Admin to enter their name

Display and view the recorded information into the screen

Select the Report from the menu

Search the date to display information

[Incorrect]

The system prompts for the day, month and year of the report[Correct]

The system request the record from the Database Server

Checking and comparing the hardcopy report to the softcopy report

Verify the indicated information

Admin has the option to hang on display, view or close the report

Checking and Comparing of Reports Activity Diagram

Figure 7: Activity diagram for Checking and comparing the hardcopy to

the softcopy report.

The diagram shows that the administrator wanted to confirm and

monitor the information given by the department assigned.


Prompt for the User/Manager/Admin to enter their name

Enter their name

Access Granted

After all transaction needed by the users

Users select "Save all" button to save all the transaction completed for the day

Receive confirmation from the system

Exit the System Activity Diagram

Figure 8: Activity diagram for Exit the System

It shows that before the user exit the system they must responsible to

save all the transaction because it would be the assurance of the company.

3.1.3 DATA MODELS DESCRIPTION

3.1.3.1 Data Objects

Administrator Data Object

UserID A unique identifier assigned to the admin to acknowledge some other

sub-system that they can access their system without using another user ID.

Username A unique username assigned to access all subsystem.

Password A unique password assigned to access all sub-system.

UserRole A designation assigned to the admin.

Manager Data Object

UserID A unique identifier assigned to the employee.

Username A unique username assigned to access the system.

Password A unique password together with the username to access the system

and make sure that the system is secured.

UserRole A designation assigned to the manager.

User Data Object

Name The user’s name.

Username A unique username assigned to the user.

Password A unique password assigned to the user.

UserRole An employee designation


SC/PWD Data Object

SC/PWDID A unique identifier assigned to the Senior Citizen and Persons

with Disabilities.

FirstNameThe SC/PWD first name.

MiddleNameThe SC/PWD middle name.

LastNameThe SC/PWD last name.

AddressThe SC/PWD address.

Gender The SC/PWD gender.

ContactNo. The SC/PWD contact number.

Creditor’s Information Data Object

CardNo A unique credit card number assigned to the creditors.

FullName A full name of the creditors.

CardName The name of the credit card of what type is that.

BankName A name of credit card assigned to the creditor.

DOB Adate of birth of the creditor.

PhoneNo A telephone number gives of the creditor.

Country The country live of the creditor.

Expiration The expiration when the credit card cannot be used.

AtmPin The atm pin of the creditor to transact the credit card.

Credit The credit amount to be used of the creditor.

Billing Adjustment Data Object

ORNo.A unique receipt number assigned on each official receipt.

ReservedID A unique reserved ID assigned to the reservation.

CustomerName The customer’s full name.

ReservedDescription The reserved description of all charges of bill.

Charges The charges assigned to the changes of reservation.

Penalty The penalty assigned to the charges of reservation.

TotalAmount The total amount of reservation.


SubTotalThe sub total of reservation.

VatableAmount The vat able amount of the bill.

AmountTender The amount tender of the customer.

Changes The changes done of the customer.

3.1.3.2 RELATIONSHIPS

The Entity Relationship Diagram of Reservation and Point of Sale System that

connected to the Restaurant Billing System.


R.Reservation System

Creditor InformationCard_NoFull_NameCard_NameBank_NameDOBPhone_NoCountryExpirationAtm_PinCredit

Billing Adjustment

Reserved_IDCustomer_NameReserved_DescriptionChargesPenaltyTotalAmountSub_TotalVatableAmountAmountTenderChanges

OR_No.

Send

to

R.Billing System

has

update

connected to

Point of Sale

computes

SC/PWD

SC/PWD_FNameSC/PWd_MNameSC/PWD_LNameSC/PWD_AddressSC/PWD_GenderSC/PWD_ContactNo.

SC/PWD_ID

Bill

OR_DateOrder_IDTable_No.Product_CodeProduct_NameQuantitySellingPriceSub_TotalVatableAmountGCPointsAmountDueAmountTenderChanged

OR_No.

Start

Start

Figure 9: Entity Relationship Diagram of Restaurant Billing System

It shows the connection of billing system to the sub-system of POS

and reservation.

3.1.3.3 COMPLETE DATA MODEL

The relationship between the data objects in section 3.2 re shown in

figure 9


UserUserIDUserNamePasswordUserRole

1

Creditor InformationCard_NoFull_NameCard_NameBank_NameDOBPhone_NoCountryExpirationAtm_PinCredit

BillORNo.OR_DateOrder_IDTable_No.Product_CodeProduct_NameQuantitySellingPriceSub_TotalVatableAmountGCPointsAmountDueAmountTenderChanged

SC/PWDSC/PWDIDSC/PWD_FNameSC/PWd_MNameSC/PWD_LNameSC/PWD_AddressSC/PWD_GenderSC/PWD_ContactNo.Billing Adjustment

ORNoReserved_IDCustomer_NameReserved_DescriptionChargesPenaltyTotalAmountSub_TotalVatableAmountAmountTenderChanges

Figure 10: Complete Data model for Restaurant Billing System

It shows the relationship of how the user can access multiple tables at

one transaction.

3.1.4 FUNCTIONAL MODEL DESCRIPTION

3.1.4.1 CLASS DIAGRAM

The connectivity between different classes is shown in figure 10.


User-userID

-userName-password-userRole +addUser()

+removeUser()

Bill-oRNo.-oRDate-orderID-tableNo

-productCode-productName

-quantity-sellingPrice

-subTotal-vatableAmount

-gcPoints-amountDue

-amountTender-changed

+credit()+scPWD()+gcPoints()

+print()+addBill()

Creditor's Information+cardNo

+fullName+cardNumber+bankNumber

+dob+phoneNo

+country+expiration

+atmPincredit

+register()+check()

+print()

Billing Adjustment

+oRNo+reservedID

+customerName+reservedDescription

+charges+penalty

+totalAmount+subTotal

+vatableAmount+amountTender

+changes

+credit()+print

+addBillingAdjustment()

SC/PWD-scpwdID

-scpwdFName-scpwdMName

-sspwsLName-scpwdAddress

scpwdGender-scpwdContactNo.

+register()+check()

+print()

1 01

0

1

0

1

1

0

0

Figure 11: Class Diagram of Restaurant Billing System

This shows the connectivity between the different classes.

Every transaction has a purpose to make information that can be useful to the

system and company.

3.1.4.2 SOFTWARE INTERFACE DESCRIPTION

3.1.4.2.1 EXTERNAL MACHINE INTERFACES

The software of Restaurant Billing System is capable of

printing reports on a local or network printer. The printer is no less

than.

3.1.4.2.2 EXTERNAL SYSTEM INTERFACES

The Restaurant Billing System will communicate with a JDBC

connection, MySQL connection java 5.1.22-bin .jar with the size of

813kb.

3.1.4.2.3 HUMAN INTERFACES

Every form of the system shall be completely using the

keyboard. In addition, it uses mouse and keyboard combinations.

3.1.4.3 REPORTS

Every report shall contain the following format

Inventory of Generated Reports

Reports Layout


Data Dictionary of Reports

3.1.4.3.1 Inventory of Reports

● SC/PWD Report

● Billing Information (Report)

● Billing Adjustment

● Creditor’s Information

3.1.4.3.2 REPORTS LAYOUT

Billing History (Reports)


Billing Adjustment

Creditor Information

SC/PWD


3.1.4.3.3 DATA DICTIONARY OF REPORT

OR – Official Receipt

GC – Gift Certificate

ID – Identification

RBS - Restaurant Billing System

SC – Senior Citizen

PWD – Person with Disabilities

CI – Creditor’s Information

TC – Take Customer

3.1.5 BEHAVIOURAL MODEL DESCRIPTION

3.1.5.1 DESCRIPTION FOR SOFTWARE BEHAVIOUR

3.1.5.1.1 EVENTS

SC/PWD Class Events

SC/PWD ID

Verifying SC/PWD ID

Record Data

New Registration

Creditor Information Class Events

Creditor ID


Verifying Credit Card No

Record Data

New Registration

Billing Adjustment Class Events

OR Number

Date of Reservation

Update the Billing Adjustment

Record Data

New Billing Adjustment

Billing History (Reports) Class Events

OR Number

Date of Reports

Print Reports

New Reports

3.1.5.1.2 STATES

SC/PWD States Description

Verifying The SC/PWD is the process of being verified.

Registering The SC/PWD is the process of being registered.


Updating The SC/PWD information has been updated.

Saving The SC/PWD that being encoded must be

saving.

Creditor Information States Description

Verifying The creditors is the process of being verified.

Registering The creditors is the process of being registered.

Updating The creditor’s information has been updated.

Saving The creditor’s information that being encoded

must be saving.

Billing Adjustment States Description

Verifying The billing adjustment is the process of being

verified.

Adding Adjustment The billing adjustment is the process of being

registered.

Updating The billing adjustment has been updated.

Saving The billing adjustment that being encoded must

be saving.


3.1.5.2 STATE CHART DIAGRAM

Figure 12: Overall System State Chart Diagram

It includes here how to enter username and how it verifies to access

the system. User has the authority to choose menu according to their

destination of transaction, it shows what the specified ID can be search to

display the needed information. When the user correctly searches the ID or


Start

Enter user

Select Menu

Search ID

Do again

Wait to display on the screen

Register/Add

Information

]Incorrect[

Record/Save

Information

Checking

Save Informat

ionBilling Adjustm

ent

SC/PWD

Creditor Informat

ionBilling History

Exit

Report Print

]Print=yes[

]Print=yes[

]Print=yes[

]* SC/PWD* Creditors Information* Billing Adjustment* Billing History[

]Correct[

date, it can view the recorded information and can validate or verify

information.

3.1.6 RESTRICTIONS, LIMITATIONS, AND CONSTRAINTS

Restrictions

The system will integrate within the existing standalone structure, such as the

database management system.

Limitations

The Restaurant Billing System cannot handle the added and registered user

and employee. Publishing of gift certificate if the customer purchased over a given

amount of restaurants, cannot cover of printing the entire list of orders before issued

in the kitchen and cannot cover of printing billing adjustment when the customer

cancel the reservation. The limitations of the Restaurant Billing System are the online

system and database which cannot operate anytime and anywhere. Also, the proposed

system cannot cover Electronic Fund Transfer (EFT) which is too complicated to use

because of the budget and the price that expensive.

CONSTRAINTS

Major Constraints

The Restaurant Billing System has several major constraints to be considered such as

follows.

Search Engine

- When the user can easily search the needed information into the system.


- When the transaction recorded by the user, it will be the back-up data of

the company.


- When the electricity shut down, there is a strategy to protect and recover

the database to avoid data loss.

3.1.7 VALIDATION CRITERIA

Software validation will ensure that the system responds according to the

users expectations.

Graphical User Interface (GUI)

The user will be responding fasten according to the system user

friendliness.

Search Engine

The user will be easy to locate the information using the search button.


The user will have backup and recovery of data into the database

which once the electricity or human errors occur there is a strategy to protect

and recovered the database to avoid data loss.

Generating Reports

The systems are easy to produce reports because of the user’s recorded

information into the database.

3.1.7.1 CLASSES OF TEST

The Unit Testing will be conducted on entire software systems including:

1. Enter the name

2. Select the Menu


3. Search the ID or Date

4. Validate or Verify

5. Display or view information

6. View report

7. Exit the system

Acceptance Testing will be conducted at the laptop or computer set.

3.1.7.2 EXPECTED SOFTWARE RESPONSE

The software must be intact of making monthly reports per day at the end of a

transaction of a restaurant.

The software must be capable of accessing in other connected system to generate

transaction using the database.

The software should have a search engine for the user to simply look at the

information needed.

The software should have Graphical User Interface (GUI) for the user easy to respond

fasten according to the system friendliness.

3.1.7.3 PERFORMANCE BOUNDS

The proposed system should support minimum up to 50 simultaneous users at any

given time.

The proposed system will provide information by the database management system

with latency without any specified time.

The proposed system should support back-up and recovery to the database.

The proposed system will generate reports in every transaction accomplished by the

user of the system.


The proposed system will support search engine to have the information that the user

can be used.

3.2 SOFTWARE DESIGN SPECIFICATION

3.2.1 INTRODUCTION

The Software Design Specification must include all the necessary

requirements that will be needed; the quality, safety, documentation and description.

It also tells specific examples of how the design of the software or project should be

executed, helping others work properly.

3.2.1.1 GOALS AND OBJECTIVES

Developing the software for Restaurant is an attempt to make the

things (current process) simpler, easier and efficient.

There are many goals for which the software is developed such as:

1. Reduces complexity

2. Cost less

3. Efficient

The software can store information for unlimited number of SC/PWD,

Creditors Information, Billing History (Reports) and Billing Adjustment. It

maintains a database of billing information. All that requires is just a

computer that includes software that can perform various operations such as

registering information of SC/PWD, Creditors Information, and Billing

Adjustment; it also records the registered information and the adjustment of

bill. It reduces complexity, as there certainly any paper and pencil on work is

not needed. Moreover, it cost less to have a computer instead of having large


number of people for various works such as managing transaction and other

for storing records of billing and so on. It can track the Billing History in very

efficient way. So it helps a lot.

3.2.1.2 STATEMENT OF SCOPE

The system software handles the Billing information/records. Not only

billing, it stores information about the SC/PWDs, Creditors Information and

Billing Adjustments. So it can be used to generate reports.

Major Inputs

SC/PWD - id, name, address, gender, and contact no.

Billing History (Reports) - oRNo, oRDate.

Billing Adjustment – oRNo, Date, Time, Remarks.

Creditor Information - CardNo, AtmPin, Credit.

Processing Functionalities

Function Priority

SC/PWD information entry EssentialBilling Adjustment information entry EssentialCreditor information entry EssentialBilling History entry EssentialNotification Future requirements

Outputs


SC/PWD information reports, Creditor Information reports, Billing History

reports and Billing Adjustments Information reports.

3.2.1.3 SOFTWARE CONTEXT

This Restaurant Billing System Software is a very efficient one, which

maintains database of billing and their short and long term activities. And this

software is less expensive and also reduces complexity. In this software we

use Net Beans IDE version 7.3 and MySql (yog) and mysql-connector-java for

the database connectivity. The database search is fast such that the system

responds to all requests within 20 seconds.

3.2.1.4 MAJOR CONSTRAINTS

The software is to run on system with MySql(yog). Therfore the

systems should be properly connected to the mysql-connector-java to access

the database. The system should be good enough to perform all the actions

fast, for example it is recommended that the system should be no older than

PII. The RAM should be no less than 256 MB.

3.2.2 DATA DESIGN

To understand the data design for the Restaurant Billing System, it’s

important to have a look at the overall design of the application. As the application is

being build in Net Beans IDE version 7.3, MySql(yog), and mysql-connector-java

the overall application design can be categorized into two parts based on the above

mentioned application developing languages.

1. Front End Graphical User Interface


Graphical User Interface (GUI)

Java Net Beans is being used for the development of the front end GUI. The

GUI Component temporarily stores the keyboard input by the users till it being used

by the functional procedures. More explanation of the overall GUI and its

components is available in the section 4 of the component.

2. Back End Back-up & Recovery of Data

MySQL(yog) Database

The proponent are using MySQL(yog) database management system at the

back end of storing all information in the form of tables. These tables will be globally

available to all the internal procedures. Mysql-connector-java is being used to

establish connectivity to the database from the application. The DBM System will be

locally available on the machine where the application is running.

For adding, accessing, updating, searching, saving and remove the data we are

using MySQL(yog) queries built in the internal procedures. Rest all the file and

management functionality is being provided by the DBMS.

3.2.2.1 INTERNAL SOFTWARE DATA STRUCTURE

Internal Software data structure is storing and organizing data in a

computer so that it can be used efficiently. Data Structure to manage large

amount of data efficiently such as large database. So that there are no data

structures available to the Internal Software Architecture. The intermediate

information while updating, adding, searching, saving and remove data to any

table in the java swing component JTextField of the GUI. When the add,

update, search, save, and remove button is pressed the information in those

text fields is directly sent to the database for add, update, search, save and

remove. For accessing or viewing any table the data is fetched directly from

the DBMS to the java database object is displayed directly on the screen. For

report printing temporary local variables have been defined in the procedures


with meaningful names to store different values and then print the report.

After finishing those variables are discarded.

3.2.2.2 GLOBAL DATA STRUCTURE

The only kind of data available globally to the whole system is the

database itself stored in MySQL(yog). After the mysql-connector-java any

data stored can be fetched, updated. For more information regarding the

database stored refer to section 3.2.2.4 of the document.

3.2.2.3 TEMPORARY DATA STRUCTURE

The Restaurant application does not use any intermediate temporary

files of its own. As data is being stored in a DBMS until the command

“Commit” is being executed in the MySQL(yog) query by the application.

Hence no intermediate files or data structures are used.

3.2.2.4 DATABASE DESCRIPTION

Below are mentioned all tables, their corresponding attributes and a

small description of each.

Table Name: billing_seniorPWD

Attributes: SC/PWD ID, First Name, Middle Name, Last Name, Address,

Gender and Contact No.

Descriptions:

It holds all the general information of all SC/PWD of RBS Data.

Primary Key of this table is SC/PWD ID.


Table Name: billing_creditcard

Attributes: CardNo, FullName, CardName, BankName, DOB, PhoneNo,

Country, Expiration, AtmPin, Credit.

Descriptions:

It holds all the general information of all Creditors of RBS Data.

Primary Key of this table is Creditor ID.

Table Name: Billing History

Attributes: OR NO, OR Date, Order ID, Table No, Product Code, Product

Name, Quantity, Standard Price, Sub Total, GC Points, Payment Option, Date.

Descriptions:

The purpose of this table is to keep the record of Billing receive from

the POS that can be the reports of the RBS. OR NO is the primary key for this

table.


3.2.3 ARCHITECHTURAL AND COMPONENT LEVEL DIAGRAM

3.2.3.1 ARCHITECHTURAL DIAGRAM

Figure 12: Architectural Context Diagram of Restaurant Billing System

The Architectural Context Diagram for the software is shown below. As it is

clear from the diagram, various actors are manager, admin staff and cashier, which

use the system. The subordinate systems that will be used by the software are the

database (MySql (yog)) and Java Net Beans. Also mysql-connector-java is required to


Setting

Manager

Admin Staff

Cashier

Restaurant Billing System (RBS)

Java (and connector-

java)

Database (MySql(yo

g))

Reservation Staff

ARCHITECHTURAL

COMPONENT DIAGRAM

OF RBS

connect java to database. Setting or Maintenance System is subordinate, which needs

the software for testing and maintenance purposes.

3.2.3.2 DESCRIPTION OF COMPONENTS

3.2.3.2.1 COMPONENT CASHIER

3.2.3.2.1.1 Processing Narrative of Component Cashier

The Component Cashier consists of the class. User, it

contains attributes, which are the major and minor

responsibility in the Restaurant System. It contains the

functions to set and get the related data into and out of the

database. It contains the data and functions to get the log-in

access. Since the cashier is also an employee of the Restaurant,

the component would have access to the basic data of the

employee. The responsibilities of this component are to set and

get the basic and major of SC/PWD, Creditor Information and

the Billing History.

3.2.3.2.1.2 Interface Description of Component Cashier

The Component Cashier has an interface with the class

Employee. As the cashier is an employee it has access to the

Employees Class, SC/PWD Class. Creditor Information Class,

and Billing Information Class and inherits the attributes and

functions of that class through the interface. Using this

interface the basic data can be getting up from the database.

3.2.3.2.1.3 Algorithmic Description of Component Cashier

Component Cashier;


The intent of this component is to get basic data of SC/PWD,

Creditor Information and Billing Information into the database.

Start

Set the data into the database

Get the data from the database

End

3.2.3.2.1.3.1 Restrictions/Limitations

This Component can only be called the user wants to

clarify the SC/PWD, Creditor Information, Billing Information

and Billing Adjustment.

3.2.3.2.2 COMPONENT MANAGER

3.2.3.2.2.1 Processing Narrative of Component Manager

The Component Manager consists of the class. User, it

contains attributes, which are the major and minor

responsibility in the Restaurant System.

The responsible of this component is to print and view,

register, update, and removes the data. This component sets

data into the database and performs on the data to print the

reports.

3.2.3.2.2.2 Interface Description of Component Manager

The Component Manager has the interface with the

SC/PWD, Creditor Information, Billing Information and

Billing Adjustment. As the manager is the employee, it

inherits the data members and functions from the class of


SC/PWD, Creditor Information, Billing Information and

Billing Adjustment to print the reports.

3.2.3.2.2.3 Algorithmic Description of Component

Manager

Component Manager;

The intent of the component manager is to add/register,

update, remove, view, view all, and print.

Start

Register, add, the SC/PWD, Creditor Information, Billing

Information and Billing Adjustment

Update the SC/PWD, Creditor Information, Billing


Remove the SC/PWD, Creditor Information, Billing


Search the SC/PWD, Creditor Information, Billing


View/View all the SC/PWD, Creditor Information, Billing


Print the reports of SC/PWD, Creditor Information, Billing


End

3.2.3.2.3 COMPONENT RESERVATION STAFF

3.2.3.2.3.1 Processing Narrative of Component Reservation

Staff


The Component Reservation Staff consists of the class.

User, it contains attributes, which are the minor responsibility

in the Restaurant System.

The responsible of this component is to add, verify, and

print the bills of Billing Adjustment and the Credit Card

information in the Billing System. The component sets and gets

the basic and major data into the database and performs on the

data to print the bill.

3.2.3.2.3.2 Interface Description of Component Reservation

Staff

This component has the interface with the Billing

Adjustment and Creditor Information. As the Reservation staff,

it inherits the data members and functions from the class

through the interface. Using this interface the basic data of

Billing Adjustment and major data of Creditor Information can

be set and get from the database.

3.2.3.2.3.3 Algorithmic Description of Component

Reservation Staff

Component Reservation Staff;

The intent of the Component Reservation Staff is to set

and get the basic and major data of Billing Adjustment and

Creditor Information into the database.

Start

Add the Billing Adjustment data into the database

Verify the Credit Card data into the database

Print the Bill Adjustment data


End

3.2.3.2.4 COMPONENT REPORTS

3.2.3.2.4.1 Processing Narrative of Component Reports

The Component Reports consist of the class of Billing

History (Reports). The responsibility of this component is to

print the data and information. This component gets the data

through various interfaces described in the next section to print

the reports.

3.2.3.2.4.2 Interface Description of Component Reports

The component report has the interface with the classes

Billing Information. It inherits the data members and functions

from the print of data reports.

3.2.3.2.4.3 Algorithmic Description of Component Reports

Component Reports;

The intent of this component is to print the reports

Start

Get the Billing Information data

Print the Billing Information report

End

3.2.3.3 DYNAMIC BEHAVIOUR FOR COMPONENT

3.2.3.3.1 INTERACTION DESIGN


This is the sequence diagram where the use case, component is

a cashier. The first event is to enter the system. A request lookup event

is passed to the system that looks up the username in the software

system and returns a result (found or not found) to monitor. A valid

username results in a username=correct event to software system

which then gives access to the cashier and the cashier can register,

update, verify and save the data of SC/PWD, CCV, Billing

Information and Billing Adjustment. This data can be displayed on the

monitor or record using the software system.

Figure 13: Cashier Interaction Diagram (Figure a)


Cashier Monitor R. Billing System

Verify & Record

Reading

]Enter Username & Password[

]Username & Password Correct[

]Request Lookup[

]Result[

]Give access to the Cashier[

]Cashier Adding/Registering and record of all oother[

Display Data Printing Data

This is the sequence diagram where the use case component is a

manager. The manager enters a username. A request lookup event is passed to

system that looks up the username in the software system and returns a result

(found or not found) to monitor. A valid username results in a

username=correct event to software system which can view and print the data

of all other SC/PWD, Creditor Information, Billing Information and Billing

Adjustment, depending upon their access level. This data can be displayed on

the monitor and print upon request.

Manager Interaction Diagram (Figure b)


Manager MonitorR. Billing System

Printing

Reading



]Request Lookup[

]Result[

]Give access to the Manager[

]Manager adding, update, verify, remove, filling report, and print report[

Display Data Printing Data

This is a sequence diagram where the use case component is Admin

staff. The Admin staffs enter a username and password. A request lookup

event is passed to system that looks up the password in the software system

and return a result (found or not found) to monitor. A valid username result in

a name=correct event to software system which then gives access to the

Admin staff and it can view and verify the data of all other SC/PWD, Creditor

Information, Billing History (Reports) and Billing Adjustment depending

upon his access level. This data can be displayed on the monitor or verified

using the Restaurant Billing System software.


Admin Staff Monitor R. Billing System

View/Checking

Reading



]Request Lookup[

]Result[

]Give access to the Admin Staff[

]Admin Staff checking and verifying the weekly, monthly or yearly reports[

Display Data

VerifyingData

Admin Staff Interaction Diagram (Figure c)

This is the sequence diagram where the use case component is

a Reservation staff. The Reservation staffs enter a username. A request

lookup event is passed to the system that looks up the name in the

software system and returns a result (found or not found) for monitor.

A valid name results in a name=correct event to system software

which then gives access to the Reservation staffs.


Reservation Staff Monitor R. Billing System Verify/Record

Reading



]Request Lookup[

]Result[

]Give access to the Reservation Staff[

]Reservation Staff adding/verifying BillingAdjustment and Creditor Information[

Display Data Saving Data

Reservation Staff Interaction Diagram (Figure d)

3.2.4. USER INTERFACE DESIGN

The Applications has a Graphical User Interface, which is built completely in

Java. Among the variety of libraries available in Java we have chosen Java Swing

library for the development as more variety of component are available in it and more

sophisticated techniques are available to change to appearance of those components if

required in future.

3.2.4.1 DESCRIPTION OF THE USER INTERFACE

3.2.4.1.1 SCREEN IMAGE

The GUI for the Restaurant Billing System has been kept quite

simple and follows a conventional style. It is very user friendly and

has not required any training to work on it.

Below is a detailed images and description of the GUI. The

object and actions performed when you clicked them are also

identified.

The first images of the Log-in screen. The user is supposed to

have a log-in and password in order to log onto POS. Otherwise,

Billing System user’s supposed to have enter their name in order to

access the system. Username and password can only create by the

Administrator staff of the company.


LOG IN

After entering the username and password you click on Login button

and the program verifies the information entered. Upon verification the

program, either it allows log-in or there will be a message that

displayed that it was not verified or an access denied.

The program also checks whether the user is a Manager,

Reservation staff, Administrator staff or Cashier depending upon this

information/designation. The program gives the respective interface

hence there by restricting user to perform any other task except that

can be performed by them.

Below is the Manager interface. The interface has only those

options that are accessible to a manager.

MAIN MENU FORM INTERFACE IMAGE


This above GUI is also self-explanatory. The Manager is

supposed to click on any of the available options to register, update,

remove, view all and print of SC/PWD, Creditor Information, Billing

History (Reports) and Billing Adjustment reports and About Us.

Now the respective Administrator staff interface is shown

below.

ADMIN STAFF INTERFACE IMAGE

Then the Cashier staff interface is shown below

Shown that all four interfaces for Manager, Administrator,

Cashier, and Reservation staffs has a differ options. That way, access

levels are restricted. Also, all four GUI follows the same convention.

Log-out and exit command buttons are also provided in each interface.

Now, when you click on any available options, another

window appears and it has sub-options for the particular menu. For

instance, for the cashier option in the manager interface above is the


sub option window that opened up. The choices are either save, save

all, register and search a particular data.

IMAGE OF POS CASHIER INTERFACE

1. Senior Citizen/ Person with the Disabilities (SC/PWD)

2. Creditor Information Form


3. About Us

The Logout command button quits the application.

Now, when you click on SC/PWD, Creditor Information,

Billing History (Reports) and Billing Adjustment button the follow


form appears where in first thing will do is SC/PWD ID, Card No and

OR No to verify the information needed. When the information

doesn’t exist in the database the cashier will need to register the

information in the respective text fields. It must be click the update

button to be recorded on the database.

Otherwise, if you click update button in the particular window

shown above, you’ll need to search for the particular SC/PWD ID,

Creditor ID and OR No. in order for you to update the details and

information. You can either search the corresponding entry by the

name, Card No, OR No. if there is no entry at all in the database, and

then a message is being displayed on the screen. You cannot either edit

the information or cannot be deleted. It only removed when you are

manager.

Exactly same window appears when it clicked on Reservation

staff and it shown below.

RESERVATION IMAGE

4. Billing Adjustment


This above GUI is also self-explanatory. The Reservation staffs

are supposed to click on some of the available option that the program

gives privilege to display the information in the database.

The option that the Reservation staff can allow is to add the

Billing Adjustment and print the bill and verify the Credit Card

information in the database.

Otherwise, if you click the search button in the particular

window shown above

3.2.4.1.2 OBJECTS AND ACTIONS

The above shown GUI window consists of java swing

components. A frame of size 1000*700 is being used as a container for

other components. The frame consists of JLabel for displaying text.

The Text field for entering/updating the text. JButon command is used

for execution of procedures. Table for viewing the specific data,

JCombo Box for choosing an option what particular data can be use.

3.2.4.2 INTERFACE DESIGN RULES

To improve the usability of an application it is important to have a

well design interface. These “Eight Golden Rules of Interface Design are a

guide to good interaction diagram.

1. Strive for consistency.

Consistent sequences of actions should be required in similar

situations; identical terminology should be used in prompts, menus, and help

screens; and consistent color, layout, capitalization, fonts, and so on should be

employed throughout. Exceptions, such as required confirmation of the delete

command or no echoing of passwords, should be comprehensible and limited

in number.

2. Cater to universal usability.


Recognize the needs of diverse users and design for plasticity,

facilitating transformation of content. Novice to expert differences, age

ranges, disabilities, and technological diversity each enrich the spectrum of

requirements that guides design. Adding features for novices, such as

explanations, and features for experts, such as shortcuts and faster pacing can

enrich the interface design and improve perceived system quality.

3. Offer informative feedback.

For every user action, there should be system feedback. For frequent

and minor actions, the response can be modest, whereas for infrequent and

major actions, the response should be more substantial. Visual presentation of

the objects of interest provides a convenient environment for showing changes

explicitly.

4. Design dialogs to yield closure.

Sequences of actions should be organized into groups with a

beginning, middle, and end. Informative feedback at the completion of a

group of actions gives operators the satisfaction of accomplishment, a sense of

relief, a signal to drop contingency plans from their minds, and an indicator to

prepare for the next group of actions. For example, e-commerce web sites

move users from selecting products to the checkout, ending with a clear

confirmation page that completes the transaction.

5. Prevent errors.

As much as possible, design the system such that users cannot make

serious errors; for example, gray out menu items that are not appropriate and

do not allow alphabetic characters in numeric entry fields. If a user makes an

error, the interface should detect the error and offer simple, constructive, and

specific instructions for recovery. For example, users should not have to

retype an entire name-address form if they enter an invalid zip code, but rather

should be guided to repair only the faulty part. Erroneous actions should leave


the system state unchanged, or the interface should give instructions about

restoring the state.

6. Permit easy reversal of actions.

As much as possible, actions should be reversible. This feature relieves

anxiety, since the user knows that errors can be undone, and encourages

exploration of unfamiliar options. The units of reversibility may be a single

action, a data-entry task, or a complete group of actions, such as entry of a

name-address block.

7. Support internal locus of control.

Experienced users strongly desire the sense that they are in charge of

the interface and that the interface responds to their actions. They don’t want

surprises or changes in familiar behaviour, and they are annoyed by tedious

data-entry sequences, difficulty in obtaining necessary information, and

inability to produce their desired result.

8. Reduce short-term memory load.

Humans’ limited capacity for information processing in short-term

memory (the rule of thumb is that we can remember "seven plus or minus two

chunks" of information) requires that designers avoid interfaces in which

users must remember information from one screen and then use that

information on another screen. It means that cell phones should not require re-

entry of phone numbers, website locations should remain visible, multiple-

page displays should be consolidated, and sufficient training time should be

allotted for complex sequences of actions.

These underlying principles must be interpreted, refined, and extended for

each environment. They have their limitations, but they provide a good

starting point for mobile, desktop, and web designers. The principles

presented in the ensuing sections focus on increasing users’ productivity by

providing simplified data-entry procedures, comprehensible displays, and


rapid, informative feedback to increase feelings of competence, mastery, and

control over the system.

3.2.4.3 COMPONENT AVAILABLE

Java swing library have many component available but for now only

JFRAME, JTextLabel, JTextField, JTable, JPanel, JScrollPanel, JComboBox,

JButton, have been added to the action listener.

3.2.4.4 UIDS DESCRIPTIONS

The Graphical User Interface are usually performed through direct

manipulation of the graphical elements. There’s a user interface development

system has been used in the development of the Restaurant Billing System.

Reports

Reports In addition to producing day to day transaction reports (e.g. a

Billing Information should provide an information that save by the Cashier,

SC/PWD & Credit Card Verification) a system must produce daily transaction

reports (SC/PWD, Credit Card Verification, Billing Information and Billing

Adjustment) for the management (e.g. daily, monthly or yearly)

3.2.5 RESTRICTIONS, LIMITATIONS, AND CONSTRAINTS

a. Only the Cashier, Reservation Staff and Manager can register the

SC/PWD, Credit Card, Billing Information and Billing Adjustment.

b. Every User should have ID and Password to access the Billing

Information

c. The functions and data members of the component are called only

when the user requires to the server to access database.

d. The software is run on a system, with MySQL(yog) Therefore the

system connected to the server to access database.


e. The software should be designed in such a way that the processing

speed of the operation should be high such as 3.00GHz

3.2.6 TESTING ISSUES

Test strategy and preliminary test case specification are presented in this

section. The various tests to be conducted to validate the software developed are login

test, SC/PWD information testing and Billing Adjustment Information testing.

There are two types of testing techniques, Black Box Testing and White Box

Testing. In Black Box Testing it ignores the internal mechanism of the system and

focuses on the output generated against any input and execution of the system. It is

also called functional testing. In White Box Testing, it takes into account the internal

mechanism of a system. It is also called structural testing and glass box testing. Black

Box Testing is often used for validation and White Box Testing is often used for

verification.

Classes of Testing

Description Expected Software Response

Performance Bounds

Components to be

identifiedLogin This test class is

defined to The user will be able to

The users should not


validate whether the users are able to login with their username and password.

login when their enters the username and password

login if enters a wrong username and password.

Test

SC/PWD

This test class is defined to verify whether the information made by the user is recorded into the database.This test class is defined to verify/add whether the information is inputted to be recorded into the database.

The Cashier and Manager will be able to verify when they enter the SC/PWD ID into the search engine.The cashier and manager are not able to verify / add if she did not supply the unfilled information.

The cashier and manager were not able to verify if enter wrong id or name in the search button.The Cashier The Cashier and Manager should not able to verify if enters a wrong ID or name in the search button.

Manager, Cashier

Test

Creditor

This test class is defined to verify whether the information made by the user is recorded into the database.This test class defined to register/add whether the information is inputted to be recorded into the database.

The Cashier and Reservation Staff will be able to verify when they enter a correct data in a search engine.The Cashier and Reservation Staff will be able to register/ add when he enters all information to be recorded into the

The Cashier and Reservation Staff should not be able to verify if a wrong data enters into the search button.The Cashier and Reservation Staff should not be able to register / add if there is blank filled information that wasn’t

Cashier, Reservation Staff


database supply.Test Billing

Adjustment

This test class is defined to update the information from the reservation system to be recorded into the database.

The Reservation Staff or Cashier will be able to update information when he enters all information to be recorded into the database.

The Reservation Staff or Cashier should not able to record the information when there is blank field information that wasn’t inputted.

Reservation, Cashier, Manager

Test Billing

History

(Reports)

This test class is defined to add bills made by the cashier to be recorded into the database and be the reports of the company.

The Cashier will be able to add bills when he punch the orders and computes the total amount.

The Cashier should not be able to add bills if the orders are not inputted.

Cashier

4.0 TESTING System testing is the testing to ensure that by putting the software in different

environment (e.g. Operating System) it still works. System testing is done with full system

implementation and environment.

After the system testing, the proponents test every the proposed system transaction

and process of occur in the Restaurant Billing System, will serves as a corrector to see the

errors in the system.

Log in

To access the system the user should input a unique username and password. When

the username and password are correct then when you accessing the system of billing it will

automatically access the Welcome Form or Main Menu of the billing system. If the username

and password are incorrect the user have a three attempts to access the system, otherwise, the

system will be terminated.


The proponent will found out they can provide alternative way before the system

terminated. For example, they forgot the username and password, there will be a pop-up

message that can help them to give them a hint to forget username and password.

Note:

For POS user, there is still username and password needed to access the billing

system to transact the system. The POS has a limited access in the billing system. He can

only access the adding/registering the information of SC/PWD, Creditor Information, Billing

Adjustment and Generating reports and at the same time record it into the database for make

sure that all transaction are generated in weekly, monthly or yearly reports.

For Reservation, the user should input a username and password to enter the billing

system. The reservation staffs have also limited access. He can only access the creditor

information for verifying then when the information is not in the database he will register and

record it. Reservation staff is also responsible for updating the billing adjustment for also

backing-up in the database.

The log in form has an access level where the user has a limited access depends on its

designation and responsibility.

Accessing the System

When the user successfully login in to the system, the user can choose which

transaction they can work on the Main Menu Form. The common transaction of the user is to

verify the SC/PWD and Creditor Information if the needed information of the customer is

already register.

If the user validate that the customer information are already register the user will go

back to the main menu to transact the bill of the customer. If not, the user must register the

customer information to be recorded in the database. After updating registered customer they

can transact their bill in to the POS system.


Billing Adjustment for Reservation

The reservation staff must access first the billing system then he she select the credit

card verification to verifies the basic information of their reserve customer, once the

reservation staff verifies those information, he/she will register or add the billing adjustment

which includes the amenities, charges, and penalties. Reservation staff is responsible to

update the database of the billing system to make sure that all information made in the

reservation system is also update in billing.

Billing History (Reports)

When the cashier done the transaction which the ordering the cashier generate bill

which contains of orders of the customers. The billing history will be recorded of the billing

system. The only responsibility of billing system is to store important data of P.O.S and

Reservation System.

The proponents done a unit testing, the testing of an individual unit or group of

related units. It is often done by the programmer to test that the unit he/she has an

implemented is producing expected input.

Integration testing, testing in which group of components are combine to produce

output. Also, the interaction between software and hardware is tested in integration testing if

software and hardware components have any relation.

5.0 EVALUATIONThe proponents evaluate the system by its uses, Findings, analysis and also by

recommendation.

Findings

Manual testing is as old as computer programming. After all, most systems are

designed to be used by someone/person.


Anyone can try out a system, just by using it and also understand it to be able to do

the task more in that system. But testing it fully is an engineering discipline. In this project

Study the proponents do some testing to find the errors in the system to know what will be

the output. When the testing was done, the proponents got some findings on each scenario.

In accessing the system, it is really easy by logging-in in the Restaurant Billing

System, but the user should be registered in the database of the system to access and can use

the system. The scenario in main menu, the user can open and do multiple transactions

without closing the other window. The other buttons in main menu like SC/PWD, Billing

Info, Creditor Information and Billing Adjustment Information are automatically backed up

in the database once the user use and do some transactions.

Testing and do some findings in the system help to develop the system well, find bugs

efficiently; and conversely, can provide better confidence that the system is ready to be

released.

Analysis

The proponents analyze the system first before it was presented. The security and

functionality of the billing system is the most priority of the proponents. It’s better to build

security and functionality of every transaction from the start.

In design decisions, it is very hard to correct and create a better graphical user

interface, the proponents had frequent reviews and concentrate on the broad architecture for

the efficient and satisfaction of the user, a user friendly GUI and easy to understand the

system.

System element things like database engines. Each of these is itself a complex

system that needs to be analyzed. Establish the properties of each element: where its inputs

come from,

What its outputs are, what can happen if something is corrupted?


Backup and recovery, it is important and necessary to have a back up of every data

and transaction when using the system to have a record and avoid data loss.

Lastly, analyzed what part of the design seems problematic to make some action

sooner and be fixed.

Lessons Learned

Doing this Project Study is a big challenge for the proponents/students. Researchers

should take a lot of time, effort, and patience and be intelligent in decision making. Being a

team proponents have to exercise to trust one another, be like brothers and sisters, exchange

ideas and suggest more valuable information. Cooperation and patience are the best

ingredients when working in a stressful situation.

Proponents discovered to explore real world problems and challenges. With this type

of active and engage learning, students are inspired to obtain a deeper knowledge of the

subjects they’re studying. Students can learn through questioning, inquiring and critical

thinking.

While fulfilling this partial requirements, proponents didn’t noticed that their

growing, enhancing their communication skills and boost their self- confidence.

“One of the major advantages of project work is that is makes school more like real

life.” –Sylvia Chard, University of Alberta.

Recommendation

The proponents recommend to the future researchers to apply an automated system

for discovering traffic anomalies on a statistical basis as an essential part of the billing

system. It’s recommended to apply only personal accounts to access to the management

interfaces of the communication hardware. The usage of the group accounts is not

recommended if the communication facility provides enough personal accounts. The

confidential information related to network management system is protected by the network

security facilities or by using isolated network segments.


Concrete suggestions for improvement are better than “this rots”. Suggestions should

be realistic in terms of cost, benefit, and business situation. Security is engineering; it’s not

an absolute goal to be pursued at any cost. There are always legacy systems you can’t touch.

Evaluation to the System

6.0 CONCLUSION AND FINDINGS

The proponents concluded, in accessing the system, it is really easy by logging in, but

the user should be registered in the database of the system to access and can be use the

system. The scenario in main menu which consist of SC/PWD, Creditor Information, Billing

Adjustment and Billing History (Reports) can open and do multiple transactions without

closing the other window. The other buttons in main menu like SC/PWD, Billing

Info/History and Creditor Information are automatically backed up in the database once the

user use and do some transactions.

The proponent concluded that this system will be more easy and understandable

because of the Graphical User interface or should we say the User Friendliness, because of

this feature the user will have a mood to do many works so that the company will improve as

the employee’s performance. It’s more applicable to use because it’s providing the search

engine that will be easy to find the information needed in the database record by the user or

cashier log-in. Give the accomplishment to do more the weekly, monthly or yearly reports of

billing system.

Future Suggested Researchers

To enhance and improve the Restaurant billing system, the proponents suggest that

take a lot of research, go to any libraries that can help to understand the system well. Go to

the company that will giving you more information especially you got to interview some

biggest people to gather the important information regarding to your documentation, research

or thesis.


For the future researchers, the proponents suggest that it should be realistic in terms

of cost, benefit, business situation and so on. Be open to all the possibilities and problems

you can encounter while creating a system so that the problem you encounter will be the aim

for you to be aggressive to find the needed information to solve it. Don’t be afraid in asking

questions and gathering information, more information much better. Meet the requirements

and comply.

Theirs is no perfect system but there always be a development and improvement for

creating a new one. That will be the biggest accomplish that you will develop a system

someday and it’s possible that this thesis will also be a big help to you to be done your work

or project.

There are always legacy systems you can’t touch. And always remember that always

be patient and bring your heart in the thesis/project/research/document you’ve work at.


restaurantbillingsystem-4103-03a.weebly.com€¦ · web viewatmpin the atm pin of ... the...

Documents