Software Requirements

Specification

Gym Finder / Locator System.

Prepared by
 Contents

1. INTRODUCTION 3

1.1. PURPOSE 3
1.2. PROJECT SCOPE 3
1.3. INTENDED AUDIENCE 3
1.4. REFERENCES 4
1.5. GLOSSARY 4

2. OVERALL DESCRIPTION 4

2.1. PRODUCT PERSPECTIVE 4

2.2. PRODUCT FUNCTIONS 4
2.3. USER CLASSES AND CHARACTERISTICS 5
I. GYM-GOERS 5
II. GYM OWNERS / PARTNERS 5
III. ADMINISTRATORS 5
IV. DEVELOPERS 6
V. QUALITY ASSURANCE TESTERS 6
VI. PROJECT MANAGERS 6
2.4. OPERATING ENVIRONMENT 7
2.5. DESIGN AND IMPLEMENTATION CONSTRAINTS 7
2.6. ASSUMPTIONS AND DEPENDENCIES 7

3. FUNCTIONAL REQUIREMENTS SPECIFICATIONS (FRS) 7

3.1. USE CASES 7

I. USER 8
II. PARTNER / GYM OWNER 12
III. ADMIN. 17
3.2. FUNCTIONAL REQUIREMENTS 18
3.2.1. REGISTRATION 18
3.2.2. LOGIN 18
3.2.3. GYM SEARCH 19
3.2.4. VIEW GYM DETAILS 19
3.2.5. REVIEW GYM 20
3.2.6. RATE GYM 20
3.2.7. SELECT MEMBERSHIP PLAN 21

4. EXTERNAL INTERFACE REQUIREMENTS. 22

1
4.1 USER INTERFACES 22
4.2 PROTOTYPE 22
23
4.2 HARDWARE INTERFACES 24
4.3 SOFTWARE INTERFACES 24
4.4 COMMUNICATIONS INTERFACES 24
4.5 SYSTEM INTERFACES 24

5. NONFUNCTIONAL REQUIREMENTS. 24

5.1 PERFORMANCE REQUIREMENTS 24

5.2 LOGICAL DATABASES OF REQUIREMENTS 26
5.3 SECURITY REQUIREMENTS 28

List of Figures
FIGURE 1- USER USE CASE DIAGRAM._________________________________________________________10
FIGURE 2 - PARTNER USE CASE DIAGRAM.____________________________________________________14
FIGURE 3 - ADMIN USE CASE DIAGRAM.______________________________________________________18

2
 1. Introduction

1.1. Purpose
The purpose of this document is to outline the software requirements for
the development of a gym finder service. The aim of the service is to provide
users with a platform to search for gyms in their local area. The software
will be designed to meet the needs of both gym-goers and gym owners.

1.2. Project Scope

The software system will be a Gym Finder System for users to easily
find gyms according to their standards. This system will be designed to
maximize the efficiency of the user’s search for a suitable gym by providing
details about the gym’s working hours, packages, and services, which would
otherwise take more effort.
Although the system offers detailed descriptions, it will meet the users’
needs while remaining easy to understand and use.
This system is also designed to help gyms get more recognition by
allowing them to partner with us and upload their gym’s information and
details so it’s easily accessible to gym-goers.

1.3. Intended Audience

The primary audience of this SRS document will be the development team
employed to implement the specified “Gym Finder” system. It will not only
provide an extensive capacity for project planning and progress assessment,
but it will further assist with stakeholders’ interactions. The secondary
document audience compromises the stakeholders of the project, that is,
business owners and associated staff. To this audience group, this SRS

3
 should convey and confirm the required functionality and represent a
contractual agreement between the involved parties.
Additionally, the document may also be shared with potential investors or
clients to provide an overview of the project's goals and requirements.

1.4. References
IEEE recommended practice for software requirements specifications, IEEE
standard 830, 1998.

1.5. Glossary

Term Definition
Partner Person who owns or manages a gym and is interested in promoting their
business on the platform.
User Person who is interested in finding and comparing gyms in their local area.
Database Collection of all the information monitored by this system.
Stakeholder Any person with an interest in the project who is not a developer.

