Skip to content

Requirements

Jump to bottom
Ebubekir Erden edited this page May 13, 2026 · 30 revisions

Glossary

  • Mentorship Session: A meeting for skill information flow between a mentor and a mentee at a determined time.
  • Mentorship: A relationship where one user (mentor) provides guidance/experience to another user (mentee) within a defined skill/topic area.
  • Mentor: A registered user who offers mentorship in one or more skills/topics.
  • Mentee: A registered user who requests mentorship in one or more skills/topics.
  • Skill/Topic: A category used to describe mentorship areas (e.g., coding, archery, interview prep). Skills are not verified by the system.
  • Match: A connection between a mentor and mentee established through the platform.
  • Feedback: An evaluation provided by mentor and mentee after a mentorship interaction.
  • Report: A user-submitted complaint about inappropriate or problematic communication or behavior.
  • Guest: A non-logged-in user who can browse/search mentors but cannot communicate.
  • User: A registered, authenticated account that can use mentorship and messaging features.
  • Admin: A privileged account that can manage users and handle reports, but cannot read private messages by default.
  • Notification: A system message delivered to users (e.g., email/in-app) about relevant events.

Requirements

1. Functional Requirements

1.1 User Requirements

1.1.1 User Types

  • 1.1.1.1 There shall be 3 types of users: guests, users, and admins.
1.1.1.1 Guests
  • 1.1.1.1.1 Guests shall not be able to initiate communication (e.g., messages) with registered users.
  • 1.1.1.1.2 Guests shall be able to register as a user account.
1.1.1.2 Users
  • 1.1.1.2.1 Users shall be able to authenticate using an email and password.
  • 1.1.1.2.2 A user shall have only one role (Mentor or Mentee) per account. Users wishing to perform both roles must register with separate email addresses.
  • 1.1.1.2.3 Users shall be able to have multiple mentorship relationships concurrently.
1.1.1.3 Admins
  • 1.1.1.3.1 Admins shall be able to manage user accounts (e.g., suspend/ban).
  • 1.1.1.3.2 Admins shall be able to review and process user reports.
  • 1.1.1.3.3 Admins shall not be able to read private user-to-user messages by default.

1.1.2 Sign Up & Login

  • 1.1.2.1 Users shall be able to sign up by providing an email address and a password.
  • 1.1.2.2 Email addresses shall be unique across all accounts.
  • 1.1.2.3 User passwords shall meet minimum safety criteria.
  • 1.1.2.4 Users shall be able to log in and log out of the system.
  • 1.1.2.5 The system shall support user authentication via third-party OAuth providers (e.g., Google, Apple, Facebook) in addition to email and password.
  • 1.1.2.6 The system shall assign each registered user a unique username in addition to a unique email address.
  • 1.1.2.7 Users shall be able to change their system-assigned default usernames during onboarding, provided the requested username is unique and satisfies the platform format rules.
  • 1.1.2.8 The system shall support password-reset workflows using time-limited reset tokens.
  • 1.1.2.9 The system shall support email-verification workflows using time-limited verification tokens.
  • 1.1.2.10 The system shall allow users to request a new email-verification message when their email address is not yet verified.
  • 1.1.2.11 The system shall prevent banned users from obtaining new authenticated sessions through token refresh.

1.1.3 Profiles & Visibility

  • 1.1.3.1 Users shall have profile pages.
  • 1.1.3.2 Users shall be able to provide profile information including a description/about section.
  • 1.1.3.3 The system shall should support profile fields with visibility settings (public vs. hidden/optional) implemented profile privacy controls, including whether a user's full name or initials are displayed publicly and whether the user's precise location is shared.
  • 1.1.3.4 Guests shall be able to view only the public parts of user profiles.
  • 1.1.3.5 Users shall be able to edit their profile information.
  • 1.1.3.6 User profiles should include a picture field.
  • 1.1.3.7 The system shall allow users to choose to display only their initials publicly, revealing their full name only to matched users.
  • 1.1.3.8 Users shall be able to upload a profile picture file.
  • 1.1.3.9 Users should be able to upload profile audio and profile video introduction files.
  • 1.1.3.10 Users should be able to provide external professional-link fields such as a LinkedIn URL.
  • 1.1.3.11 The system shall support username-based public profile URLs.
  • 1.1.3.12 The system should allow users to choose whether their precise location is shared or privacy-masked in discovery results.

