CHAPTER III

MATERIALS AND METHODOLOGY

This chapter discusses the materials and methodology used by the

researchers in gathering data for the proposed system in Mj’s Hair Expert

and Nail Bar Salon management.

Research Design

This study used a descriptive research design that is suitable for

illustrating the system's functions. Gathering of data through research,

interview and survey questionnaire were utilized by the researchers in

this study. The research subjects were the salon's employees and the

owner.

Figure 3.1. The Modified Waterfall Model

 This figure shows the development process of the study which follows

several stages presented in the next page.

Modified model is that the phases in the modified waterfall model life cycle

are permitted to overlap. Since the phases overlap, a lot of versatility has been

implemented in the updated software engineering model. Around the same time,

a variety of activities will run concurrently, meaning that the technical flaw is

removed at the development stage itself and the operating expense of making

adjustments to the software before deployment is spared.

The researchers used this method in the system because it is flexible and

easy to modify. It is also possible to make improvements to the original

configuration at the same time as a variety of steps are involved at one point of

time. In the event that any mistakes are implemented as a result of the

improvements made, it is often simple to fix them because each step of the model

testing and validation process has been added. That will also reduce the number

of paper works, and we will have more time to do the system.

Requirements

This is the phase where solutions were identified to what is needed to be

done to the system. The researchers gathered information through investigating

the nature of the application.

22
Designing

This phase discusses all the activities involved in conceptualizing, framing

implementing and modifying complex systems.

Coding

This phase is where we started doing our programming codes. Slowly by

slowly we made progress and did percentages of the system’s process.

Integration In this phase, we gathered all the data and made the project possible

by integrating the design with our program codes.

Deployment

In this phase the researchers finished the needed for the system. This time

the process of developing the application is done and is ready for the user to try.

Maintenance

This phase only serves to enhance the system with possible future updates

which might affect the system process, and so, maintenance is needed.

Project Environment

Locale

The proponents conducted the research study at Mj’s Hair Expert and Nail

Bar Salon and the respondents would be the staff and the owner working in the

salon.

23
Population of the study

There were eight respondents of this study who were the employees of the

Mj’s Hair Expert and Nail Bar Salon including the owner of the salon. These are

the employees who have worked to manage the salon manually. The results of

the survey were treated statistically through the use of the weighted mean.

Research Instrument

The researchers used interview guide questions and survey questionnaires

to collect the relevant data order to accomplish the study. Questions from the

Interview Guide will be used to classify the issues faced by the respondents while

the survey questionnaire will be used during the implementation of the system.

Statistical Tool

The researchers used purposive sampling to focus on particular

characteristics of a population that are interested in the study, which is best

enabled to answer research questions. Typical case sampling is a type of

purposive sampling and to focus on “typical” or “average” members of the

population.

24
Time Table

Table 3.1. Gantt chart (December 2020- May 2021)

ACTIVITIES Online Project Planning and Progress Monitoring

System

Dec Jan Feb Mar Apr May

Research

Planning

Documentation

Design

Implementation

Deployment

This table shows the progress of our research and implementation.

The progress of research is shown in Table 3.1 Including its

implementation. First, the researchers have started to gather Information on the

1st of December until the last week of January to know what is going on. It's all

about the interactive learning tool. Then, with the development of the system, it

was the manuscript. In addition, all data and information collected was

documented by the researchers

25
 In addition, the researchers documented all data and information gathered.

After the research, planning and documentation the researchers will implement

their proposed research study. And lastly, the system used was tested and

deployed.

Data Gathering Instruments

The instruments used in the gathering information are research, interview

and survey.

Data Gathering Procedures

1. Asking permission.

Researchers asked for approval with respect to their proposed

system. They would be able to formulate questions.

2. Formulate Questions

Researchers formulated questions in order to conduct interviews.

3. Conduct interview

Researchers conducted interviews in order to gather problems.

4. Transcribe interview

Researchers noted the significant information stated by the

interviewed person.

5. Validate Transcription

Documents are gathered data for validating the information.

26
Methodology

This section contains the following: Software design, Requirement

analysis, Cost benefit analysis, Development, and Verification, Validation, and

testing.

Requirement Specification

This section includes a use-case diagram and use-case specification

related to functions of the system.

Conceptual Framework

INPUT PROCESS OUTPUT

Figure 3.2 IPO Diagram

This shows the IPO (Input-process-output) diagram of the system

Manual Record of
Record of Sales, Sales, inventory, More Record
Inventory, that contains
INPUT

Scheduling and INPUT

Scheduling, Errors, Wasted

payroll for the
time and effort
Payroll Salon

Figure 3.3 Existing System Diagram

This is the existing system diagram illustrates the problem in the manual
style and system of the company; record that contains errors and wasted time and
energy.

27
 Record of Sales,
Inventory of Stocks, Less error of
Computerized
Profiling, Payroll, records,
Records and
Appointment and
Transactions for Saves time and
Biometric
INPUT
INPUT

the Salon effort efficiently

Fingerprint for
attendance

Figure 2.3 Researcher’s Proposed System

