Scenario 1 ‐ Discovering and Joining an Event - bounswe/bounswe2026group11 GitHub Wiki

🎭 Scenario 1

Name: Elif Kaya
Age: 24
Occupation: Graduate Student
Location: Istanbul
Technical Proficiency: Comfortable with mobile applications and map-based interfaces

Behavioral Traits:

Elif regularly uses the Social Event Mapper's mobile app to discover weekend activities near her home in Kadıköy.

Elif wants to:

Elif has already completed phone-based registration and authentication (1.1.1, 1.1.2, 11.1.2)
She has defined Kadıköy as a favorite location for personalized discovery (5.6.1)
The system is fully operational and accessible
Event discovery queries perform within acceptable latency (9.1.1, 9.1.2)

Elif logs into the system using phone verification.
- Requirement references: 1.1.1, 1.1.2, 1.1.3, 11.1.2
After successful authentication, she is redirected to the main discovery interface displaying:
- Interactive Map View
- Alternative List View
- Active filtering panel
- Requirement reference: 5.1.1, 5.4.1

Elif sets the following filters:
- Distance: 5 km radius around Kadıköy (5.2.1)
- Time: Upcoming weekend (Friday–Sunday interval) (5.3.1)
- Category: Cycling (2.4.2, 5.4.1)
The system performs geospatial and time-based queries within acceptable response time.
- Requirement reference: 9.1.1, 9.1.2
Results appear prioritized on the map using internal priority logic.
- Requirement reference: 5.7.1
Elif decides to look at the list view to further display event details of the listed events on the map, then one event stands out:
- Route-based cycling event along the Bosphorus (2.2.1)
- Start–end time interval clearly displayed (2.3.1)
- Custom tags such as #morningride and #bosphorus (2.5.1)
- Organizer reliability metric visible (6.4.1, 6.4.2)
- Number of participants and number of saves displayed (6.2.1)

Elif is able to view the filtered events on the map but clicks to the desired event using the list view.
The event detail page opens and displays:
- Route visualized on map (2.2.1)
- Time interval with start and end timestamps (2.3.1)
- Category and tags (2.4.1, 2.5.1)
- Host information (2.1.2)
- Participant count and save count (6.2.1)
- Organizer reliability metric (6.4.1)
The event is labeled as Protected visibility.
- Requirement references: 3.1.1, 3.3.2
- Some detailed participant information is hidden from non-approved users.

Elif clicks the “Request to Join” button.
The system records her join request with a “Pending” status.
- Requirement reference: 3.2.2
The organizer receives a real-time notification about the new request.
- Requirement reference: 7.3.1
The organizer approves Elif’s request.
- Requirement reference: 3.2.3
Elif receives a notification that her request has been approved.
- Requirement reference: 7.3.2
The event is automatically added to her participation history.
- Requirement reference: 1.3.1
Access to full event details is now granted due to authorized status.
- Requirement references: 3.3.1, 11.2.1

The cycling event takes place successfully.
After completion:
- Event status changes to “Completed”
- Event moves to the archive (8.1.1)
- Event remains searchable in system history (8.2.1)
- Historical data is retained for analytics and recommendation models (8.3.1)
Elif leaves feedback and rates the organizer.
- Requirement references: 6.3.1, 6.3.2, 6.4.1

This scenario satisfies the following requirements from the Functional and Non-Functional Requirements: