Design

Decomposition Diagram
 Create Bookings: Users can make new bookings for gym sessions upon login
Provide Feedback: Users can offer their opinions or reviews on the gym experience upon login
Review History: Users can view their past bookings and activities upon login
Previous Bookings: Users can view their past bookings upon login
 Activities: Users can see their previous gym activities upon login
Update Account Details: Users can edit their contact details, manage their account security options,
and adjust personal preferences upon login
Contact Information: Users can edit their contact details upon login
Security Settings: Users can manage their account security options upon login
Preferences: Users can adjust their personal preferences upon login
Modify Bookings: Users can change the timing and details of their existing bookings upon login
Adapt Schedules: Users can change the timing of their bookings upon login
Change Details: Users can alter the details of their existing bookings upon login
Access Analytics Reports: Staff members can view analytical reports about gym usage upon login
Access User Profiles: Staff members can see user profiles upon login
Access Settings: Staff members can access system settings upon login
Access Feedback: Staff members can view user feedback upon login
Access Admin Panel: Staff members can access administrative functions upon login
Modify User Accounts: Staff members can make changes to user accounts upon login
Modify Bookings: Staff members can adjust booking details upon login
Class Diagrams
 User Class

The user class has the attributes display name, password, first name, address, email, phone number,
register date, user type, account status, and age. These are the qualities of the customers that we
will be storing about the users. We will have their display name as the unique username they pick,
which will be used as the display on the site when their account is viewed. Their password will be
needed as this is how we will confirm their identity when logging into their accounts. We will have
their first name stored so we can speak to them formally and address them. We will have their
address and email, so we have a method of communication with them. For example, when they are
purchasing things, they will need an address for the products to be shipped to and an email to be
contacted for invoices with their phone number. We will store the registration date, the date they
made an account with the system, which will help determine their account age when checking for
things like how long they have been with the system. The user type will be what kind of a customer
they are and how they are viewed, such as a total customer or a new customer. This helps determine
the account age and how we can reward them with loyalty schemes, for example.
Finally, we should store the user's age to help restrict things on the site to help the staff understand
the audience that is using the gym and the online system. This can also be used to restrict access to
certain features or what is displayed to make it more age appropriate.

Looking at the methods, these are what the users will be able to do. For example, they will be able to
log in and log out of their accounts when creating and ending sessions in PHP to make changes to
their accounts. They will be able to make bookings as this is a main feature of the system. It was
designed to remove the paper-based system, so they need this to make appointments. Customers
will also need to be able to register accounts. They will be able to make accounts so that they can
become part of the online system and start using the services available when logging into the
accounts.

Finally, they can update their account information and any details such as booking details. They will
be able to view their details such as their account details and the details of the bookings they made
as the online system will act to help track this information and then perform calculations to
determine things such as availability. Customers must also be able to cancel things such as their
appointments. They should be able to cancel the bookings they have made or cancel transactions if
they decide not to purchase anything.

Staff Class

For the staff class, we will be storing information about the staff members. For example, we will be
storing their usernames and passwords for their accounts. We will have an address to be used for
shipping and delivery of things like products. We have an email and phone number to contact the
staff members if there are any issues or concerns with customers or the site, so they can make
changes and let us communicate with them. We will have the start date to know when these staff
members started as staff members and have been employed to know how long they have been with
the system and how long they have been with a staff member. We will have the user type to know
what type of user they are for their account; they may be a manager and oversee all the other staff
members, or they may be a new staff member and will be currently in training. This will be linked to
the employment status to know if they are currently a staff member in the system when seeing the
data stored on them if they were a previous staff member. The role and position will show what kind
of staff member they are, and this will be linked with what kind of staff member they are.

The methods will be what the staff can do in the system. They will be able to log in to their accounts
that have been made so that they can make changes to the site. They can then log out of these
accounts after they are done. These together will open and close sessions that will allow changes to
account details and access to things on the system designed for the staff. They will be able to create
bookings and book their appointments but will also be able to edit the bookings made by the
customers. They will be able to create and delete things such as customer accounts and bookings.
They will also be able to update the stored information we have; we will be able to update their
account information and the bookings they have. They will also have the ability to cancel and view
things; they will be able to view customer details and the bookings they make and will be able to
cancel bookings customers make if there is a reason or prevent purchases that users make if there
are any issues with the site. They will be able to generate and view reports which have analytics and
allow them to make predictions and observations about trends in data such as the number of
 bookings being made or the number of accounts that are being made and view these visually to
represent the data.

Bookings Class