2. Overall description

2.1. Product Perspective

The Gym Finder service is a standalone product that will be developed and
implemented separately from any other systems or platforms. The platform
will provide a valuable tool for gym-goers to find and compare gyms in their
local area, and for gym owners to manage their listing on the platform. The
service will be available as a web application and a mobile application for
both iOS and Android devices.

2.2. product functions

The product should make the search for gyms and the entire process easier,
streamlined time and efficient for the users.

4
 The system interfaces with a payment system, including a software
accessible credit system to handle billing quickly and easily. The payments
system should be operable such that it can return information to the system
as to whether payment was successful or failed.

2.3. User classes and characteristics

Users:
i. Gym-goers

Gym-goers are the primary users of the gym finder service. They are individuals
who are interested in finding and comparing gyms in their local area. They may be
fitness enthusiasts, athletes, or individuals who are looking to start a fitness
routine. Characteristics of gym-goers include:

 Comfortable using technology to search for gyms and manage their account
on the platform.
 Interested in finding a gym that meets their specific needs and preferences,
such as location, price, and facilities.
 Willing to share their personal information, such as location, name and email
address, in order to find their preferred gym.

ii. Gym Owners / Partners

Gym owners / partners are the secondary users of the gym finder service. They are
individuals who own or manage a gym and are interested in promoting their
business on the platform. They may be small business owners, franchise owners, or
managers of larger gym chains. Characteristics of gym owners include:

 Comfortable using technology to manage their gym listing on the platform.

 Interested in promoting their gym to a wider audience and reaching potential
new customers.
 Willing to provide accurate and up-to-date information about their gym,
such as images, packages, pricing, and opening hours.

iii. Administrators

5
Administrators are the tertiary users of the gym finder service. They are individuals
who are responsible for managing the platform and ensuring that it runs smoothly.
They may be project managers, software developers, or quality assurance testers.
Characteristics of administrators include:

 Comfortable using technology to manage the platform and troubleshoot any

issues that arise.
 Interested in ensuring that the platform is user-friendly and meets the needs
of both gym-goers and gym owners.
 Willing to work collaboratively with other stakeholders involved in the
project to ensure its success.

iv. Developers

Developers are responsible for building and maintaining the gym finder service.
They may be software engineers, programmers, front-end developers, or back-end
developers. Characteristics of developers include:

 Proficient in programming languages such as HTML, CSS, JavaScript, PHP,

and Python
 Experienced in developing web and mobile applications.
 Able to work collaboratively with other developers and stakeholders to
ensure the successful development and implementation of the service.

v. Quality Assurance Testers

Quality assurance testers are responsible for testing the gym finder service to
ensure that it meets the requirements outlined in the SRS document. They may be
software testers, quality assurance engineers, or quality assurance analysts.
Characteristics of quality assurance testers include:

 Experienced in testing web and mobile applications.

 Able to create and execute test cases and test plans.
 Detail-oriented and able to identify and report issues and bugs.

vi. Project Managers

Project managers are responsible for overseeing the development and

implementation of the Gym Finder service. They may be project managers, product
managers, or program managers. Characteristics of project managers include:

6
  Experienced in managing software development projects.
 Able to create and manage project timelines and budgets.
 Skilled in communicating with stakeholders and managing project risks and
issues.

2.4. Operating environment

The operating environment for the gym finder service is a web application
and a mobile application for both iOS and Android devices.

2.5. Design and implementation constraints

1. Compatibility: The platform should be compatible with multiple devices

and web browsers.
2. User-friendliness: The platform should be easy to use and navigate, with
clear instructions and prompts for users.
3. Security: User data should be stored securely and accessed only by
authorized personnel.
4. Performance: The platform should be able to handle a large number of
users and gym listings without any performance issues.

2.6. Assumptions and dependencies

1. Technology: The platform must be developed using open-source
technology to minimize costs.
2. Time: The project must be completed within 3 months.
3. Budget: The project budget is limited to $10,000.

3. Functional Requirements Specifications (FRS)

3.1. Use cases

This section outlines the use cases for each of the actors separately. The
user, and partner have only one use case apiece while the administrator is
main actor in this system.
7
i. User

Figure 1- user use case diagram.

8
Search for gyms.
Actor: User

Description: The user wants to find gyms in their local area.

Preconditions: The user has a stable internet connection and a compatible device.

Basic Flow:

1. The user enters their location.

2. The user selects their search criteria, such as gym facilities, price, and distance.
3. The platform displays a list of gyms that match the user's search criteria.
4. The user selects a gym from the list to view more detailed information.

Alternate Flows:

 If there are no gyms that match the user's search criteria, the platform displays a message
indicating that no results were found.
 If the user encounters any issues during the search process, they can contact customer
support for assistance.

Save favorite gyms.

Actor: User

Description: The user wants to save their favorite gyms for future reference.

Preconditions: The user has a stable internet connection and a compatible device.

Basic Flow:

1. The user selects a gym from the list of search results.

2. The user selects the option to save the gym as a favorite.
3. The platform adds the gym to the user's list of favorite gyms.

Alternate Flows:

 If the user encounters any issues while saving a favorite gym, they can contact customer
support for assistance.

9
Receive notifications.

Actor: User

Description: The user wants to receive notifications about special offers, promotions, and
updates to their favorite gyms.

Preconditions: The user has a stable internet connection and a compatible device.

Basic Flow:

1. The user selects the option to receive notifications.

2. The platform sends notifications to the user's device about special offers, promotions, and
updates to their favorite gyms.

Alternate Flows:

 If the user encounters any issues while receiving notifications, they can contact customer
support for assistance.

Filter search results.

Actor: User

Description: The user wants to filter search results based on specific criteria.

Preconditions: The user has a stable internet connection and a compatible device.

Basic Flow:

1. The user enters their location.

2. The user selects their search criteria, such as gym facilities, price, and distance.
3. The platform displays a list of gyms that match the user's search criteria.
4. The user selects the option to filter the search results.
5. The platform displays a list of filter options, such as gym facilities, price range, distance,
and ratings.
6. The user selects the desired filter options.
7. The platform updates the search results based on the selected filter options.

Alternate Flows:

 If there are no gyms that match the user's search criteria, the platform displays a message
indicating that no results were found.

10
  If the user encounters any issues during the search process, they can contact customer
support for assistance.

This use case describes the steps a user takes to filter search results based on specific criteria,
such as gym facilities, price, and distance. The platform displays a list of filter options, such as
gym facilities, price range, distance, and ratings, which the user can select to further refine their
search results.

Post reviews

Actor: User

Description: The user wants to post a review about their gym experience on the platform.

Preconditions: The user has a stable internet connection and a compatible device. The user has
visited a gym that is listed on the platform.

Basic Flow:

1. The user logs in to their account on the platform.

2. The user searches for the gym they visited using the search function.
3. The platform displays the gym listing.
4. The user selects the option to post a review.
5. The platform displays a form for the user to fill out.
6. The user enters their review in the form, including a rating and any additional comments.
7. The user submits the review.

Alternate Flows:

 If the user encounters any issues while posting a review, they can contact customer
support for assistance.

This use case describes the steps a user takes to post a review about their gym experience on the
platform. The user logs in to their account and searches for the gym they visited using the search
function. Once the gym listing is displayed, the user selects the option to post a review and fills
out the review form, including a rating and any additional comments. The user then submits the
review.

11
ii. Partner / Gym Owner

Figure 2 - Partner use case diagram.

12
Fill Partnership Form.

Actor: Gym owner

Description: The gym owner wants to fill out a partnership form to join the gym finder system.

Preconditions: The gym owner has a stable internet connection and a compatible device.

Basic Flow:

1. The gym owner visits the gym finder system website.

2. The gym owner selects the option to join the platform as a partner.
3. The platform displays a form for the gym owner to fill out.
4. The gym owner enters their gym name, address, and contact information.
5. The gym owner selects the gym facilities and services that their gym offers.
6. The gym owner selects the pricing options for their gym.
7. The gym owner selects the preferred method of communication for the partnership.
8. The gym owner submits the form.

Alternate Flows:

 If the gym owner encounters any issues while filling out the form, they can contact
customer support for assistance.

This use case describes the steps a gym owner takes to fill out a partnership form to join the gym
finder system. The form asks for information about the gym, including gym facilities, pricing,
and contact information. The gym owner can select the preferred method of communication for
the partnership. Once the form is filled out, the gym owner submits it to join the platform as a
partner.

Manage gym listing information.

Actor: Gym owner

Description: The gym owner wants to manage their gym listing on the platform.

Preconditions: The gym owner has a stable internet connection and a compatible device.

Basic Flow:

1. The gym owner logs in to their account on the platform.

2. The gym owner selects the option to manage their gym listing.
3. The platform displays the gym listing information, such as facilities, pricing, and opening
hours.

13
 4. The gym owner updates the gym listing information as needed.
5. The gym owner saves the changes to the gym listing.

Alternate Flows:

 If the gym owner encounters any issues while managing their gym listing, they can
contact customer support for assistance.

This use case describes the steps a gym owner takes to manage their gym listing on the
platform. The gym owner logs in to their account and selects the option to manage their gym
listing. The platform displays the gym listing information, such as facilities, pricing, and
opening hours, and the gym owner updates the information as needed. Additionally, the gym
owner uploads a virtual tour of the gym for users to view. The gym owner then saves the
changes to the gym listing.

Respond to reviews.

Actor: Gym owner

Description: The gym owner wants to respond to reviews left by users on their gym listing.

Preconditions: The gym owner has a stable internet connection and a compatible device.

Basic Flow:

1. The gym owner logs in to their account on the platform.

2. The gym owner selects the option to view reviews.
3. The platform displays the reviews left by users on the gym listing.
4. The gym owner selects a review to respond to.
5. The gym owner types a response to the review.
6. The gym owner saves the response to the review.

Alternate Flows:

 If the gym owner encounters any issues while responding to reviews, they can contact
customer support for assistance.

The platform should be able to handle a large number of users and gym listings without any
performance issues. This can be achieved by optimizing the codebase, implementing caching
mechanisms, and using a scalable infrastructure. Additionally, the platform should be regularly
monitored and tested to ensure that it is performing optimally.

14
Pay for Advertisements.

Actor: Gym owner

Description: The gym owner wants to pay for advertisements on the platform to increase the
visibility of their gym listing.

Preconditions: The gym owner has a stable internet connection and a compatible device. The
gym owner has created a profile for their gym on the platform.

Basic Flow:

1. The gym owner logs in to their account on the platform.

2. The gym owner selects the option to pay for advertisements.
3. The platform displays a list of advertising options and pricing.
4. The gym owner selects the desired advertising option.
5. The gym owner provides payment information and completes the transaction.
6. The platform displays the advertisement for the gym listing.

Alternate Flows:

 If the gym owner encounters any issues while paying for advertisements, they can contact
customer support for assistance.

This use case describes the steps a gym owner takes to pay for advertisements on the platform to
increase the visibility of their gym listing. The gym owner logs in to their account and selects the
option to pay for advertisements. The platform displays a list of advertising options and pricing,
and the gym owner selects the desired option. The gym owner provides payment information and
completes the transaction. The platform then displays the advertisement for the gym listing.

View statistics.

Actor: Gym owner

Description: The gym owner wants to view statistics about their gym's performance on the
platform.

Preconditions: The gym owner has a stable internet connection and a compatible device. The
gym owner has created a profile for their gym on the platform.

Basic Flow:

1. The gym owner logs in to their account on the platform.

2. The gym owner selects the option to view their gym statistics.

15
 3. The platform displays statistics about the gym's performance on the platform, such as the
number of views and clicks on the gym listing, and the number of reviews and ratings
received.

Alternate Flows:

 If the gym owner encounters any issues while viewing their gym statistics, they can
contact customer support for assistance.

This use case describes the steps a gym owner takes to view statistics about their gym's
performance on the platform. The gym owner logs in to their account and selects the option to
view their gym statistics. The platform displays statistics about the gym's performance, such as
the number of views and clicks on the gym listing, and the number of reviews and ratings
received.

iii. Admin.

Figure 3 - Admin use case diagram.