1.1.4 Mentorship Roles and Relationships

  • 1.1.4.1 The system shall support many-to-many mentorship relationships (a user may have multiple mentors and or multiple mentees according to their app usage mode).
  • 1.1.4.2 The system shall allow mutual mentorship between two users (a user may mentor another user in one skill while being mentored by the same user in another skill).
  • 1.1.4.3 The system shall support mentorship topics/skills as metadata for matching and discovery.
  • 1.1.4.4 The system shall allow users mentees to send mentorship requests to mentors.
  • 1.1.4.5 The system shall allow mentors to accept or reject received mentorship requests.
  • 1.1.4.6 The system shall allow mentors to create specific mentorship "packages" or listings, detailing distinct academic/skill levels and custom cover photos.
  • 1.1.4.7 The system shall allow mentees to include a text-based introductory note (cover letter) when submitting a mentorship request, but shall accept submissions where this field is left empty (an empty string).
  • 1.1.4.8 The system shall restrict mentees to having only one active or pending mentorship request per mentor at any given time to prevent spam.

1.1.5 Messaging

  • 1.1.5.1 Users shall be able to exchange messages with other users.
  • 1.1.5.2 Messages shall be private between the communicating users.
  • 1.1.5.3 The system shall provide a mechanism for users to report problematic communication.
  • 1.1.5.4 The system shall allow users to share files (e.g., PDFs, images, text, and audio) within the messaging interface and display these files directly within the message history.
  • 1.1.5.5 The system shall should support Markdown formatting for user messages and simple note-taking areas.
  • 1.1.5.6 The system should support message read-receipt states such as sent, delivered, and read.

1.1.6 Feedback

  • 1.1.6.1 The system shall allow mentors and mentees to provide feedback to each other mentors after an interaction.
  • 1.1.6.2 Feedback shall be associated with the relevant mentorship relationship.
  • 1.1.6.3 The system shall update and display a mentor's average public rating only after receiving a defined threshold of new feedback entries (e.g., every 5 reviews) to preserve user anonymity.
  • 1.1.6.4 Feedback shall be anonymized.

1.1.7 Notifications

  • 1.1.7.1 The system shall provide a notification mechanism to inform users about relevant events.
  • 1.1.7.2 Notifications shall be delivered only to users directly affected by the triggering event.
  • 1.1.7.3 Following events shall create a notification for the Mentor: Receiving a new mentorship request, a Mentee booking a meeting, a Mentee canceling a meeting, a Mentee rescheduling a meeting, a match with a Mentee being deactivated, receiving new feedback, workshop cancellation, workshop rescheduling, and relevant community-tag events.
  • 1.1.7.4 Following events shall create a notification for the Mentee: Rejection of a mentorship request, acceptance of a mentorship request, a Mentor cancelling a meeting, a match with a Mentor being deactivated, and relevant workshop or community-tag events directly affecting the Mentee.
  • 1.1.7.5 Following events shall create a notification for all affected users: New message received and other directly relevant personal account events.
  • 1.1.7.6 Following events shall create a notification for Admins: New report received.
  • 1.1.7.7 Users shall be able to mark individual notifications as read.
  • 1.1.7.8 Users should be able to mark all notifications as read in bulk.
  • 1.1.7.9 The system should support push-notification token registration for supported client platforms.

1.1.8 Scheduling

  • 1.1.8.1 Users Mentors shall be able to create and manage availability schedules.
  • 1.1.8.2 Users shall be able to view their upcoming mentorship sessions in the form of a calendar.
  • 1.1.8.3 Users Mentees shall be able to reschedule their upcoming mentorship sessions from the calendar.
  • 1.1.8.4 Users Authorized mentorship participants shall be able to cancel their upcoming mentorship sessions from the calendar.
  • 1.1.8.5 Users should be able to open the mentor's profile page from the classes shown on the calendar.
  • 1.1.8.6 The system should integrate with external calendar services (e.g., Google Calendar) to sync availability and appointments.
  • 1.1.8.7 The system shall support scheduling for both one-time meetings and recurring mentorship sessions.
  • 1.1.8.8 The system shall represent mentorship meetings as explicit session records with statuses including scheduled, rescheduled, canceled, and completed.
  • 1.1.8.9 The system shall record which participant canceled a session and preserve cancellation metadata.

