Final Count

HiLCoE School of Computer Science & Technology
Quads Gym Management System
A senior project document in partial fulfillment of the requirements for

the B.Sc. Degree in Computer Science
Prepared by: Brook Solomon

Henok Tesfu
Hiruy Bizuneh
Michael Mesfin
Advisor: Tesfaye Eyasu
September 2019
HiLCoE School of Computer Science & Technology

Quads Gym Management System
Prepared by: Brook Solomon

Henok Tesfu
Hiruy Bizuneh
Michael Mesfin
Approved by (Name and Signature):

Advisor: ______________________
Examiner: ______________________
Acknowledgement
We wish to express our sincere gratitude to our project advisor, Mr. Tesfaye Eyasu, for his
guidance, continuous support and encouragement throughout the completion of this final year
project. A warm thank is extended to lecturers at HiLCoE for sharing their resources, opinions,
knowledge, experience and skills in programming and development methodology, so generously.
We would also like to thank our family, friends in HiLCoE and our fellow classmates who have
offered their assistance in completing this project.
i
Table of Contents
1. Introduction..............................................................................................................................1
1.1. Background.......................................................................................................................1
1.2. Statement of the Problem..................................................................................................2
1.3. Objective of the Study.......................................................................................................2
1.3.1. General Objective......................................................................................................2
1.3.2. Specific Objectives....................................................................................................2
1.4. Scope of the Project..........................................................................................................3
1.5. Limitation of the Project...................................................................................................3
1.6. Methodology.....................................................................................................................3
1.7. Significance and Beneficiaries of the Project...................................................................5
1.8. Task Breakdown...............................................................................................................5
1.9. Feasibility Analysis...........................................................................................................7
1.9.1. Operational Feasibility...............................................................................................7
1.9.2. Economic Feasibility.................................................................................................7
1.9.3. Social Feasibility.......................................................................................................7
1.9.4. Technical Feasibility..................................................................................................7
2. System Requirements Specification Document.......................................................................8
2.1. Introduction/Overview......................................................................................................8
2.2. Purpose..............................................................................................................................8
2.3. Scope.................................................................................................................................8
2.4. Existing Systems...............................................................................................................8
2.4.1. Golden Gym...............................................................................................................9
2.4.2. Drawbacks of Golden Gym’s System........................................................................9
2.4.3. Virtuagym..................................................................................................................9
2.4.4. Drawbacks of Virtuagym’s System.........................................................................10
2.5. Proposed System.............................................................................................................10
2.6. Functional Definition......................................................................................................10
2.6.1. Functional Requirements.........................................................................................10
2.6.2. Non - Functional Requirements...............................................................................11
2.6.3. Business Rule...........................................................................................................12
2.7. System Models................................................................................................................14
ii
2.7.1. Use Case..................................................................................................................14
2.7.1.1. Use Case Diagram............................................................................................14
2.7.1.2. Use Case Description.......................................................................................15
2.7.2. Class Diagram..........................................................................................................28
2.7.3. Sequence Diagram...................................................................................................29
2.7.4. Activity Diagram.....................................................................................................40
3. System Design Document..........................................................................................................57
3.1. Introduction.....................................................................................................................57
3.2. Assumptions....................................................................................................................57
3.3. Constraints......................................................................................................................57
3.4. Design Goals...................................................................................................................57
3.4.1 Usability...................................................................................................................58
3.4.2 Reliability................................................................................................................58
3.4.3 Performance.............................................................................................................58
3.4.4 Portability................................................................................................................58
3.4.5 Security....................................................................................................................58
3.5. Software Architecture.....................................................................................................58
3.5.1 Xamarin Architecture..............................................................................................60
3.6. Subsystem Decomposition..............................................................................................61
3.6.1. User Management Subsystem..............................................................................62
3.6.2. Schedule Management Subsystem.......................................................................62
3.6.3. Offer Management Subsystem.............................................................................63
3.6.4. Payment Management Subsystem.......................................................................63
3.6.5. Data Management Subsystem..............................................................................64
3.6.6. Communication Management Subsystem............................................................64
3.6.7. Guide Management Subsystem............................................................................65
3.7. Hardware Software Mapping..........................................................................................66
3.8. Persistent Data Management...........................................................................................67
3.9. Access Control................................................................................................................68
3.10. Boundary Conditions...................................................................................................69
3.11. Subsystem Services.....................................................................................................69
4. Object Design Document.......................................................................................................70
iii
4.1. Object Design Trade-offs................................................................................................70
4.2. Interface Documentation Guidelines..............................................................................70
4.3. Package...........................................................................................................................70
4.4. Class Interface.................................................................................................................72
4.4.1. Schedule Class.....................................................................................................72
4.4.2. Class Model Class................................................................................................72
4.4.3. Package Class.......................................................................................................73
4.4.4. Guide Class..........................................................................................................73
4.4.5. User Class............................................................................................................74
4.4.6. Comment Class....................................................................................................74
4.4.7. Verification Class.................................................................................................75
4.4.8. Profile Class.........................................................................................................75
4.4.9. Trainer Class........................................................................................................76
4.4.10. QRcode Class...................................................................................................76
5. Implementation.......................................................................................................................77
5.1. Tools................................................................................................................................77
5.2. Major Class Code............................................................................................................77
5.2.1. Account Verification...............................................................................................77
5.2.2. Gym Classes Creation..............................................................................................78
5.2.3. Profile Editing..........................................................................................................79
5.2.4. Registration..............................................................................................................80
5.2.5. Membership Approval.............................................................................................82
6. Annexes..................................................................................................................................83
6.1. Questionnaire..................................................................................................................83
6.1.1. Introduction to Questionnaires................................................................................83
6.1.2. Questions for Gym Owners.....................................................................................83
6.1.3. Questions for Gym Members...................................................................................84
6.1.4. Summary..................................................................................................................85
6.1.5. User Manual.............................................................................................................85
6.1.5.1. Home Page.......................................................................................................85
6.1.5.2. Login Page – For all users of the system..........................................................86
6.1.5.3. Registration Page – For first time members.....................................................87
iv
6.1.5.4. Registered Member Profile Page......................................................................87
6.1.5.5. Registered Member Schedule Page..................................................................88
6.1.5.6. Classes Description Page..................................................................................88
6.1.5.7. Receptionist - Schedule Management Page.....................................................89
6.1.5.8. Receptionist - Member and Trainer Management Page..................................89
6.1.5.9. Gym Owner – Workout Class Customization Page.........................................90
6.1.5.10. Gym Owner – Membership Package Customization Page..............................90
6.1.5.11. Gym Owner – Receptionist Management Page...............................................91
6.1.5.12. Gym Owner – View Report Page....................................................................91
References......................................................................................................................................92
Glossary.........................................................................................................................................92
v
List of Figures
Figure 2.7- 1 - GMS Use Case Diagram.........................................................................................................................14
Figure 2.7- 2 - Analysis Class Diagram..........................................................................................................................28
Figure 2.7- 3 - Sequence Diagram for Login..................................................................................................................29
Figure 2.7- 4 - Sequence Diagram for Registration.......................................................................................................30
Figure 2.7- 5 - Sequence Diagram for Viewing Schedule..............................................................................................30
Figure 2.7- 6 - Sequence Diagram for Viewing Guides..................................................................................................31
Figure 2.7- 7 - Sequence Diagram for Tracking Information........................................................................................31
Figure 2.7- 8 - Sequence Diagram for Viewing Package...............................................................................................32
Figure 2.7- 9 - Sequence Diagram for Viewing Classes.................................................................................................32
Figure 2.7- 10 - Sequence Diagram for Posting Comment............................................................................................33
Figure 2.7- 11 - Sequence Diagram for Viewing Notification.......................................................................................33
Figure 2.7- 12 - Sequence Diagram for Payment..........................................................................................................34
Figure 2.7- 13 - Sequence Diagram for Managing Schedule........................................................................................34
Figure 2.7- 14 - Sequence Diagram for Managing Trainers..........................................................................................35
Figure 2.7- 15 - Sequence Diagram for Managing Members.......................................................................................35
Figure 2.7- 16 - Sequence Diagram for Posting Guides................................................................................................36
Figure 2.7- 17 - Sequence Diagram for Managing Class...............................................................................................36
Figure 2.7- 18 - Sequence Diagram for Managing Package.........................................................................................37
Figure 2.7- 19 - Sequence Diagram for Adding Notification.........................................................................................37
Figure 2.7- 20 - Sequence Diagram for Viewing Report................................................................................................38
Figure 2.7- 21 - Sequence Diagram for Managing Receptionist...................................................................................38
Figure 2.7- 22 - Sequence Diagram for Viewing Comment...........................................................................................39
Figure 2.7- 23 - Sequence Diagram for Generating QR code........................................................................................39
Figure 2.7- 24 - Activity Diagram for Login...................................................................................................................40
Figure 2.7- 25 - Activity Diagram for Registration........................................................................................................41
Figure 2.7- 26 - Activity Diagram for Viewing Schedule...............................................................................................42
Figure 2.7- 27 - Activity Diagram for Viewing Notification...........................................................................................43
Figure 2.7- 28 - Activity Diagram for Tracking Information..........................................................................................44
Figure 2.7- 29 - Activity Diagram for Adding Comment................................................................................................44
Figure 2.7- 30 - Activity Diagram for Viewing Guides...................................................................................................45
Figure 2.7- 31 - Activity Diagram for Viewing Package................................................................................................46
Figure 2.7- 32 - Activity Diagram for Viewing Class......................................................................................................46
Figure 2.7- 33 - Activity Diagram for Managing Trainer...............................................................................................47
Figure 2.7- 34 - Activity Diagram for Managing Schedule............................................................................................48
Figure 2.7- 35 - Activity Diagram for Managing Member............................................................................................49
Figure 2.7- 36 - Activity Diagram for Posting Guides....................................................................................................50
Figure 2.7- 37 - Activity Diagram for Adding Notification............................................................................................50
Figure 2.7- 38 - Activity Diagram for Managing Package.............................................................................................51
Figure 2.7- 39 - Activity Diagram for Managing Class..................................................................................................52
Figure 2.7- 40 - Activity Diagram for Viewing Report...................................................................................................53
Figure 2.7- 41 - Activity Diagram for Managing Receptionist......................................................................................54
Figure 2.7- 42 - Activity Diagram for Generating QR code...........................................................................................55
Figure 2.7- 43 - Activity Diagram for View Comment...................................................................................................56
Figure 3.5- 1 - Software Architecture Diagram.............................................................................................................59
Figure 3.5- 2 - Xamarin Architecture.............................................................................................................................60
Figure 3.6- 1 - Subsystem Decomposition Diagram......................................................................................................61
vi
Figure 3.6- 2 - User Management Subsystem...............................................................................................................62
Figure 3.6- 3 - Schedule Management Subsystem........................................................................................................62
Figure 3.6- 4 - Offer Management Subsystem..............................................................................................................63
Figure 3.6- 5 - Payment Management Subsystem........................................................................................................64
Figure 3.6- 6 - Data Management Subsystem..............................................................................................................64
Figure 3.6- 7 - Communication Management Subsystem.............................................................................................65
Figure 3.6- 8 - Guide Management Subsystem.............................................................................................................65
Figure 3.7- 1 - Hardware Software Mapping................................................................................................................66
Figure 3.8- 1 - Design Class Diagram............................................................................................................................67
Figure 4.3- 1 - Controllers..............................................................................................................................................71
Figure 4.3- 2 - Models...................................................................................................................................................71
Figure 4.3- 3 - Views......................................................................................................................................................71
Figure 4.4- 1 - Schedule Class........................................................................................................................................72
Figure 4.4- 2 - Class Model Class...................................................................................................................................72
Figure 4.4- 3 - Package Class.........................................................................................................................................73
Figure 4.4- 4 - Guide Class.............................................................................................................................................73
Figure 4.4- 5 - User Class...............................................................................................................................................74
Figure 4.4- 6 - Comment Class......................................................................................................................................74
Figure 4.4- 7 - Verification Class....................................................................................................................................75
Figure 4.4- 8 - Profile Class............................................................................................................................................75
Figure 4.4- 9 - Trainer Class...........................................................................................................................................76
Figure 4.4- 10 - QRcode Class........................................................................................................................................76
Figure 5.2- 1 - Account Verification...............................................................................................................................77
Figure 5.2- 2 - Gym Classes Management....................................................................................................................78
Figure 5.2- 3 - Profile Editing.........................................................................................................................................79
Figure 5.2- 4 - Registration............................................................................................................................................80
Figure 5.2- 5 - Registration............................................................................................................................................81
Figure 5.2- 6 - Membership Approval...........................................................................................................................82
Figure 6.1- 1 - Home Page.............................................................................................................................................86
Figure 6.1- 2 - Login Page.............................................................................................................................................86
Figure 6.1- 3 - Registration Page...................................................................................................................................87
Figure 6.1- 4 - Profile Page............................................................................................................................................87
Figure 6.1- 5 - Registered Member Schedule Page.......................................................................................................88
Figure 6.1- 6 - Classes Description Page.......................................................................................................................88
Figure 6.1- 7 - Schedule Management Page.................................................................................................................89
Figure 6.1- 8 - Member and Trainer Management Page..............................................................................................89
Figure 6.1- 9 - Workout Class Customization Page.......................................................................................................90
Figure 6.1- 10 - Membership Package Customization Page.........................................................................................90
Figure 6.1- 11 - Receptionist Management Page.........................................................................................................91
Figure 6.1- 12 - View Report Page................................................................................................................................91
vii
List of Tables
Table 2.6-1 - Business Rule...........................................................................................................................................13
Table 2.7-1 - Use Case Description for Registration.....................................................................................................15
Table 2.7-2 - Use Case Description for Login................................................................................................................16
Table 2.7-3 - Use Case Description for Viewing Schedule............................................................................................16
Table 2.7-4 - Use Case Description for Viewing Guides...............................................................................................16
Table 2.7-5 - Use Case Description for Viewing Notification.......................................................................................17
Table 2.7-6 - Use Case Description for Tracking Information......................................................................................17
Table 2.7-7 - Use Case Description for Viewing Package.............................................................................................17
Table 2.7-8 - Use Case Description for Viewing Classes...............................................................................................18
Table 2.7-9 - Use Case Description for Payment..........................................................................................................18
Table 2.7-10 - Use Case Description for Adding Comment..........................................................................................18
Table 2.7-11 - Use Case Description for Managing Trainers........................................................................................20
Table 2.7-12 - Use Case Description for Managing Schedule......................................................................................21
Table 2.7-13 - Use Case Description for Viewing Members.........................................................................................22
Table 2.7-14 - Use Case Description for Posting Guides..............................................................................................22
Table 2.7-15 - Use Case Description for Managing Package.......................................................................................24
Table 2.7-16 - Use Case Description for Managing Classes.........................................................................................25
Table 2.7-17 - Use Case Description for Viewing Report..............................................................................................25
Table 2.7-18 - Use Case Description for Managing Receptionist.................................................................................26
Table 2.7-19 - Use Case Description for Viewing Comment.........................................................................................26
Table 2.7-20 - Use Case Description for Generating QR codes....................................................................................27
Table 2.7-21 - Use Case Description for Adding Notification.......................................................................................27
Table 3.9-1 - Access Control.........................................................................................................................................69
Table 3.11- 1 - Subsystem Service.................................................................................................................................69
Table 4.4-1 - Schedule Class.........................................................................................................................................72
Table 4.4-2 - Class Model Class....................................................................................................................................73
Table 4.4-3 - Package Class..........................................................................................................................................73
Table 4.4-4 - Guide Class..............................................................................................................................................74
Table 4.4-5 - User Class................................................................................................................................................74
Table 4.4-6 - Comment Class........................................................................................................................................74
Table 4.4-7 - Verification Class.....................................................................................................................................75
Table 4.4-8 - Profile Class.............................................................................................................................................75
Table 4.4-9 - Trainer Class............................................................................................................................................76
Table 4.4-10 - QRcode Class.........................................................................................................................................76
viii
List of Acronyms and Abbreviations
GMS – Gym Management System

