# TECHNICAL REQUIREMENTS DOCUMENT

## Vision statement

Pierre is a platform that connects club owners/managers to end-users, which allows users to buy tickets to clubs and discos.

## Project charter

Pierre is composed of:
- a management front-end (MFE), where authenticated users can manage SERATE and review bookings
- a multi-platform application (APP) that allows the user to book a table or buy a TICKET for a SERATA
- a back-end server which hold the database, serves the MFE and communicates with both the MFE and the APP
- a bouncer service that allows users to scan TICKETS' QR code and allow or refuse entry to the holder. The choice will be saved, and considered for granting refunds. Implementation will be chosen later.

## Software requirements

### APP

### Unauthenticated features (U)
1. Visualization of the various SERATE. _Necessary_ info (_additional_ info may be included):
1. Name
2. Location/Time
3. Dress code
4. Map of location

### Authenticated features (A)

1. Register, login; relevant info:
1. Privacy terms visualization and accept button. For each user we will need to collect **(What's the legal status?)**:
1. Anagraphical info: **(Which info is necessary (business needs)?)**
1. First-last name
2. Date of birth
3. Address
2. Picture (Optional) how about (if business required????)
3. Contact details of buyer
1. Email
2. Phone number
2. Buying TICKETS:
1. TABLE tickets (tickets which allow access to multiple people) include the number of people they grant access to. **(Do we need to collect their names or other info?)**
3. View purchase history, including QR Code for tickets as proof of purchase
4. Asking for refunds on SERATE **(Refund policy must be clearly outlined in FAQ somewhere, so write it.)**

### MFE
The management front-end must allow its users to:
1. Authenticate: no operations are allowed for unauthorized users.
2. Create a new SERATA, \*editing its:
1. Name of serata
2. Date
3. Location/Time
4. Image
5. Description
6. Dress code
7. Music genre
8. Map of location
9. For each type of TICKET created:
1. Cost
2. Total availability
3. Number of people it can sit
4. Title
5. Description
3. View and edit existing SERATE.
4. For every SERATA, view its current BOOKINGS (TICKETS sold). Every BOOKING comes with:
1. Anagraphical details of buyer **(Which info is necessary (business needs)?)**
1. First-last name
2. Date of birth
3. Address
2. Contact details of buyer
1. Email
2. Phone number
3. When the BOOKING was bought

\*while editing, tickets cannot be bought

### Business Needs
- We need proof of access in order to issue refunds only in case the USER showed up to the SERATA and there were issues such that the USER could not access; Therefore MFE needs to be able to check the ticket of the USER, in that case we can issue refund. Refunds policy should be clearly outlined in the FAQ, available in-app.
- Is **Adyen** a viable payment provider?
- Tickets less expensive than 50€ (_in-app payment threshold_, may be subject to change) will be paid entirely via APP. Tickets more expensive than the _in-app payment threshold_ allow the user to be paid in part online, 10% (_in-app payment percentage_, may be subject to change), and in part at the entrance. **their request is to pay the total via app. we need to check if this is fine with the payment provider**

## Release plan (determine the schedule of the project duration)
1. Release schedule:
1. End of 2022: Basic features, general outline is final but needs tuning of major components
2. March 2023: additional features.