Requirements - bounswe/bounswe2025group2 GitHub Wiki

Title Page

Software Requirements Specification for

  • Project Name: GenFit
  • Version: 3.0.4
  • Date: 18/11/25

Prepared by (Version 3.0.0): bounswe2025group2

Prepared for: CmpE 451 - Fall 2025

Previous Version Contributors

Version 2.0.0 Contributors (CmpE 352)

Prepared by: bounswe2025group2

Prepared for: CmpE 352 - Spring 2025

Version 1.0.0 Contributors

Prepared by: bounswe2025group2

Table of Contents

Revision History

Name Date Reason for Change Version
Removed badge functionality 18/11/2025 With the limited time we have, remaining feautures were more crucial to app than badge functionality. 3.0.4
A small change after lab 3 20/10/2025 2.1.2 and 2.1.3 are merged 3.0.3
Improve formatting and clarity of requirements 07/10/2025 Clarified wording, ensured consistent style, and improved markup readability for 1.2.4 and 1.2.5 sections 3.0.2
add cross domain requrement 02/10/2025 unauthorized cross-domain requests will be covered using django's built-in mechanisms 3.0.1
Enhancements for Cmpe 451 02/10/2025 Updating requirements based on new enhancements for Cmpe 451 course 3.0.0
requirements overhaul after imp 14/05/2025 changes made on the project during the implementation 2.0.0
versioning fix 27/04/2025 flawed versioning 1.3.5
revisit login requirements 24/04/2025 Instructor feedback 1.3.4
add project name 15/04/25 added project name 1.3.3
links fix 01/04/25 fixed the links of revision history and requirements on the table of contents 1.3.2
revision history rework 01/04/25 seperated the table before and after 1.0 and put pre-1.0 in a dropdown to simplify the page 1.3.1
versions rework 26/03/25 reworked versioning and added to conventions 1.3
fix document conventions 26/03/25 fixed a small misteki in non-func part of document conventions 1.2.1
add appendix b 26/03/25 Added appendix b: guide to parse from doc to wiki page 1.2
add overall description 26/03/25 Added overall description part 1.1.3
add introduction 26/03/25 Added introduction part 1.1.2
add revision history 26/03/25 Added revision history extracted from google doc 1.1.1
add srs headers 26/03/25 Added srs headers to be filled 1.1
version 1.0 21/03/25 Moved the glossary to bottom, also finalized the requirements until implementation 1.0

Before 1.0

Click to expand the table
Name Date Reason for Change Version
add 2.1 2.2 2.3 19/03/25 Added non functional requirements: Performance, Reliability, Compatibility 0.9
update goals-rewards req 06/03/25 Added extra goals and rewards requirements that is needed 0.8.1
add notifications req 05/02/25 Added notifications requirements 0.8
update goals-rewards req 05/03/25 Added extra goals and rewards requirements that is needed 0.7.2
update forum req 05/03/25 Added extra forum requirements that is needed 0.7.1
finish glossary 01/03/25 Added the last words to glossary that is still not defined 0.7
add some words to glossary 28/02/25 Added some glossary definitions 0.6.1
add search-interactive directory req 27/02/25 Added search and interactive directory requirements 0.6
add 2.4 2.5 2.6 27/02/25 Added non functional requirements: User Friendliness and Usability, Privacy and Data Related, Debugging; also some glossary definitions 0.5
add account-profile req 27/02/25 Added Account and profile requirements 0.4
add goals-rewards req 26/02/25 Added goals and rewards requirements 0.3
add forum req 25/02/25 Added forum requirements 0.2
add login-registration req 25/02/25 Added login and registration requirements 0.1
initial commit 22/02/25 Opened the blank page 0.0.1

Introduction

Purpose

The purpose of this project is to develop a fully functional app with both front-end (Web and Mobile) and back-end, aimed at providing a platform that connects kids with local sports programs and mentors via forums and challanges.

Document conventions

For functional requirements:

  • x.x: Major section (e.g. System Requirements)
  • x.x.x: Subsection (e.g., Account and Profile)
  • x.x.x.x: Specific requirement within that subsection
  • x.x.x.x.x: More granular sub-requirement (e.g., Filtering criteria)

For non-functional requirements:

  • x.x: Subsection
  • x.x.x: Specific requirement within that subsection
  • x.x.x.x: More granular sub-requirement