1.1.9 Group Sessions and Workshops

  • 1.1.9.1 The system should allow mentors to create and schedule community-scoped collective training sessions (workshops).
  • 1.1.9.2 The system should allow mentors to define minimum and maximum participant thresholds for workshops.
  • 1.1.9.3 The system should allow mentees to request group attendance (e.g., bringing friends) for a session, subject to mentor approval join and leave workshops individually.
  • 1.1.9.4 Workshop authors shall be able to edit and cancel their workshops.
  • 1.1.9.5 Mentors should be able to see their hosted workshops on their profiles.

1.1.10 Session and Role Context

  • 1.1.10.1 The system shall allow authenticated users to retrieve their current account context (e.g., id, email, role/mode flags).
  • 1.1.10.2 The system shall allow users to set their active usage mode preference (mentor, mentee, or both) for UI personalization.

1.1.11 Mentorship Request and Match Lifecycle

  • 1.1.11.1 The system shall prevent users from sending mentorship requests to themselves.
  • 1.1.11.2 The system shall support a clear request lifecycle with status transitions (at minimum: pending, accepted, rejected).
  • 1.1.11.3 When a mentor accepts a mentorship request tied to a specific slot, the system shall mark that slot as booked.
  • 1.1.11.4 When a mentorship request is accepted, the system shall create a corresponding match record linking mentor and mentee.
  • 1.1.11.5 When a mentorship request is rejected, the system shall not create a match.
  • 1.1.11.6 The system shall allow mentors or mentees to deactivate an existing mentorship match.

1.1.12 Availability and Booking Integrity

  • 1.1.12.1 The system shall reject availability slots where end time is earlier than or equal to start time.
  • 1.1.12.2 The system shall prevent overlapping availability slots for the same mentor.
  • 1.1.12.3 The system shall not allow booking of an already booked slot.
  • 1.1.12.4 The system shall allow cancellation of booked slots only by authorized users (e.g., booked mentee and/or slot owner).
  • 1.1.12.5 The system shall preserve booking metadata (e.g., who booked and when booked) for booked slots.

1.1.13 UI/UX & Feedback

  • 1.1.13.1 The system shall provide clear success and failure notifications (e.g., Toast messages or alerts) for all key actions, such as sending mentorship requests, profile updates, or form errors.
  • 1.1.13.2 The system shall enforce stricter validation on all forms to prevent the use of special characters in name fields and numeric-only names username fields to prevent invalid characters and conflicting usernames.

1.1.14 "Time Tunnel" (Situation Tracking) Match Journey and Timeline

  • 1.1.14.1 The system shall provide a "Time Tunnel" interface for matches to visualize their mentorship history. a shared mentorship journey interface for matches to visualize their mentorship history.
  • 1.1.14.2 The Time Tunnel shall display specific data points including session dates, major milestones (e.g., "Learned Python basics," "Hired at Tech Corp"), and human-dimension encounters (e.g., "Met for coffee"). The mentorship journey interface should display session lifecycle events, major milestones, and selected human-dimension encounters contributed by match participants.
  • 1.1.14.3 The system shall provide a shared mentorship journey feed for each active or historical match.
  • 1.1.14.4 Match participants shall be able to create, edit, and delete manual entries in the shared journey feed.
  • 1.1.14.5 Manual entries should support visibility control for whether they are also shown on the author’s profile.

1.1.15 Accountability & Moderation

  • 1.1.15.1 The system shall issue notifications or warnings to Mentees Mentors if they exceed a reasonable number of active mentorships, though no hard limit will be enforced.
  • 1.1.15.2 The system shall rely on a natural balancing mechanism where Mentor ratings and feedback reflect their capacity to handle multiple mentees.

1.2 System Requirements

1.2.1 Mentorship Discovery and Ranking

  • 1.2.1.1 The system shall allow searching mentors by skill/topic.
  • 1.2.1.2 The system shall allow viewing mentor profiles as search results.
  • 1.2.1.3 The system shall allow guests to search and view mentors without authentication.
  • 1.2.1.4 The system shall allow filtering the mentors by criteria.
  • 1.2.1.5 The system should allow users to view mentor listings on an interactive map interface.
  • 1.2.1.6 The system should allow users to filter mentors by geographical distance or radius.
  • 1.2.1.7 The system shall feature dynamic UI lists to improve discovery, such as "Recently Added Listings Mentors" and "Popular Mentors".
  • 1.2.1.8 The system shall treat "Groups" or "Campuses" as public tags to facilitate discovery and real-world encounters (e.g., workshops) rather than strictly isolated silos.
  • 1.2.1.9 The system shall support the creation of "virtual communities" to bridge geographical gaps between users with similar interests.
  • 1.2.1.10 The system should expose mentor overload indicators when a mentor reaches a configurable active-match threshold.