For the bookings class, we will store information we need about them. We will store information
such as the users, who are the people making the bookings, so the bookings can be linked to
accounts. We will have the time slot and date stored so we know when the booking will take place,
and we will have the status of the booking stored, such as the booking and payment status, to know
if the booking has been made and if the booking has been fully paid. This will allow us to ascertain if
the bookings have been made and paid for before they are submitted and stored in the system. We
will store the payment amount to know how much was paid for the booking, as this will be important
when tracking things such as refunds. We will have the user type stored to know what type of users
are making bookings, and the cancellation reason will be stored in case the bookings are canceled so
we have a form of feedback to know why bookings are being canceled if there needs to be
improvements made. There will be a history of bookings made as these will help track refunds and
user activity by knowing what bookings were made and when by which users. Finally, there will be
feedback about each booking that will be made so that we can make improvements and know what
the users enjoy about the bookings and what they do not.

For the bookings, there will be things that can be done such as confirming bookings, which will make
sure that the customers, when they make bookings, know what they are doing and can confirm the
details they are entering. Bookings can also be canceled in case the customers change their minds,
and this will be linked to refunds. The check-in and set payment will work so customers can pay for
the bookings and sign in to confirm they have attended their appointments. There will be a provide
feedback and get details function where the users and staff will be able to get information about the
bookings stored and stated above. They will then provide feedback about the bookings and their
experiences to help with future improvements. Also be a function to view the history of bookings to
know which users are making bookings and how much they are paying for bookings and what dates
the appointments occur on. This will be used to generate reports shown in the staff section above.
There will be an add notes and update feature that will be used to update the comments of bookings
and add additional information to them if it is needed to inform the gym staff and the system of the
customers' needs or other information that may be relevant to the bookings. Finally, there will be a
delete function that will be used to delete the bookings, which will act like canceling them; however,
canceling them is more about rescheduling, whereas deleting them removes the stored data from
the system.

Membership Class

The membership will have stored information that we will need. We will have the users stored so we
know which members have what membership, allowing us to link to them. We will then have the
type of membership being stored to know what is being paid for. For example, it could be a beginner
membership or a premium membership. We will then store the duration of the membership, and the
price of the membership will be stored and linked with the type of membership to help manage
things such as transactions if it were to be canceled. Benefits and renewal will be stored so that we
can know what benefits the customers get with the system by having a type of membership and
what access they will get in the system depending on their membership type. The renewal feature
 will be for when a membership expires, it can be renewed and extended. There will be a history of
memberships being stored, such as the members who have memberships, the amount being paid,
and the duration of them. This will be used to help monitor customer activity and the memberships
made within the system. We will store feedback about the memberships to know what can be
improved and what works so that changes can be made to them in the future if needed to support
the customers further as they are paying for extra services. We will store the discounts that are
associated with the memberships to support the customers when they have memberships; they can
get discounts on things such as products and bookings when they make payments to encourage
them to have memberships if they are frequent users. Finally, we will store the start date of the
memberships, so we know what date they were paid for and start the memberships being made by
the customers.

For the memberships, they will be able to be renewed. If a membership expires and the customers
would like to renew it and extend their memberships, they will be able to. They will be able to cancel
their memberships and get partial refunds. They will be able to update their memberships and
change what kind of course or plan they are currently on. They will be able to enroll and start a
membership and gain access to the features that become available when they start, as they will be
able to have discounts as part of the services made available when purchasing things such as
bookings or other products. They will be able to get the details of their memberships and view their
current plans and any details on them if needed. They will be able to view their history and know
what memberships have been made and the details about them for all the customers if they need to
be retrieved. Finally, they will be able to update and confirm details made to bookings, such as
extending the time durations of their memberships, and then they will be able to confirm the
changes made.

ER Diagram
 Users
Entity Relationship Description
Users to Feedback One to many A user can leave multiple
feedback, but each feedback is
associated with only one user.
Users to Payment Track One to many A user can make multiple
payments, but each payment is
associated with only one user.
Users to Booking One to many A user can make multiple
bookings, but each booking is
associated with only one user.
 Staff
Entity Relationship Description
Staff to Bookings One to many A staff member can create
multiple bookings, but each
booking is associated with only
one staff member.

Products
Entity Relationship Description
Products to Feedback One to many A product can have multiple
feedback, but each feedback is
related to only one product.

Feedback
Entity Relationship Description
Feedback to users Many to one Each feedback is left by a user,
but one user can leave
multiple feedback.

Payment Track
Entity Relationship Description
Payment track to users Many to one Each payment is made by a
user, but one user can make
multiple payments.

Booking
Entity Relationship Description
Booking to users Many to one Each booking is made by a
user, but one user can make
multiple bookings.
Booking to staff Many to one Each booking is associated
with a staff member who
created it, but one staff
member can create multiple
bookings.
 User interface