For versions (x.y.zzz):

  • x: Major Updates such as a complete rework or milestone
  • y: Modarate Updates such as new tab or a header rework
  • z: Minor Updates such as grammar and structural fixes

Product scope

This project is an application designed to encourage users to be more physically active. Users can set personal fitness goals, interact with mentors and trainers, share information through forums, and boost their motivation by earning various rewards. The platform aims to help users track their fitness activities and stay engaged within the community.

References

Overall Description

The platform is designed to connect young individuals with local sports programs to promote an active lifestyle and combat harmful habits. By offering a comprehensive directory of sports activities, the platform allows users to find free and low-cost programs based on their location and age group. In addition, the platform encourages fitness progress through virtual challenges, personalized fitness goals, and the opportunity to connect with experienced mentors and coaches for guidance. Users can earn rewards, share their progress with the community, and engage in forums dedicated to training tips, motivation, and success stories.

This platform aims to provide a safe, engaging, and motivating environment where young individuals can develop a healthy relationship with fitness while being supported by a community of mentors, coaches, and peers. It also empowers users to track their achievements, interact with others, and participate in fitness challenges that promote personal growth.

The project will utilize a robust tech stack to ensure seamless performance and scalability across web and mobile platforms. For the back-end, Django REST Framework (Python) and Spring Boot (Java) will be used to build efficient and secure APIs, while MySQL and PostgreSQL databases store user data and progress information. On the front-end, React 18+ and Vue.js will be used for the web application, ensuring responsive and dynamic user interfaces. The mobile app is going to be built with React Native, allowing cross-platform compatibility for both iOS and Android. Please note that the tech stack are subject to change.

1. Functional Requirements (System Features)

1.1. User Requirements

1.1.1. Account and Profile
  • 1.1.1.1. Users shall be able to create an account by providing a unique username, a valid email address, and a password.
  • 1.1.1.2. Users can either register as a normal user or a coach upon registration.
  • 1.1.1.3. Users shall be able to send a mentor-mentee relationship request to another user to be their mentors or mentees via their profile.
  • 1.1.1.4. Once approved, mentors shall gain additional permissions such as:
    • 1.1.1.4.1. Setting fitness goals for mentees.
    • 1.1.1.4.2. Tracking mentee progress.
    • 1.1.1.4.3. Providing structured feedback and training tips.
  • 1.1.1.5. Once approved, coaches shall gain additional permissions such as:
    • 1.1.1.5.1. Creating customized challenges.
  • 1.1.1.6. Each user shall have a profile that includes their username, profile picture (with alternative text), location, birth date, short bio, and age.
  • 1.1.1.7. Users shall be able to edit their profile details, including their name, surname, bio, birth date, location, and profile picture.
  • 1.1.1.8. Users shall be able to set their preferred sports categories and fitness interests.
  • 1.1.1.9. Users shall be able to adjust their profile visibility settings (public, private, or visible only to friends/mentors), and the visibility options shall be clearly described in accessible form elements.
1.1.2. Login and Registration
  • 1.1.2.1. Users shall be able to sign up, log in, and log out through accessible form interfaces.
  • 1.1.2.2. Users shall provide an appropriate and unique username along with a unique email address among all users, and a password to sign up. Passwords shall not need to be unique.
  • 1.1.2.3. Usernames shall meet the security criteria. Usernames must start with a lowercase letter, they shall consist only of alphanumeric characters, and contain at least one digit and one letter. Additionally, they shall be able to include characters only from the English alphabet.
  • 1.1.2.4. Email address provided by the user during registration shall be confirmed via a confirmation email.
  • 1.1.2.5. User passwords shall be strong, meeting the security criteria. Passwords must be at least 8 characters long, they can only include alphanumeric characters, and contain at least one letter and one digit. Password fields shall be masked and meet accessibility requirements (e.g., labeled form elements).
  • 1.1.2.6. Users shall be able to change their password via a confirmation email, sent to the email address provided during registration. This can also be used when users forget their password.