SDLC – Software Development Life Cycle
UML – Unified Modeling Language
XP – Extreme Programming
PHP – Hypertext Pre-processor
BR – Business Rule
SDD – System Design Document
MVC – Model-View-Controller
URL – Uniform Resource Location
QR Code – Quick Response Code
UML – Unified Modelling Language
XAML - Extensible Application Markup Language
XAMP - Cross-Platform (X), Apache (A), MariaDB (M), PHP (P) and Perl (P)
ix
Executive Summary
Nowadays gyms are more concerned how they conduct their business as well as attract new
members for retention. They want their members to feel comfortable with their membership. A
major issue is the lack of information the exists between gym administration and the members.
Henceforth the need for an online system for all parties that steps in the right direction in solving
the problem. This project explored the benefits of having an online platform for people looking
to manage their gym and for people looking for a membership. The methodology used to
accomplish this was the agile software engineering method; Extreme Programming. The system
used a web-based application to allow gym owners and their employees to manage the day to day
task and have their clients enjoy their membership with ease. Consequently, we hope to provide
an elegant means of running a business.
x
1. Introduction
1.1. Background
It is known that exercise is important. Exercise has a great impact on the body as it has all sorts
of benefits. Physical activities are very helpful not only on making people fit but also on
improving one’s personality. If they have a healthy body, they can be productive in daily life.
Exercise increases the energy level. Through it delivers oxygen and nutrients to the whole body
helping it to work more efficiently and boost endurance. It is also proven that regular exercise
decreases the risk of health problems.
A Fitness gym is a place for an indoor physical workout where numerous equipment is typically
used for health and fitness. For some people, a typical gym is a place where you focus on weight
lifting and similar activities. While it is true that gyms used to be reserved for weight training,
that is not the case nowadays. There are trainers that give exercise programs and help you to
become fit and strong. These days when people all over the world have become so much
concerned about their health and diet, it is but obvious that they continually seek out for gyms
which are loaded with the best equipment and trainers. To provide a good quality of service to
people, fitness gym should have an organized management system that will provide convenience
to their staff to perform their work more efficiently.
Modernizing is taking over all the systems and digitalizing helps them improve in so many
particular ways. QUADS Gym Management System is one of those systems which helps the
administration in speeding up the tasks at the same time reducing the complexity. The present
scenario at gyms is the recording of data currently being kept handwritten on a paper filing
system. Every management task is done manually, creating an unreliable and puzzling system to
keep track of. Payment transactions require the members to physically pay fees inside the gym
which is an inconvenience.
The purpose or objective of this system is to digitalize and create an automated system that
retains the records of gym members and accepts the payment of bills from the members through
QR coded currency. This will help the administration and staff in monitoring the daily activities
of the gym. This system does not only limit itself to the administration and but also helps the
members of the gym. The proposed system will be helpful to members because it will guide
them in doing proper exercise according to their schedule and improve the productivity of
business by gym owners providing an excellent service. This will improve the transparency
between the members and administration which is always a good quality in the system and will
also give a layer of security to the administration that only authorized users can gain access by
their credentials. It also helps the users in reducing the carbon footprint as the amount of paper
used for the work is decreased. This also helps in keeping the standard width of the management
1
system as if there is a case where the administration involves more than one person to manage
the gym.
1.2. Statement of the Problem

The proposed system is made to cater to the requirements of a fitness gym. The main problem
with the current system from the management aspect is the overall manual process of
registration, transaction, and scheduling of training programs. The aforementioned processes
become quite cumbersome meanwhile any wrong data entered mistakenly can bring serious
results. As for evidence that supports the existence of said problem is the massive paper trail that
can be found in the work place.
More issues underlying with the current setting are:
 Searching a particular information to a specific requirement is quite tedious. The

responsible party needs to retrieve records by hand at the same time a large amount of
data cannot easily be viewed at a glance hence both are time consuming.
 Updating is not performed efficiently and may lead to complications. Data redundancy is
a key issue as current data changes or modifications are not updated simultaneously for
authorized parties. It leads to inconsistencies in data handling as well as destroys the
integrity of the data and creates confusion for management.
 Data and files are stored physically meaning it can easily be misplaced or damaged.
There are no scheduled file back-ups or data risk management system in place. Such
means of data handling leads to a more disastrous way of running a business.
The current system from the customer/members aspect is also lacking in contrast to the proposed
one. Newcomers are restricted to registering and making payments inside the gym without any
knowledge as to if the gym is accepting any new members. Those who were not able to register
the first time would not even know whether spots were available after their misfortune. Enrolled
members also had to deal with constantly remembering when to pay and physically paying
regardless of their schedule before losing the membership. Members could not also keep track of
their workout statistics, and gain information from the employees that will help with their
enduring fitness.
1.3. Objective of the Study
1.3.1. General Objective
The main objective of the project is to design and develop a Web-based GMS, offering complete
support and assistance while improving member retention.
1.3.2. Specific Objectives
2
To meet the overall objective of the project, these specific objectives are set:
 To make it possible for gym owners to specify the membership packages and their
durations, and also assign prices for the various payment packages.
 To allow members to register and pay for their membership online.
 To allow employees to set workout class schedules and manage trainer’s information in a
simple and orderly fashion.
 To record registered members information for the utilization of a workout statistics.
 To track and inform the gym members of their fitness and health status in order to keep
them up-to-date.
1.4. Scope of the Project

The scope of the project is limited to the automation of a GMS managing over the old process of
registration and transactions of the gym while adding new key features such as:
 Membership Package Plans: Owner can define different membership plans and assign
membership period for each plan as well as their prices.
 Scheduled Timetable: A streamlined weekly schedule full of exercise classes that can
easily be managed by the reception that the member can gain access to.
 Activity Tracking: Members are intended to specify their body requirements along with
their present health condition during registration so that members can keep the track of
their future activity and changes.
 Workout Guides: After analyzing members provided data, trainers recommend them
proper set of exercise, routine and diet.
 Payment Accounts: Members are opted to scan QR coded currencies for fee payment.
1.5. Limitation of the Project

Some of the possible impedances that may affect the system from achieving its goal are:
 The system will try to make sure any information about the members put in their profile
is filled into completion as much as possible. But there are some circumstances where
users are reluctant to input their measurements. This will affect future calculations
regarding their changes during workout. Still, there is always the possibility for the users
to top-up the missing information about their body measurements at a later time.
 Due to the absence of a fully functional online payment platform, we had to adapt and
implement a simpler payment module in order to include payment capabilities. The
proposed systems payment method is only available locally and does not embrace the
more accustomed online payment platforms. Online payment services will likely be
available and be integrated into the system in the near future.
1.6. Methodology
System Implementation: Extreme Programming Methodology
3
Extreme Programming (XP) is a software engineering methodology, the most prominent of
several agile software development methodologies [1]. Like other agile methodologies, Extreme
Programming differs from traditional methodologies primarily in placing a higher value on
adaptability than on predictability [1]. Proponents of XP regard ongoing changes to requirements
as an often natural and often inescapable aspect of software development projects; they believe
that being able to adapt to changing requirements at any point during the project life is a more
realistic and better approach than attempting to define all requirements at the beginning of a
project and then expending effort to control changes to the requirements [1].
The main uses for the application of Extreme Programming methodology are:
 It is chiefly used for crafting software within a very unbalanced atmosphere.

 It enables greater tractability within the modeling procedure.
 The foremost aim of this XP model is to reduce the cost of software essentials.
 It is fairly mutual in the XP model that the price of altering the requirements on future
stage in the project can be really whooping.
Why XP Methodology?
 It lays focus on customer involvement

 Establishes rational plans and schedules
 Developers are exceptionally committed to the project
 Rapid feedback
 Simplicity
 Incremental change
 Embracing Change
 Humanistic
 Based on the mentality of sufficiency
For modeling and diagram design, the Unified Modeling Language will be used. This is a
standardized modeling language consisting of an integrated set of diagrams, developed to help
system and software developers for specifying, visualizing, constructing and documenting
artifacts of a system, as well as for business modeling and other non-software systems [2].
Tools used:
Programming Tools:
 PHP
 Java
 C#
 Bootstrap
Frameworks:
4
 Laravel
IDE:
 PHP Storm
 Visual Studio
Documentation Tools:
 Microsoft Visio 2019

 Microsoft Word 2019
 Microsoft Project 2019
Data Gathering Methods:
 Questionnaire
 Observation
1.7. Significance and Beneficiaries of the Project

The proposed GMS provides a significant improvement to the gym owner, the gym employees
and its members above the manual process of the current system. The proposed system will help
with the following recipients:
 Gym Owners: The system will keep the records of dealings with their clients and it will
be helpful in monitoring their business.
 Gym Staff/Reception: Using an automated system will lessen the effort and avoid hassle
in membership approval, keeping their records and sending out reports.
 Clients/Members: It will provide privacy on their personal information and payment
transactions. They will not be confused on what workout they will do where system will
provide guidelines in performing exercises.
1.8. Task Breakdown

In order to develop the process model of the new system at first, the system analysis and the
requirement analysis of the proposed system has to be done.
Task 1(ID:TK01) - Requirements Elicitations (Gathering)
Questionnaire Structures:
Our goal is to implement a new system and to overcome the drawbacks of the existing manual
system. That’s why we have to go through a questioning process which will give the necessary
information about the project requirements and help to solve a problem as well as fulfill the
member’s requirements.
5
For this purpose, the questions must address to the gym’s owners and its members in this regard,
we discussed with them about our proposed GMS and wanted to know about the existing
problem of manual Gym management as a whole. We will also try to collect their opinions about
the development of our system, which will help us in including new system or add new features.
Observation:
As students we were already familiar with some existing procedure. Yet we will communicate
with the administrative level personnel (Gym Owner) to know all the specific activities as stated.
 How the information is stored?

 How membership is guaranteed?
 How payment is made?
 What are the rules of memberships (Package offers)?
Requirements Analysis:
We should need to analyze the following things for the GMS:
Membership Forms: Forms and documents which are used for assuring membership duration.
Schedule Timetable: For workout classes and overall gym working hours.
Payment Method Forms: Transactional papers and receipts.
Task 2(ID:TK02) - System Design
In this phase, we will analyze our module and fragment the overall module in some small
modules which help us to complete the total system easily.
Task 3(ID:TK03) – Development/Construction
We will make the task flow and code flow of each module in this phase. We will write the actual
code to build up the modules.
Task 4(ID:TK05) - Testing, bug finding and fixing
We will test the overall features of the software. By testing the features, we will find out the
bugs. After that, all the bugs will be solved.
Task 5(ID:TK06) – Deployment and Maintenance
The manual for the software will be developed at the end of this task.
6
1.9. Feasibility Analysis
System is worth developing only if it can meet the establishments operating requirements. The
feasibility study proposes one or more conceptual solutions to the problem set for the project.
The following are the criteria that are considered to confirm the project feasibility.
1.9.1. Operational Feasibility
Concerning the feasibility of the project with respect to the its operation, the system is targeted to
be in harmony with the afore-mentioned issues. Earlier, the management issues and user
requirements have been taken into consideration. So, there is no question of resistance from the
users that can undermine the possible application benefits.
1.9.2. Economic Feasibility
The development of the system is evaluated against the ultimate benefit derived from the new
system. Financial benefits must equal or exceed the costs. The system is economically feasible. It
does not require any special hardware or software. Once the interface for this system is up and
running it will more than make up its development cost.
1.9.3. Social Feasibility
Although generally there is always resistance, any change in the system is initially aimed at
reliving the work load of the users. The system is going to facilitate user to perform operations
like calculating package price amounts and deductions, generating reports with less possible
errors. Thus, there is no reason to make system socially unfeasible.
1.9.4. Technical Feasibility
The proposed system developed is technically feasible. It is a web-based user interface which
provides an easy access to all users. The database’s purpose shall be to create, establish and
maintain a work-flow among various entities in order to facilitate all concerned users in their
various capacities or roles. Permission to the users would be granted based on the role specified.
Therefore, it provides the technical guarantee of accuracy, reliability and security.
7
2. System Requirements Specification Document
2.1. Introduction/Overview
Health is very important factor because a person who is fit physically & mentally will be capable
of being less prone to medical condition and living life to its fullest extent. Therefore, a
“QUADS Gym Management System” will provide a workout atmosphere with service to enroll
at a gym via online. Members who have enrolled can access their schedule and workout classes
at the best time per their schedule. After some data entry in the database, system will
automatically update the members body measurements while staff recommend workouts guides
for members by enquiring their condition of health. System will be profitable for both owner of
the gym and members. The first profit which is that they will save both money and time.
Secondly, members will achieve effective fitness through high level of encouragement and
motivation provided by the gym. So, this system of health and fitness business will give good
results that can sometimes be truly life changing.
2.2. Purpose
The purpose of this system is to provide an easy-to-use gym management system. It strives to
deliver a system where it supports in keeping records of members and their memberships, and
allows easy communication between management and its members. QUADS Gym Management
system is also feature-packed, helping those in management and benefit the growth of the gym. It
provides a scheme which handles the information of the people joining the gym to maintain their
health. It even maintains an organized timetable for people who joined the gym through schedule
management. Data will be stored in a secure database. The system is strong enough to withstand
regressive yearly operations under conditions where the database is maintained and cleared over
a certain time of span. The implementation of the system in the gym will considerably reduce
data entry, time and also provide readily calculated reports regarding supervision.
2.3. Scope
The scope of the project is limited to the automation of a GMS managing over the old process of
registration and transactions of the gym. Members are intended to specify their body
requirements along with their present health condition during registration so that members can
keep the track of their future activity and changes. After analyzing members provided data,
employees recommend them proper set of exercise, routine and diet. Meanwhile admins can
define different membership plans and define membership period for each plan as well as price
management. There is also a weekly schedule full of exercise classes that can easily be managed
by the reception that the member can gain access to.
2.4. Existing Systems

In the gym management system, which is currently practical in Ethiopia is so far behind in
comparison with the system we have proposed. Stated below will be two different systems, one
8
of which is located in our country and the second one is a foreign system with somehow
similarities to the proposed system but with lacking features.
2.4.1. Golden Gym

Golden Gym, one of the largest gyms located here in Addis Ababa, which has hundreds of
members engaged in fitness on a daily basis. They claim to have state-of-the-art workout
machineries as well as certified trainers for the best gym experience that any member could ask
for. First time members are required to register to the gym physically and have no prior
information whether the gym is accepting more members. Members who have successfully
registered have no identifications for their next arrival and are required to check-in with
reception every time. Members are obligated to memorize their weekly schedules and choose
dates according to their payment plan. They are given printed out schedules and trainer’s
information for their workout classes of choice. On the management side of things employees are
require to update the weekly schedule and post it at the receptions notice board. Data handling
operations like updating and synchronizing are also done manually in the existing system. Gym
owners manage their business by requesting reports of weekly activities from the employees.
2.4.2. Drawbacks of Golden Gym’s System

Every work in this existing system takes place manually and is done on paper. The computers
used in the work place are not doing exactly what they are supposed to which is reducing the
ongoing manual work. These practices are not at all reliable as one wrong entry can take a lot of
time in detection. Hence, the need for correction is obligatory. Humans are prone to errors and
can make mistakes more often without the assistance of ingrained programs which can check
their inputs and save from error.
More issues with the existing system:
 Entail a lot of paperwork, resulting in slow search.

 Need for immense storage space for handwritten documents.
 Prone to damages, also requires a good amount of security.
 Require purchasing of goods more frequent as compared to the online system. E.g. Paper
(stationaries) and other office supplies.
 Restrict members to pay fees physically.
 Restrict location since information is not available globally for both members and
management.
2.4.3. Virtuagym
Current system “Virtuagym” includes online payments and invoice to members which is a very
good feature. It provides free demos for users who are using system for the first time [3]. It
contains a rich library of workout with thousands of animations so that members can choose
from their database. There is nutrition coaching where it creates plans of diet for members and
also trainers assign members their daily workouts [3].
9
2.4.4. Drawbacks of Virtuagym’s System
 Workout schedule is non-existent, only implies users to come up with theirs if need be.
 Members are not required to enter their body measurement so no keeping track of
ongoing changes after following their routines and/or regimens.
 Not integrated to a working gym meaning users are reluctant in believing whether the
information received from trainers and nutritionists are reliable.
 Even if there is any question to user about his/her diet or workout, user will get a delayed
response.
 Trainers are not always available for user for their doubts.
2.5. Proposed System

This is a fully-fledged system which will be the backbone for the whole management of the gym,
so ignoring the risks and errors from the existing system is not an option as later it can make a
greater form of itself. We introduced the system to reduce the manual work effectively as there is
the backend of the system which will take care of synchronizing and updating of the data. So, if
there is any change in the system data it will appear to all users of the system. As the system was
not previously online the members could not see the event generated by them in the past such as
fee payment, workout schedule, workout statistics and recommendations (guides).
Keeping an automated system also helps in securing the member’s information instead of the
records being kept in a physically safe location. Sensitive information can only be seen by the
administrator and employees with the correct credentials which does not happen to be an option
in the existing system.
In the proposed system users are opted between the use of either the website or the mobile
application. Users can both register and login as members on both device but updating balance is
only included in the mobile application via the implementation of our payment module where the
user has to scan a QR code currency membership card. Each QR code is specific to the various
amount of currency customized by the gym owner.
2.6. Functional Definition

As any other system, this will have an input, process, output, prerequisites, conditions, side
effects, post conditions, integration of functions (modules) and problems in the process.
2.6.1. Functional Requirements

1) End-users (Members)
 System will provide registration and authentication by login.

 System shall provide online payment capability.
 User can change personal details at any time
 Users shall be able to view their personal details
 Users shall be able to view their workout schedule
10
 System shall be able to provide members with workout guides and recommendations
 System shall keep track of measurements and statistics of changes
2) System Owners
 System will provide secure login

 Can view his/her details
 Can have record of all employees
 Can add new employee
 Can delete employee
 System shall be able to generate reports
 Can manage classes and packages
 Can set and make changes on payment
3) System managers (Reception)
 System will provide Secure login

 Approve pending members
 Disapprove registered members
 Can manage trainer information
 Can view members details
 Can view and edit schedule
 Can post exercise guides for members
2.6.2. Non - Functional Requirements

The non-functional requirements of our system are as follows:
 System should provide a consistent user experience throughout the interface. It should
use contrasting colors that will catch to members attention, and avoid bad color
combinations so as to drive and motivate clients to join the Gym.
 Navigation towards other pages should require minimum effort. Navigating to major
features from any page should not take more than four pages.
 The system must be accessible from mobile phones, desktops, and laptops. It must be
adaptable to size changes when it is used in different devices.
 All data files should be backed up on a tape drive and stored in a separate off-site
location.
 Onsite backups should be taken daily and weekly, while off-site backups should be taken
every month.
 The server room should require locks and electric card for entry.
 The system should validate inputs provided by the users.
 The system helps to maintain the privacy of user by best encryption method techniques.
11
 User password must be at least eight characters long and must require small and capital
letter, special character, and a number.
 The validity of a user should be checked and approved by the receptionist.
 All web pages generated by the system shall appear in no more than ten seconds.
 The application can run on any system with a web browser. So, it can be used wherever
the member or system owner desires.
 The application is user-friendly and no prior knowledge is required to access it.
Application is simple and easy to use.
 The product can be used on any system. Since it’s a web-based system there is no harm in
using it. It is all healthy and safe.
 The sustainability of the system validates the member’s needs. There is no resistance
from members since new system is helpful.
2.6.3. Business Rule

A business rule is a statement that defines or constrains some aspects of the business [4]. The
business rule that defines the business aspects of the system is shown in below.
ID Rule Definition Type of Static or Source

Rule Dynamic
BR-1 Guests can explore the system without Policy Dynamic Gym Owner, Reception,
registering. Member, System
Developers
BR-2 Guests must be registered to access services Constraint Static Members, Reception,
of the system. System Developers
BR-3 Guests must have an email address to register. Constraint Dynamic System Developers
BR-4 Guests must verify account using email Constraint Static Member,
address in order to login. System Developers
BR-5 A gym owner should be able to create, edit, Policy Static Gym Owner,
remove and view receptionists. System Developers
BR-6 A logged in gym owner should be able edit Policy Dynamic Gym Owner,
the value of the QR code currency. System Developers
BR-7 A logged in gym owner should be able create, Policy Dynamic Gym Owner,
view and edit the packages/classes. System Developers
BR-8 A logged in gym owner should be able to Policy Dynamic Gym Owner,
view reports generated from by the system. System Developers
BR-9 Members logged in using the mobile Policy Dynamic Members,
application must purchase and scan the QR System Developers
code in order to add currency to their balance
BR-10 An approved logged in member should be Policy Dynamic Member,
able to view schedule and guides. System Developers
12
able to view his/her personal information for System Developers
tracking.
able to choose his/her payment method. System Developers
BR-13 An approved logged in receptionist should be Policy Dynamic Reception,

able to approve paying members and System
disapprove those who have not. Developers
BR-14 The system should notify logged in members Policy Static Members,
upon changes they are interested in. System Developers
BR-15 A receptionist must verify the payment of Policy Dynamic Reception,

guests for approval. System Developers
Table 2.6-1 - Business Rule
13
2.7. System Models
2.7.1. Use Case
2.7.1.1. Use Case Diagram
A use case is the specific way of using the system by using some part of the functionality; this
describes the simplest representation of a user’s interaction with the system that shows the
relationship between the user and the different use cases in which the user is involved [5]. A use
case diagram can identify the different types of users of a system and the different use cases.
Pay_Fee Manage_Members
Add_Trainer <<include>> Manage_Trainer