Home Page

Here we have a basic layout for the homepage. At the top will be a navigation bar that will function
to navigate through the site and access multiple pages easily. There will be a sign-up option at the
top which will direct users to the registration page in which they will be able to create an account to
gain access to the full services provided within the system. There will be a payment section to setup
the relevant information, this will be to purchase the services we provide and is the goal of the entire
system, creating appointments/bookings and then paying for the allocated slot times. We will have a
direct access to the feedback forms where the users are encouraged to talk about their experiences
and leave feedback. This will be used a point to improve the site and the facility to accustom and
enhance the users experience with the system. This is important as it will allow us to interact with
the users and make changes to the systems to meet their needs as we progress after testing and
proposing our solution. We will also display some of the feedback we get on the site within the
homepage as a little sample, here the users will be able to view the first few reviews without leaving
the homepage and if anything catches their interest they may click on it and leave the home page
and go into the feedback section to review the comments made by other users and also leave their
own feedback so that as a community everyone can work together to help improve the site together
to enhance everyone personal experience. They will have direct access to the booking page where
they will be able to create a booking. This will be the main attraction of our site; they will be able to
create their bookings at certain times for certain time slots on a specific day and pay for their session
and attend it. On the side they can have a preview of any bookings that are currently available to give
them an insight into when they can book their next session. Additionally, we can also present them
with offers or discounts that are also available at the time to help encourage them to make their
appointments and start to make a change, utilising the services we provide. There will be a contact
page where the hard will be able to get in contact with a member of staff or someone of authority to
be able to voice their concerns if they have issues. They will have access to a help centre and
potentially a FAQ page where they can get the assistance, they need by contacting someone who can
remedy the situation, or they view previous problems and seek additional guidance.
For example, someone may have forgotten their password and would like to reset it, in this case they
could go to the help desk and receive instructions written on the site as a guide or receive
instructions from someone at the help desk, giving them guidance to be able to fix the situation and
reset their password. Another example could be someone wanted to change the information on their
account, they may change their names or wish to use a new email address. If they are unable to, they
may contact someone on the help desk and request this change to be made or they can do it for
themselves and have responsibility over their account by seeking assistance on other pages such as
an FAQ page where there could be a common question “how do I change my email address” and a
conversation or discussion between users that will be able to assist each other, removing pressure
from the staff desk to resolve more important issues such as security and maintenance.

Register Page
Here, there will be fields for the users to input data. We will require their first name and last name to
identify them and personalize their account. We will collect email as a form of contact to
communicate with the users and allow other features to become available, such as verification and
discounts. They will, of course, need a password to prove their identity when logging in, and then a
double-entry check field to confirm the password. This is to ensure they have input the correct
password and will remember it. Underneath is an optional setting that can be left blank or modified
later. This will correspond to the type of memberships a user can have, which will be decided later. By
having them select options, we limit the things they can input, making it more predictable about the
data we store in the database to improve security and prevent any harmful inputs. Finally, there will
be a button at the bottom of the form called 'Register.' This will send the data across to the database
once clicked, starting the process for any other algorithms that will be used. For example, a password
strength algorithm to ensure we have secure passwords being stored to improve security and
prevent any risks with the system. We will also need to sanitize every input for all the fields for the
same reason. We will, of course, need algorithms to check certain things, such as whether their
name is valid (it shouldn’t have numbers or symbols), whether their email is valid (should include an
@ sign), whether their password is secure (meeting certain criteria), and whether their passwords
match (comparing the two inputs). Once these are considered and implemented, the form data can
be sent across, and we will store them with a new record for our user.

Login Page

This will be the login page. We will have fields for their username or email and then a password. By
doing this, we imply that each username and email will be unique to each user. We will allow users to
log in using either their email or their username, depending on their preference. The ID means that
with the algorithm, we will need to search for multiple things. There will be a password field that can
be entered, and once the login button is pressed, we will then compare the values entered to any in
the database. If the details match, we can allow them to log in and redirect to another page, such as
the homepage or a dashboard. There will be links at the bottom of the page to help redirect people
to other relevant pages. If they cannot remember their password when logging in, they can click on
the 'forgot password' link, and they will be able to reset their password with some steps shown later
in this section. If they do not have an account and are viewing as a guest instead, they can then go to
the register page shown above using the register link at the bottom of the page here. As usual, we
will need to sanitize all inputs. As these are the same fields used in the registration page, they will
follow the same procedure and have the same requirements, such as a name not having any
numbers or symbols, and emails must have a @ sign. Once the inputs are sanitized, there will be a
submit button at the bottom of the page that will start all these processes once pressed. By doing
this, we create a way for users to log in safely while also providing a way to redirect them to other
pages if necessary to aid them.