1.1.3. Forum Requirements
  • 1.1.3.1. Users shall be able to create new forum threads under specific forum categories.
  • 1.1.3.2. Users shall be able to view forum threads in a responsive and accessible layout compatible with WCAG 2.1 Level AA.
  • 1.1.3.3. Users shall be able to bookmark forum threads to access them later by using a bookmarks page.
  • 1.1.3.4. Users shall be able to reply to existing forum threads.
  • 1.1.3.5. Users shall be able to upvote or downvote threads and comments using accessible buttons with clear labels for assistive technologies.
  • 1.1.3.6. Users shall be able to report inappropriate content through an accessible interface, ensuring the action is confirmed before submission.
  • 1.1.3.7. Users shall be able to follow specific threads to get notifications on replies, with the option to opt out.
  • 1.1.3.8. Users shall be able to use search and filtering options to find relevant threads. Search forms and filters shall have appropriate labels and keyboard accessibility.
  • 1.1.3.9. Users shall be able to edit or delete their own posts. Deletion actions shall require confirmation to prevent accidental data loss.
  • 1.1.3.10. Users shall be able to visit profiles of people tagged in posts, with accessible links that follow W3C hyperlink standards.
1.1.4. Goals & Rewards Requirements
  • 1.1.4.1. The users shall be able to set personal fitness goals.
  • 1.1.4.2. Fitness goals shall have pre-defined types like:
    • 1.1.4.2.1. Walking/Running
    • 1.1.4.2.2. Workout
    • 1.1.4.2.3. Cycling
    • 1.1.4.2.4. Swimming
    • 1.1.4.2.5. Sports
  • 1.1.4.3. Depending on the type of the goal, users shall be able to set measurable limits on the goals like durations, distance etc.
  • 1.1.4.4. The user shall be able to update or restart the set goals.
  • 1.1.4.5. The user shall be able to track and see goal progress on his/her profile.
  • 1.1.4.6. The mentors shall be able to set goals for their mentees and track their progress.
1.1.5. Notifications Requirements
  • 1.1.5.1. Users shall be able to enable or disable notifications through their settings.
  • 1.1.5.2. Users shall reach a notification tab in the web-based platform to track all notifications and mark them as read.
1.1.6. Support and Contact
  • 1.1.6.1. Users shall be able to access a support email address for assistance with moderation or platform-related issues.
  • 1.1.6.2. Users shall be able to appeal moderation decisions including content removal, warnings, or account restrictions for any platform content (forum posts, challenges, goals, profiles) through a formal appeal process.

1.2. System Requirements

1.2.1. Account and Profile
  • 1.2.1.1. The system shall implement a verification process for coach applications.
1.2.2. Goals & Rewards Requirements
  • 1.2.2.1. The system shall send notifications for the goals that have reached their deadlines.
  • 1.2.2.2. The system shall send notifications to encourage users to set a goal if they haven't done so in the last week.
1.2.3. Search and Interactive Directory
  • 1.2.3.1. The system shall allow users to search for mentors, challenges, and forum discussions.
  • 1.2.3.2. The search bar shall be accessible through the main page.
  • 1.2.3.3. The system shall allow users to filter search results based on:
    • 1.2.3.3.1. Age group
    • 1.2.3.3.2. Location
    • 1.2.3.3.3. Sport type
  • 1.2.3.4. The system shall allow users to bookmark challenges for later accession from bookmarks page.
1.2.4. Challenges and Leaderboards
  • 1.2.4.1 The system shall allow users to join virtual fitness challenges via web or mobile applications.
  • 1.2.4.2 The system shall allow coaches to create virtual fitness challenges, specifying challenge details such as title, description, duration, and ranking criteria.
  • 1.2.4.3 The system shall automatically track challenge progress based on manual user input or connected device data.
  • 1.2.4.4 The system shall display challenge deadlines and notify users accordingly via in-app, push, or email notifications.
  • 1.2.4.5 The system shall allow users to view their challenge history, including performance and completion records.
  • 1.2.4.6 The system shall maintain a leaderboard ranking participants based on challenge performance criteria.
  • 1.2.4.7 The system shall support different ranking criteria configurable by challenge creators.
  • 1.2.4.8 The system shall update the leaderboard in real-time.
  • 1.2.4.9 The system shall display each user's ranking and progress within the leaderboard.
1.2.5. Notifications Requirements
  • 1.2.5.1 The system shall notify users when someone likes or comments on their posts via in-app, push, or email notifications.
  • 1.2.5.2 The system shall notify users when they are tagged in a forum thread or comment.
  • 1.2.5.3 The system shall notify users when someone replies to their posts or comments.
  • 1.2.5.4 The system shall send updates on users' challenge and goal deadlines.
  • 1.2.5.5 The system shall notify mentees when a mentor sets a new goal for them.
  • 1.2.5.6 The system shall send pop-up notifications on mobile devices, configurable in user settings.
  • 1.2.5.7 The system shall send lead emails encouraging inactive users to return to the platform.