<<extend>>
Edit_Trainer <<extend>>
Post_Guides
Remove_Trainer
Register
<<include>> Manage_Schedule
Login
View_Guides
<<extend>> Receptionist
<<include>> <<extend>>
Edit_Schedule
View_Schedule
Add_Schedule Remove_Schedule
Member
Track_Activity Generate_Report
View_Report
Generate_QRcode
View_Package Verfication
<<include>> Manage_Package
Add_Package Gym Owner
<<extend>> <<extend>>
Edit_Package
Remove_Package
Add_Class
<<include>>
Edit_Class <<extend>> Manage_Class
<<extend>>
Remove_Class
View_Class
<<include>> Manage_Receptionist
Add_Receptionist
<<extend>>
Remove_Receptionist
Add_Comment <<include>> View_Comment
View_Notification <<include>> Add_Notification
Figure 2.7-1 - GMS Use Case Diagram
14
2.7.1.2. Use Case Description
The following tables show description of use case for each use case.
Use Case Id UC-01
Use Case Name Registration
Participating Actors Member
Description All members must be registered in order to use the GMS it includes like
view schedule, make payment, view guides, tracking personal
information.
Pre-Condition Members must visit the website in order to register.
Flow of Event 1. The actors click on register link.
2. The system displays registration form.
3. The actor fills the required information.
4. The actor clicks on the register button to submit the
information.
5. The system validates the information filled by the actor.
6. Request the actor to verify his/her account through their
email.
7. The system saves the actor data into the database.
8. Display a “Successfully registered” message and
9. Redirects to the login page.
Exception Step 5: If the information filled by the actor is invalid. The system
displays invalid message. Then go to step 2
Step 6: If the actor didn’t verify his/her account it won’t login. So, it
must be verified in order to use the system.
Post Condition A new member is successfully registered into the system.
Table 2.7-2 - Use Case Description for Registration
Use Case Id UC-02

Use Case Name Login
Participating Actors Member, Receptionist and Gym Owner
Description The actor needs to be logged-in, in order to use the system.
Pre-Condition The actor should have an account and it must be verified to log in to the
system.
Flow of Event 1. The actor clicks on login link.
2. The system display the login form.
3. Actor enters the email and password.
4. The actor clicks on login button.
5. The system validate and checks credentials.
6. The system takes the actors to their own window depending
on type of the actor.
Exception Step 5: If email and/or password are incorrect the system will display
invalid message and request the actor to try again. Step 2
15
Post Condition The actor is successfully logged in into the system.
Table 2.7-3 - Use Case Description for Login
Use Case Id UC-03

Use Case Name View-Schedule
Participating Actors Members and Receptionist
Description This use case allows actors to see schedules that are posted by
Reception in order to do the activities.
Pre-Condition Actors should be logged-in in order to view schedule details.
Flow of Event 1. The actor clicks on schedule link.
2. The system shows the schedule that are add by the reception.
3. The actor view the schedule.
Exception Step 2: if the reception didn’t add the schedule it will not show them
schedule.
Post Condition The schedule detail is displayed successfully.
Table 2.7-4 - Use Case Description for Viewing Schedule
Use Case Id UC-04

Use Case Name View-Guides
Description Allows the actor to view guides. It helps the actor to improve his/her
work out performance.
Pre-Condition The actor should be logged-in to view guides.
Flow of Event 1. The actor clicks on Guides link.
2. The system will display the guides that are posted by
reception.
3. The actor views the guides.
Exception Step 2: if the guides didn’t send by the reception. It doesn’t show.
Post Condition Guides are shown to the actor.
Table 2.7-5 - Use Case Description for Viewing Guides
Use Case Id UC-05

Use Case Name View-Notification
Description It updates the actor with new information
Pre-Condition The actor must be logged-in to view notification
Flow of Event 1. The actor clicks on the My_Profile link.
2. The system displays actors’ profile.
3. The system shows the message.
4. The actor views the message.
Post Condition The actor views notification that is sent by the actor.
Exception Step 3: If gym owner did add a notification it doesn’t show.
Table 2.7-6 - Use Case Description for Viewing Notification
16
Use Case Id UC-06
Use Case Name Track activity
Description Allows the actor track their information if they have achieved their goal
like weight loose or gaining. The actor can calculate his/her BMI.
Pre-Condition The actor should be logged-in to track his/her information.
Flow of Event 1. The actor clicks on the My_Goal link.
2. The system displays actor’s status information.
3. The actor fills his status like current weight and height
4. The system calculate the BMI. Shows the actor if they
achieved their goal.
5. Saves the data to the database.
Post Condition Displays actor’s goal, achievements and status.
Table 2.7-7 - Use Case Description for Tracking Information
Use Case Id UC-07

Use Case Name View-Package
Participating Actors Member, Reception, Gym Owner
Description It helps the actor to view different packages and their detail that are
posted by the gym owner
Pre-Condition The actor must be logged in order to see the packages.
Flow of Event 1. The actor selects the package link.
2. The system shows packages that are posted by the gym owner.
3. The actor views the packages and their detail.
Post Condition Packages are displayed to the actor.
Table 2.7-8 - Use Case Description for Viewing Package
Use Case Id UC-08

Use Case Name View-Class
Participating Actors Member, Reception, Gym Owner, Reception
Description It helps the actor to view different classes that gym has and their detail
that are posted by the gym owner
Pre-Condition The actor must be logged in order to see the packages.
Flow of Event 1. The actor selects the class link.
2. The system shows classes that are posted by the gym owner.
3. The actor views the classes and their detail.
Post Condition Classes are displayed to the actor.
Table 2.7-9 - Use Case Description for Viewing Classes
Use Case Id UC-09

Use Case Name Pay-Fee
Description In order to be legit member and to access the site fully the actor must
pay. The payment method can be processed by using phone. Which
17
helps to scan the QR code.
Pre-Condition The actor must be Logged-in by his/her phone in order to pay.
Flow of Event 1 The actor clicks on QR tap.
2 The system displays the QR page.
3 The actor clicks on scan button.
4 The system displays the QR code scanner.
5 The actor scans the QR code using his phone.
6 The system updates the balance information.
7 The system displays a message saying successfully scanned.
Alternative flow
Post Condition The actor will be a legit member.
Exception Step 5: if the actor scans unsupported or invalid QR code it doesn’t pay.
Table 2.7-10 - Use Case Description for Payment
Use Case Id UC-10

Use Case Name Add-Comment
Description It helps the actor to give comment on the gym or on the system. The
comment made by the actor are going to be viewed by the gym owner
only.
Pre-Condition The actor must be a legit member in order to give a comment and it has
to be logged in.
3. The actor selects comment.
4. The system displays the comment section.
5. The actor writes a comment or feedback.
6. The actor clicks on post button.
7. Saves the information to the database.
8. The system displays sent comment message.
Post Condition The comment has been submitted to the gym owner.
Table 2.7-11 - Use Case Description for Adding Comment
Description for Trainer management use case it is a general use case for
 Adding Trainer
 Removing Trainer and
 Editing Trainer
Use Case Id UC-11

Use Case Name Manage-Trainer
Participating Actors Reception
Description Allows the actor to manage the trainer data. Entering trainer data helps
18
with the schedule. Like who trains on Monday, what kind of exercise
does he/she train.
Pre-Condition The actor should be login in order handle the trainer data.
Flow of Event E1 if the actor chooses to add a trainer.
1.1 The actor selects on manage user link.
1.2 The system displays manage member and manage trainer
tabs.
1.3 The actor chooses manage trainer.
1.4 The actor clicks on the registered trainers tab.
1.5 The system shows trainers data table.
1.6 The actor clicks on add trainer button.
1.7 The actor enters the trainer data.
1.8 The actor clicks on register trainer button.
1.9 The system will verify the data that the actor entered.
1.10 The system adds trainer data to the database.
1.11 The system shows a successfully registered message.
Alternative flow E2. If the actor chooses to remove a trainer.
tabs.
2.3 The actor chooses manage trainer.
2.6 The actor selects a trainer.
2.7 The actor clicks on the delete button to remove the trainer
data.
2.8 The system will ask a confirmation message to remove
trainer.
2.9 The actor clicks on conform button to the remove the trainer.
2.10 The system removes trainer data from the list and the
database.
2.11 The system updates the database.
2.12 The system shows a successfully removed message.
E3. If the actor chooses to edit trainer data.
tabs
3.3 The actor chooses manage trainer
3.6 The actor selects a trainer.
19
3.7 The actor clicks on the edit button.
3.8 The actor edits trainer data.
3.9 The actor clicks on edit trainer.
3.10 The system will ask a confirmation message to save the
updated information.
3.11 The actor clicks on conform button.
3.12 The system will update trainer data.
3.13 The system shows trainer data updated message.
Exception E1 step 1.9: the system checks on trainer’s data like if there is a missing
information and if trainer age is under 18, trainer data will not be added.
E2 step 2.8: If the actor chooses not to remove trainer’s data, the actor
must click on no thanks.
E3 step 3.10: If the actor chooses not to edit trainer’s data, the actor
must click on no thanks.
Post Condition Trainer data is managed and uploaded to the site in order to add
schedule.
Table 2.7-12 - Use Case Description for Managing Trainers
Description for Schedule management use case it is a general use case for
 Adding Schedule
 Removing Schedule and
 Editing Schedule
Use Case Id UC-12

Use Case Name Manage-Schedule
Description Allows the actor to manage schedules.
Pre-Condition The actor should be login in order handle the schedules.
Flow of Event E1. If the actor chooses add schedule.
1.1 The actor selects schedule link.
1.2 System display schedule form for the actor.
1.3 The actor will click on add schedule button.
1.4 The actor enters the schedule information.
1.5 The actor clicks on save button.
1.6 The system will valid the data that the actor enters.
1.7 The system adds trainer data to the database.
1.8 The system displays schedule added successfully message.
Alternative flow E2. If the actor chooses to remove a schedule.
2.1 The actor chooses the schedule link.
2.2 The actor will click on delete button to remove the schedule.
2.3 System will ask the confirmation from to delete the schedule.
20
2.4 The actor clicks on conform button to remove the schedule.
2.6 The system displays schedule successfully removed
message.
E3. If the actor chooses to edit the schedule.
3.1 The actor chooses the schedule link.
3.2 The actor will click on edit button to update the schedule.
3.3 The actor edits the information.
3.4 System will ask a confirmation message box to save the
schedule.
3.5 The actor clicks on conform button.
3.7 The system displays schedule successfully edited.
Exception E1 step 1.6: If the actor didn’t fill the data properly it will not be added.
The actor must fill the data properly in order to save the schedule data.
E2 step 2.4: If the actor chooses not to remove, the actor must click on
no thanks.
E3 step 3.4: If the actor chooses not to edit, the actor must click on no
thanks.
Post Condition Schedule is managed and uploaded to the site.
Table 2.7-13 - Use Case Description for Managing Schedule
Use Case Id UC-13

Use Case Name Manage-Members
Description This use case is to allows the actor to approve and disapprove members
who have paid or not.
Pre-Condition Actor should be login in to the system to approve members
Flow of Event 1. The actor selects manage user link.
2. The system displays manage member and manage trainer
options.
3. The actor clicks on the manage member tab.
4. The system displays drop down list registered member
and pending member options.
5. The actor clicks on pending member to approve
members.
6. The actor clicks on a toggle button.
7. The approved member goes to registered member list.
8. The system updates the database.
Alternative flow
Exception E1 Step 5: if the member did not pay with a given time, it’ll not be
approved.
21
Post Condition Members are approved.
Table 2.7-14 - Use Case Description for Viewing Members
Use Case Id UC-14

Use Case Name Post-guides
Description This use case helps the actor to prepare and upload resources such as
exercises music, workout instructions, video tutorial embeded links.
Pre-Condition Actor should be login in to the system to post resources to the members.
Flow of Event 1. The actor selects on manage guides link.
2. The System display the resource form.
3. The actor adds resources that he/she wants to send.
4. The actor will click on upload button to send the guides and
the resources.
5. The System displays the resources successfully uploaded.
Alternative flow
Exception
Post Condition Guides successfully posted.
Table 2.7-15 - Use Case Description for Posting Guides
Use Case Id UC-15