Booking Page

This will be the booking page, the main part of the system, allowing users to create
bookings/appointments for certain time slots. They will have options for classes that should not be
left blank. By presenting options, we limit the inputs users can give, making it easier to predict what
data will be stored about the users and bookings, providing the system with more security. There will
be a way to select a date, done using a calendar so they can pick a date easily, something users are
familiar with and can easily check for availability. This will make it easier for users to select a date
when booking their test. Afterwards, there will be a list of times for users to choose from depending
on availability. Time periods for users to pick from after they have entered a suitable date (not in the
past, as that would not make sense) should be able to change depending on the day picked, as each
day will have different available times. This gives responsibility to the user over their account and
experience, making it more personalised and giving a sense of ownership to having an account within
the system. Upon clicking the submission button at the bottom of the page, the forms will be
checked and validated to ensure there is data in them and they are not left null, with appropriate
information provided. While there won't need to be as much sanitisation as before due to the
provided inputs, we will still need to confirm all details submitted. Other algorithms will be needed
to confirm things such as double bookings; it would be problematic for multiple people to book the
same time slot, so there should be a way of preventing this and having options removed not just
based on the day but also the availability of other users if they have already booked. Of this is
confirmed, users should be redirected to a payment page so they can pay for the services they have
applied for. Once that process is done and valid payment is made, we should store this information
as a new record in the database and remove these options from other users in the time slot list. After
the date of their booking, the record should be deleted as it will not be required to store the specific
information about them anymore, improving security and reducing the number of records in the
database to make it more manageable. However, I would also like to store some information about
the bookings, such as the date, class, and user, to form a history of bookings to present to users so
they can view their progress and see what they have done with their account, but also as a receipt to
confirm details in the past in case any issues do arise and evidence is required of bookings and
payment. For example, there may be an issue with payment, and someone would like a refund; we
would need proof of the booking, so we should store minimal information that is also still relevant.

Payment Page
This will be the page to set up payment. We will take information in fields such as their card number,
expiry date, and CVV. We need to be extremely careful with this information as it is extremely
sensitive. When inputting the card number, I would like to implement a security method so that an
asterisk (*) appears as a mask to prevent other people from viewing their information. We will then
take the expiration date and CVV code. The expiry date can also form a calendar above for the
booking; however, I feel that it is not as necessary. With the booking, it was more about being
available and deciding when someone is free to make an appointment and changing their schedule
around it. However, with an expiration date on a card, users should be able to read their information
from the physical card they have and then submit that data into the form. It will be checked using
another algorithm and ideally a third-party system to validate payment information and handle
transactions. Expiration dates are not daily soon and are years into the future, so it is unlikely that
they will be expiring, and it would be more standard for users to just input the data and then have it
confirmed. For a CVV code, it should be of a certain length, so we will need an algorithm in place to
determine if the data entered is valid before sending it off to another procedure to confirm the data
stored about users and their payment information. As usual, there will be a button at the bottom of
the page for submission that will allow the data in the form to be sent across and then validated
before storing it in the database as required, and then being read from and used in later sections
such as paying for products or creating bookings and paying for them. Payment details are subject to
change, so this will be a point where users need to update their payment information. In that case,
we can reuse this page but modify the heading from 'setup' to 'update' and carry out the same
process of verification and validation before handling the data and then storing it again to reuse it
later.

Update Account Page

This is the update account page. There will be fields to change certain data about the user which we
hold records of in the database. A person's name and last name can be changed, so it would be
appropriate to be able to change these on the site to allow their experience with the system to feel
more personal by addressing them properly. There will be a field to enter a new email address; this is
important as it is our main way of contacting users off-site. If they lose access to their email, for
example, if they don’t remember their password, then they would not be able to contact us unless it
was through the site, which can be problematic as they won’t get access to certain things such as
verifying their account which enables them to make a booking, they would lose out on offers or
discounts not made available to them if they aren’t aware of them and aren’t told, they may hold
fewer records such as losing a receipt for when they make a booking/appointment. By not having the
correct email address, users will lose out on these features and will not have full access to the site,
damaging the way they can interact with the system and preventing them from making full use of the
services we provide. Being able to change your password is important. If users forget their
passwords, it would be beneficial to change them. If there was an issue with security, being able to
change your password gives a significant boost in the security of their accounts. In fact, we should
encourage users to have their passwords changed often just to improve the security of their accounts
and protect their data. Then, of course, we will need to confirm this password to ensure they’re
happy with what they are changing it to and check they’ve input the correct password; it would be
an issue if they made a spelling mistake changing their passwords, updated their account, and could
no longer log in. This would lead them to have to email for a password reset, but if the above
password also required changing they wouldn’t even be able to reset their password and would then
be stuck having to contact a help desk to be able to make the changes on their account, disturbing
the staff team as they would rather be working on the maintenance and improvements of the site
rather than dealing with customer data such as their names and emails. Hence, it is essential to allow
users to change their password but also check what they’ve changed their password to. The checking
part of the password will require a simple algorithm in that we just need to take an input and
compare the results; if they are the same, then we can carry out the progress and submit the form
data; otherwise, we should terminate the process. Of course, every field will require input
sanitization as usual, and since we have used these fields, we can use similar things stated above
which as names not containing numbers or symbols, emails should contain @ signs, passwords
should have a strength algorithm applied to them to ensure we have secure passwords being used to
then protect the user's data. Once the submit button at the bottom is clicked on, it should submit the
data in the form and all the details should be checked against an algorithm to ensure all the
information is valid; if not, then terminate the procedure and leave the fields blank requesting data
to be resubmitted. Otherwise, we should update the records within the database.