16
Administrator use case.

Actor: Administrator

Description: The administrator wants to manage the overall functionality and performance of
the gym finder system.

Preconditions: The administrator has a stable internet connection and a compatible device. The
gym finder system is fully implemented and operational.

Basic Flow:

1. The administrator logs in to their account on the platform.

2. The administrator selects the option to view system statistics.
3. The platform displays statistics about the gym finder system's performance, such as the
number of users, gyms, and reviews.
4. The administrator selects the option to manage users.
5. The platform displays a list of users and their information.
6. The administrator can edit or delete user information as needed.
7. The administrator selects the option to manage gyms.
8. The platform displays a list of gyms and their information.
9. The administrator can edit or delete gym information as needed.
10. The administrator selects the option to manage reviews.
11. The platform displays a list of reviews and their information.
12. The administrator can edit or delete reviews as needed.

Alternate Flows:

 If the administrator encounters any issues while managing the gym finder system, they
can contact technical support for assistance.

This use case describes the steps an administrator takes to manage the overall functionality and
performance of the gym finder system. The administrator logs in to their account and selects the
option to manage users, gyms, or reviews, depending on the task at hand. The administrator can
edit or delete user, gym, or review information as needed. The administrator can also view
system statistics to monitor the gym finder system's performance.

3.2. Functional Requirements

3.2.1. Registration

Precondition: user is not already registered with the system.

17
Input: valid email, password, name, age.

Trigger: user clicks on the “Register” button.

Path:
1. Navigate to the registration page.
2. enter a valid email, password, name, age.
3. click “Register” button.
4. verify that the user account is created successfully.

Expected output: user account is created successfully.

Post condition: user is redirected to the login page.

3.2.2. Login

Precondition: user is registered with the system.

Input: valid email & password.

Trigger: user clicks on “Login” button.

Path:
1.Navigate to the login page.
2. enter a valid email & password.
3. click the “Login” button.

Expected output: user is logged in successfully and redirected to the homepage.

Post condition: user can access their account information and search for gyms.

3.2.3. Gym search

Precondition: user is logged in and on the homepage.

Input: location (e.g., city, state, zip code).

Trigger: user clicks on “Search” button.

Path:
1. Navigate to the homepage.
2. Enter a valid location (e.g., city, state, zip code).
3. Click the "Search" button.
4. Verify that a list of nearby gyms is displayed.
5. Verify that the list contains relevant information, such as gym name, address, phone number,
and distance from the user's location.
18
Expected output: List of nearby gyms is displayed.

Post conditions: User can view the list of nearby gyms and select one for further information.

3.2.4. View gym details

Preconditions: User has searched for a gym and is on the gym details page.

Input: Gym name.

Triggers: User clicks on the "View Details" button.

Path:
1. Navigate to the gym details page.
2. Enter a valid Gym name.
3. Click the "View Details" button.
4. gym details are displayed.

Expected output: Details of the gym are displayed, such as name, address, phone number,
website, amenities, and membership plans.

Post conditions: User can view the gym details and interact with the gym (e.g., leave a review,
select a membership plan).

3.2.5. Review gym

Preconditions: User has selected a gym and is on the gym details page.

Input: Gym name and review text.

Triggers: User clicks on the "Submit Review" button.

Path:
1. Navigate to the gym details page.
2. Enter a review text.
3. Click the "Submit Review" button.
4. Verify that the review is submitted successfully.
5. Verify that the review is displayed on the gym details page.

Expected output: Review is submitted and displayed on the gym details page.

19
Post conditions: Review is added to the gym's profile and displayed for other users to view.

3.2.6. Rate gym

Preconditions: User has selected a gym and is on the gym details page.

Input: Gym name and rating (1-5 stars).

Triggers: User clicks on the "Submit Rating" button.

Path:
1. Navigate to the gym details page.
2. Enter a valid Gym name.
3. Select a rating (1-5 stars).
4. Click the "Submit Rating" button.
5. Verify that the rating is submitted successfully.
6. Verify that the rating is displayed on the gym details page.

Expected output: Rating is submitted and displayed on the gym details page.

Post conditions: Rating is added to the gym's profile and displayed for other users to view.

3.2.7. Select membership plan

Preconditions: User has selected a gym and is on the gym details page.

Input: Gym name and membership plan.

Triggers: User clicks on the "Select Plan" button.

Path:
1. Navigate to the gym details page.
2. Enter a valid Gym name.
3. Select a membership plan.
4. Click the "Select Plan" button.
5. Verify that the membership plan is selected successfully.
6. Verify that the plan is added to the user's account.

Expected output: Membership plan is selected and added to the user's account.
Post conditions: User can access the gym's amenities and services based on their membership
plan.

20
21
 4. External Interface Requirements.

4.1 User Interfaces

The system will have a web-based user interface that is accessible from any
device with an internet connection and a compatible web browser. The user
interface will be designed to be user-friendly and easy to navigate, with clear
instructions and prompts for users.

4.2 Prototype

Figure 4 – prototype 1 Figure 5 – prototype 2

22
Figure 6 - prototype 3
Figure 7 – prototype 4

Figure 8 - prototype 5

23
 4.2 Hardware Interfaces
The system will be compatible with multiple devices, including desktop
computers, laptops, tablets, and smartphones. The system will require an internet
connection to access the platform.

4.3 Software Interfaces

The system will use a variety of software interfaces to ensure compatibility with
multiple platforms and devices. These software interfaces will include web
browsers, operating systems, and programming languages.

4.4 Communications Interfaces

The system will use various communication interfaces to enable communication
between users and the platform. These interfaces will include email notifications,
in-app messaging, and social media integration.

4.5 System Interfaces

The system will use system interfaces to ensure compatibility with other systems
and applications. These interfaces will include APIs for integrating with third-party
systems and applications.

5. Nonfunctional requirements.

5.1 Performance requirements

i. Response Time: The system should provide search results within a
reasonable amount of time, preferably within a few seconds.

ii. Capacity: The system should be able to handle a large number of

concurrent users without affecting its performance.

iii. Reliability: The system should be reliable and able to handle a high
volume of search requests without crashing or experiencing
downtime.

24
 iv. Scalability: The system should be scalable to accommodate future
growth and increasing user traffic.

v. Load Testing: The system should undergo load testing to ensure it

can handle a heavy load of search requests.

vi. Caching: The system should cache frequently searched gym

information to reduce the search time and improve performance.

vii. Network Latency: The system should minimize network latency to

provide search results quickly to users.

viii. User Feedback: The system should allow users to provide feedback
on the search results and improve its performance based on user
feedback.

ix. System Monitoring: The system should be monitored for

performance issues and errors, with regular updates and maintenance
to ensure optimal performance.

x. Optimization: The system should be optimized for efficient search

queries and data retrieval to improve its performance.

25
5.2 Logical databases of requirements

Figure 9 - ERD

26
Figure 10 -ERD mapping

27
5.3 Security requirements

i. User Authentication: The system should require users to

authenticate themselves before accessing any personal or sensitive
data.

ii. Password Policy: The system should enforce a strong password

policy, including a minimum length, complex requirements, and
periodic password changes.

iii. User Roles and Access Control: The system should define different
user roles, such as admin, member, and guest, with different access
levels and permissions.

iv. Encryption: The system should use encryption to protect sensitive

data, such as passwords, credit card information, and personal
identification.

v. Secure Communication: The system should ensure that all

communication between the client and server is secure, using
protocols such as HTTPS and SSL/TLS.

vi. Security Testing: The system should undergo security testing to

identify and fix any vulnerabilities or weaknesses.

vii. Audit Logging: The system should maintain an audit log of all user
activities and system events, including login attempts, data access,
and changes to system configurations.

viii. Data Backup and Recovery: The system should have a backup and
recovery plan in place to ensure that data is not lost in case of a
security breach or system failure.

ix. Access Monitoring: The system should monitor access to sensitive

data and alert administrators of any suspicious or unauthorized
access attempts.

28
x. Compliance: The system should comply with all relevant data
protection laws and regulations, such as GDPR, HIPAA, and PCI-
DSS, to ensure the privacy and security of user data.

29