Use Case Name Manage-Package
Participating Actors Gym Owner
Description It helps the actor to set payment rule. Like weekly, monthly, termly and
yearly payment system.
Pre-Condition Actor should be login in to the system to add payment details
Flow of Event E1. If the actor chooses to add package.
1.1 The actor selects on manage package link.
1.2 The system displays package card forms.
1.3 The actor selects on add new plan card form.
1.4 The actor fills the form.
1.5 The system will check the data the actor entered.
1.6 The actor clicks on add new plan button.
1.7 The system saves the data to the database.
1.8 The system displays you successfully added package
message.
1.9 Redirect to manage package.
Alternative flow E2. If the actor chooses to edit package.
2.3 The actor selects a plan card.
22
2.4 The actor edits the data of the package.
2.5 The actor clicks on update plan.
2.6 The system will verify the data that the actor enters.
2.8 The system displays you successfully edited package
message.
E3. If the actor chooses to remove package.
3.3 The actor clicks on ‘x’ sign to remove the package he/she
want.
3.4 A conformation box is displayed.
3.5 The actor clicks on ‘remove now’ button.
3.6 The system will remove the information from database.
3.7 The system displays a message which says you successfully
removed package.
Exception E1 step 4: If the actor didn’t fill the name of the package or price it will
not add the package. The system tells the actor to fill the data
properly.
E2 step 6: If the actor didn’t fill valid data it will not edit the package.
The system tells the actor to fill it properly.
E3 step 4: If the actor chooses not to remove, the actor must click on no
thanks.
Post Condition Package is managed like add, edit and remove.
Table 2.7-16 - Use Case Description for Managing Package
Use Case Id UC-16

Use Case Name Manage-Class
Description It helps the actor to set classes that are given by the gym.
Pre-Condition Actor should be login in to the system to add payment details
Flow of Event E1. If the actor chooses to add class.
1.1The actor selects on manage class link.
1.2The system displays class card forms.
1.3 The actor selects on new class card form.
1.5 The system will check the data that is entered by the actor.
1.6 The actor clicks on add new class button.
1.7 The system saves the data to the database.
1.8 The system displays you successfully added class
23
message.
1.9 Redirect to manage class.
Alternative flow E2. If the actor chooses to edit class.
2.1 The actor selects on manage class link.
2.2 The system displays class card forms.
2.3 The actor selects a plan card.
2.4 The actor edits the data of the class.
2.5 The actor clicks on update class button.
2.6 The system will verify the data that the actor entered.
2.8 The system displays you successfully edited class message.
E3. If the actor chooses to remove class.
3.1 The actor selects on manage class link.
3.2 The system displays class card forms.
3.3 The actor clicks on ‘x’ sign to remove the class he/she want.
3.4 A conformation box is displayed.
3.5 The actor clicks on ‘remove now’ button.
3.6 The system will remove the information from database.
3.7 The system displays a message which says you successfully
removed class.
Exception E1 step 4: If the actor didn’t fill the name of the class or price it will
not add the class. The system tells the actor to fill the data
properly.
E2 step 6: If the actor didn’t fill valid data it will not edit the class. The
system tells the actor to fill it properly.
E3 step 4: If the actor chooses not to remove, the actor must click on no
thanks.
Post Condition Class is managed like add, edit and remove.
Business Rule
Table 2.7-17 - Use Case Description for Managing Classes
Use Case Id UC-17

Use Case Name View-Report
Description Allows the actor to view the report that is generated by the system. It
helps the actor to track information about the member. Like how many
members are registered and helps the actor to compare data to make an
analysis.
Pre-Condition Actor should be login in order to view report. There must be at least one
or two members must be registered in order to see the report.
24
Flow of Event 1. The actor selects view report link.
2. The system shows the report.
3. The actor views the report.
Alternative flow
Exception Step 2: if there are no members registered in the system it doesn’t
display the information it required.
Post Condition The report is displayed successfully
Table 2.7-18 - Use Case Description for Viewing Report
Description for Receptionist management use case it is a general use case for
 Adding Receptionist and

 Removing Receptionist
Use Case Id UC-18

Use Case Name Manage-Receptionist
Description This use case allows the actor manage receptionist.
Pre-Condition Actor should be login in to the system to add trainer
Flow of Event E1. If the actor selects add receptionist.
1.1 The actor selects manage receptionist link.
1.2 The system will display manage receptionist form.
1.4 The actor clicks on register receptionist button.
1.5 The system will verify the data that is entered by the actor.
1.6 The system will add the receptionist to the database
Alternative flow E2. If the actor selects remove receptionist.
2.1 The actor selects manage receptionist link.
2.2 The system displays list of receptionists.
2.3 The actor selects a receptionist from the list.
2.4 The actor clicks on remove button.
2.5 The system will ask a confirmation message to receptionist
employee.
2.6 The actor clicks on remove now button.
2.7 The system will remove receptionist from the database.
2.8 The system displays successfully removed message.
Exception E1 Step 1.4: If one of the information entered by the actor is invalid, the
system will display invalid data. And it will go to step 1.4.
E2 Step 2.5: If the actor clicks No on confirmation box, the receptionist
will not be removed. And it will go to step 2.3.
Post Condition Receptionist is added to the database that helps on managing members,
trainers and schedule.
Table 2.7-19 - Use Case Description for Managing Receptionist
25
Use Case Id UC-19
Use Case Name View-Comment
Description It helps the actor view comments or feedbacks that are sent by the
member. It gives the actor to improve the system or the gym based on
the comment.
Pre-Condition The actor must be logged-in to view comment.
3. The actor selects comment tab.
4. The actor views comment or feedback.
Post Condition The actor views comment that are sent by the actor.
Exception If members did post a comment it doesn’t show.
Table 2.7-20 - Use Case Description for Viewing Comment
Use Case Id UC-20

Use Case Name Generate-QR code
Description It decreases the hassle of the traditional payment.
Pre-Condition The actor should be logged-in in order to generate QR codes.
Flow of Event 1. The actor selects on QR code Generator link.
2. The system displays QR code generator page.
3. The actor enters the amount that the QR code holds.
4. The actor clicks generate button.
Post Condition The QR codes will be generated.
Table 2.7-21 - Use Case Description for Generating QR codes
Use Case Id UC-21

Use Case Name Add-Notification
Description It helps the members to update them with new information. If there is a
new thing are added like if discount made, new classes add and other
things. The notification sent by the actor can be viewed by all members.
Pre-Condition The actor must be a legit member in order to give a notification and it
has to be logged in.
3. The actor selects broadcast.
4. The system displays the broadcast section.
5. The actor writes a message.
6. The actor clicks on post button.
7. Saves the information to the database.
8. The system displays notification sent message.
26
Post Condition The notification has been sent to all members.
Table 2.7-22 - Use Case Description for Adding Notification
27
2.7.2. Class Diagram
Class diagram provide a graphical notation for modelling, classes with their attribute data types,
methods with their return types and arguments and their data types, relationships, access
visibility, and multiplicity.
Figure 2.7-2 - Analysis Class Diagram
28
2.7.3. Sequence Diagram
Sequence diagrams model the dynamic aspects of a software system. The emphasis is on the
sequence of messages rather than relationship between objects.
<<Actor>>
:Member,
GymOwner, <<Boundary>> <<Boundary>> <<Controller>> <<Entity>>
Receptionist :GYMPage :LoginPage :LoginController :User
Visit
Display GYMpage
Click Login Link
Display Login Form
Enter Email
and Password
Entered Data
Check User Data
alt
Invalid Invalid
Return to Login Page
Display Login Form
valid Valid
Member Valid
Display member page
Receptionist
Display receptionist page
GymOwner
Display gym owner page
Figure 2.7-3 - Sequence Diagram for Login
29
<<Actor>> <<Boundary>> <<Boundary>> <<Boundary>> <<Contoller>> <<Entity>>
:Member :GYMPage :RegistrationPage :LoginPage :RegisterController :User
Visit
Display GYMpage
Click Register link
Display Registration Form

Fill the Form
Click Submit
Save
Saved
Check Verfication
alt
Verified Verified
Notverified
Not Verified
Redirect to Login Page
Display Login Form
Figure 2.7-4 - Sequence Diagram for Registration
<<Actor>>
:Member, <<Boundary>> <<Boundary>> <<Controller>> <<Entity>>
Receptionist :GYMPage :SchedulePage :ScheduleController :Schedule
Visit
Display GYMpage
Click Schedule Link
Ask Data
Request Data
Return Data
Pass Data
Display Schedule Page
Figure 2.7-5 - Sequence Diagram for Viewing Schedule
30
<<Actor>> <<Boundary>> <<Boundary>> <<Controller>> <<Entity>>
:Member :GYMPage :GuidePage :GuideController :Guide
Visit
Display GYMpage
Click Guides Link
Ask Data
Request Data
Return Data
Pass Data
Display Guides Page
Figure 2.7-6 - Sequence Diagram for Viewing Guides

:Member :GYMPage :MyGoalPage :ProfileController :User
Visit
Display GYMpage
Click MyGoal
Request data
Request data
Return data
Passess Status
Display MyGoalPage
Enters height and weight
Calculate BMI
Saves data
Saves data
Saved
Return Result
Display the result
Figure 2.7-7 - Sequence Diagram for Tracking Information
31
<<Actor>>
:Member,
GymOwner, <<Boundary>> <<Boundary>> <<Controller>> <<Entity>>
:GYMPage :PackagePage :PackageController :Package
Receptionist
Visit
Display GYMpage
Click Package Link
Request list of packages
Request packages
Return packages
Passes list of packages
Display Package Page
Figure 2.7-8 - Sequence Diagram for Viewing Package
<<Actors>>
:Member,Gym <<Boundary>> <<Boundary>> <<Controller>> <<Entity>>
Owner,Receptionist :GYMPage :ClassPage :ClassController :Class
Visit
Display GYMpage
Click Class Link
Request list of Classes
Request Classes
Return Classes
Passes list of Classes
Display Class Page
Figure 2.7-9 - Sequence Diagram for Viewing Classes
32
:Member :GYMPage :MyProfilePage :CommentController :Comment
Visit
Displays GYMpage
Click My_profile link
Displays Profile page

Clicks Comment Tab
Displays Comment Section
Write a Comment
Click Send
Save Comment
Saves Comment
Comment Saved
Return Message
Displays Sent Comment Message
Figure 2.7-10 - Sequence Diagram for Posting Comment
<<Actor>> <<Boundary>> <<Boundary>> <<Controler>> <<Entity>>

:Member :GYMPage :MyProfilePage :CommentController :Comment
Visit
Display GYMpage
Click MyProfile link

Request notifications
Checks
alt
Return notifications
Show
Passes notifications
Display notifications
Else
No notifications
Return Result
Doesn't Display
Figure 2.7-11 - Sequence Diagram for Viewing Notification
33
:Member :HomePage :PackagePage :QRController :QRcode
Visit
Clicks on QR Tab
Display QR Page
Clicks Scan
Display QRcode Scanner
Scans QRcode
Scanned Data
Checks QRcode
alt
Invalid Invalid
Display Invalid QRcode message
Valid Valid
Display Successfully Paid message
Figure 2.7-12 - Sequence Diagram for Payment

:Receptionist :GYMPage :ManageSchedulePage :ScheduleController :Schedule
Visit
Display GYMpage
Clicks Manage Schedule link
Request list of Schedules
Request Schedules
Return Schedules
Return list of Schedules
Display Manage Schedule page
Selects Schedule
Display Schedule
Removes Schedule
Removes Schedule
Conformation
Display Conformation box
alt
Clicks Conform
Conformed
Conformed
Removes data
Removed
Schedule Removed
Display Message
Else Clicks No
No
Return page
Display Manage Schedule Page
Figure 2.7-13 - Sequence Diagram for Managing Schedule
34
:Receptionist :GYMPage :ManageTrainerPage :TrainerController :Trainer
Visit
Display GYMpage
Clicks Manage Trainer link
Request list of Trainers
Request Trainers
Return Trainers
Return list of Trainers
Display Manage Trainer page
Selects Trainer
Display Trainer
Removes Trainer
Removes Trainer
Conformation
alt
Clicks Conform
Conformed
Conformed
Removes data
Removed
Trainer Removed
Display Message
Else Clicks No
No
Return page
Display Manage Trainer Page
Figure 2.7-14 - Sequence Diagram for Managing Trainers

:Receptionist :GYMPage :ManageUserPage :UserController :User
Visit
Display GYMpage
Clicks Manage User
Request list
Passes the lists
Display lists
alt
if paid Clicks Approve

Updates the database
Updated
Member Approved
elsa Dosen't Approve
Updates the database
Updated
Member Disapproved
Figure 2.7-15 - Sequence Diagram for Managing Members
35
:Receptionist :GYMPage :PostGuidesPage :GuideController :Guide
Visit
Display GYMpage
Click Guide link
Click Guide link
Display Guide Page
Display Guide Page
Add Resources
Add Guides
Saves data
Saved
Guide Saved
Display Message
Figure 2.7-16 - Sequence Diagram for Posting Guides