Delete Account Page

This will be the account deletion page, designed for staff use. There will be a search field to collect all
users with the same name. This makes it easier to search a list for some users as it would be more
common to know someone by name rather than a unique identification code. Doing this will make it
easier for the staff to find specific users and then delete their accounts. There will be a list of the
users with their ID in numerical order, their first name, email, and an option to delete their account.
This will give staff a way to uniquely identify which account they are deleting, the name of the person
whose account will be deleted, an email to contact them and inform them about the status of their
account, and provide a reason as to why they are being let go. The option to delete is simple, it’s just
a true or false to whether the account should be deleted or not. Initially, the list of all users should be
displayed and then have scrolling options to view pages of lists since there should be many users.
Once entering the name, it should shorten the list down to those with the matching name and from
there, the staff will be able to pinpoint a specific account and then confirm the deletion process.
Once options have been selected, there will be a button at the bottom of the page for submission.
Once pressed, all the data in the form must be validated and confirmed about the account being
deleted, and the name of the account should appear with the record. Once confirmed, there will be
a success message at the bottom of the page to indicate that an account has been deleted. With this,
there will be a process for searching the database for the record which will be done by the search
form anyway, and then using the delete command to remove that record from the table and
disabling the person from using that account again. Technically, this means that the old username
will become available again for other users to make use of, and an email will then become available
for other users to use if there is someone else who would like to use it. This may pose a potential
problem but will have to be discussed more and have further judgment with an interview later with
stakeholders if I hold another one.

Forgot Password Page

This is the forgot password page, which I mentioned above slightly when updating accounts. Here,
there is just one field to submit data into, which will be an email address that is entered, and then
contacted to let them know that a password has been reset, sending them confirmation and
instructions on what to do next with some guidelines if they are stuck. There is a small message at
the start instructing the users to input their email address if they want to reset their password. Upon
entering an email, as usual, we must check this field for certain qualities such as containing an @
sign. At the bottom of the page, there will be a little indicator for some users that if they remember
their password, they can then click the link underneath to be redirected to the login page shown
above. This will then allow them to log into their account as normal and will not need to go through
the entire process of changing their password and going through a set of instructions to then change
it and confirm the changes they made. Looking back on this now, one thing I have missed out on is a
'resend email' option. Sometimes there is a lot of junk within people’s emails and it may cause them
to find it difficult to find the instructions to change their password. In the case of this problem, they
may want to resend the email so they have another chance to look for it if they cannot find it due to
spam or other issues related to their email address. Additionally, if the email in the field is changed
and they click the resend option, it should then terminate the old process and then open a new one
with the new email address and begin emailing that one. Upon pressing the submission button at the
bottom, the fields should be checked with some algorithm to ensure that they are valid and then
have them sent across and let the process be carried out. Ideally, all that should be changed is to
review over this little design area and modify it so that it can resend emails to any addresses it’s
needed for in case any of the users require this.

Verify Account Page