2. Non-functional Requirements (System Features)

2.1. Performance
  • 2.1.1. The system should support up to 1000 concurrent users.
  • 2.1.2. The main page of application & web page should load within 1 second under normal network conditions
  • 2.1.3. logging in to an account should take at most 3 seconds under normal network conditions
  • 2.1.4. upon completion of a challenge, the leaderboard should take at most 1 minute to be updated
2.2. Reliability
  • 2.2.1. The System should have at least %99.9 monthly uptime
  • 2.2.2. The System shall backup its database every 24 hours
  • 2.2.3. Data Restoration should Occur within an hour in case of a system failure
2.3. Compatibility
  • 2.3.1. The webpage should be compatible with Google Chrome (version 115+), Mozilla Firefox (Version 115+) and Apple Safari (Version 16+)
  • 2.3.2. The Mobile App shall be compatible with Android 12 and above
  • 2.3.3. The Mobile App Should Support Portrait orientation
  • 2.3.4. Both Web and Mobile apps should support resolutions 720p (1280x720) and above.
  • 2.3.5. The system shall support UTF-8 encoding for all text fields to allow consistent storage and display of multiple languages and special characters.
2.4. User Friendliness and Accessibility
  • 2.4.1. The platform should allow users to navigate to any primary feature within 3 clicks.
  • 2.4.2. The interactable UI elements should support scaling.
  • 2.4.3. Each page shall be loaded within 3 seconds under normal internet conditions.
  • 2.4.4. The system shall implement navigation patterns in compliance with W3C WCAG 2.1 AA guidelines.
  • 2.4.5. The system shall support full keyboard navigation
  • 2.4.6. The system shall provide text alternatives (alt text) for all profile pictures and user-uploaded images.
2.5. Data and Activity Standards
  • 2.5.1. The system shall represent user activities (posts, challenges, goals, achievements) in Activity Stream 2.0 compliant format for data portability and API consistency.
  • 2.5.2. The system shall provide automatic timezone detection based on user location.
  • 2.5.3. The system shall allow users to manually select and change their timezone settings.
  • 2.5.4. The system shall display all timestamps according to the user's selected timezone.
2.6. Privacy and Data Related
  • 2.6.1. All sensitive data should be stored securely with encryption.
  • 2.6.2. All data transmissions between the frontend, backend, and external services shall be secured using HTTPS (TLS 1.2 or higher).
  • 2.6.3. The system should delete accounts with users' requests within 14 days.
  • 2.6.4. The platform shall require guardian consent for users under 13 years old.
  • 2.6.5. The platform should allow users to switch onto a "private" setting.
  • 2.6.6. The platform should comply with KVKK by allowing users to access, correct, and delete their personal data upon request.
  • 2.6.7. No personal data should be shared with any third parties without explicit consent.
  • 2.6.8. The system shall use HTTPS encryption for all data transmissions to ensure secure communication between client and server.
  • 2.6.9 The system shall block unauthorized cross-domain requests to protect user data. Django’s built-in CORS and CSRF protection mechanisms shall be configured to allow requests only from trusted origins.
  • 2.6.10 The system shall provide a persistent login feature that allows users to remain logged in across sessions without re-entering their credentials, if they have previously opted in.
2.7. Legal Disclosures
  • 2.7.1. The platform shall provide clear and accessible Terms of Service that outline user rights, responsibilities, and platform usage guidelines.
  • 2.7.2. The platform shall provide a comprehensive Privacy Policy detailing data collection, usage, storage, and sharing practices.
  • 2.7.3. The platform shall implement cookie consent mechanisms to comply with applicable privacy regulations.
2.8. Debugging (for maintainers)
  • 2.8.1. The system should generate error logs.
  • 2.8.2. Maintainers should have access to an admin panel.
  • 2.8.3. The app should automate crash reports without requiring user intervention.
  • 2.8.4. Minimum of 90% of the platform shall be targeted to be covered by unit tests.

Appendix

