Use Case Diagram for Scenario 3

Ambiguities & Assumptions

The bullet points below summarize potential ambiguities / implicit assumptions in the Scenario #3 use case diagram:

• Registration and login are considered out of scope: The pre-condition states that the organization account is already registered and logged in via phone verification. Therefore, the diagram does not model the registration flow and assumes authentication has already been completed.

• Organization account is modeled as a generic “Host” actor: The diagram uses a single Host actor. This assumes there is no behavioral distinction between an individual user and an organization account at the use case level.

• Mandatory field highlighting is not modeled explicitly: The system “highlights mandatory fields” when displaying the creation form. This UI feedback behavior is assumed to be internal system logic and not represented as a separate use case.

• Route-based location is abstracted under “Create Route”: The scenario explicitly defines:

  • Starting point
  • Ending point
  • Optional waypoints

  The diagram models this under Create Route and Select Route Point Coordinates, assuming:

  • Waypoints are optional.
  • The system supports multi-point route storage.
  • Coordinate validation (2.2.2) is handled internally before Save Route.

• Route preview is implicitly handled before saving: The scenario states that the system previews the route before storing it. The diagram represents this behavior implicitly inside Save Route rather than modeling a separate Preview Route use case.

• Time validation logic is internal to “Set Time Interval”: Requirements 2.3.1 and 2.3.2 enforce:

  • Both start and end timestamps must exist.
  • End time cannot be earlier than start time.

  The diagram does not show a separate validation use case. It assumes validation occurs automatically before Save Event.

• Public visibility path only is considered: The scenario explicitly sets visibility to Public. The diagram includes Set Visibility but does not restrict it to Public. It assumes the same creation UI supports all three privacy types (Public, Protected, Private).

• Notification behavior is not modeled: The scenario mentions that users with favorite locations may receive notifications. The diagram does not include a Send Notification use case, assuming:

  • Notification triggering is a system-side process.
  • Delivery channels (push, in-app, email) are handled outside the event creation flow.

• Tag limits are not enforced in the diagram: Requirement 2.5.1 allows up to N custom tags. The diagram includes Add Tags but does not model:

  • The maximum tag count.
  • Validation or error handling if the limit is exceeded.

• Event versioning and atomicity are not explicitly shown: Requirement 10.1.1 requires atomic versioning. The diagram assumes this occurs internally during Save Event.

• Post-event lifecycle is not included: The following behaviors are not modeled:

  • Automatic move to “Past” after end time (8.1.1)
  • Archived searchability (8.2.1)
  • Participant/favorite count display (6.2.1)

  These are considered system lifecycle behaviors rather than part of the creation use case.

• No alternate or error flows are shown: The diagram represents only the happy path. It does not model:

  • Invalid coordinates
  • Missing mandatory fields
  • Invalid time interval
  • Image upload failure
  • Save/transaction failure

Note: The diagram communicates the main public route-based event creation flow, while validation, notification, lifecycle management, and versioning behaviors are treated as internal system responsibilities and therefore remain implicit.