This will be the verify account page. Here, there will be a field to input the verification code
sent to an email address that will have previously been stated. From their emails, they will
receive a special code that is valid for a certain period. If within this time the code is then
entered on site, it will be checked with an algorithm comparing the input to a randomly
generated code. If these match, then the account will be considered as verified, and that will
be the end of the process. If the time limit is exceeded, then it should terminate the process
and make the code invalid, requiring the user to resend the code and have a new one
randomly generated as they try again. Here, there is only one field where the user inputs the
code from their email address, they entered beforehand. This will require some sanitisation.
Since it is a code, we should determine what type of characters are within the randomly
generated codes. For example, if we have it just being numbers, that is appropriate.
However, this may not be the safest approach. While it may be easily implemented and
validated, the security would come from the length of the code to determine the number of
codes that could be generated. To improve security, we could then also add in other
characters and have those searched for too to prevent random guessing. Take, for example,
the code “586” - a user may be able to guess this without checking their email as it is quite
basic and a short code. However, consider: “L7^mN!9s”, “Q*wD5tRz”, “X&h3G+kF”,
“U^o6V,1b”. These are much more abstract and difficult to guess, making them much more
secure compared to the original idea of using just numbers. Hence, the code sent should be
a randomly generated sequence of letters, numbers, and symbols. What we can implement
is a dictionary of characters that we would like to appear in a code, then have them
randomly regenerated based on the characters that we have stored in our dictionary, and
then have the code checked against the dictionary first to ensure every character there is
meant to appear, and then have it checked against the one randomly generated to allow the
verification. All of this should take place after clicking the submission button at the bottom
of the form. Additionally, there is a resend option at the bottom of the form underneath the
submission button. If there is an issue with reading the code from an email or a message
cannot be found containing it, it is important the email can be resent to make it easier for
the users to find the account details they need that are relevant to them. By implementing
this, it ensures that the user will be able to find the email and then the code given to them
in case of things such as a wrong email being inputted, spam in a folder so that the email
doesn’t appear, or it would just be a greater convenience to have it resent than to go
searching for it. Both combined wills allow the users to enter an email address, have it
checked that it is valid and then receive a special code that is useable for a limited amount of
time. Then they may enter the code and verify the account as intended otherwise if there
are any issues the progress can be terminated and started again by using the submission
form at the bottom of the form to resend the code and restart the timer to get a new code
and check their emails again.

Contact Page
This will be the contact page to allow the users to be in contact with the staff team. At the top will be
a message to the user indicating that by filling out the form and submitting the data, it will enable
them to get in touch with the staff team. There will be fields to enter data such as their name, email,
and the message they would like to leave. The name they use can range from their first name,
username, or a different name to leave an anonymous message. This leaves options for the users so
that we can know who left what message, but in online forums and discussions, not everyone may
want to reveal information about themselves such as their name. Offering a way to be anonymous
allows the users to protect their identities online and gives a sense of security to their information.
They will have an email address so that the staff team are able to get in contact with them if the
message or issue cannot be handled on site. Taking it to email will make it more personal so the
users can input a different email from the one they used to sign up for their account if they wish for
another means of contact. However, it is entirely possible for users to input their given name and
email address that they used to sign up for the account and services too. By doing this, it allows the
users to remain anonymous and give message and speak with the staff team while protecting their
identity if they wish, depending on the matter. Finally, there will be a much larger field for the
message where this will be the contents of what the users are trying to communicate. This will be
what can be viewed by the staff as a priority with a name tagged to it and an email in case they need
to. It is worth noting that this page could be revised and improved to allow staff to also communicate
back in a similar manner, opening a sort of chat box or ticket allowing them to communicate
between each other on site if that is required. Just like every other section, every field needs
sanitisation. As usual, the field that takes in a name shouldn’t take in numbers or symbols; it should
accept standard strings and characters for names. Email addresses should contain an @ sign and can
follow the same sanitisation as all the above. The message will be harder to sanitise; in
communication, there isn’t much restriction as letters, symbols, and numbers are all going to be used
when communicating. Instead, what we can do is put a character limit within the message field to
put a restriction on how much can be said in a message. This will need to be a suitable amount, but
this is also helpful if we store this on our database as it will be more predictable to the amount of
storage we are using. We could then also blacklist certain characters that shouldn’t be used in
normal conversation and have certain error messages telling users that they can't have certain
characters within their message if they try to submit the data. Upon pressing submit, the data in the
form should be checked by an algorithm to ensure that it’s all valid, and then have the form data
processed and submitted to be stored and shown up on other pages, as necessary. This section is the
start, and other things like a chat box may be implemented if deemed necessary by stakeholders.

View/Edit Page