This is the researcher’s proposed diagram shows the solution to problem;

less errors and saves time and effort efficiently.

A.) Use Case Diagram

Use Case diagrams use to describe activities (use cases) performed by

the system (subject) in collaborate with one or more external users of the system

(actors). Figure 3.4, Figure 3.5, Figure 3.6, Figure 3.7, Figure 3.8 and Figure 3.9

displays the interaction between the customer, owner and receptionist inside the

system.

28
a.) Profiling Management

Figure 3.4: Proposed Profiling Management Subsystem for Beauty Salon

29
b.) Sales Management

Figure 3.5: Proposed Sales Management Subsystem for Beauty Salon

30
c.) Inventory Management

Figure 3.6: Proposed Inventory Management Subsystem for Beauty Salon

31
d.) Appointment Management

Figure 3.7: Proposed Appointment Management Subsystem for Beauty Salon

32
e.) Payroll Management

Figure 3.8: Proposed Payroll Management Subsystem for Beauty Salon

33
f.) Biometric Fingerprint Attendance

Figure 3.9: Proposed Biometric Fingerprint Attendance Subsystem for Beauty

Salon.

34
B.) Use Case Specification

Profiling Management (Table 3.2)

Use Case Name: Add staff details
Scenario: Owner will add a new staff profile to the system
Triggering Event New staff
Brief Description: The owner will add the details of the new staff.
Actors: Owner
Stakeholders: Owner
Preconditions: The staff’s is not existing in the system
Post conditions: The owner/receptionist will receive the staff’s details
Flow of Events:

Actor System

1. Owner will look up

staff
2.1 Display staff details
2. Owner will receive
staff’s details
Exception Conditions:
If the staff’s details do not exist in the system,

a. Proceed to adding a new staff

Use Case Name: Update staff details
Scenario: Owner will change staff details
Triggering Event Changes in staff details
Brief Description: The owner/receptionist will update the staff’s details.
Actors: Owner
Related Use Cases: Extends: Add staff details
Stakeholders: Owner
Preconditions: The staff’s details exist in the system
Post conditions: The staff’s details must be updated
Flow of Events:

Actor System

35
 1. Owner inputs the 1.1 Update staff details
staff's details that
need updating.

2. Owner verifies the 2.1 Display updated

updated staff details.
staff details

Exception Conditions:
If there are no changes in the staff’s profile.

a. Cancel update
Use Case Name: View staff details
Scenario: Owner looks up staffs’ details
Triggering Event View staff details
Brief Description: The owner will view the staff’s details in the system.
Actors: Owner
Stakeholders: Owner
Preconditions: The staff’s details exist in the system
Post conditions: The owner will receive the staff’s details
Flow of Events:

Actor System

1. Owner will look

up staff

2. Owner will receive

staff’s details 2.1 Display staff details

Exception Conditions:
If the staff’s details do not exist in the system,

a. Proceed to adding a new staff

Use Case Name: Add company details
Scenario: Owner will add a company profile to the system
Triggering Event Add company profile
Brief Description: The owner will add the details of the company.
Actors: Owner
Stakeholders: Owner
Preconditions: The company details do not exist in the system
Post conditions: The owner will receive the staff’s details

36
Flow of Events:

Actor System

1. Owner will look up

company details
2.1 Display staff details
2. Owner will receive
staff’s details
Exception Conditions:
If the staff’s details do not exist in the system,

a. Proceed to adding a new staff

Use Case Name: Update Company details
Scenario: Owner will change company details
Triggering Event Changes in company details
Brief Description: The owner will update the company details.
Actors: Owner
Related Use Cases: Extends: Add Company details
Stakeholders: Owner
Preconditions: The company details exist in the system
Post conditions: The company details must be updated
Flow of Events:

Actor System

1. Owner inputs the 1.1 Update company

company details that details
need updating.

2. Owner verifies the

updated company 2.1 Display updated
details. company details
Exception Conditions:
If there are no changes in the staff’s profile,

a. Cancel update
Use Case Name: View company details
Scenario: Owner looks up company’s details
Triggering Event View company’s details
Brief Description: The owner will view the company’s details in the system.
Actors: Owner

37
Stakeholders: Owner
Preconditions: The company details exist in the system
Post conditions: The owner will receive the company details
Flow of Events:

Actor System

1. Owner will look

the up company

2. Owner will
receive company 2.1 Display company
details details
Exception Conditions:
If the company details do not exist in the system,

a. Proceed to adding a company detail.

Use Case Name: Add customer details
Scenario: Receptionist will add a new customer profile to the system
Triggering Event New customer
Brief Description: The receptionist will add the details of the new customer.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The customer’s details do not exist in the system
Post conditions: The receptionist will receive the customer’s details
Flow of Events:
Actor System

1. Receptionist will
look up customer
2.1 Display customer’s
2. Receptionist will details
receive customer’s
details
Exception Conditions:
If the customer’s details do not exist in the system,

a. Proceed to adding a new customer

