Assumptions - CMPUT301F24syzygy/syzygy-events GitHub Wiki

Assumptions made on ambiguous user stories to be clarified by final submission

General

Notifications

  • Assumed that notifications are in-app and notifications are not actually pushed to the user's phone

Events and entrants

  • When an entrant is attached to the event, they are one and exactly one of the following statuses
    • Waitlist (They are currently on the waitlist)
    • Invited (They were selected by the lottery and have received an invitation, they have not accepted nor declined the invitation)
    • Enrolled (They accepted the invitation)
    • Cancelled (They were removed from the event by the organizer or they declined the invitation)
    • Not attached (They were in the waitlist and left (removed themselves) without ever receiving an invitation or they never joined the waitlist)
  • Assumed that an entrant should be able to join the waitlist again after being removed by the organizer if they were removed before registration closes

Map of statuses and movement between

[            ] <----------------------decline--- [       ]
[Not Attached] --join--> [Waitlist] --lottery--> [Invited] --accept--> [Enrolled]      [Cancelled]
[            ] <-leave-- [        ]              [       ] --remove------------------> [         ]
                         [        ] -------------------------remove------------------> [         ]
                         [        ] <-------------------------join-------------------- [         ]

Notes

  • the join can only happen before the registration closes
  • lottery only applies if the user was sampled
  • lottery can only happen after the registration closes
  • remove is when the organizer removes the user
  • leave is when the entrant leaves the waitlist themselves

From scenarios

1

  • Assumed events must have an open registration and closed registration date (based on scenarios)
  • Assumed that a new spot is not open if a user does not action an invitation (thus an invited user who has not accepted nor declined takes up one of the available spots)
  • Assumed events must be associated to a facility

2

  • Assumed that events must be able to be scheduled with a start date, an end date, and a repetition given by days of the week
  • Assumed that events must be able to be given a price
  • Assumed that the capacity of an event cannot change after creation
  • Assumed that the capacity and price must be displayed to the user
  • Assumed QR code is generated after creation and leads the user to event page (not directly signs up)

3

No additional assumptions made

User Stories

  • Assumes all users are entrants

01.01.01

No assumptions made

01.01.02

  • Assumed that a user can leave the waiting list at any point, including after registration is closed, after the event has started, and after the event has finished but the user may not leave if enrolled or invited (invited they can just decline which would be the same as leaving)

01.02.01

No assumptions made

01.02.02

No assumptions made

01.03.01

No assumptions made

01.03.02

No assumptions made

01.03.03

  • Assumed this also applies to after a profile picture is removed
  • Implemented this is generated on account creation not before

01.04.01

No assumptions

01.04.02

No assumptions

01.04.03

  • Assumed opting out of organizer notifications applies uniquely to notifications manually created by the organizer and not automatic notifications created by the running the lottery
  • Assumed opting out of admin notifications is non-applicable as there are no admin notifications

01.05.01

  • Assumed the user is counted as remaining as [Waitlist] after losing the lottery

01.05.02

No assumptions made

01.05.03

  • Assumed the user is removed from [Waitlist] and is no longer attached to the event upon declining the invitation

01.06.01

No assumptions made

01.06.02

  • Assumed the QR code does not automatically sign the user up, but brings them to a page where the user can do that
  • Assumed "sign up" refers to joining the [Waitlist] or becoming [Enrolled] if currently [Invited] to the event

01.07.01

  • Assumed the device id is the only unique identifier - the user cannot access the account from any other device

01.08.01

No assumptions made

Organization Stories

Implementation

  • An organizer must first have a basic user account (and is thus an entrant)
  • Assumed all users can become organizers
  • Assumed being an organizer is defined by having a facility

02.01.01

  • Assumed the QR only needs to be recognized by the in-app QR scan
  • Assumed that a facility must exist for the event
  • Assumed that an event is attached to a facility

02.01.02

  • Assumed that being able to copy the hash to clipboard fulfils this requirement

02.01.03

  • Creating a facility makes the user an organizer
  • Assumed that two users cannot have the same facility
  • Assumed that any user can only create one facility
  • Assumed that "manage" refers to editing the profile and managing events under the facility

02.02.01

  • Assumed that "joined my event waitlist" only refers to [Waitlist], [Invited], [Enrolled], [Cancelled] (not entrants who joined and then left the waitlist)

02.02.02

  • Assumed that "joined my event waitlist" only refers to [Waitlist], [Invited], [Enrolled], [Cancelled]
  • Assumed that the organizer being able to view a map of where any individual user joined from is sufficient
  • Assumed that this map should not be visible if the event does not require geolocation
  • Assumed that a location is not stored for each user if requires geolocation is false

02.02.03

  • Assumed this can only happen on creation and is not modifiable

02.03.01

  • Assumed that this is a limit to the number of users in [Waitlist]. Thus, if the limit is 1, and the user in [Waitlist] becomes a different status, another user can join the [Waitlist]. (Instead of to the total number of users that ever joined the waitlist)

02.04.01

  • Assumed this is a photo
  • Assumed this is optional

02.04.02

No assumptions made

02.05.01

  • Assumed this is automatic upon triggering the lottery

02.05.02

  • Implemented the organizer sets a "capacity" (the number of users to be sampled) upon creation
  • Assumed the capacity should not be modifiable after creation
  • Assumed the triggering of the lottery should be manual
  • Assumed the lottery can be triggered even after the event starts and ends
  • Assumed the lottery only samples from users currently in [Waitlist].

02.05.03

  • Assumed the drawing is triggered manually by the organizer
  • Assumed the drawing choose a user from the [Waitlist] randomly
  • Assumed the user who declines the invitation is not counted as part of the waitlist
  • Assumed "cancel" refers to declining the invitation.

02.06.01

  • Assumed that "invited" is any user that currently has an invitation that they have not declined or accepted ([Invited])

02.06.02

  • Assumed that "cancelled" is any user who was removed from the event by the organizer ([Canceled])

02.06.03

  • Assumed that "enrolled" is any user that has accepted an invitation ([Enrolled])
  • Assumed that "final" means that a user cannot leave the event after accepting the invitation
  • Assumed that the list can be updated if more users are sampled after invitations are declined

02.06.04

  • Assumed that "cancel" means removed (-->[Cancelled])
  • Assumed that the organizer can remove any users that is currently in the waitlist or has received an invitation but has not accepted/declined
  • Assumed that a user can not accept/decline an invitation after being removed
  • Assumed that "sign up" means [Enrolled] (accepted an invitation)

02.07.01

N/A

02.07.02

N/A

02.07.03

N/A

Admin Stories

03.01.01

N/A

03.02.01

N/A

03.03.01

N/A

03.03.02

N/A

03.04.01

N/A

03.05.01

N/A

03.06.01

N/A

03.07.01

N/A