Requirements - bounswe/bounswe2026group9 GitHub Wiki

Functional Requirements (FR)

User Requirements (FRU)

FRU-1. Event Creation and Management (Registered Users)

  • FRU-1.1. Registered users shall be able to create community events.

    • FRU-1.1.1. Users shall provide an event title, description, and category, and shall specify the start and end date/time.

    • FRU-1.1.2. Users shall be able to upload one or more images for the event and display them on the event page.

      • FRU-1.1.2.1. (Nice-to-have) Users may create online meeting-type events.

    • FRU-1.1.3. Users shall be able to edit events they have created.

      • FRU-1.1.3.1. Only the event host (creator) shall be able to delete their event, and deletion shall not be permitted without cancelling or ending the event.

      • FRU-1.1.3.2. The system shall support two modification outcomes for host-initiated changes: (a) the event is updated (edited), or (b) the event is cancelled.

        • FRU-1.1.3.2.1. Note: Define and document concrete edit/cancellation scenarios (rules) based on customer meeting notes.

    • FRU-1.1.4. Users shall be able to set the event’s visibility as public or private.

      • FRU-1.1.4.1. Private events shall be visible to all users in browse/search results (map/list), but their event detail content shall not be accessible to non-host users.

    • FRU-1.1.5. Users shall be able to classify the event by selecting an event type from a predefined catalog.

      • FRU-1.1.5.1. If no suitable catalog option exists, users shall be able to create a new catalog/type entry (subject to moderation/approval rules, if applicable).

    • FRU-1.1.6. Users shall be able to specify the event location.

      • FRU-1.1.6.1. Users shall be able to specify multiple locations as an ordered route/path (for events that take place across multiple points).

    • FRU-1.1.7. Users shall be able to mark an event as 18+ (age-restricted).

    • FRU-1.1.8. Users shall be able to set an optional attendee limit (capacity).

FRU-2. Event Discovery (Map/List)

  • FRU-2.1. Users shall be able to browse and discover events via a map view and a list view.

    • FRU-2.1.1. Users shall be able to filter events by criteria including catalog/type, distance, and time/date.

    • FRU- 2.1.1.1. (Nice-to-have) Users shall be able to view events near a selected location on the map, preferably using GPS if available and permitted.

    • FRU-2.1.2. Users shall be able to select a specific time and search for events starting after that time.

FRU-3. Event Page Interaction (Registered Users)

  • FRU-3.1. Registered users shall be able to view an event details page for public events.

    • FRU-3.1.1. Users shall be able to bookmark events to view later and to receive relevant notifications/updates.

    • FRU-3.1.2. Users shall be able to interact with other users on the event page.

      • FRU-3.1.2.1. Users shall be able to comment under an event.
      • FRU-3.1.2.2. (Nice-to-have) Users shall be able to use peer-to-peer messaging between users.

    • FRU-3.1.3. Users shall be able to rate the event host.

FRU-4. Access Control (Unregistered Users)

  • FRU-4.1. Unregistered users shall not be able to view event detail pages for any events (public or private).
  • FRU-4.2. Unregistered users shall only be able to browse events via map/list with limited information.
  • FRU-4.3. Private events shall be visible to all users in browse/search results, but full details shall not be visible to non-host users.

FRU-5. Host Profiles

  • FRU-5.1. Users shall be able to view host profile pages, including:

    • FRU-5.1.1. contact information (as permitted by the host’s privacy settings),
    • FRU-5.1.2. hosted events (past and upcoming), and
    • FRU-5.1.3. host ratings.

FRU-6. Notifications

  • FRU-6.1. Users shall receive notifications when an event is updated or deleted, particularly for events they have bookmarked or otherwise follow.

    • FRU-6.1.1. Notifications shall always be sent when an event is edited (updated) or cancelled.

System Requirements (FRS)