Appendix A: Glossary

  • User: A person that decided to use our software for their benefit.
  • Coach: A special type of user that has privilage to create custom virtual challanges via our software.
  • Mentor: A type of user that can set and view goals to their mentees in their mentor-mentee relations.
  • Mentee: A type of user that can get goals from their mentors in their mentor-mentee relations.
  • Goal: An objective set by the user or their mentor to reach some level of effort.
  • Profile: A piece of data that belongs to a user and contains relevant information such as their username, profile picture, bio, birth date, age, and fitness goals.
  • Challenge: A virtual fitness activity that created by coaches so that users can participate in to achieve specific fitness goals, such as step count, workout duration, or calories burned.
  • Leaderboard: A ranking system that displays participants’ performance in ongoing or completed challenges based on predefined criteria.
  • (Goal) Progress: Development on the goal, reaching a more advanced condition on it.
  • Primary Feature: Pages about goals, challenges, forums, and profiles.
  • Normal Internet Conditions: Any internet connection over 10 Mbps speed.
  • Interactable UI Elements: Any clickable element and any texts
  • Private Account: An account where any data besides username and profile picture is not visible to the public and any users not connected to this account.
  • Error Logs: A log that includes timestamps, error codes, and the most recent user activities without exposing sensitive data.
  • Forum thread: A forum post that contains text, labels (for filtering), and users tagged; created for sharing training tips, motivation, success stories, and asking fitness-related questions.
  • Bookmark: A user action to save forum threads for easier access
  • Upvote: A point given by users to forum threads to indicate that the thread is useful.
  • Downvote: A point given by users to forum threads to indicate that the thread is not useful.
  • Report: A user action to report inappropriate posts for inspection.
  • Tag: A label used to categorize forum posts for better classification.
  • Inappropriate Content: Any forum post or comment that contains offensive, harmful, or rule-violating image or text, such as spam, harassment, hate speech, misinformation, or explicit content.
  • Notification Tab: A dedicated section within the web-based platform where users can view all their notifications, including interactions, challenge updates, goal progress, and system alerts.
  • Pop-up Notification: A real-time alert that appears on a user’s mobile device to inform them about important activities such as likes, comments, challenge invitations, or mentor feedback.
  • Lead Email: A reminder email sent to inactive users, encouraging them to return to the platform and re-engage with its features.
  • W3C WCAG 2.1 AA Guidelines: Standards by the W3C Web Accessibility Initiative to ensure web content is accessible to people with disabilities.
    AA level requires:
    • Text alternatives for non-text content
    • Sufficient color contrast
    • Scalable text
    • Consistent navigation
    • Accessibility with assistive technologies
  • Full Keyboard Navigation: All interactive elements (buttons, links, forms, menus) must be operable using only a keyboard (Tab, Shift+Tab, Enter, Space, arrow keys). Supports users who cannot use a mouse or rely on assistive tech.
  • UTF-8 Encoding: A character encoding standard that represents every character in the Unicode character set using one to four bytes. It allows consistent storage, display, and transfer of text in multiple languages and special symbols across different platforms and systems.
  • Activity Stream 2.0: A W3C standard for representing social activities in a consistent JSON format, enabling data portability and API interoperability across different platforms and services.
  • Automatic Timezone Detection: A system feature that determines a user's timezone based on their geographic location or device settings without requiring manual input.
  • Manual Timezone Selection: A user interface feature that allows users to explicitly choose their preferred timezone from a list of available options, overriding automatic detection.
  • Text Alternatives (Alt Text): Descriptive text that conveys the meaning and context of images to users who cannot see them, essential for screen readers and accessibility compliance.
  • Assistive Technologies: Software and hardware tools that help people with disabilities interact with digital content, including screen readers, voice control software, and specialized keyboards.
  • Appeal Process: A formal mechanism allowing users to request review and reconsideration of moderation decisions, including content removal, account restrictions, or other penalties.
  • HTTPS (HyperText Transfer Protocol Secure): An encrypted version of HTTP that secures data transmission between web browsers and servers using SSL/TLS encryption.

Appendix B: Guide to Parse Google Doc to Wiki Page

To parse requirements from the google doc to the wiki page:

  • Get this plugin from the google workspace marketplace.
  • In the google doc page; select this plugin from the extensions tab, click convert, and select markdown from the menu on the right.
  • Copy the output in markdown.
  • Go to this website and parse the copied text.
  • Copy the output to the wiki page and make sure that everything is parsed correctly since the parser is using brute-force parsing, make sure that the given text is in correct form that is described in the conventions.
⚠️ **GitHub.com Fallback** ⚠️