Use Case Name: Update customer details
Scenario: Owner will change customer details
Triggering Event Changes in customer details
Brief Description: The receptionist will update the staff’s details.
Actors: Receptionist

38
Related Use Cases: Extends: Add customer details
Stakeholders: Receptionist
Preconditions: The customer’s details exist in the system
Post conditions: The customer’s details must be updated
Exception Conditions:
If there are no changes in the customer’s profile,
a. Cancel update
Use Case Name: View customer details
Scenario: Receptionist looks up customer’s details
Triggering Event View customer’s details
Brief Description: The Receptionist will view the customer’s details in the
system.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The customer’s details exist in the system
Post conditions: The receptionist will receive the customer’s details
Flow of Events:

Actor System

1. Receptionist will
look up customer’s
2.1 Display customer’s
2. Receptionist will details
receive customer’s
details
Exception Conditions:
If the customer’s details do not exist in the system,

a. Proceed to adding a new customer

Use Case Name: Add product details
Scenario: Receptionist will add a new product to the system
Triggering Event New product
Brief Description: The receptionist will add the details of the new product.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The product’s details do not exist in the system
Post conditions: The receptionist will receive the product’s details
Flow of Events:

Actor System

39
 1. Receptionist will
look up product
2.1 Display product’s
2. Receptionist will details
receive product’s
details
Exception Conditions:
If the product’s details do not exist in the system,

a. Proceed to adding a new product

Use Case Name: Update product details
Scenario: Receptionist will change product details
Triggering Event Changes in product details
Brief Description: The receptionist will update the product’s details.
Actors: Receptionist
Related Use Cases: Extends: Add product details
Stakeholders: Receptionist
Preconditions: The product’s details exist in the system
Post conditions: The product’s details must be updated
Flow of Events:

Actor System

1. Receptionist 1.1 Update product

inputs the product’s details
details that need
updating.

2. Receptionist
verifies the updated
product details. 2.1 Display updated
product details
Exception Conditions:
If there are no changes in the product’s profile,

a. Cancel update
Use Case Name: View product details
Scenario: Receptionist looks up product’s details
Triggering Event View product’s details
Brief Description: The Receptionist will view the product’s details in the
system.
Actors: Receptionist
Stakeholders: Receptionist

40
Preconditions: The product’s details exist in the system
Post conditions: The receptionist will receive the product’s details
Flow of Events:

Actor System

1. Receptionist will look up

product’s
2.1 Display product’s
2. Receptionist will receive details
product’s details

Exception Conditions: If the product’s details do not exist in the system,

a. Proceed to adding a new product

Use Case Name: Add service details
Scenario: Receptionist will add a new service to the system
Triggering Event New service
Brief Description: The receptionist will add the details of the new service.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The service’s details do not exist in the system
Post conditions: The receptionist will receive the service’s details
Flow of Events:

Actor System

1. Receptionist will
look up product
2.1 Display service’s
2. Receptionist will details
receive service’s
details

Exception Conditions: If the service’s details do not exist in the system,

a. Proceed to adding a new service

Use Case Name: Update service details
Scenario: Receptionist will change service details
Triggering Event Changes in service details
Brief Description: The receptionist will update the service’s details.

41
Actors: Receptionist
Related Use Cases: Extends: Add service details
Stakeholders: Receptionist
Preconditions: The service’s details exist in the system
Post conditions: The service’s details must be updated
Flow of Events:

Actor System

1. Receptionist 1.1 Update service’s

inputs the service’s details
details that need
updating.

2. Receptionist
verifies the updated
service details. 2.1 Display updated
service details

Exception Conditions: If there are no changes in the service’s profile,

a. Cancel update
Use Case Name: View service details
Scenario: Receptionist looks up service’s details
Triggering Event View service’s details
Brief Description: The Receptionist will view the service’s details in the
system.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The service’s details exist in the system
Post conditions: The receptionist will receive the service’s details
Flow of Events:

Actor System

1. Receptionist will
look up service’s
2.1 Display service details
2. Receptionist will
receive service’s
details

42
Exception Conditions:
If the service’s details do not exist in the system,

a. Proceed to adding a new service

Use Case Name: Add staff designation details

Scenario: Receptionist will add a new staff designation to the
system
Triggering Event New staff designation
Brief Description: The receptionist will add the details of the new staff
designation.
Actors: Receptionist
Related Use Cases:
Stakeholders: Receptionist
Preconditions: The staff designation details do not exist in the system
Post conditions: The receptionist will receive the staff designation details
Flow of Events:

Actor System

1. Receptionist will
look up staff
designation 2.1 Display staff
designation details
2. Receptionist will
receive staff
designation details
Exception Conditions:
If the service’s details do not exist in the system,

a. Proceed to adding a new staff designation

Use Case Name: Update staff designation details
Scenario: Receptionist will change staff designation details
Triggering Event Changes in staff designation details
Brief Description: The receptionist will update the staff designation details.
Actors: Receptionist
Related Use Cases: Extends: Add staff designation details
Stakeholders: Receptionist
Preconditions: The staff designation details exist in the system
Post conditions: The staff designation details must be updated
Flow of Events:

43
 Actor System

1. Receptionist inputs 1.1 Update staff

the staff designation designation details
details that need
updating.

2. Receptionist verifies 2.1 Display updated

the updated service service details
details.
Exception Conditions:
If there are no changes in the staff designation profile,

a. Cancel update
Use Case Name: View service designation details
Scenario: Receptionist looks up staff designation details
Triggering Event View staff designation details
Brief Description: The Receptionist will view the staff designation details in
the system.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The staff designation details exist in the system
Post conditions: The receptionist will receive the staff designation details
Flow of Events:

Actor System

1. Receptionist will
look up staff
designation

2. Receptionist will
receive staff
designation details 2.1 Display staff
designation details
Exception Conditions:
If the staff designation details do not exist in the system,

a. Proceed to adding a new staff designation

Use Case Name: Add product category details
Scenario: Receptionist will add a new product category to the
system

44
Triggering Event New product category
Brief Description: The receptionist will add the details of the new product
category.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The product category details do not exist in the system
Post conditions: The receptionist will receive the staff designation details
Exception Conditions:
If the product category details do not exist in the system,
a. Proceed to adding a new product category
Use Case Name: Update product category details
Scenario: Receptionist will change product category details
Triggering Event Changes in product category details
Brief Description: The receptionist will update the product category details.
Actors: Receptionist
Related Use Cases: Extends: Add product category details
Stakeholders: Receptionist
Preconditions: The product category details exist in the system
Post conditions: The product category details must be updated
Flow of Events:

Actor System

1. Receptionist 1.1 Update product

inputs the product category details
category details
that need updating.

2. Receptionist
verifies the updated
product category 2.1 Display updated
details. product category details
Exception Conditions:
If there are no changes in the product category profile,

a. Cancel update
Use Case Name: View product category details
Scenario: Receptionist looks up product category details
Triggering Event View product category details
Brief Description: The Receptionist will view the product category details in
the system.
Actors: Receptionist
Stakeholders: Receptionist

45
Preconditions: The product category details exist in the system
Post conditions: The receptionist will receive the product category details
Flow of Events:

Actor System

1. Receptionist will
look up product
category

2. Receptionist will
receive product
category details 2.1 Display product
category details
Exception Conditions:
If the product category details do not exist in the system,

a. Proceed to adding a new product category

Use Case Name: Add service category details
Scenario: Receptionist will add a new service category to the
system
Triggering Event New service category
Brief Description: The receptionist will add the details of the new service
category.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The service category details do not exist in the system
Post conditions: The receptionist will receive the service category details
Flow of Events:

Actor System

1. Receptionist will
look up service
category

2. Receptionist will 2.1 Display service

receive service category details
category details
Exception Conditions:
If the service category details do not exist in the system,

46
 a. Proceed to adding a new service category
Use Case Name: Update service category details
Scenario: Receptionist will change service category details
Triggering Event Changes in service category details
Brief Description: The receptionist will update the service category details.
Actors: Receptionist
Related Use Cases: Extends: Add service category details
Stakeholders: Receptionist
Preconditions: The service category details exist in the system
Post conditions: The service category details must be updated
Flow of Events:

Actor System

1. Receptionist 1.1 Update service

inputs the service category details
category details that
need updating.

2. Receptionist
verifies the updated
service category 2.1 Display updated
details. service category details
Exception Conditions:
If there are no changes in the service category profile,

a. Cancel update
Use Case Name: View service category details
Scenario: Receptionist looks up service category details
Triggering Event View service category details
Brief Description: The Receptionist will view the service category details in
the system.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The service category details exist in the system
Post conditions: The receptionist will receive the service category details
Flow of Events:

Actor System

47
 1. Receptionist will
look up service
category

2. Receptionist will
receive service
category details 2.1 Display service
category details
Exception Conditions:
If the service category details do not exist in the system,

a. Proceed to adding a new service category

Sales Management (Table 3.3)

Use Case Name: Add sales record
Scenario: Create new sales record
Triggering Event Customer approaches the staff to have a service
Brief Description: The staff will list or tell the service to the receptionist and
the receptionist inputs the customers service in the system
Actors: Receptionist
Stakeholders: Receptionist, staff, customer
Preconditions: the service must exist in the system
Post conditions:
Sales transaction must be created
The transaction must be associated to a customer
Flow of Events:

Actor System

1. Receptionist 1.1 Creates a new sales

initiates the creation transaction
of a new transaction

2. Customer request a
service to be added
to the
transaction/cart 2.1 Look up service
availability
3. Receptionist
verifies the service
information with the
staff

48
 4. Receptionist adds 3.1 Display service
the service to the information
transaction/cart
4.1 Add a service
5. Repeat steps 3,4,
and 5 until the all 4.2 Update inventory
services are added
to the 6.1 Complete transaction.
transaction/cart
6.2 Calculate total.
6. Customer indicates
end of transaction; 6.3 Verify total.
Receptionist enters
6.4 Finalize transaction.
end of transaction

Exception
Conditions: If a product is not in stock, then customer can

a. Choose another product and services

Update the transaction service

Use Case Name: Update sales record
Scenario: Customer changes their service
Triggering Event Service change request
Brief Description: When the customer changes their services, the
receptionist will update the sales record
Actors: Receptionist
Related Use Cases: Extends: Add sales record
Stakeholders: Customer, Receptionist
Preconditions: Sales record is existing in the system
Post conditions: Sales record must be updated
Flow of Events:

Actor System

1.Receptionist will 1.1 Update sales details

input updated
request details

2.Receptionist verifies 2.1 Display updated sales

the updated request details
details

49
Exception
Conditions: If there are no changes in the sales record details,

a. Cancel update
Use Case Name: Record payment details
Scenario: Receptionist will receive payment and receipt
Triggering Event Customer indicates the end of request/services
Brief Description: When the customer indicates the end of the
requests/services, the receptionist will inform the customer
the total amount. Afterwards, the receptionist will receive
payment and print the receipt
Actors: Receptionist
Related Use Cases:
Includes: Make payment
Extends: Print receipt
Stakeholders: Customer, Receptionist
Preconditions:
Request services must be created

Request Transaction must be created

Total amount should already be calculated; inclusive of tax

and discounts.
Discount should be verified by the owner.
Post conditions:
If there is change, the exact amount of change should be
given.

Receipt must be issued.

Request transactions must be reflected on the sales report

of the month.
Flow of Events:

Actor System

1. Receptionist must 1.1 Verify the total amount.

inform the customer
of the total
payment.
3.1 Calculate the
2. Customer will give difference between the
the payment to the amount given and total
receptionist amount.

50
 3. Receptionist will
record the amount.
5.1 Print Receipt.
4. If there is change,
the exact amount of
change should be
given. 5.2 Products in the
inventory should decrease
5. Receptionist will in the proportion to the
issue the receipt products that the service
performs to the customer.
6. Customer will
receive the receipt
Exception
Conditions: 2.1 If customer payment is rejected due to lack of cash,

Transaction is cancelled
Use Case Name: Generates sales report
Scenario: Receptionist will create the sales report of the week/month
Triggering Event End of the week/month
Brief Description: The receptionist will create the sales report of the
week/month
Actors: Receptionist
Stakeholders: Owner, Receptionist
Preconditions: Sales transaction records must be reflected on the sales
report.
Post conditions: Sales report must be created.
Flow of Events:

Actor System

1. Receptionist will 1.1 Display the sales of the

look up the week or the month.
recorded
transactions of the
week or the month 2.1 Put sales report in an
excel spreadsheet.
1. Receptionist will
print the sales
report.
Use Case Name: Record refund details
Scenario: Receptionist will record refund details

51
Triggering Event Customer presents unused product with official receipt
Brief Description: The customer can be refunded if the product he or she
bought is still in its original packaging and is not yet
opened. The customer must present the product and the
official cash invoice.
Actors: Customer, Staff
Related Use Cases: Includes: Approve refund
Stakeholders: Customer, Staff, Owner
Preconditions:
If the result is not fixable and can’t be done with a back job.

The result of the service must be presented to the staff that

performs the service.

The customer must present the result of the service to be

refunded.
The customer must present an official cash invoice.
Post conditions:
Sales invoice must be printed again.

Refund details must be recorded.

Flow of Events:

Actor System

1. Customer will present

the unused item or
the service result for
a receipt.

2. Staff will accept items.

2.1 Verify order details
3. Staff will input refund
details

4. Staff will issue a new 3.1 Record refund details

cash invoice
recognizing the
refund.
4.1 Print cash invoice
5. Owner will sign the
cash invoice.

52
 6. Customers will
receive the cash and
cash invoice.

Use Case Name: Stock in

Scenario: Receptionist will stock in the product to the system
Triggering Event Refund
Brief Description: The staff will stock in the refunded product to the system
Actors: Staff
Stakeholders: Customer, Staff
Preconditions:
The product must be bought from the clinic.
The product is still in good condition and has not expired.
Post conditions: The stock in details must be added to the system
Flow of Events:

Actor System

1. Staff inputs stock 1.1 Record stock in details

in details in the
system

2. Staff verifies stock 2.1 Display stock in details

in details
Use Case Name: Update refund details
Scenario: Staff will update refund details
Triggering Event Changes in refund details
Brief Description: The staff will update the refund details
Actors: Staff
Stakeholders: Staff
Preconditions: Refund details exist in the system
Post conditions: Refund details must be updated
Flow of Events:

Actor System

53
 1. Staff inputs refund 1.1 Update refund details
details that need
updating.

2. Staff verifies the 2.1 Display updated

updated refund refund details
details.
Exception
Conditions: If there are no changes in the service’s details,

a. Cancel update
Use Case Name: Generate refund expense report
Scenario: Staff will create the refund expense report of the month
Triggering Event End of the month
Brief Description: The staff will create the refund expense report of the
month.
Actors: Staff
Stakeholders: Staff, Owner
Preconditions: Refund details exist in the system
Post conditions: Refund Expense report must be created.
Flow of Events:

Actor System

1. Staff looks up 1.1 Display refund

refund details details

2. Staff creates
refund expense
report

54
 Inventory Management (Table 3.4)
Use Case Name: Check product quantity
Scenario: Receptionist will check the quantity of products
Triggering Event Check product quantity
Brief Description: Receptionist will check the quantity of products to know
what to order from the supplier.
Actors: Receptionist
Related Use Cases:
Stakeholders: Receptionist
Preconditions: Product must exist in the inventory.
Post conditions: Product quantity details
Flow of Events:

Actor System

1. Staff will look up 1.1 Display product

product quantity
Use Case Name: Update product quantity
Scenario: Receptionist will update product quantity
Triggering Event Changes in product quantity
Brief Description: Receptionist will update the product quantity.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: Product must exist in the inventory.
Post conditions: Updated product quantity details
Flow of Events:

Actor System

1. Receptionist 1.1 Update product

inputs product quantity details
quantity details that
need updating.

2. Receptionist 2.1 Display updated

verifies the updated product quantity details
product quantity
details.

55
Exception Conditions:
If there are no changes in the product quantity details,

a. Cancel update
Use Case Name: Stock out expired or damaged product
Scenario: Receptionist will add stock out details of an expired or
damaged product to the system
Triggering Event Expired or damaged product
Brief Description: The Receptionist will add stock out details to the system
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The product is expired or damages
Post conditions: The stock out details must be added to the system
Flow of Events:

Actor System

1. Receptionist inputs 1.1 Record stock out

stock out details in details
the system
2.1 Display stock out
2. Receptionist verifies details
stock out details
Use Case Name: Stock out expired or damaged product
Scenario: Receptionist will add stock out details of an expired or
damaged product to the system
Triggering Event Expired or damaged product
Brief Description: The Receptionist will add stock out details to the system
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The product is expired or damages
Post conditions: The stock out details must be added to the system
Flow of Events:

Actor System

1. Receptionist 1.1 Record stock out

inputs stock out details
details in the
system

56
 2. Receptionist 2.1 Display stock out
verifies stock out details
details

Purchasing Management (Table 3.5)

Use Case Name: Record purchased products
Scenario: Receptionist/Owner will record purchased product details
Triggering Event Product restock
Brief Description: The Receptionist/Owner will record the purchased
product details
Actors: Receptionist/Owner
Stakeholders: Receptionist/Owner
Preconditions:
Owner has paid the supplier
Products are already paid and ready to stock
Post conditions:
Order receipt details must be recorded in the system
Flow of Events:

Actor System

1. Staff inputs order 1.1 Add order receipt

receipt details details

2. Staff verifies order

receipt details
2.1 Display order receipt
details

Appointment Management (Table3.6)

Use Case Name: Adding appointment details
Scenario: Receptionist will add new appointment for a customer
Triggering Event Customer scheduled a service appointment
Brief Description: The receptionist will add a new service appointment for a
customer in the system.
Actors: Receptionist
Stakeholders: Receptionist

57
Preconditions: The appointment with a specific customer and in a
specific date doesn’t existing in the system
Post conditions: The appointment details must be added to the system
Flow of Events:

Actor System

1. Receptionist 1.1 Record service

inputs service appointment
appointment details
in the system

If there are appointment duplication with the same

Exception Conditions: customer,

cancel add service appointment

Use Case Name: Update appointment details
Scenario: Receptionist will update service appointment details of
the customer
Triggering Event Customer reschedules its appointment time
Brief Description: The receptionist will update service appointments of the
customer in the system.
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The appointment with a specific customer and in a
specific date doesn’t existing in the system
Post conditions: The appointment details must be added to the system
Flow of Events:

Actor System

1. Receptionist 1.1 Record service

inputs service appointment
appointment details
in the system
Exception Conditions:
If there are appointment duplication with the same
customer,

cancel add service appointment

Use Case Name: View appointment details

58
Scenario: Receptionist will check or view the details of the
customers appointment
Triggering Event
Brief Description: The receptionist checks or view the appointment calendar
in the system
Actors: Receptionist
Stakeholders: Receptionist
Preconditions: The appointment details exist in the system
Post conditions: The receptionist will receive the appointment details
Flow of Events:

Actor System

1. Receptionist will 1.1 Displays customer’s

look up customers appointment details
appointment details

2. Owner will receive

customers
appointment details

Exception Conditions:
If the appointment details do not exist in the system,

Proceed to add new appointment

Payroll Management (Table 3.6)

Use Case Name: Adding benefits deduction details
Scenario: Owner will add staff’s benefit deduction in the system
Triggering Event New staff benefit
Brief Description: The owner will add the details of the new staff.
Actors: Owner
Related Use Cases: Extends: Update staff benefits deduction
Stakeholders: Owner
Preconditions: Staff don’t have benefit deduction yet.
Post conditions: The benefit deduction details for the staff must be added
to the system
Flow of Events:

Actor System

59
 1. Owner inputs 1.1 Record benefit
benefit deduction deduction
details in the system
Use Case Name: Update benefits deduction details
Scenario: Owner will update staff’s benefits deduction details
Triggering Event Changes in benefit amount
Brief Description: The Owner will update benefits deduction of the staff in
the system.
Actors: Owner
Stakeholders: Owner
Preconditions: Staff’s benefit deduction is existing in the system.
Post conditions: Staff’s benefit deduction amount must be updated
Flow of Events:

Actor System

1. Owner updates 1.1 Updates staff’s benefit

benefit deduction deduction
details in the system
Exception Conditions:
If there’s no changes with the benefit deduction,

cancel update benefit deduction

Use Case Name: Check benefit deduction details
Scenario: Owner will check or view the details of the staff benefit
deduction
Brief Description: The Owner checks or view the staff’s benefit deduction in
the system
Actors: Owner
Stakeholders: Owner
Preconditions: The staff has a benefit deduction exist in the system
Post conditions: The Owner will receive the staff’s benefit deduction
details
Flow of Events:

Actor System

1. Owner will look up 1.1 Displays staff’s benefit

staff’s benefit deduction amount.
deduction

60
 2. Owner will receive
staff’s benefit
deduction details
Exception Conditions:
If the staff do not have any benefit deduction exist in the
system,

b. Proceed to add benefit deduction

Use Case Name: Adding cash advance details

Scenario: Owner will add staff’s cash advance in the system
Triggering Event New staff cash advance
Brief Description: The owner will add the cash advance details of the staff.
Actors: Owner
Related Use Cases: Extends: Update staff cash advance
Stakeholders: Owner
Preconditions: Staff do not have cash advance yet.
Post conditions: The cash advance details for the staff must be added to
the system
Flow of Events:

Actor System

1. Owner inputs cash 1.1 Record staff’s cash

advance details to a advance amount
staff in the system
Use Case Name: Update cash advance details
Scenario: Owner will update cash advance amount of a staff
Triggering Event Changes in cash advance amount
Brief Description: The Owner will update the cash advance amount of the
staff in the system.
Actors: Owner
Stakeholders: Owner
Preconditions: Staff’s cash advance details are existing in the system.
Post conditions: Staff’s cash advance amount must be updated
Flow of Events:

Actor System

61
 1. Owner updates cash 1.1 Updates staff’s cash
advance amount of advance details
the staff in the
system
Exception Conditions:
If there’s no changes with the staff’s cash advance,

d. cancel update cash advance

Use Case Name: Check cash advance details
Scenario: Owner will check or view the details of the staff cash
advances
Triggering Event
Brief Description: The owner checks or view the staff’s cash advances in
the system
Actors: Owner
Stakeholders: Owner
Preconditions: The staff has a cash advances exist in the system
Post conditions: The owner will receive the staff’s cash advance details
Flow of Events:

Actor System

1. Owner will look up 1.1 Displays staff’s cash

staff’s cash advance advance details.

2. Owner will receive

staff’s cash advance
details
Exception Conditions:
If the staff do not have any benefit deduction exist in the
system,

c. Proceed to add benefit deduction

Use Case Name: Generate staff’s overall payroll
Scenario: Owner will generate the payroll details of a staff including
the benefit deduction, cash advances and their total
commission for a certain time period.
Brief Description: Owner will generate the payroll details of a staff including
the benefit deduction, cash advances and their total
commission for a certain time period.
Actors: Owner
Stakeholders: Owner

62
Preconditions: Staff’s overall payroll details must be reflected on the
overall payroll
Post conditions: Staff’s overall payroll details must be created.
Flow of Events:

Actor System

1. Owner will look up 1.1 Display the overall

the recorded staff’s payroll details of the staff
services made over in a certain period of time.
a certain time
period. 2.1 Put the overall payroll
report in an excel
2. Owner will receive spreadsheet or print the
the staff's overall overall payroll report.
payroll details.

Use Case Name: Adding salary details

Scenario: Owner will add staff’s salary details in the system
Triggering Event New staff salary
Brief Description: The owner will add the salary details of the staff.
Actors: Owner
Related Use Cases: Extends: Update staff salary
Stakeholders: Owner
Preconditions: Staff do not have salary yet.
Post conditions: The salary details for the staff must be added to the
system
Flow of Events:

Actor System

1. Owner generate the 1.1 Record staff’s salary

overall payroll of a details
staff and add salary
pay slip report
Use Case Name:
Update salary details
Scenario:
Owner will update salary details of a staff
Triggering Event
Changes in salary details

63
Brief Description:
The Owner will update the salary details of the staff in the
system.
Actors:
Owner
Stakeholders:
Owner
Preconditions:
Staff’s salary details are existing in the system.
Post conditions:
Staff’s salary details must be updated
Flow of Events:

Actor System

2. Owner updates 1.1 Updates staff’s salary

salary details of the details
staff in the system
Exception Conditions:
If there’s no changes with the staff’s salary details,

e. cancel update salary details

Use Case Name: Check cash advance details
Scenario: Owner will check or view the details of the staff salary
details
Brief Description: The owner checks or view the staff’s salary details in the
system
Actors: Owner
Stakeholders: Owner
Preconditions: The staff has a salary details exist in the system
Post conditions: The owner will receive the staff’s salary details
Flow of Events:

Actor System

3. Owner will look up 1.1 Displays staff’s salary

staff’s salary details details.

4. Owner will receive

staff’s salary details

64
Exception Conditions:
If the staff do not have any salary details exist in the
system,

d. Proceed to add salary details

Use Case Name: Generate staff’s salary report

Scenario: Owner will generate the payroll details of all the staff
including the benefit deduction, cash advances and their
total commission for a certain time period.
Brief Description: Owner will generate the payroll details of all the staff
including the benefit deduction, cash advances and their
total commission for a certain time period.
Actors: Owner
Stakeholders: Owner
Preconditions: salary details of all the staff must be reflected on the
salary report
Post conditions: Salary details of all the staff must be created.
Flow of Events:

Actor System

3. Owner will look up 1.1 Display the salary

the recorded salary report details of the staff in
report made over a a certain period of time.
certain time period.

4. Owner will receive

the staff's salary 2.1 Put the salary report
report details. details in an excel
spreadsheet or print the
salary report.

65
 Biometric Fingerprint Attendance (Table 3.7)
Use Case Name: Generate Staff Attendance
Scenario: Staff show up for work and check in for attendance
before opening hour
Brief Description: Staff will use the biometric scanner to check in and out
for work with the correct time record
Actors: Owner
Stakeholders: Owner
Preconditions: Staff attendance will be recorded in the attendance log
Post conditions: Staff attendance log must be created
Flow of Events:

Actor System

1. Staff will use 1.1 Display time and date

biometric scanner
2.1 System records time
and date record it to
attendance log

Exception
Conditions: New staff with no attendance record

b. Owner will add new staff to the system

66
C.) System Architecture Design

This section includes the context flow diagram and program flow diagram.

Context Flow Diagram

Figure 3.10: Context Diagram of Mj’s Nail Bar & Hair Expert Salon

The figure shown above is the structural design of the management

system. It shows how the system processes the inputs of data and sending it to

its specific output destination.

67
Data Flow Diagram

Figure 3.11: Data Flow Diagram

Data Flow Diagram contains the step by step process that generalizes the

function of the entire system in relationship to external entities.

68
Cost Benefit

The process used to measure the benefits of a decision or taking action

minus the costs associated with taking that action.

Cost Benefit Analysis

Cost

Category Item Quantity Price Total

Software
Transaction System 1 15,000 15,000
Hardware
Personal Computer 1 15,000 15,000

Biometric Scanner 1 1,300 1,300

TOTAL COST: 31,300

Benefits
1 Month 2 Month

Workflow efficiencies 9,000 9,000

Better business processes 6,000 6,000

Better database 15,000 15,000

TOTAL BENEFITS 30,000 30,000

Table 3.8 Cost Benefit

Requirement Analysis

Non-functional specifications define 'how the system operates' essentially,

while functional requirements describe 'what the system can do’. In order to collect

requirements, observations and interviews were performed as proof collecting

techniques at the requirement selection point.

69
Functional Requirement

The functionality of a system or one of its subsystems is specified by a

functional necessity document. It also relies on the software type, expected users,

and the system type where the software is used.

High-level statements of what the system should do could be practical user

specifications, but functional system requirements should also explicitly define

system services in depth.

● Create salon staff and maintain (Update/ Inactive) their details.

● Create salon services and maintain (Update/ Delete) their details such as

prices, commission for staff and company etc.

● Maintain resources (Create/Update/ Delete) at the salon premise.

● Reminder generating facilities are provided through the system.

● Facilitate appointment handling through an event calendar by the system.

● Generating invoices through the system.

● Generate sales reports though the system and export it to excel.

● Import staff’s attendance sheet from fingerprint biometric scanner to

system.

Non - Functional Requirements

● Accessibility – The system can be easily accessed by authorized

users.

● Accuracy – The accuracy of the system's data inputs has been

assured.

70
 ● Availability – System is available within working hours.

● Efficiency – Users were given the facility to perform the salon

transactions processes correctly through the salon sales record

management system.

● Effectiveness – Users were given the facility to perform correct

salon management processes via the suggesting system.

● Maintainability – This is a significant factor, especially for non-

technical users. The management of the machine is no longer

difficult.

● Privacy – The confidentiality of the data inputs to the system has

been assured.

● Reliability - Ability of the suggested system to function under stated

conditions for a specified period of time has been assured.

● Robustness – This functionality has been considered when

managing payments.

● Security – The system's data feeds have been secured by

monitoring user access rights.

System Users and their involvement at the system

Mainly there are two system users who need to access the system. They

are as follows:

1. System administrator / Owner

2. Receptionist

71
Program Flowchart

Figure 3.12: Program Flowchart Diagram

Displays the step-by-step process of the system from the starting phase

which is the login will show up and to the end phase which is the logout.

72