FRS-1. Authentication and Roles

  • FRS-1.1. The system shall support guest access without requiring account creation.

  • FRS-1.2. The system shall allow users to register, sign in, and sign out of the platform.

    • FRS-1.2.1. The system shall require users to be authenticated to publish events.
    • FRS-1.2.2. The system shall require users to be authenticated to edit or cancel their events.
    • FRS-1.2.3. The system shall require users to be authenticated to comment on events.
    • FRS-1.2.4. The system shall require users to be authenticated to bookmark events.
    • FRS-1.2.5. The system shall require users to be authenticated to mark events as going.
    • FRS-1.2.6. The system shall associate all authenticated actions with the corresponding user account.

  • FRS-1.3. The system shall support the roles of guest, registered user (publisher), and admin, and enforce permissions accordingly.

FRS-2. Event Lifecycle and Validation

  • FRS-2.1. The system shall validate event data before publishing.

    • FRS-2.1.1. The system shall require the following fields before publishing: title, description, category, start time, end time or duration, location name, location coordinates, and at least one image.
    • FRS-2.1.2. The system shall validate that the event end time is later than the start time.
    • FRS-2.1.3. The system shall prevent publishing if mandatory fields are missing or invalid.

  • FRS-2.2. The system shall manage event lifecycle states.

    • FRS-2.2.1. The system shall support the states draft, published, updated, cancelled, ended.
    • FRS-2.2.2. The system shall automatically mark events as ended once their end time has passed.

  • FRS-2.3. The system shall regulate editing and cancellation behavior.

    • FRS-2.3.1. The system shall allow hosts to edit event details before the event starts.
    • FRS-2.3.2. The system shall prevent modification of event time and location after the event has started.
    • FRS-2.3.3. When an event is cancelled, the system shall remove it from discovery results.
    • FRS-2.3.4. When an event is cancelled, the system shall keep the event page accessible with a visible cancellation label.

  • FRS-2.4. The system shall prevent duplicate event creation by the same host when title, time, and location are identical.

  • FRS-2.5. The system shall support optional venue metadata.

    • FRS-2.5.1. The system shall allow hosts to optionally specify additional venue metadata including price (free/paid), language, health requirements, and age restriction.
    • FRS-2.5.2. The system shall allow hosts to optionally specify accessibility features such as wheelchair access, accessible restroom, elevator availability, seating availability, captions/sign language support, and quiet-friendly environment.

  • FRS-2.6. The system shall manage event categories.

    • FRS-2.6.1. The system shall provide a predefined catalog of event categories.

    • FRS-2.6.2. The system shall require hosts to assign at least one category to an event when publishing.

      • FRS-2.6.2.1. The assigned category shall be either selected from the predefined catalog or created as a custom category.

    • FRS-2.6.3. The system may allow hosts to create a new custom category if no suitable predefined category exists.

      • FRS-2.6.3.1. Custom categories may be subject to moderation or approval rules.

FRS-3. Event Visibility and Access Control

  • FRS-3.1. The system shall support public and private visibility modes.

    • FRS-3.1.1. Private events shall appear in discovery results with limited preview information.
    • FRS-3.1.2. The system shall restrict full private event details to the host.
    • FRS-3.1.3. The system shall enforce private event access control at the backend level.

  • FRS-3.2. The system shall clearly label events marked as 18+ and may restrict interaction for underage users.

FRS-4. Discovery and Search Behavior

  • FRS-4.1. The system shall provide both map and list views for event discovery.

    • FRS-4.1.1. The system shall allow users to switch between map and list views.

  • FRS-4.2. The system shall prioritize and sort discovery results.

    • FRS-4.2.1. The system shall prioritize events based on proximity in time and distance.
    • FRS-4.2.2. The system shall support sorting events by distance, start time, and category.
    • FRS-4.2.3. The system shall limit the number of discovery results displayed at one time and prioritize top-ranked events.

  • FRS-4.3. The system shall support filtering.

    • FRS-4.3.1. The system shall support filtering by a custom start–end time window.
    • FRS-4.3.2. The system shall provide quick filters such as “Now,” “Today,” and “Weekend.”
    • FRS-4.3.3. The system shall allow filtering based on accessibility features when provided.

  • FRS-4.4. The system shall handle user location preferences.

    • FRS-4.4.1. The system shall use GPS-based location when permitted.
    • FRS-4.4.2. If GPS is not permitted, the system shall display a predefined default area.
    • FRS-4.4.3. The system shall allow authenticated users to change the default map area.
    • FRS-4.4.4. The system shall remember the preferred default map area for future sessions.

FRS-5. Bookmarking and Attendance Intent

FRS-5.1. The system shall allow registered users to bookmark an event for later viewing and notifications.

FRS-5.2. The system shall allow registered users to mark an event as Going.

  • FRS-5.2.1. The system shall allow hosts to define an optional attendee capacity limit.
  • FRS-5.2.2. The system shall prevent additional users from marking the event as Going once the capacity limit is reached.
  • FRS-5.2.3. The system shall display the event as full or sold out when capacity is reached.

FRS-5.3. The system shall allow users to remove their Bookmark or Going status at any time.

FRS-6. Social Interaction and Host Profiles

  • FRS-6.1. The system shall allow registered users to comment on events.

  • FRS-6.2. The system shall display comments publicly on the event page.

  • FRS-6.3. The system shall provide host profile pages.

    • FRS-6.3.1. Host profiles shall display hosted events.
    • FRS-6.3.2. Host profiles shall display ratings.
    • FRS-6.3.3. Host profiles shall display contact information according to privacy settings.

  • FRS-6.4. The system shall maintain separate rating representations for hosts and regular users.

FRS-7. Notifications

  • FRS-7.1. The system shall notify users when events they bookmarked or marked as going are updated.
  • FRS-7.2. The system shall notify users immediately when such events are cancelled.
  • FRS-7.3. The system shall deliver notifications through in-app messaging at minimum.

FRS-8. Multi-Location and Equipment

  • FRS-8.1. The system shall allow hosts to define multiple locations for an event.

    • FRS-8.1.1. The system shall require one location to be designated as the primary location for discovery purposes.

  • FRS-8.2. The system shall allow hosts to define an ordered itinerary consisting of time-based segments.

  • FRS-8.3. The system shall allow hosts to specify required and optional equipment or materials.

    • FRS-8.3.1. The system shall display equipment requirements on the event details page.

FRS-9. Reporting and Abuse Control

  • FRS-9.1. The system shall allow users to report events.
  • FRS-9.2. The system shall allow users to report host profiles.
  • FRS-9.3. The system shall enforce configurable rate limits on event creation per user.

FRS-10. Past Events and Archiving

  • FRS-10.1. The system shall retain past events and mark them as ended once their end time has passed.
  • FRS-10.2. The system shall allow users to view past events on event detail pages and host profile pages.
  • FRS-10.3. The system shall exclude past events from default discovery results unless explicitly filtered by the user.

Non-Functional Requirements (NFR)

Performance

  • NFR-01. Search response time: The system shall return event search results (distance + time window + category filters) within 2 seconds for a typical query.
  • NFR-02. Update/cancellation visibility time: Event updates and cancellations shall appear in map/list search results within 60 seconds.

Security

  • NFR-03. HTTPS only: The system shall use HTTPS for all client-server communication.
  • NFR-04. Private event protection (backend enforced): The backend shall not return private event details to unauthorised users, even via direct API calls.

Reliability

  • NFR-05. Low server error rate: The system shall keep unexpected server errors (HTTP 5xx) below 1% of requests in normal usage.

Scalability

  • NFR-06. Dataset size support: The system shall support at least 10,000 events in the database while still meeting NFR-01 (2-second search).

Observability

  • NFR-07. Minimal logging: The backend shall log errors and key event actions (publish, update, cancel) with timestamp and event ID.

Usability

  • NFR-08. Mobile-friendly UI: Core pages (map/list discovery, event details, create event) shall work on mobile screen widths without broken layout or horizontal scrolling.

Privacy

  • NFR-09. Location data minimization: The system shall not store precise user GPS coordinates permanently; location is used only for search and is not saved in the database.