1.2.2 Privacy and Reporting

  • 1.2.2.1 The system shall provide admins with a report review interface.
  • 1.2.2.2 The system shall not provide admins direct access to read user messages unless required by a report workflow.

1.2.3 Forum Communities, Posts, and Public Social Features

  • 1.2.3.1 The system shall should include community-based forum discussion features.
  • 1.2.3.2 The forum shall Community discussion areas should support reading content by guests and posting by users.
  • 1.2.3.3 The system should provide public interest-based communities organized by community tags.
  • 1.2.3.4 Authenticated users shall be able to create, join, and leave community tags.
  • 1.2.3.5 Guests shall be able to browse public community information and public community content.
  • 1.2.3.6 Authenticated users shall be able to publish community posts.
  • 1.2.3.7 Authenticated users shall be able to publish profile posts visible on their profile pages.
  • 1.2.3.8 Community and profile posts shall support optional media attachments.
  • 1.2.3.9 Community posts should support tagging eligible users by username.
  • 1.2.3.10 Authors shall be able to choose whether certain community content is also shown on their public profile.

1.2.4 Platform Support

  • 1.2.4.1 The system shall provide a web application interface.
  • 1.2.4.2 The system shall provide a mobile application interface.

1.2.5 External Service Integrations

  • 1.2.5.1 The system should utilize a mapping API (e.g., Google Maps API, OpenStreetMap, or Mapbox) to render location-based mentor discovery.

1.2.6 Moderation and Account State

  • 1.2.6.1 The system shall issue both access and refresh tokens upon successful authentication.
  • 1.2.6.2 The system shall allow users to refresh expired access tokens using a valid refresh token.
  • 1.2.6.3 The system shall allow admins to view a manageable list of user accounts for moderation workflows.
  • 1.2.6.4 The system shall support account-level moderation actions such as banning/suspending users.
  • 1.2.6.5 The system shall prevent banned/suspended users from continuing normal platform interactions according to policy.

1.2.7 API and Documentation

  • 1.2.7.1 The system shall provide OpenAPI-compatible API documentation for backend endpoints.
  • 1.2.7.2 The system shall enforce authorization and ownership checks on protected API endpoints.

2. Non-functional Requirements

2.1 Constraints

  • 2.1.1 The system shall not include monetization features.
  • 2.1.2 The system shall not include skill verification mechanisms (e.g., certification checks).
  • 2.1.3 All third-party libraries used in the project shall should be open-source.

2.2 Privacy

  • 2.2.1 Private messages shall not be publicly visible.
  • 2.2.2 The system shall allow users to control the visibility of optional profile fields.
  • 2.2.3 The system shall allow users to control the visibility of their profile page implemented profile privacy settings, including name-display privacy and precise-location sharing.

2.3 Security

  • 2.3.1 User passwords shall be stored as hashed in the database.
  • 2.3.2 The system shall ensure that one email corresponds to one account.

2.4 Accessibility

  • 2.4.1 The system shall should comply with the WCAG 2.1 AA accessibility standards.

2.5 Reliability and Data Integrity

  • 2.5.1 Critical lifecycle operations (e.g., request acceptance and slot booking) shall be executed atomically to avoid inconsistent states.
  • 2.5.2 Core entities (e.g., mentorship requests, matches, slots, reports) shall include auditable timestamps.
  • 2.5.3 The system shall enforce data integrity constraints to prevent duplicate or conflicting lifecycle records.

Links: Home | Main Repository

Team Members

Requirements & Design

Milestones & Deliverables

Final Milestone (1.0.0)

Final Release Reports

Milestone 2 (0.2.0-alpha)

MVP Milestone (0.1.0-alpha)

Project Documentation

Meetings & Reports

Weekly Meetings

View List

Customer & Stakeholder Meetings

Other Meetings

Lab Reports

View List

Templates

Clone this wiki locally