:GymOwner :GYMPage :ManageClassPage :ClassController :Class
Visit
Display GYMpage
Clicks Manage Class link
Request list of Classes
Request Classes
Return Classes
Return list of Classes
Display Manage Class page
Selects class
Display class
Removes Class
Removes Class
Conformation
alt
Clicks Conform
Conformed
Conformed
Removes data
Removed
Removed
Display Message
Else Clicks No
No
Return page
Display Manage Class Page
Figure 2.7-17 - Sequence Diagram for Managing Class
36
:GymOwner :GYMPage :ManagePackagePage :PackageController :Package
Visit
Display GYMpage
Clicks Manage Package link
Request list of Packages
Request Packages
Return Packages
Return list of Packages
Display Manage Package page
Selects Package
Display Package
Removes Package
Removes Package
Conformation
alt
Clicks Conform
Conformed
Conformed
Removes data
Removed
Package Removed
Display Message
Else Clicks No
No
Return page
Display Manage Package Page
Figure 2.7-18 - Sequence Diagram for Managing Package

:GymOwner :GYMPage :MyProfilePage :CommentController :Comment
Visit
Displays GYMpage
Click My_profile link
Displays Profile page

Clicks BroadCast Tab
Displays BroadCast Section
Enter Notification
Save Notification
Saves Notification
Notification Saved
Return Message
Displays Message
Figure 2.7-19 - Sequence Diagram for Adding Notification
37
:GymOwner :GYMPage :ManageUserPage :ReportController :User
Visit
Display GYMpage
Click Manage User page
Display Report page

Click Report
Request Data
Request Data
Return Data
Pass Data
Display Result
Figure 2.7-20 - Sequence Diagram for Viewing Report
<<Boundary>>
<<Actor>> <<Boundary>> :ManageReceptionist <<Controller>> <<Entity>>
:GymOwner :GYMPage Page :ReceptionistController :User
Visit
Display GYMpage
Clicks Manage Receptionist link
Request list of Receptionist
Request Receptionist
Return Receptionist
Return list of Receptionist
Display Manage Receptionist page
Enter New Receptionist

Add Receptionist
Saves Receptionist
New Receptionist Added
New Receptionist Added
Display Message
Figure 2.7-21 - Sequence Diagram for Managing Receptionist
38
<<Actor>> <<Boundary>> <<Boundary>> <<Controler>> <<Entity>>
:GymOwner :GYMPage :MyProfilePage :CommentController :Comment
Visit
Display GYMpage
Click MyProfile link
Display Profile Page

Clicks Comment tab
Request comments
Checks
alt Return comments
Show
Passes comments
Display Comments
Else
No Comments
Return Result
Doesn't Display
Figure 2.7-22 - Sequence Diagram for Viewing Comment

:GymOwner :GYMPage :QRcodePage :QRcodeController :QRcode
Visit
Display GYMpage
Click QRcode link

Request QRcode page
Sends QRcode data
Display QRcode Page
Set Price Value

Clicks Generate
Generate QRcodes
Saves Data
Saved
Passes the lists of QRcodes
Display Result
Figure 2.7-23 - Sequence Diagram for Generating QR code
39
2.7.4. Activity Diagram
Activity diagram is basically a flow chart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system. The control flow is drawn
from one operation to another. This flow can be sequential, branched or concurrent. This
distinction is important for a distributed system. Activity diagrams allow you to think
functionally. This diagram is used to model the activities which are nothing but business
requirements. So, the diagram has more impact on business’ understanding rather than the
implementation details.
The relevant activity diagrams are presented as follows:
User is
registered
and verified
Click Login
User enters email

and Password
Display Invalid
Invalid
email/password
valid
User Successfully User logs

Logged in into the
system
Figure 2.7-24 - Activity Diagram for Login
40
Click Register
Member enter
registraion
information
Display Invalid data
Invalid
Valid
Verify Member
Can login
because Can't login
member is but
verified Registered
Verified Notverified
Display Login page
Figure 2.7-25 - Activity Diagram for Registration
41
Click Schedule
If member
Paid
NotPaid
Checks
Paid
Views Schedule Display Message
Figure 2.7-26 - Activity Diagram for Viewing Schedule
42
Click View
Notification link
If Notification
are posted
NotPosted
Checks
Posted
Doesn't Show
Show Notifications
Figure 2.7-27 - Activity Diagram for Viewing Notification
43
Track information
Member enters
height and weight
Displays Result
Figure 2.7-28 - Activity Diagram for Tracking Information
Clicks on Comment
member enter
comment
Posted
Figure 2.7-29 - Activity Diagram for Adding Comment
44
Click Guides
NotPaid
Paid
Display
Message
View Guides
Display Please Pay
Figure 2.7-30 - Activity Diagram for Viewing Guides
45
Click Package
Views Package
Figure 2.7-31 - Activity Diagram for Viewing Package
Click Class
Views Class
Figure 2.7-32 - Activity Diagram for Viewing Class
46
Manage Trainer
Add Trainer Edit Trainer Remove Trainer
List of Trainers
List of Trainers
Fill form Select Trainer

Select Trainer
Display Invalid
Data No Change
No
Information
Invalid
Checks
Conformation
Valid Conformation
yes
yes
Trainer
Trainer Added Trainer Edited
Removed
Figure 2.7-33 - Activity Diagram for Managing Trainer
47
Manage
Schedule
Remove
Add Schedule Edit Schedule
Schedule
List of
Schedules
List of
Schedules
Fill form Select Schedule

Select Schedule
Display Invalid
No
Data Change No
Information
Invalid
Checks
Conformation
Conformation
Valid
yes
yes
Schedule Schedule Schedule

Added Edited Removed
Figure 2.7-34 - Activity Diagram for Managing Schedule
48
Manage
Member
Approve
Member
List of
Members
Didn͛t Pay
Paid
Member
Approved
Figure 2.7-35 - Activity Diagram for Managing Member
49
Clcik Post Guides
link
Display Resource
form
Add resources
Guides Posted
Figure 2.7-36 - Activity Diagram for Posting Guides
Clicks on
Notification
Fill Notification
Notification Added
Figure 2.7-37 - Activity Diagram for Adding Notification
50
Manage
Package
Remove
Add Package Edit Package
Package
List of Packages
List of Packages
Fill form Select Package

Select Package
Display Invalid No Change No

Data Information
Invalid
Checks Conformation
Conformation yes
Valid
yes
Package
Package Added Package Edited
Removed
Figure 2.7-38 - Activity Diagram for Managing Package
51
Manage Class
Add Class Edit Class Remove Class
List of Classs
List of Classs
Fill form Select Class

Select Class
No
Display Invalid
Change No
Data
Information
Invalid
Checks Conformaiton
Conformation
Valid yes yes
Class Added Class Edited Class Removed
Figure 2.7-39 - Activity Diagram for Managing Class
52
Click View Report
link
unsent
Check
sent
Doesn't Show
Show reports
Figure 2.7-40 - Activity Diagram for Viewing Report
53
Manage
Receptionist
Add Remove
Receptionist Receptionist
List of
Fill form
Employees
Display Invalid Select

Data Employee
No
Invalid
Checks
Conformation
Valid
yes
Receptionist Receptionist
Added Removed
Figure 2.7-41 - Activity Diagram for Managing Receptionist
54
Click Generate
QRcode link
Fill information
Invalid Display invalid data
Checks
Valid
QR code Generated
Figure 2.7-42 - Activity Diagram for Generating QR code
55
Click View
Comment link
If Comment
are posted NotPosted
Checks
Posted
Doesn't Show
Show Comments
Select persons
Comment
Figure 2.7-43 - Activity Diagram for View Comment
56
3. System Design Document
3.1. Introduction
The System Design Document (SDD) is one of the vibrant pieces for the whole documentation.
It is the bridge that conjoins the high-level requirements with technical execution details. The
SDD attends a major purpose by documenting the low-level detailed design specifications and
the high-level system design.
The purpose of this document is to give a detailed explanation of the system design for the
QUADS GMS. It will establish how the requirements from the former section will be charted
into a more methodological and implementable unit. At this stage design goals will be identified,
and the system will be decomposed into subsystems.
3.2. Assumptions
For the system we are proposing to develop, we have made some assumptions as follows:
 Users of the system have a basic understanding of how to use electronic devices. We
assume that users will be fairly familiar with using desktops, laptops, tablets or mobile
phones.
 Users of the system are familiar with web applications and their usage. We assume that
the users have somewhat a basic understanding or experience with email usage, web
pages and other mobile applications.
 Users have access to an internet connection when using the system since they are going
to be accessing it from a central server.
 Users of the system have updated browsers. Any browser version existing and been
updated since the year 2010 can more or less run our system without any problem. The
same goes for mobile devices, any android device beginning with android version 5.0 and
above.
3.3. Constraints
As a result of comprehensive restrictions, there are numerous issues that will affect how the
system is designed. Some of them are as follows:
 Due to the hitches with the network, performance might alter when using the system.
 Due to an out-of-date version of browsers and mobile devices that some user’s routine,
there might be compatibility and execution issues.
3.4. Design Goals

The design goals of a system are different qualities and criteria that define how the system is
going to be implemented. The design goals for this system are as follows:
57
3.4.1 Usability
First off, system has to be docile and enlightening. Users using the system shouldn’t get baffled
by strange controls or intricate forms. The system should have a user interface that is relaxed to
understand and prime users to attain the desired task with less effort. Key functionalities of the
system should be two to three clicks away from within the system. The system should be simple
enough to use without the requirement of additional assistance and/or help.
3.4.2 Reliability
Requests made by users need to be handled properly by the system. The system should be able to
respond to a user’s request adequately. Users of the system will likely spend a fair amount of
time on the system. Any unreliability that might occur from operating the system should be
minimized. Backups should be taken regularly. The system should be able to recover from server
crashes and failures using these backups.
3.4.3 Performance
The system should be able to interest users demand in an efficient manner. Users shouldn’t feel
impatient while using the system. The system should store frequently accessed elements of the
system in a way that is easy to retrieve and process. Caching is to be used for elements like these.
3.4.4 Portability
The system is anticipated to address users nonetheless of the machine or operating system they
are using. It is to be portable across platforms, giving various users the benefit of accessing the
system in an environment they are familiar with. The system should give the same look and feel
across different platforms and different screens.
3.4.5 Security
The system should not allow access to features that require authorization, without doing the
proper security checks. Guests using the system should not be able to make any modification to
the system or the data stored by the system. The system should be able to restrict access if a user
cannot provide the valid security credentials. The system should also be protected from the risk
associated with the physical state of the system. The physical implementation of the system
should be done in a secure location that prevents tampering by unauthorized individuals.
3.5. Software Architecture

The software architecture of a program or a computer system is the structure or structures of the
system, which comprise software elements, the externally visible properties of those elements,
and the relationship among them [6]. They contain important design decisions about the system
and the interactions between those structures that comprise the system. When considering the
software architecture of our system, it is going to be implemented in a three-tied layer having
data-access, business, and presentation layers [6].
58
 Data-access Layer: is going to handle the back-end functionalities of the system related
to the persistent data management. We used a repository class for a model which holds all
your data access logic, then injected the repository to the controller.
 Business Layer: will be composed of business logic that will use the data-access layer to
obtain the data needed for that service. This layer entertains different functionalities of
the system that are either present to users through the presentation layer or responsible for
providing added features and services that support those business operations.
 Presentation Layer: is the layer that allows users to make use of the system. This is
responsible for showing the interface of the application through the end-user’s web
browser. It provides a mechanism for end-users to interact with the system, and make use
of its functionalities by making use of the business layer which in turn use the data-access
layer for its operation. Using the MVC design pattern simplifies the task of creating a
separate view for each model. Also, custom views can be created to select and arrange
elements in the way that seems fit to when presenting them to the end-users.
Figure 3.5-44 - Software Architecture Diagram
59
3.5.1 Xamarin Architecture
 Data Layer – contains specific code for working with the data storage.
 Data Access Layer – wrapper around the Data Layer that is used to retrieve data from the
data storage without exposing implementation details to the caller.
 Service Access Layer – used to retrieve data from the data services.
 Business Layer – contains business logic specific for that type of application.
 Application Layer – contains platform specific code defining UI components behaviors
and more.
 UI Layer – contains platform specific code defining UI components.
