Scenario 1 ‐ Discovering and Joining an Event
- Name: Elif Kaya
- Age: 24
- Occupation: Graduate Student
- Location: Istanbul
- Technical Proficiency: Comfortable with mobile applications and map-based interfaces
Behavioral Traits:
- Actively searches for outdoor and social activities
- Prefers well-organized events with reliable hosts
- Values privacy and controlled participation environments
Elif regularly uses the Social Event Mapper's mobile app to discover weekend activities near her home in Kadıköy.
Elif wants to:
- Discover nearby cycling events happening this weekend
- Filter events by category, distance, and time window
- Join a protected cycling event that requires organizer approval
- Save the event for later reference
- 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:
- 1.1.1, 1.1.2, 1.1.3
- 1.3.1
- 2.2.1, 2.3.1, 2.4.1, 2.4.2, 2.5.1
- 3.1.1, 3.2.2, 3.2.3, 3.3.1, 3.3.2
- 5.1.1, 5.2.1, 5.3.1, 5.4.1, 5.6.1, 5.7.1
- 6.2.1, 6.3.1, 6.3.2, 6.4.1, 6.4.2
- 7.3.1, 7.3.2
- 8.1.1, 8.2.1, 8.3.1
- 9.1.1, 9.1.2
- 11.1.2, 11.2.1