This will be the view page only accessible for admins. Here, it will read from the database and output
a list of all the users that are in our database. The list will be sorted in ascending order using
everyone’s unique IDs. Next to everyone’s ID, it will display their first name and last name to allow
the staff to identify and communicate with the users more effectively, and using their ID will allow
them to uniquely identify an account. There will also be a list of email addresses with each account
to offer the staff a way to communicate with each customer that has an account. Overall, this will
display a list of all users and give a way for the staff to communicate with them, address them, and
uniquely identify them if necessary. Next to each user, there will be a list of potential actions named
“edit” and “delete.” When staff click on these, it will redirect them to their respective pages. Upon
clicking the edit option, it will direct the staff to a special page that will allow them to view the data
in the users and allow them to update and edit their information. This will then modify the records
that hold data in the database and allow us to keep more accurate records. This can be a way for the
staff to resolve certain issues, if there are any, that can be resolved by this method. There will also be
the delete option. Here, it will lead staff to a special delete page that will display a list of the same
users in a similar style. Once on this page, they will be able to select the account presented to them
as a list and select options to be able to remove the records from the database – deleting the
accounts. This is important as it’s a core function of the maintenance of the site and will be a priority
as this was a requirement stated before. The delete account page has been shown before. However,
the update account for the staff will look slightly different to the one proposed to the users who can
edit their accounts.

Feedback Page

This will be the feedback page. At the top, we will display a friendly message to the customers,
inviting them to share their feedback. We will take their name as an input so that they may use a
different name than the one assigned to their account, allowing for anonymity, or using a preferred
name to avoid bias. This option encourages honesty and ensures feedback is not influenced by
factors like membership status. There will be a field for them to enter an email, which does not have
to match the one on their account. This provides a means to communicate about the feedback and
improve the site, although other feedback channels may also be available, such as a chat box or a
help desk for users with varying levels of technological experience. The feedback box will be larger
than the other fields, where customers can relay their message to the staff team for appropriate
action. Validation will be needed to filter out banned characters, although this may be challenging as
feedback may include symbols or statistics. Implementing a character limit can control the length of
replies. The purpose of this page is to gather data from the fields and store it in our table for further
use, such as viewing all feedback and leaving comments. Form validation will ensure the name field
does not accept unwanted characters like numbers and symbols, while emails should contain an "@"
sign and ideally be valid for customer login and replies, although this may not be necessary if a
chatbot-like feature is employed.

Admin Panel

This will be the admin panel, where staff will have options that redirect them to other pages to do
their tasks. With "Users," it will take them to a list of all user accounts where they can view all the
accounts made and currently registered with the online system. With "Bookings," they will have the
same list but for the bookings made by the customers. On both pages, they will be able to take
actions such as updating the information or deleting records from our table. The settings page will
have preferences that can be changed, allowing the staff to customise the appearance of the site to
make it more appealing if necessary. There will be a products page where staff can access a list of the
products and make changes if needed or have been asked to ensure we are storing accurate and
appropriate records of the data we have. At the bottom of the page, we can have a list of things to
show the activity logs of the users; for example, we can have their name to see who is doing
something, an email for the staff team to be able to contact them if they need to. There will be a
corresponding action to see what they are doing; for example, it may say "logged in" or "made a
booking" to tell staff what is happening on the website in real-time. There will be a timestamp to tell
how long ago these actions were if they need to be checked as an activity log. Finally, there will be a
portion of the page dedicated to statistics and analytics where there will be visual representations of
data such as graphs to show insights into things such as customer behaviour and activity, and then
other pages which elaborate and show these graphs in more detail.

Database Tables
Users table

Field Name Data type Description of

data

UserID Integer Unique

identifier for
specific records
First Name varchar First name of
the customer
Last Name varchar Surname of the
customer
Username varchar Username of
the customers
account
Password varchar Password to the
customers
account
Email varchar Email for the
customers
account

Staff table
 Field Name Data type Description of data

StaffID Integer Unique identifier for specific

records in staff table
First Name varchar First name of any staff
members
Last Name varchar Surname of any staff members
Username varchar Username of the accounts
made by staff
Password Varchar Password for the accounts
made by staff
Email Varchar Email for the accounts of staff
Phone Varchar A form of contract to
communicate with staff

Feedback table

Field Name Data type Description of data

FeedbackID integer Unique identifier of

records in the feedback
table
Name varachar Name of the account
leaving the feedback
 Email varchar Email to communicate
and contact those leaving
feedback
Comments text The actual comments and
reviews being left by the
customers
time Time stamp Time of creation if
feedback when it was left

Payment table

Field Name Data type Description of data

PaymentID integer Unique identifier of

records in the payment
table
Name varchar Name of the account
making a payment
Amount decimal Amount of money being
paid
Method varchar The method of payment
being used
Date Date time Date that the payment
took place

Products table
 Field Name Data type Description of data

ProductID integer Unique identifier for

records in the products
table
Name varchar Name of the products
Price decimal Price of the products
Stock integer How much stock there is
of a product
Description text Description of the product

Booking table

Field Name Data type Description of data

BookingID integer Unique identifier for

records in bookings table
Name varchar Name of the account
creating an appointment
email varchar Email of the account
making the appointment
date date Date at which the booking
is
time time The specific time on the
date for when
appointment starts

Algorithms Pseudocode & Flowcharts

Registering an account
Logging into an account

Updating an account
Deleting an account
Creating a booking
Deleting a booking
Updating a booking
Payment Track
 Variable and Testing Tables
Register
Variable Description Test Data Expected Outcome
FirstName This will be the first Albert Valid
name of the
customers
LastName This will be the last Smith Valid
name of the
customers
Username The username for “User123" Valid
customer "user1234567890” Consists of
identification “UserName65” alphanumeric
characters and they
 don't contain any
disallowed characters
or symbols.
Password The password for “123” Invalid
customer “Password” These are too basic to
authentication “1234567890” be used as passwords
Email The email address of “email@email” Invalid
the customers “invalid..email@exampl First one missed
e.com” a .com
Second one has a
double dot

Login
Variable Description Test Data Expected Outcome
Username The username used “User123" Valid
for authentication "user1234567890” Consists of
“UserName65” alphanumeric
characters and they
don't contain any
disallowed characters
or symbols.
Password The password used for “123” Invalid
authentication “Password” These are too basic to
“1234567890” be used as passwords

Update Account
Variable Description Test Data Expected Outcome
AccountID Unique identifier for “3212” Valid
account
newFirstName New first name for the "-” Invalid
account Does not fit format
Should not be null
newLastName New last name for the "Brown" Valid
account
newUsername New username for the “NewUsername” Valid
account
newPassword New password for the “Password213” Invalid
account This is too basic and
unsecure to be used
as a password

newEmail New email for the “[email protected]” Valid

account

Delete Account
 Variable Description Test Data Expected Outcome
AccountID Unique identifier for “3212” Valid
account

Create Booking
Variable Description Test Data Expected Outcome
Name The name of the Smith Valid
customer booking
Email Email address of the “24857” Invalid, should have an
customer booking @sign and domain
name
Date Date of the booking "-” Invalid
Does not fit format
Should not be null
Time Time of the booking "-” Invalid
Does not fit format
Should not be null

Delete Booking
Variable Description Test Data Expected Outcome
BookingID Unique identifier for “213” Valid
booking

Update Booking
Variable Description Test Data Expected Outcome
BookingId Unique identifier for "342” Valid
booking
NewName New name for the "Bailey” Valid
booking
NewEmail New email for the “[email protected]” Valid
booking
NewDate New date for the 23/11/29 Valid
booking
NewTime New time for the "-” Invalid
booking Does not fit format
Should not be null

Payment Tracking
Variable Description Test Data Expected Outcome
Name The name of the "Bailey” Valid
 customer making the
payment
Amount Amount being paid "-” Invalid
Does not fit format
Should not be null
Method Payment method "-” Invalid
being used Does not fit format
= Should not be null
Date Date the payment
took place

Development Milestones
Feature Purpose
Customers should be able to register and make This will allow customers to create accounts,
accounts providing a personalised experience and
personalised features such as order tracking and
saved preferences.
Customers should be able to log into the Enable customers to securely access their
accounts they have made accounts, ensuring privacy, and make use of the
services available through the booking system.
Customers should be able to leave feedback Customers will be able to leave feedback and
and comments about their experiences give suggestions about the booking system to
help the staff understand what works and is
liked, and what should be improved to support
future development.
Customers should be able to schedule This will allow customers to book sessions and
appointments without having issues such as time periods, where they can then attend the
double booking sessions, they've reserved without
encountering previous issues such as inefficient
rescheduling, struggles to obtain refunds, or
lack of calculations on the availability of time
slots.
Customers should be able to view a products This will allow customers to make purchases
page and add things to their basket outside of the scheduling of bookings, helping
the gym generate revenue and improving their
experiences with other equipment.
Staff should be able to view and edit the This will allow the staff to support customers
accounts made by the customers and enable them to make changes to their
account if necessary. Staff can ensure
compliance with company policies regarding
customer data handling and privacy.
Staff should be able to view and edit the This will allow staff to moderate the bookings
bookings made by the customers made by customers and will improve the
maintenance of the site.
Staff should be able to view and edit the This will allow the staff to manage and
comments left by the customers moderate the feedback forms to ensure that all
records are up to date and hold appropriate
and accurate information.
Staff should be able to view a list of payment This will allow staff to track the payment and
history and transactions transaction history to help manage things such
as refunds when rescheduling bookings or
cancelling them.
Staff should be able to visually see trends in This will allow the staff to see how the
data and activity among customers customers are behaving and view trends in data
so that they can make predictions or
observations