Figure 3.5-45 - Xamarin Architecture
60
3.6. Subsystem Decomposition
Subsystem decomposition is an important step in software analysis and design that breaks down
the system into less complex and simpler subsystems. In our case the decomposition of our
system looks as follows:
Offers Payment
Payment
Management Management Management
Subsystem Subsystem
Guide
Offers User Management Guide
Management Management Management
Subsystem Communication Subsystem
Management
Schedule
Schedule
Management Management
Subsystem
Communication
Management
Subsystem
Data Management
Subsystem
Figure 3.6-46 - Subsystem Decomposition Diagram
61
3.6.1. User Management Subsystem
User management subsystem is used for administration of giving individual users within a
system access to the tools they need at the right time which includes authorization and
authentication of a user. It checks whether a right user is logged in to the system and checks what
kind of access and privileges the user has to data that the system provides.
Figure 3.6-47 - User Management Subsystem
3.6.2. Schedule Management Subsystem

Schedule Management subsystem deals with adding and viewing the workout class schedule of
the gym. The components of the subsystem are adding schedule and view schedule.
Member Reception
View Schedule Adds Schedule
Schedule
Schedule Schedule Information
information
Figure 3.6-48 - Schedule Management Subsystem
62
3.6.3. Offer Management Subsystem
Offer management subsystem is deals with the different kinds of membership offers the gym
provides whether its packages or workout classes. Each offer will have their own descriptions as
well as their assigned prices.
Package Classes
Description Price
Figure 3.6-49 - Offer Management Subsystem
3.6.4. Payment Management Subsystem

Payment management subsystem is where the registered member scans the QR code on their
purchased package card and adds currency to their balance.
63
Figure 3.6-50 - Payment Management Subsystem
3.6.5. Data Management Subsystem

This subsystem handles the management of overall data that our system uses. The data
management subsystem is responsible for data access, storage, retrieval, and manipulation. It
provides these features to the subsystems.
Persistence
Data Reader Data Writer
Manager
Figure 3.6-51 - Data Management Subsystem
3.6.6. Communication Management Subsystem

Communication Management subsystem deals with the overall communication between gym
owner and its members. It also handles the communication of the system with the gym owner as
it generates reports of current standings.
64
Broadcast Comment
Report
Figure 3.6-52 - Communication Management Subsystem
3.6.7. Guide Management Subsystem

Guide Management subsystem deals with posting and viewing the guides in order to suggest
member current workout trends and exercises.
Member Reception
View Guid Post Guide
Guide Guide Information Guide Information
Figure 3.6-53 - Guide Management Subsystem
65
3.7. Hardware Software Mapping
This system will be able to run on desktops, laptops, and mobile devices since it is going to be a
web-based system. Below is the hardware/software mapping for our system represented by the
deployment diagram. The Unified Modelling Language (UML) deployment diagram drafts a
static view of the run-time configuration of processing nodes and the components that run on
those nodes.
Web Server
Offer Management
Schedule Management
Client
Communication Management Database Server
Guide Management
Browse
<<http>> <<TCP/IP>>
Payment Management Mysql
Mobile
User Management
Application
Data Management
Figure 3.7-54 - Hardware Software Mapping
66
3.8. Persistent Data Management
This shows how the data produced by the user in the system is going to be stored. The data that
users of the system, that is the gym owners, reception and members, generate will need to be
stored so that it can be accessed and modified for later times. The persistent data storage for our
system looks as follows:
Figure 3.8-55 - Design Class Diagram
67
3.9. Access Control
Here we have the access control list matrix by determining how actors can control access and
which operations are shared among the actors. This approach helps to show the association of the
actors and the operations they have access to.
Actor Use Case Operation

Owner Add Employee EmployeeController@register()
Remove Employee EmployeeController@destroy()
View Employee/Report EmployeeController@index_managegymEmployee()
Add Class ClassController@add_gymClass()
Edit Class ClassController@edit_gymClass()
Remove Class ClassController@remove_gymClass()
View Class ClassController@index_managegymClass()
Add Package PackageController@add_gymPackage()
Edit Package PackageController@edit_gymPackage()
Remove Package PackageController@remove_gymPackage()
View Package PackageController@index_managegymPackage()
View Comment ProfileController@profile()
Delete Comment CommentController@destroyComment()
Receptionis Add Schedule ScheduleController@add_gymSchedule()
Edit Schedule ScheduleController@edit_gymSchedule()
t
Remove Schedule ScheduleController@remove_gymSchedule()
Add Trainer TrainerController@registerTrainer()
Edit Trainer TrainerController@index_edit(),
TrainerController@editTrainer()
Remove Trainer TrainerController@destroy()
Approve Member UserController@handleApproval()
Disapprove Member UserController@handleDisapproval()
View User UserController@index_manageUser()
Add Guide GuideController@add_gymGuide()
Member Register RegisterController@register()
View Schedule ScheduleController@index_gymSchedule()
View Package PackageController@index_gymPackage()
View Class ScheduleController@index_gymClass()
View Guides GuideController@index_gymGuide()
Track Information HomeController@mygoal()
View Notification ProfileController@profile()
Add Comment CommentController@postComment()
Payment PaymentController@add_gymPayment()
Table 3.9- 23 - Access Control
3.10. Boundary Conditions

This section conditions how our system starts ups, shuts down, and handles its error behavior.
The system will be started when the user installs either the mobile application or the URL of the
68
website in a browser. Then the user is taken to the systems home page if on the website, where
they can simply browse through the content. The user can then fully obtain access to the whole
system after registering and then logging in. Meanwhile users on the mobile application are
required to register and login at the get-go. The user logging out or being done with the system
and closing the application accounts for the shutdown condition. Errors might occur when using
the system, and the system is expected to catch and throw those exceptions to the users to inform
them that there is something wrong.
3.11. Subsystem Services

Subsystem Class Operations
User Management Subsystem User, User_Package Register(), Verification(),
Verification,Trainer Authenticated(),Index()
Schedule Management Subsystem Schedule Add(), Edit(), Remove(),
Index()
Offer Management Subsystem Package, Class Add(), Edit(), Remove(),
Index()
Payment Management Subsystem Payment GenerateQR(), Payment()
Communication Management Comment, User PostComment(),Broadcast(),
Subsystem DestroyComment()
Guide Management Subsystem Guide PostGuide(),
Table 3.11- 24 - Subsystem Service
4. Object Design Document

Object design is the process of adding details to the requirements analysis and making
implementation decisions. The object designer must choose among different ways to implement
the analysis model with the goal to minimize execution time, memory and other measures of
cost. The ODD is used to exchange interface information among developers and as a reference
during testing.
4.1. Object Design Trade-offs

The following are the trade-offs found in QUADS GMS:
 Buy vs. Build: Of course, the system that we have can be divided into modules. If we
can find some module in the market with most of the functionality that we need, included
in it, then that system can be bought to save time, money and human resources. Although
buying the system limits the flexibility for each module while building the system can
adhere to our specific requirements and design. In order to include the prerequisite for
customization we have decided to stay with building the system instead of purchasing it.
 Scalability vs. Security: For our system to be scalability is important even though our
first priority is aimed at security. Users of the system will feel more comfortable with
their personal data being more secure and helps in gaining their trust. Since our system is
also dealing with payment transactions it is a necessity for it to be further protected.
69
 Memory space vs. Response time: Our main focus here is to provide a quicker response
time. The system is intended for providing a fast performance to its users so response
time is major aspect and more memory can be used to speed up the system.
4.2. Interface Documentation Guidelines
Naming conventions make programs more understandable by making them easier to read. They
can also give information about the function of the identifier for example, whether it's a constant,
method, or variable which can be helpful in understanding the code.
 Classes are to be named with singular nouns.

 Methods that are not by default defined by the controllers are to be named with verb
phrases and could come along with nouns which help further describe the method.
 Code should be readable. It should follow indentations.
 Code also needs to be properly commented throughout.
4.3. Package
A package is used to group together elements that are semantically related and might change
together. It is a general-purpose mechanism to organize elements into groups to provide better
structure for system model. Using Laravel’s MVC framework allows us to separate the business
logic from the user interface by separating the application into three parts namely model, view,
and controller.
ForgotPasswordContr
LoginController RegisterController ResetPasswordController PaymentController
oller
ClassController CommentController GuideController HomeController PackageController
ProfileController QRcodeController ReceptionistController ScheduleController TrainerController
UserController
Figure 4.3- 56 - Controllers
70
Payment Comment Guide Package Profile
QRcode Schedule SocialAccount Sport Time
Trainer User UserPackage Verification
Figure 4.3- 57 - Models
gymClass gymPackage gymSchedule home managegymClass
managegymGuide managegymPackage managegymReceptionist managegymSchedule manageUser
mygoal updateTrainer welcome
Figure 4.3- 58 - Views
 View: The view deals with presenting all the different user interfaces for the system
users.
 Controller: The controller is responsible to handle the business and application logic,
providing a functionality for the users via the view.
 Model: This will be mapped into a database that will be responsible for storing data so
that it can be retrieved for future use. It entertains the request made by the controller and
provides a corresponding response for it.
4.4. Class Interface

Schedule
+index_gymSchedule()
+index_managegymSchedule()
+add_gymSchedule(request,id)
+edit_gymSchedule(request,id)
+remove_gymSchedule(request,id)
Figure 4.4- 59 - Schedule Class
71
4.4.1. Schedule Class
Method Return Type Description
index_gymSchedule Action result Redirects to the gym’s Schedule page.
index_manageSchedule Action result Redirects to the managing schedule page.
add_gymSchedule(request) Action result Handles POST request intended to add a
new schedule.
edit_gymSchedule(request) Action result Handles POST request intended to edit
current schedule.
edit_gymSchedule(request) Action result Handles POST request intended to
remove current schedule.
Table 4.4- 25 - Schedule Class
Class
+add_gymClass(request)
+remove_gymClass(request)
+edit_gymClass(request,id)
+index_manageClass()
+index_gymClass()
Figure 4.4- 60 - Class Model Class
4.4.2. Class Model Class

index_gymClass Action result Redirects to the gym’s Classes page.
index_manageClass Action result Redirects to the managing Class page.
add_gymClass(request) Action result Handles POST request intended to add a
new gym class.
edit_gymClass(request,id) Action result Handles POST request intended to edit
current gym class for selected id.
edit_gymClass(request) Action result Handles POST request intended to
remove current gym class.
Table 4.4- 26 - Class Model Class
Package
+index_managegymPackage()
+index_gymPacakage()
#packageValidator(data)
+add_gymPackage(request)
+edit_gymPackage(request,id)
+remove_gymPackage(request,id)
Figure 4.4- 61 - Package Class
4.4.3. Package Class

72
index_gymPackage() Action result Redirects to the gym’s Classes page.
index_managePackage() Action result Redirects to the managing Class page.
packageValidator(data) Validator Class Validates the POST request values.
Instance
add_gymPackage(request,id) Action result Handles POST request intended to add a
new gym class.
edit_gymPackage(request,id) Action result Handles POST request intended to edit
current gym class.
edit_gymPackage(request) Action result Handles POST request intended to
remove current gym class.
Table 4.4- 27 - Package Class
Guides
+index_managegymGuide()
+add_gymGuide(request,id)
+edit_gymGuide(request,id)
+remove_gymGuide(request,id)
Figure 4.4- 62 - Guide Class
4.4.4. Guide Class

index_gymGuide() Action result Redirects to the gym’s Guides page.
index_manageGuide() Action result Redirects to the managing Guide page.
add_gymGuide(request,id) Action result Handles POST request intended to add a
new gym guide.
edit_gymGuide(request,id) Action result Handles POST request intended to edit
current gym guide for selected id.
edit_gymClass(request,id) Action result Handles POST request intended to
remove current gym guide.
Table 4.4- 28 - Guide Class
User
+index_manageUser()
+handleApproval(request)
+handleDisapproval(request)
+register(request)
+authenticated(request,user)
Figure 4.4- 63 - User Class
4.4.5. User Class

index_manageUser() Action result Redirects to the managing User page.
73
handleAproval(request) Action result Handles POST request intended to
approve gym members who made
payment.
handleDisaproval(request) Action result Handles POST request intended to
disapprove gym members finished their
payed plan.
register(request) Action result Handles POST request intended to
register gym members.
authenticated(request, user) Action result Handles POST request intended to
authenticate gym members, receptionist
and Owner.
Table 4.4- 29 - User Class
Comment
+postComment(request,id)
+destroyComment(request,id)
Figure 4.4- 64 - Comment Class
4.4.6. Comment Class

postComment(request,id) Action result Handles POST request intended to give
feedback to the gym Owner
destroyComment(request,id) Action result Handles POST request intended to
remove feedbacks made by members
and the gym Owner
Table 4.4- 30 - Comment Class
Verfication
+verification(token)
Figure 4.4- 65 - Verification Class
4.4.7. Verification Class

verification(token) Action result Handles GET request intended
to verify the member after
registration.
Table 4.4- 31 - Verification Class
74
Profile
+update_avatar(request)
+calculateBMI(request)
+profile()
#profileValidator(data)
+editProfile(request)
Figure 4.4- 66 - Profile Class
4.4.8. Profile Class

update_avatar(request) Action result Handles POST request
intended to change default or
previous Proifle avatar.
calculateBMI(request) Action result Handles POST request
intended to calculate and
notify the BMI of the gym
Member.
profile() Action result Redirect to Profile page
profileValidator(data) Validator Class Instance Validates the POST request
values.
editProfile(request) Action result Handles POST request
intended to update the gym
member’s profile information.
Table 4.4- 32 - Profile Class
Trainer
#trainerValidator(data)
+index_edit(request,id)
+destroy(request)
+editTrainer(request,id)
+registerTrainer(request)
Figure 4.4- 67 - Trainer Class
4.4.9. Trainer Class

trainerValidator(data) Validator Class Validates the POST request values.
Instance
index_edit(request,id) Action result Handles GET request intended to update
Trainer’s information for selected id.
destroy(request) Action result Handles POST request intended to
remove a trainer.
editTrainer(request,id) Action result Handles POST request intended to edit
current gym guide for selected id.
75
registerTrainer(request) Action result Handles POST request intended to
register new trainer.
Table 4.4- 33 - Trainer Class
QRcode
+generate_QRcode()
Figure 4.4- 68 - QRcode Class
4.4.10.QRcode Class
generateQRcode(request) Action result Handles POST request
intended to generate new QR
code.
Table 4.4- 34 - QRcode Class
76
5. Implementation
5.1. Tools
 For development purpose, we will be using the Model View Controller design paradigm
provided by Laravel’s MVC.
 The languages that will be used are HTML5, CSS3, Material Design (MD) Bootstrap,
and PHP 7.1.3.
 For the mobile application we are using Xamarin.
 The languages that will be used are XAML and C#.
 The database we used is MySQL through XAMP servers.
5.2. Major Class Code
5.2.1. Account Verification
Figure 5.2- 69 - Account Verification
77
78
5.2.2. Gym Classes Creation
Figure 5.2- 70 - Gym Classes Management
79
80
5.2.3. Profile Editing
Figure 5.2- 71 - Profile Editing
81
5.2.4. Registration
Figure 5.2- 72 - Registration
82
Figure 5.2- 73 - Registration
83
5.2.5. Membership Approval
Figure 5.2- 74 - Membership Approval
84
6. Annexes
6.1. Questionnaire
6.1.1. Introduction to Questionnaires
We are students of HiLCoE, School of Computer Science and Technology. We are conducting a
research on “Gym Management System” based on your organization. The purpose of this
questionnaire is to find solutions for the problems occurring in the organization. The responses
will be analyzed and will be used merely for academic purpose. Therefore, your genuine and
prompt response is highly appreciated.
Hereby below you will find a questionnaire that will be filled out. We kindly request for you to
answer these questions by selecting the index number or letter of your choice while reading the
question carefully. Be assured that all answers you provide will be strictly confidential. Thank
you again for your co-operation.
6.1.2. Questions for Gym Owners
Carefully select the index number or letter of your choice while reading the questionnaire
statements below. Fill free to leave any suggestions or comments regarding the proposed GMS.
1. Strongly Disagree M - Manual

2. Disagree A -Automatic
3. Neutral
4. Agree Member Limit: 50, 100, 200
5. Strongly Agree
1. What type of system are you using till now; M A

Manual Automated
2. I believe the current system brings me satisfaction and attracts good 1 2 3 4 5
business.
3. Having a web-based system will increase the process of maintaining 1 2 3 4 5
member records.
4. As an owner I want my customers private data to be secured. 1 2 3 4 5
5. I would like to develop a relationship with my customers through a 1 2 3 4 5

web-based system.
6. Having a web-based gym management system will create awareness 1 2 3 4 5
to new members.
85
7. Upgrading the payment rule via the web-based management system 1 2 3 4 5
will bring versatility.
8. Specify the limit of members for one season on the GMS. _ 50 100 200 _
9. Viewing the report that is sent by the reception will allow me to 1 2 3 4 5
manage members and give them what they need.
10. Being a Gym owner, the GMS can effectively assist me to manage 1 2 3 4 5
my employees.
Additional Comments/Suggestions for Improvement:
______________________________________________________________________________
6.1.3. Questions for Gym Members
Carefully select the index number of your choice while reading the questionnaire statements
below. Fill free to leave any suggestions or comments regarding the proposed GMS.
1. Strongly Disagree
2. Disagree
3. Neutral
4. Agree
5. Strongly Agree
1. Searching for a Gym fitness center, I would rather get more information by 1 2 3 4 5
visiting a gym center website.
2. Making a payment online is better than coming in and speaking to the sales 1 2 3 4 5
representative.
3. Availability of different classes (Yoga, Weight training, Cardio Sessions...) 1 2 3 4 5
completes the picture of a gym?
4. Schedule layout of the classes can be better accessed via website or mobile. 1 2 3 4 5
5. Booking and canceling classes makes positive impact on my daytime schedule. 1 2 3 4 5
6. Tracking my BMI, and setting goals can be a motivation to going to the gym. 1 2 3 4 5
7. Services provided by the gym that are sold individually are better than custom 1 2 3 4 5
packages.
8. I am inclined to go to a personal trainer or nutritionist if they all worked 1 2 3 4 5
together in helping me achieve my goals.
86
9. Guides posted on the website can be shared for new members to join the Gym 1 2 3 4 5
center.
10. Integrating a GMS (Gym Management System) will help me be more 1 2 3 4 5
knowledgeable about different workout routine.
Additional Comments/Suggestions for Improvement:
______________________________________________________________________________
6.1.4. Summary
The results from the questionnaires shows that there is a discontent between gym owner and their
member. When asking the owners about the system they use, more than 85% of these gym
owners informed us that they are still using a manual system. The rest of the gym owners
informed us that they use an automated system but only for member attendance and check in.
They also strongly agree with our management approach and some have suggested they are more
than willing to integrate our system after its completion. The same can be said about the gym
members, most are dissatisfied with the current system as they find it cumbersome and tedious.
They fully agree with the need of a more robust way of managing their schedules as well as keep
track of their information. The members feel more comfortable finding out everything about a
gym through a web-based application than scouting for gyms every time. All in all, the results
suggest that much needs to be done to tackle this problem.
6.1.5. User Manual
In this section, we will depict the main screens that a certain user will encounter while they are in
our system. A screenshot along with a description will be used to explain how everything works.
6.1.5.1. Home Page

The first page of our system is the home page of the Quads Gym Management System website.
A very simple, yet attractive UI will welcome the user to the system making the user want to
explore more.
87
Figure 6.1- 75 - Home Page
6.1.5.2. Login Page – For all users of the system

This is the login page. Users enter Email address and password then click on login button to use
the system.
Figure 6.1- 76 - Login Page
88
6.1.5.3. Registration Page – For first time members
This is the registration page. The user fills required information and clicks the register button to
progress.
Figure 6.1- 77 - Registration Page
6.1.5.4. Registered Member Profile Page

Users can see their profile by clicking on my profile. Also, they can edit their profile if they
want.
89
Figure 6.1- 78 - Profile Page
6.1.5.5. Registered Member Schedule Page

Members can see their schedule that are added by receptionist by clicking on schedule link.
Change the picture please

Figure 6.1- 79 - Registered Member Schedule Page
6.1.5.6. Classes Description Page

Members can see class by clicking on class link.
90
Figure 6.1- 80 - Classes Description Page
91
6.1.5.7. Receptionist - Schedule Management Page
The receptionist can manage schedule by visiting the “Manage Schedule” link. Can also preview
the current schedule.
Change the picture

Figure 6.1- 81 - Schedule Management Page
6.1.5.8. Receptionist - Member and Trainer Management Page

The receptionist can manage member and trainer by visiting the “Manage User” link. By visiting
“Manage Member” tab the receptionist can approve and disapprove members using the slider
button.
Figure 6.1- 82 - Member and Trainer Management Page
92
6.1.5.9. Gym Owner – Workout Class Customization Page
The gym owner can manage receptionist by visiting the “Manage Class” link. The owner can
also view the classes by visiting “View Class” tab.
Figure 6.1- 83 - Workout Class Customization Page
6.1.5.10. Gym Owner – Membership Package Customization Page

The gym owner can manage receptionist by visiting the “Manage Package” link. The owner can
also view the packages by visiting “View Package” tab.
Figure 6.1- 84 - Membership Package Customization Page
93
6.1.5.11. Gym Owner – Receptionist Management Page
The gym owner can manage receptionist by visiting the “Manage Receptionist” link. The owner
can also view the report that is generated by the system via the “View Report” tab.
Figure 6.1- 85 - Receptionist Management Page
6.1.5.12. Gym Owner – View Report Page
Figure 6.1- 86 - View Report Page
94
References
[1] “what-is-extreme-programming @ www.selectbs.com.” [Online]. Available:
http://www.selectbs.com/process-maturity/what-is-extreme-programming
[2] “unified-modeling-language @ www.sciencedirect.com.” [Online]. Available:
https://www.sciencedirect.com/topics/engineering/unified-modeling-language
[3] Ahmed, “Gym Management System,” vol. 4, no. 11, pp. 384–389, 2016 [Online].
Available: http://ijetsr.com/images/short_pdf/1510987099_384-389-site139_ijetsr.pdf
[4] “business-rule-group @ www.sciencedirect.com.” [Online]. Available:
https://www.sciencedirect.com/topics/computer-science/business-rule-group
[5] “uml-use-case-diagram @ www.lucidchart.com.” [Online]. Available:
https://www.lucidchart.com/pages/uml-use-case-diagram
[6] “Index @ Www.Ibm.Com,” Ibm. p. 13, 2015 [Online]. Available:
http://www.ibm.com/developerworks/data/library/dmmag/DMMag_2009_Issue2/Industry/
index.html
Glossary
Quads - A muscle of the thigh that extends the leg. It also means “four of a kind” in Poker slang.
Class - Refers to group sessions provided by QUADS Gym.
Package – Refers to membership payment plans provided by QUADS Gym.
95

Final Count

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Count

Uploaded by

Copyright:

Available Formats

HiLCoE School of Computer Science & Technology

Quads Gym Management System

A senior project document in partial fulfillment of the requirements for

Prepared by: Brook Solomon

Advisor: Tesfaye Eyasu

HiLCoE School of Computer Science & Technology

Prepared by: Brook Solomon

Approved by (Name and Signature):

GMS – Gym Management System

1.2. Statement of the Problem

 Searching a particular information to a specific requirement is quite tedious. The

1.3. Objective of the Study

1.3.1. General Objective

1.3.2. Specific Objectives

1.4. Scope of the Project

1.5. Limitation of the Project

 It is chiefly used for crafting software within a very unbalanced atmosphere.

 It lays focus on customer involvement

 Microsoft Visio 2019

Data Gathering Methods:

1.7. Significance and Beneficiaries of the Project

1.8. Task Breakdown

 How the information is stored?

1.9.1. Operational Feasibility

1.9.2. Economic Feasibility

1.9.3. Social Feasibility

1.9.4. Technical Feasibility

2.4. Existing Systems

2.4.1. Golden Gym

2.4.2. Drawbacks of Golden Gym’s System

 Entail a lot of paperwork, resulting in slow search.

2.5. Proposed System

2.6. Functional Definition

2.6.1. Functional Requirements

 System will provide registration and authentication by login.

 System will provide secure login

3) System managers (Reception)

 System will provide Secure login

2.6.2. Non - Functional Requirements

2.6.3. Business Rule

ID Rule Definition Type of Static or Source

BR-13 An approved logged in receptionist should be Policy Dynamic Reception,

BR-15 A receptionist must verify the payment of Policy Dynamic Reception,

Table 2.6-1 - Business Rule

Add_Trainer <<include>> Manage_Trainer

View_Notification <<include>> Add_Notification

Figure 2.7-1 - GMS Use Case Diagram

Use Case Id UC-02

Use Case Id UC-03

Use Case Id UC-04

Use Case Id UC-05

Use Case Id UC-07

Use Case Id UC-08

Use Case Id UC-09

Use Case Id UC-10

Use Case Id UC-11

Use Case Id UC-12

Use Case Id UC-13

Use Case Id UC-14

Use Case Id UC-15

Use Case Id UC-16

Use Case Id UC-17

 Adding Receptionist and

Use Case Id UC-18