Examenprojecten

• Overview project 1 t/m 12
• Project 1 - StagePortaal
• Project 2 - ServiceDesk Portaal
• Project 3 - Fleet Management Portaal
• Project 4 - Voorraad & Defecten Beheer
• Project 5 - Tournooi Planner
• Project 6 - Real-time Feedback Systeem
• Project 7 - Bibliotheek Beheersysteem
• Project 8 - Bezichtigingsbeheer
• Project 9 - Voorraad- en Distributiebeheer
• Project 10 - E-sports Arena
• Project 11 - Sneaker Marketplace
• Project 12 - Studie-Portaal
• Project 13 - GoalGetter
• Project 14 - CoachVision
• Project 15 - MatchUp
• Project 16 - EuroMatch
• Project 17 - ReWear
• Project 18 - StyleCycle
• Project 19 - MediaMeter
• Project 20 - TrendWatch

Overview project 1 t/m 12

StagePortaal (TalentMatch)

TalentMatch verbindt lokale MBO-studenten met leerbedrijven door stagevacatures overzichtelijk en AVG-proof aan te bieden. Bedrijven beheren hun eigen vacatures en reacties, terwijl studenten via een persoonlijk dashboard direct kunnen solliciteren. De opdracht focust op een zakelijke uitstraling met specifieke visuele eisen zoals een sidebar-navigatie en interactieve vacature-kaarten.

ServiceDesk Portaal (FixIT)

FixIT is een ticketingsysteem waarmee medewerkers van een logistiek centrum technische storingen eenvoudig kunnen melden bij de IT-afdeling. IT-beheerders krijgen een centraal overzicht om meldingen te prioriteren, te bewerken en van oplossingen te voorzien. De technische uitdaging ligt in het bouwen van een veilige administratie-omgeving met handige filters die werken via URL-parameters.

Fleet Management Portaal (DriveSafe)

DriveSafe wordt gebruikt door chauffeurs om defecten aan voertuigen direct via hun telefoon of tablet door te geven aan de werkplaats. Monteurs beheren de reparaties en prioriteren meldingen op basis van de urgentie voor de verkeersveiligheid. Het project vereist een industriële interface die geoptimaliseerd is voor touchscreens en sterke gegevensvalidatie voor kentekens en kilometerstanden.

Voorraad & Defecten Beheer (StockCheck)

StockCheck is een meldingsportaal voor eventlocaties waarmee vloerpersoneel defecte apparatuur of lage voorraden direct kan rapporteren aan de technische dienst en inkoop. Het ontwerp volgt een "Mobile First" gedachte met een zwevende navigatiebalk voor optimaal gebruiksgemak tijdens het werk. De kern van de opdracht is het correct koppelen van specifieke zalen en locaties aan de binnengekomen meldingen.

Toernooi Planner (MatchPoint)

MatchPoint vervangt handmatige papieren schema's door een digitaal platform waar tennisspelers hun wedstrijden en actuele poulestanden kunnen volgen. De wedstrijdleiding voert uitslagen in, wijst banen toe en bewaakt de voortgang van het toernooi. Technisch is dit project uitdagend vanwege de complexe SQL-logica die nodig is om ranglijsten te berekenen op basis van gewonnen sets.

Real-time Feedback Systeem (PulseCheck)

PulseCheck verzamelt korte klantbeoordelingen via QR-codes op de winkelvloer om de prestaties van filialen direct in kaart te brengen. Klanten vullen anoniem hun score en toelichting in, waarna bedrijfsleiders de resultaten per locatie analyseren in een afgeschermd dashboard. Het project vereist een sterke focus op mobiele gebruikerservaring en beveiliging tegen kwaadaardige tekstinvoer.

Bibliotheek Beheersysteem (BookFlow)

BookFlow laat leerlingen een digitale catalogus doorzoeken en boeken reserveren, terwijl mediabeheerders de uitleningen en innames registreren. Een cruciaal onderdeel is de automatische berekening van inleverdata en het signaleren van boeken die te laat zijn teruggebracht. Je leert hier werken met complexe SQL-joins om gegevens van boeken, leningen en gebruikers in één overzicht te combineren.

Bezichtigingsbeheer (KeyMaster)

KeyMaster wordt gebruikt door makelaars om woningbezichtigingen in te plannen en de status van sleutels en aanvragen efficiënt bij te houden. Klanten kunnen online aanvragen indienen voor woningen en in hun eigen dashboard de status van hun afspraken inzien. De nadruk ligt op privacybescherming van gevoelige gegevens en het werken met specifieke datum-filters in de database.

Voorraad- en Distributiebeheer (Vuller)

Vuller is een portaal voor vrijwilligers van een stichting waarmee zij hun dagelijkse bezorgroutes voor voedselpakketten kunnen inzien en leveringen kunnen afmelden. De logistiek manager wijst adressen toe aan bezorgers en volgt live de voortgang per wijk. Het systeem stroomlijnt het proces door te garanderen dat elke levering aan de juiste vrijwilliger is gekoppeld.

E-sports Arena (Respawn & Conquer)

Respawn & Conquer fungeert als de centrale bron voor online toernooien, waar gamers hun persoonlijke uitslagen en de actuele competitie-ranking kunnen volgen. Toernooi-organisatoren gebruiken de match-maker interface om spelers te koppelen, lobby-codes te delen en winnaars te valideren. De technische diepgang zit in de database-relaties waarbij twee unieke spelers aan één wedstrijdrecord worden gekoppeld.

Sneaker Marketplace (SoleExchange)

SoleExchange biedt leden van de community de mogelijkheid om exclusieve sneakers te koop aan te bieden aan andere verzamelaars en biedingen uit te brengen op beschikbare items. Medewerkers treden op als admins om de echtheid van de schoenen te controleren voordat de verkoop definitief wordt goedgekeurd. Veiligheid is bij dit project essentieel om te voorkomen dat gebruikers onrechtmatig biedingen van anderen aanpassen of verwijderen.

Studie-Portaal (StudyBuddy)

StudyBuddy helpt studenten hun studietijd te organiseren door vakken, taken en cijfers centraal in één overzichtelijk dashboard te beheren. De applicatie berekent automatisch gemiddelden en geeft visuele waarschuwingen wanneer deadlines kritiek worden of cijfers onvoldoende zijn. Dit project is bij uitstek geschikt voor wie zijn vaardigheden in wiskundige backend-logica en database-integriteit wil bewijzen.

 

Complexiteit

P#	Naam (MVP)	Uren (Briefing)	Complexiteit	Kern-uitdaging (W3/Realisatie)
1	StagePortaal (TalentMatch)	40u	Medium	KPI-berekeningen via COUNT() query [11].
2	ServiceDesk Portaal (FixIT)	40-45u	Medium	1-op-N relatie en SQL filtering via GET parameters [12, 19].
3	Fleet Management (DriveSafe)	40-45u	Medium	Inputvalidatie voor kentekens en kilometerstanden [13].
4	Voorraad & Defecten (StockCheck)	40-45u	Medium	Mobile First layout en koppeling van zalen aan meldingen [20, 21].
5	Toernooi Planner (MatchPoint)	40-45u	Hoog	N-op-M relaties en sorteren op complexe poulestanden [6, 15].
6	Feedback Systeem (PulseCheck)	40-45u	Medium/Hoog	Anonieme data-entry en gemiddelde scores berekenen per filiaal [22, 23].
7	Bibliotheek Beheer (BookFlow)	40-45u	Hoog	Datum-logica (vandaag + 28 dagen) en SQL JOINs over 3 tabellen [17].
8	Bezichtigingsbeheer (KeyMaster)	40-45u	Medium/Hoog	SQL datum-functies (CURDATE) en strikte autorisatie-checks [9, 18].
9	Distributiebeheer (Vuller)	40-45u	Medium/Hoog	Live statistieken (% bezorgd) en route-autorisatie [24].
10	E-sports Arena (Respawn)	40-45u	Hoog	Match-tabel met twee verwijzingen naar één player-tabel [25].
11	Sneaker Marketplace (SoleExchange)	40-45u	Hoog	Biedings-systeem (N-op-M) en beveiliging tegen ID-manipulatie [26, 27].
12	Studie-Portaal (StudyBuddy)	40-45u	Medium/Hoog	Wiskundige backend-berekeningen voor gemiddelden [28].

Project 1 - StagePortaal

Projectbriefing: TalentMatch

Datum: 11 december 2025

Opdrachtgever: Ondernemersvereniging "MKB Regio Connect"

Contactpersoon: Dhr. J. van de Velde (Voorzitter)

---

1. Achtergrond en Probleemstelling

Onze ondernemersvereniging vertegenwoordigt 50+ lokale bedrijven. Wij merken dat de aansluiting tussen lokale MBO-studenten en onze leerbedrijven stroef verloopt. Bedrijven zoeken stagiairs, maar bereiken de scholen lastig. Studenten weten vaak niet welke leuke bedrijven er in de buurt zitten.

Momenteel houden we vacatures bij in een Excel-sheet en worden CV’s via e-mail heen en weer gestuurd. Dit is onoverzichtelijk, foutgevoelig en voldoet niet aan de privacywetgeving (AVG).

2. Doelstelling

Wij zoeken een webontwikkelaar die voor ons een Minimum Viable Product (MVP) kan bouwen van een online stageplatform: "TalentMatch".

Het doel is een webapplicatie waar bedrijven zelf hun vacatures kunnen plaatsen en beheren, en waar studenten eenvoudig kunnen reageren. Het systeem moet laagdrempelig, overzichtelijk en veilig zijn.

3. Doelgroepen

1. Studenten: Willen zoeken naar stages en direct reageren zonder gedoe.

2. Bedrijven: Willen vacatures plaatsen, aanpassen en zien wie er gereageerd heeft.

4. Gewenste Functionaliteiten (Must-Haves)

Wij verwachten in de eerste versie (MVP) minimaal de volgende functies:

• Registratie & Login:

  • Gescheiden accounts voor 'Studenten' en 'Bedrijven'.

  • Veilige inlog (wachtwoorden mogen niet leesbaar zijn voor beheerders).

• Voor Bedrijven:

  • Een eigen dashboard na inloggen.

  • Mogelijkheid om een nieuwe stagevacature toe te voegen (Titel, Omschrijving, Periode, Eisen).

  • Mogelijkheid om eigen vacatures aan te passen of te verwijderen (CRUD).

  • Inzicht in wie er op hun vacatures gereageerd heeft.

• Voor Studenten:

  • Een overzichtspagina van alle actuele vacatures.

  • Een detailpagina per vacature met alle informatie.

  • Een knop/formulier om direct te reageren (solliciteren) op een vacature.

  • Een overzicht in hun eigen dashboard waarop ze hebben gereageerd en wat de status is.

• Algemeen:

  • Het platform moet werken op desktop en mobiel (Responsive).

5. Technische Eisen & Randvoorwaarden

Omdat wij werken met beperkte budgetten voor hosting, hebben wij de volgende technische voorkeuren:

• Taal: PHP (versie 8+).

• Database: MySQL / MariaDB.

• Design: Mag gebruik maken van standaard CSS of een licht framework, maar moet wel een eigen 'look & feel' hebben die past bij een zakelijke markt (zie bijlage).

• Beveiliging: Gezien we met persoonsgegevens werken (namen, e-mailadressen), is beveiliging tegen SQL-injectie en sessie-hijacking cruciaal.

• Privacy: Het systeem moet 'AVG-proof' ontworpen worden (geen onnodige data opslaan).

6. Budget en Planning

Wij begrijpen dat softwareontwikkeling tijd kost. Echter, wij willen graag snel live met een eerste versie.

• Beschikbaar budget: Wij gaan uit van circa 40 uur ontwikkeltijd voor deze eerste versie.

• Deadline: Wij ontvangen graag een oplevering binnen 6 weken na goedkeuring van de offerte.

7. Gevraagde actie

Graag ontvangen wij van u:

1. Een Plan van Aanpak (inclusief functioneel ontwerp/schetsen).

2. Een Ureninschatting per onderdeel.

3. Een Offerte voor de realisatie van dit MVP.

---

BIJLAGE: Specifieke Design & Interface Wensen

Let op: Deze wensen zijn cruciaal voor de acceptatie van het eindproduct.

Onze marketingafdeling heeft net een nieuwe huisstijl ontwikkeld. Wij accepteren geen standaard "Bootstrap-blauw" of grijze templates. Het ontwerp moet voldoen aan de volgende specifieke visuele eisen:

1. Verplicht Kleurenpalet: De applicatie moet gebruikmaken van onze specifieke huisstijlkleuren. Gebruik CSS-variabelen (:root) om dit consistent toe te passen:

   • Primaire Actiekleur (Knoppen/Links): #E63946 (Koraalrood).

   • Hoofdkleur (Headers/Navigatie): #1D3557 (Diep Oceaanblauw).

   • Achtergrond Dashboards: #F1FAEE (Off-white/Mint).

   • Status Meldingen:

     • Succes/Open: #2A9D8F (Groen).

     • Error/Gesloten: #E63946 (Rood).

2. Dashboard Layout (Sidebar Navigatie): Voor het ingelogde gedeelte (Bedrijf & Student) willen wij geen navigatiebalk bovenin de pagina.

   • Wij willen een verticale sidebar aan de linkerkant van het scherm die altijd zichtbaar blijft.

   • In deze sidebar staat het logo, de menu-items onder elkaar, en onderaan de "Uitloggen" knop.

3. De "Vacature-Kaart": Op de overzichtspagina voor studenten willen wij de vacatures niet onder elkaar in een simpele tabel zien.

   • Toon vacatures als "Cards" (Tegels) in een grid van 2 of 3 naast elkaar (op desktop).

   • Elke kaart moet een "Status Badge" in de rechterbovenhoek hebben (bijv: "Nieuw" = Groen).

4. Interactieve Feedback:

   • Alle knoppen moeten een duidelijke :hover state hebben.

   • Na verzending van een formulier moet er een gekleurde notificatiebalk verschijnen (Feedback aan de gebruiker).

5. De "Welkom" Widget: Op het dashboard van het bedrijf willen wij bovenaan direct drie grote cijfers zien (KPI's):

   1. Totaal aantal vacatures.

   2. Aantal openstaande sollicitaties.

   3. Datum van laatste login.

---

Tips voor jouw Examenportfolio

Dit document kun je direct gebruiken om je examen-criteria af te vinken:

1. W1 (Klantvraag & Planning):

   • De briefing bevat je Functionele Eisen (wat moet het doen?) en Niet-functionele eisen (AVG/Design). Noteer deze letterlijk in je PvA.

   • De klant noemt een budget van 40 uur. Maak een planning die hierop uitkomt (bijv. 10 uur database, 10 uur login, 20 uur CRUD/Design).

2. W2 (Ontwerp):

   • Teken je wireframes exact zoals de klant vraagt: met een Sidebar en Cards. Als je dit niet doet, voldoe je niet aan de "Specificaties van de klant".

3. W3 (Realisatie):

   • Let op de "KPI Widget" (Eis 5 in de bijlage). Dit dwingt je om een COUNT() query te schrijven. Dit is een uitstekend bewijs van SQL-kennis voor de examencommissie.

4. Verantwoording:

   • Als je bij het CGI-gesprek de vraag krijgt: "Waarom heb je deze kleuren gekozen?", is het antwoord: "Dit was een harde eis uit de briefing van de opdrachtgever."

Project 2 - ServiceDesk Portaal

Projectbriefing

Projectnaam: ServiceDesk Portaal "FixIT"

Datum: 11 december 2025

Opdrachtgever: Logistiek Centrum "De Haven"

Contactpersoon: Mevr. S. Bakker (Hoofd Automatisering)

---

1. Achtergrond en Probleemstelling

Binnen ons logistiek centrum werken 80 medewerkers die dagelijks afhankelijk zijn van scanners, computers en printers. Als er iets stuk gaat, lopen medewerkers nu naar de IT-afdeling of sturen ze een WhatsApp-bericht naar één van de beheerders.

Hierdoor raken meldingen kwijt, weten we niet wat de status is van een reparatie en hebben we geen inzicht in hoeveel storingen er eigenlijk zijn. Dit moet geprofessionaliseerd worden.

2. Doelstelling

Wij willen een web-based ticketingsysteem (FixIT) laten ontwikkelen.

Medewerkers moeten zelf eenvoudig een storing ("Ticket") kunnen aanmaken. De IT-afdeling moet deze tickets centraal kunnen beheren, prioriteren en afmelden.

3. Doelgroepen

1. Medewerkers (Gebruikers): Willen snel melden dat hun PC stuk is en zien wanneer het gemaakt is.

2. IT-Support (Beheerders): Willen een lijst met openstaande taken, gesorteerd op prioriteit.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor alle gebruikers.

  • Rol-verdeling in de database: user (medewerker) en admin (IT-support).

• Voor Medewerkers:

  • Dashboard met overzicht van eigen gemelde tickets.

  • Formulier om een nieuw ticket aan te maken (Onderwerp, Beschrijving, Categorie: Hardware/Software).

  • Zichtbare status van hun ticket (bijv. "In Behandeling" of "Opgelost").

• Voor IT-Support (Admins):

  • Centraal dashboard met alle openstaande tickets van het hele bedrijf.

  • Detailpagina per ticket om deze te bewerken.

  • Mogelijkheid om de Status (Open/Closed) en Prioriteit (Laag/Hoog) aan te passen.

  • Mogelijkheid om een "Admin Opmerking" (oplossing) toe te voegen aan het ticket.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) in combinatie met MySQL.

• Code Architectuur: Gebruik van includes voor header/footer om dubbele code te voorkomen.

• Veiligheid: Alle invoer (forms) moet 'sanitized' worden om XSS te voorkomen. Gebruik Prepared Statements voor SQL.

• Data Integriteit: Een ticket moet altijd gekoppeld zijn aan de gebruiker die het heeft aangemaakt (Relational Database ID).

6. Budget en Planning

• Tijdsinvestering: Wij schatten dit project op circa 40-45 uur ontwikkeling.

• Oplevering: Deadline in overleg, bij voorkeur binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (wat gaat het systeem doen?).

2. Lever een Technische Schets (ERD van de database + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

Omdat het systeem de hele dag open staat op de schermen van IT-support, zijn de visuele eisen strikt. Wij willen een professionele "SaaS" (Software as a Service) uitstraling.

1. Kleurcodering van Prioriteiten (Must-have):

   • In de ticket-lijsten moet de prioriteit direct visueel herkenbaar zijn d.m.v. gekleurde labels ('badges') of randen:

     • Laag: Blauw of Grijs.

     • Normaal: Groen.

     • Hoog / Spoed: Fel Rood (#D32F2F).

2. De "Top-Bar" Navigatie:

   • In tegenstelling tot veel andere systemen, willen wij geen sidebar. Wij willen een strakke, donkere navigatiebalk (Header) over de volledige breedte bovenin.

   • Rechts in deze balk moet de naam van de ingelogde gebruiker staan met een klein profiel-icoon.

3. Ticket Detail Weergave:

   • Wanneer je op een ticket klikt, moet de pagina in twee kolommen verdeeld zijn:

     • Links (70%): De beschrijving van het probleem en de oplossing.

     • Rechts (30%): Een "Infobox" met metadata (Datum aangemaakt, Naam melder, Huidige Status).

   • Toelichting: Dit toont aan dat je met Grid of Flexbox kolommen kunt maken.

4. De "Admin Quick-Filter":

   • Boven de lijst met tickets moeten 3 grote knoppen staan waarmee de admin direct de lijst kan filteren:

     1. "Alles tonen"

     2. "Alleen Spoed"

     3. "Alleen Openstaand"

   • Dit vereist het gebruik van GET parameters in de URL (bijv: dashboard.php?filter=spoed) en de verwerking daarvan in je SQL query.

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Het systeem vereist dat je een gebruiker (User ID) koppelt aan een ticket. Dit is een 1-op-N relatie. Zonder deze relatie werkt het systeem niet.

2. SQL Parameters (W3): De eis "Admin Quick-Filter" (punt 4 in de bijlage) is de perfecte manier om te laten zien dat je veilige SQL-queries kunt bouwen op basis van input (WHERE status = ?).

3. Veiligheid (W1/W3): Omdat gebruikers input leveren (tekst in tickets), moet je "Input Sanitization" (htmlspecialchars) toepassen om XSS-aanvallen te voorkomen. Dit is een verplicht onderdeel van de exameneisen.

4. Testen (W4): Je kunt heel makkelijk scenario's testen:

   • "Als ik inlog als medewerker, mag ik de 'Verwijder Ticket' knop NIET zien."

   • "Als ik filter op Spoed, mag ik geen blauwe tickets zien."

Project 3 - Fleet Management Portaal

Projectbriefing

Projectnaam: Fleet Management Portaal "DriveSafe"

Datum: 18 december 2025

Opdrachtgever: Transportbedrijf "SnelWeg Logistiek"

Contactpersoon: Dhr. R. Verhoeven (Wagenparkbeheerder)

---

1. Achtergrond en Probleemstelling

SnelWeg Logistiek heeft 60 chauffeurs op de weg. Chauffeurs merken regelmatig gebreken op aan hun voertuig (bijv. een kapotte lamp, rammelende motor of een deuk). Momenteel worden deze gebreken doorgegeven via briefjes op het planbord of mondeling in de kantine.

Hierdoor worden reparaties vergeten, rijden chauffeurs onveilig rond en heeft de werkplaats geen overzicht van de onderhoudsdruk. Dit proces moet geprofessionaliseerd worden.

2. Doelstelling

Wij willen een web-based wagenpark-portaal (DriveSafe) laten ontwikkelen.

Chauffeurs moeten zelf eenvoudig een defect ("Melding") kunnen registreren. De werkplaats (monteurs) moet deze meldingen centraal kunnen inplannen, prioriteren en afmelden.

3. Doelgroepen

1. Chauffeurs (Gebruikers): Willen onderweg via tablet of telefoon snel een defect melden en zien wanneer hun voertuig weer veilig is.

2. Monteurs (Beheerders): Willen een lijst met openstaande reparaties, gesorteerd op urgentie voor de verkeersveiligheid.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor alle medewerkers.

  • Rol-verdeling in de database: chauffeur (user) en monteur (admin).

• Voor Chauffeurs:

  • Dashboard met overzicht van eigen actieve meldingen.

  • Formulier "Defect Melden" (Kenteken, Kilometerstand, Omschrijving, Type: Mechanisch/Elektrisch/Carrosserie).

  • Statusoverzicht van hun melding (bijv. "In Afwachting" of "Gereed").

• Voor Monteurs (Admins):

  • Centraal dashboard met alle defecte voertuigen van het hele bedrijf.

  • Detailpagina per melding om de reparatie te verwerken.

  • Mogelijkheid om de Status (Open/In Reparatie/Gereed) en Urgentie (Veiligheidsrisico: Ja/Nee) aan te passen.

  • Mogelijkheid om een "Monteur Notitie" (vervangen onderdelen) toe te voegen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) in combinatie met MySQL.

• Code Architectuur: Gebruik van includes voor navigatie en database-connectie.

• Veiligheid: Gebruik van PDO Prepared Statements is verplicht. Alle output via htmlspecialchars().

• Data Integriteit: Elke melding moet gekoppeld zijn aan de user_id van de chauffeur (Relational Database ID).

6. Budget en Planning

• Tijdsinvestering: Geschat op circa 40-45 uur ontwikkeling.

• Oplevering: Deadline binnen 5 weken na start.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (user stories en procesflow).

2. Lever een Technische Schets (ERD van de database + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De werkplaats gebruikt grote touchscreens. De interface moet een "Industriële & Clean" uitstraling hebben.

1. Kleurcodering van Urgentie:

   • In de lijsten moet de ernst van het defect direct visueel herkenbaar zijn:

     • Geen risico: Blauw of Grijs (bijv. cosmetisch defect).

     • Aandacht nodig: Oranje (bijv. onderhoud binnenkort).

     • ONVEILIG / STOP: Fel Rood (#D32F2F) (bijv. remproblemen).

2. De Sidebar Navigatie:

   • Wij willen een vaste sidebar aan de linkerkant (Dark Mode). Bovenin de sidebar staat het bedrijfslogo.

   • Onderin de sidebar moet de naam van de ingelogde chauffeur/monteur staan met de uitlogknop.

3. Melding Detail Weergave (Flexbox):

   • Bij het bekijken van een melding moet de informatie verdeeld zijn met kolommen:

     • Links (60%): De uitgebreide omschrijving en de werkplaats-notities.

     • Rechts (40%): Technische metadata (Kenteken, Kilometerstand, Datum melding).

4. De "Workshop Quick-Filter":

   • Boven de lijst moeten 3 tabs staan waarmee de monteur de lijst kan filteren:

     1. "Alle Voertuigen"

     2. "Directe Veiligheidsrisico's"

     3. "Wacht op Reparatie"

   • Dit moet werken via GET parameters in de URL (bijv: overzicht.php?filter=gevaar) en verwerkt worden in de SQL-query.

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): De relatie tussen een voertuigmelding en de chauffeur (User ID) is een 1-op-N relatie, essentieel voor het aantonen van database-vaardigheden.

2. SQL Parameters (W3): Het bouwen van de "Workshop Quick-Filter" laat zien dat je veilige SQL-queries kunt schrijven op basis van URL-input.

3. Validatie (W3): Input zoals kilometerstanden (cijfers) en kentekens (patronen) vereisen specifieke validatie, wat een sterk punt is in je documentatie.

4. Testen (W4): Test scenario's: "Kan een chauffeur de reparatie-notitie van een monteur aanpassen?" of "Toont het filter correct alleen de voertuigen met een veiligheidsrisico?".

Project 4 - Voorraad & Defecten Beheer

Projectbriefing

Projectnaam: Voorraad & Defecten Beheer "StockCheck"

Datum: 18 december 2025

Opdrachtgever: Event-locatie "De Festiviteit"

Contactpersoon: Dhr. J. Willems (Operationeel Manager)

---

1. Achtergrond en Probleemstelling

Event-locatie "De Festiviteit" beschikt over 12 verschillende zalen en 4 bars. Tijdens events merken kelners en barpersoneel vaak dat apparatuur (zoals een biertap, koffiemachine of verlichting) defect is of dat specifieke voorraad (zoals fusten of glaswerk) kritiek laag is.

Nu wordt dit doorgegeven op bierviltjes of via een rommelige groepsapp. De technische dienst en de inkoper missen hierdoor het overzicht, waardoor events soms starten met kapotte apparatuur of te weinig voorraad.

2. Doelstelling

Wij willen een intern meldingsportaal (StockCheck) laten ontwikkelen.

Personeel moet op de werkvloer direct een melding kunnen maken. De technische dienst en inkoop moeten deze meldingen centraal kunnen beheren, prioriteren en afvinken.

3. Doelgroepen

1. Vloerpersoneel (Gebruikers): Willen direct melden dat een koelkast niet koelt en zien of de melding is opgepakt.

2. Facilitair Beheer (Admins): Willen een lijst met taken (reparaties/bestellingen), gesorteerd op urgentie voor het volgende event.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor medewerkers.

  • Rol-verdeling in de database: staff (user) en facilitair (admin).

• Voor Vloerpersoneel:

  • Dashboard met een lijst van hun eigen actieve meldingen.

  • Formulier "Nieuwe Melding" (Locatie/Zaal, Omschrijving, Type: Defect/Voorraadtekort).

  • Zichtbare status (bijv. "In wachtrij", "Wordt geregeld", "Afgehandeld").

• Voor Facilitair Beheer (Admins):

  • Centraal overzicht van alle openstaande meldingen van de gehele locatie.

  • Detailpagina om per melding actie te ondernemen.

  • Mogelijkheid om de Status en de Impact (Kritiek/Niet-kritiek) aan te passen.

  • Mogelijkheid om een "Logboek Notitie" (bijv: onderdeel besteld) toe te voegen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de navigatie en database-instellingen.

• Veiligheid: Verplichte beveiliging tegen SQL-injection via Prepared Statements en XSS via htmlspecialchars().

• Data Integriteit: Elke melding is via een Foreign Key gekoppeld aan de user_id van de melder.

6. Budget en Planning

• Tijdsinvestering: Wij schatten dit project op circa 40-45 uur.

• Oplevering: Prototype binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp.

2. Lever een Technische Schets (ERD + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De look & feel moet passen bij een moderne horeca-omgeving: donkere achtergronden met "Neon" accentkleuren voor status-indicatoren.

1. Visuele Impact-indicatie:

   • In de meldingslijst moet de impact direct opvallen:

     • Lage impact: Grijze rand (bijv. kapot lampje in gang).

     • Medium impact: Gele rand (bijv. voorraad fusten bijna op).

     • KRITIEK: Dikke, rode gloed/rand (#FF0000) (bijv. hoofdtap defect vóór bruiloft).

2. De "Floating" Navigatie:

   • Wij willen een zwevende navigatiebalk onderin het scherm (Mobile First gedachte), zodat personeel met hun duim makkelijk tussen "Home" en "Melden" kan schakelen.

   • Op desktop moet deze balk gewoon bovenin vaststaan (sticky top).

3. Melding Detail (Split View):

   • Gebruik CSS Grid voor de detailpagina:

     • Header (100%): De locatie/zaal naam in een groot font.

     • Main (70%): De omschrijving en de admin-notities.

     • Sidebar (30%): Tijdstip van melding, naam medewerker en een dropdown voor de status.

4. De "Manager Filter":

   • Boven de lijst moeten knoppen staan voor snelle filtering via de URL (GET):

     1. "Toon Alles"

     2. "Kritieke Meldingen"

     3. "Alleen Voorraadtekorten"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): De koppeling tussen zalen/locaties en meldingen dwingt je tot een goede relationele database-opzet.

2. SQL Parameters (W3): De "Manager Filter" laat zien dat je variabelen veilig uit de URL kunt halen en kunt binden aan een SQL query.

3. UX/UI (W1): De Mobile First navigatie-eis laat zien dat je kunt werken met Responsive Design en moderne layout-technieken.

4. Testen (W4): Test of een gewone medewerker de status niet zelf stiekem naar "Afgehandeld" kan zetten via de URL of het formulier.

Project 5 - Tournooi Planner

Projectbriefing

Projectnaam: Toernooi Planner "MatchPoint"

Datum: 18 december 2025

Opdrachtgever: Tennisvereniging "De Gravelbijters"

Contactpersoon: Dhr. A. Fedder (Wedstrijdcommissaris)

Student: Joey

---

1. Achtergrond en Probleemstelling

Bij onze tennisvereniging organiseren we jaarlijks het "Club Open" toernooi. Momenteel worden de standen en uitslagen bijgehouden op papieren schema's die in de kantine hangen. Spelers moeten fysiek naar de kantine komen om te zien wanneer ze moeten spelen of wat de stand in de poule is.

De wedstrijdleiding verliest het overzicht bij regenvertragingen en spelers weten vaak niet waar ze aan toe zijn. Dit moet gedigitaliseerd worden in een overzichtelijk portaal.

2. Doelstelling

Wij willen een online toernooisysteem (MatchPoint) laten ontwikkelen.

Spelers moeten hun eigen wedstrijdschema en de actuele standen kunnen bekijken. De wedstrijdleiding moet uitslagen kunnen invoeren, banen kunnen toewijzen en de voortgang bewaken.

3. Doelgroepen

1. Spelers (Gebruikers): Willen hun geplande wedstrijden zien en de uitslagen van hun poule volgen.

2. Wedstrijdleiding (Admins): Willen een overzicht van alle wedstrijden en de mogelijkheid om scores en winnaars te registreren.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inlogscherm voor spelers en organisatie.

  • Rol-verdeling: speler (user) en leider (admin).

• Voor Spelers:

  • Persoonlijk dashboard met eigen geplande wedstrijden.

  • Overzichtspagina met de actuele stand (Punten/Sets) in hun poule.

  • Zichtbare status van de wedstrijd (bijv. "Gepland", "Bezig" of "Gespeeld").

• Voor Wedstrijdleiding (Admins):

  • Centraal dashboard met alle wedstrijden van het toernooi.

  • Detailpagina per wedstrijd om de Score (bijv. 6-4, 6-2) in te voeren.

  • Mogelijkheid om een Baan toe te wijzen (bijv. Baan 1, Baan 2).

  • Knop om een wedstrijd officieel te "Sluiten" (winnaar bepalen).

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de lay-out elementen.

• Veiligheid: SQL-injectie preventie (Prepared Statements) en XSS-bescherming bij het tonen van spelernamen.

• Data Integriteit: Een wedstrijd (match) moet gekoppeld zijn aan minimaal twee users (spelers). Dit is een 1-op-N of N-op-M relatie.

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.

• Oplevering: Volledig werkend systeem vóór het begin van het toernooiseizoen.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp.

2. Lever een Technische Schets (ERD met minimaal Users en Matches + Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

De vereniging wil een sportieve, frisse uitstraling met de kleuren wit, groen en donkerblauw.

1. Status Labels (Badges):

   • In de lijsten moet de status van een partij direct herkenbaar zijn:

     • Gepland: Grijze achtergrond.

     • Bezig: Fel Groene achtergrond (Live).

     • Afgelopen: Donkerblauwe achtergrond.

2. De "Scoreboard" Navigatie:

   • Wij willen een strakke top-navigatie waar in het midden groot de naam van het huidige toernooi staat.

   • Aan de linkerkant de links naar "Mijn Wedstrijden" en aan de rechterkant het profiel van de speler.

3. Match Detail View (2-Koloms):

   • Maak gebruik van een zijpaneel voor extra informatie:

     • Links (75%): Het actuele scoreverloop en de namen van de spelers (groot).

     • Rechts (25%): "Wedstrijd-info" box met de toegewezen Baan, Starttijd en de Scheidsrechter.

4. De "Leiding Quick-Filter":

   • Boven het totaaloverzicht moeten filters staan (via GET parameters):

     1. "Toon Alle Wedstrijden"

     2. "Nu op de Baan (Bezig)"

     3. "Nog Gepland"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Je werkt met relaties tussen spelers en wedstrijden. Het tonen van een poulestand vereist slimme SQL queries (bijv. ORDER BY gewonnen_sets DESC).

2. Beveiliging (W1/W3): Je moet voorkomen dat een speler via de URL de score van zijn eigen wedstrijd aanpast (autorisatie-check).

3. Gebruikerservaring (W1): Het visueel maken van de status (Bezig vs Gepland) is een belangrijk onderdeel van de front-end eisen.

Project 6 - Real-time Feedback Systeem

Projectbriefing

Projectnaam: Real-time Feedback Systeem "PulseCheck"

Datum: 18 december 2025

Opdrachtgever: Retail Groep "De Markt"

Contactpersoon: Dhr. T. Hendriks (Operationeel Manager)

---

1. Achtergrond en Probleemstelling

Retail Groep "De Markt" wil stoppen met lange, saaie online vragenlijsten waar klanten geen tijd voor hebben. In plaats daarvan willen we "Pulse-Surveys": korte, krachtige vragenlijsten van maximaal 3 vragen die via een QR-code op de winkelvloer direct door klanten kunnen worden ingevuld.

We willen geen standaard pakket zoals SurveyMonkey, omdat we de data direct willen koppelen aan onze eigen filiaalnummers en medewerkers-ID's voor interne prestatie-analyses. De anonimiteit van de klant moet gewaarborgd blijven, maar de data moet wel direct actiegericht zijn voor de bedrijfsleider.

2. Doelstelling

Wij willen een custom-built survey platform (PulseCheck) laten ontwikkelen.

Klanten moeten zonder account een korte vragenlijst kunnen invullen. De bedrijfsleiders moeten in een afgeschermd beheerpaneel de resultaten per filiaal kunnen inzien en analyseren.

3. Doelgroepen

1. Klanten (Anonieme Gebruikers): Willen binnen 30 seconden hun mening geven over de wachttijd en vriendelijkheid.

2. Bedrijfsleiders (Admins): Willen per filiaal zien wat de gemiddelde score is en welke opmerkingen klanten achterlaten.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Toegang & Authenticatie:

  • De survey zelf is publiek toegankelijk (geen login).

  • Inlogscherm voor admins (bedrijfsleiders) om resultaten te bekijken.

• De Pulse-Survey (Voor Klanten):

  • Invulformulier met 3 verplichte velden: Score (1-5 sterren), Categorie (Service/Prijs/Assortiment) en Toelichting (tekst).

  • Automatische registratie van het filiaal-ID (via een hidden field of URL-parameter).

  • Vriendelijke bedankpagina na verzending.

• Het Dashboard (Voor Admins):

  • Overzicht van alle binnengekomen feedback in een tabel.

  • Berekening van de gemiddelde score per filiaal.

  • Mogelijkheid om een survey-antwoord te markeren als "Gelezen" of "Actie ondernomen".

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.

• Code Architectuur: Gebruik van includes voor de database-connectie en herbruikbare UI componenten.

• Veiligheid: Omdat klanten tekst invoeren, is XSS preventie (htmlspecialchars) cruciaal. Gebruik Prepared Statements voor het opslaan van antwoorden.

• Data Integriteit: Elke feedback-entry moet gekoppeld zijn aan een bestaand filiaal-ID in de database.

6. Budget en Planning

• Tijdsinvestering: Geschat op circa 40-45 uur.

• Oplevering: Prototype binnen 5 weken.

7. Gevraagde actie

1. Lever een Functioneel Ontwerp (wat is de flow van de klant?).

2. Lever een Technische Schets (Database ontwerp + Mobile Wireframes).

3. Realiseer de applicatie en lever de broncode op via Git.

---

BIJLAGE: Specifieke Design & Interface Wensen

Omdat de klant dit op hun eigen telefoon invult, moet de survey 100% geoptimaliseerd zijn voor mobile (Mobile First).

1. Visual Feedback (Rating):

   • De 5-sterren score moet visueel aantrekkelijk zijn. Gebruik kleurverloop:

     • Score 1-2: Rood (Slecht).

     • Score 3: Oranje/Geel (Gemiddeld).

     • Score 4-5: Helder Groen (#2E7D32) (Top).

2. Clean Header:

   • Geen ingewikkelde menu's. Alleen een logo gecentreerd bovenin en een subtiele filiaalnaam eronder.

3. Admin Detail View (70/30 Split):

   • Wanneer een admin op een feedback-item klikt:

     • Links (70%): De volledige toelichting van de klant in een leesbaar font.

     • Rechts (30%): De metadata (Datum/Tijd, Filiaalnummer, IP-adres check).

4. De "Analytics Filter":

   • De admin moet bovenin de lijst kunnen filteren via URL parameters (GET):

     1. "Toon alle scores"

     2. "Alleen Negatief (1-2 sterren)"

     3. "Alleen deze week"

---

Tips voor jouw Examenportfolio

Waarom is deze opdracht geschikt voor je examen?

1. Complexiteit (W3): Je moet omgaan met publieke data-entry (de klant) en geprivilegieerde data-viewing (de admin). De link met filiaal-ID's is een klassieke 1-op-N relatie.

2. SQL Parameters (W3): De "Analytics Filter" dwingt je om veilige SQL te schrijven die reageert op URL-input.

3. Validation & Security (W1/W3): Omdat de survey openstaat voor iedereen, is input-validatie (bijv. maximale tekstlengte) en sanitization essentieel om de database schoon te houden.

Project 7 - Bibliotheek Beheersysteem

Projectbriefing

Projectnaam: Bibliotheek Beheersysteem "BookFlow"

Datum: 18 december 2025

Opdrachtgever: Brede School "Het Leerpark"

Contactpersoon: Mevr. L. de Vries (Mediabeheerder)

---

1. Achtergrond en Probleemstelling

Brede School "Het Leerpark" heeft een bibliotheek met ruim 2.000 boeken. Momenteel wordt het uitlenen bijgehouden in Excel. Dit is foutgevoelig: we weten vaak niet wie welk boek heeft, of de inleverdatum is verstreken en leerlingen kunnen de catalogus niet inzien.

Dit leidt tot verlies van boeken en een enorme administratieve druk. We willen dit professionaliseren met een systeem waarbij leerlingen zelfredzaam zijn en beheerders controle houden.

2. Doelstelling

De ontwikkeling van een web-based uitleensysteem (BookFlow).

Leerlingen moeten online de catalogus doorzoeken en reserveringen plaatsen. De mediabeheerder moet aanvragen verwerken, termijnen bewaken en de inname van boeken efficiënt registreren.

3. Doelgroepen

1. Leerlingen (Gebruikers): Willen direct zien of een boek 'thuis' is en wanneer zij hun eigen boeken moeten inleveren.

2. Mediabeheerders (Admins): Willen met minimale handelingen uitleningen registreren en proactief 'te laat' meldingen inzien.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inlogscherm met rol-verdeling: student en librarian.

• Voor Leerlingen:

  • Dashboard met eigen actieve leningen en historie.
  • Doorzoekbare catalogus (Titel, Auteur, Categorie).
  • Knop "Reserveer Boek" (alleen mogelijk indien boek status 'Beschikbaar' heeft).

• Voor Mediabeheerders (Admins):

  • Uitleentermijn beheer: Mogelijkheid om bij uitgifte de inleverdatum aan te passen (default 4 weken).
  • Snel-registratie: Een dedicated "Uitleen-scherm" waar via een dropdown (of zoekveld) een leerling en boek gekoppeld kunnen worden.
  • Dashboard: Overzicht van alle actieve uitleningen, gesorteerd op inleverdatum.
  • Statusbeheer: Detailpagina om een lening af te ronden of de staat van het boek (notitie) bij te werken.

5. Technische Eisen & Randvoorwaarden

• PHP 8.x & MySQL: Gebruik van PDO voor database-interactie.
• Security: Verplichte password_hash voor accounts, Prepared Statements tegen SQL-injection en htmlspecialchars tegen XSS.
• Validatie: Een boek kan niet worden uitgeleend als de huidige status 'Uitgeleend' is.
• Architectuur: Logische mappenstructuur (bijv. /assets, /includes, /admin).

6. Budget en Planning

• Tijdsinvestering: 40-45 uur.
• Oplevering: Werkend MVP inclusief testrapport binnen 5 weken.

---

BIJLAGE: Design & UI Wensen

1. Status Labels: Gebruik visuele indicators (badges) in de tabel: Beschikbaar (Groen), Uitgeleend (Grijs), Te laat (Rood).
2. UX voor Admins: Het uitleenscherm moet 'keyboard-friendly' zijn (tabben tussen velden) voor snelle verwerking aan de balie.
3. Split-Screen Detail: Op de detailpagina van een boek: links de boekinformatie, rechts de uitleenhistorie van dat specifieke boek (wie had het wanneer?).

---

Extra Tips voor je Portfolio

1. Datum-logica (W3): Laat in je code zien hoe je met PHP de 'inleverdatum' berekent (vandaag + 28 dagen) en hoe je dit vergelijkt met de huidige datum om de status 'Te laat' te triggeren.
2. Joins (W3): In je Admin Dashboard gebruik je SQL JOINs om gegevens uit de tabellen gebruikers, boeken en leningen in één overzicht te tonen.

Project 8 - Bezichtigingsbeheer

Projectbriefing

Projectnaam: Bezichtigingsbeheer "KeyMaster"

Datum: 18 december 2025

Opdrachtgever: Makelaardij "De Gouden Sleutel"

Contactpersoon: Dhr. M. van Ommen (Eigenaar)

---

1. Achtergrond en Probleemstelling

Makelaardij De Gouden Sleutel beheert 150 huurwoningen. Wanneer er een woning vrijkomt, melden zich tientallen geïnteresseerden. Momenteel worden afspraken voor bezichtigingen in een papieren agenda genoteerd. Hierdoor is het onduidelijk wie er komt kijken, of de sleutel wel aanwezig is op kantoor en welke feedback de kijkers hebben gegeven.

Potentiële huurders bellen constant voor de status van hun aanvraag. Dit zorgt voor enorme drukte aan de telefoon. We willen een systeem waar makelaars bezichtigingen inplannen en klanten de status van hun afspraak kunnen inzien.

2. Doelstelling

De ontwikkeling van een portaal voor bezichtigingen (KeyMaster).

Klanten moeten online een aanvraag kunnen doen voor een woning. De makelaar moet deze aanvragen kunnen omzetten in een geplande afspraak, een sleutelstatus bijhouden en na afloop feedback noteren.

3. Doelgroepen

1. Klanten (Gebruikers): Willen zien of hun aanvraag is goedgekeurd en wanneer ze verwacht worden bij de woning.

2. Makelaars (Admins): Willen een dagoverzicht van alle geplande bezichtigingen en de status van de woning (bijv. "Verhuurd").

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen voor klanten en makelaars.
  • Rollen: klant en makelaar.

• Voor Klanten:

  • Dashboard met hun actuele aanvragen en geplande datums.
  • Formulier "Bezichtiging Aanvragen" (Adres woning, Voorkeursdatum, Inkomen-indicatie).

• Voor Makelaars (Admins):

  • Centraal dashboard met alle binnengekomen aanvragen.
  • Planningsmodule: Een datum en tijdstip definitief koppelen aan een aanvraag.
  • Sleutelbeheer: Bijhouden of de sleutel op kantoor ligt of dat de huidige bewoner open doet.
  • Feedback-veld: Na de bezichtiging noteren of de klant interesse heeft of heeft afgehaakt.

5. Technische Eisen & Randvoorwaarden

• PHP 8.x & MySQL: Gebruik van PDO.
• Data Koppeling: Elke afspraak (appointment) moet gekoppeld zijn aan een property_id en een user_id.
• Veiligheid: Gebruik Prepared Statements voor alle queries en XSS-bescherming bij de adresgegevens.

6. Budget en Planning

• Ontwikkeltijd: 40-45 uur.
• Deadline: Binnen 5 weken.

---

BIJLAGE: Design & UI Wensen

1. Status Badges: Geef afspraken een kleur: Aanvraag (Blauw), Ingepland (Geel), Afgerond (Groen), Geannuleerd (Rood).
2. De "Daily View" Filter: De makelaar moet met één klik kunnen filteren op "Afspraken van Vandaag" (gebruik WHERE date = CURDATE() in je SQL).
3. Adres Detail: In het overzicht moet het adres van de woning groot en vetgedrukt staan, met daaronder de naam van de klant.

---

Waarom dit goed is voor je examen:

1. SQL Datum-functies: Je laat zien dat je kunt werken met DATE types en filters op specifieke dagen.
2. Privacy (W1/W3): Klanten mogen elkaars aanvragen en inkomensgegevens absoluut niet zien. Dit is een perfecte case om je autorisatie-checks (PHP sessies icm SQL) te bewijzen.
3. Complexiteit: Het omzetten van een 'losse' aanvraag naar een 'geplande afspraak' vereist een status-update in je database, wat een kernproces is van een applicatie-ontwikkelaar.

Project 9 - Voorraad- en Distributiebeheer

Projectbriefing

Projectnaam: Voorraad- en Distributiebeheer "Vuller"

Datum: 8 januari 2026

Opdrachtgever: Stichting "De Reikende Hand"

Contactpersoon: Mevr. S. Broodstra (Logistiek Manager)

Student: [Naam Student]

---

1. Achtergrond en Probleemstelling

Onze stichting zamelt voedselpakketten in voor gezinnen in de regio. Momenteel werken we met Excel-lijsten om bij te houden welke vrijwilliger welk pakket op welk adres moet afleveren. Dit zorgt voor fouten: soms staan twee vrijwilligers bij hetzelfde adres, of worden pakketten vergeten.

Daarnaast hebben de bezorgers onderweg geen inzicht in hun route of specifieke afleverinstructies (bijv. "pakket achter het tuinhek"). We hebben behoefte aan een centraal systeem dat de logistiek stroomlijnt.

2. Doelstelling

Wij willen een web-based portaal (Vuller) laten ontwikkelen voor het beheren van bezorgroutes.

Vrijwilligers moeten op hun telefoon hun eigen route kunnen zien en pakketten als "afgeleverd" kunnen markeren. De logistiek manager moet routes kunnen aanmaken, vrijwilligers koppelen en de status van alle leveringen live kunnen volgen.

3. Doelgroepen

1. Bezorgers (Vrijwilligers): Willen hun toegewezen adressen zien en de status van een levering bijwerken.

2. Logistiek Managers (Admins): Willen een totaaloverzicht van de voorraad en de voortgang van de bezorgingen per wijk.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Inloggen voor vrijwilligers en managers.
  • Rollen: vrijwilliger en manager.

• Voor Vrijwilligers:

  • Dashboard met de lijst van af te leveren pakketten voor vandaag.
  • Detailpagina per adres met afleverinstructies en een knop "Markeer als Bezorgd".
  • Overzicht van eigen voltooide leveringen.

• Voor Managers (Admins):

  • Beheerpagina om nieuwe leveringen (adressen + inhoud pakket) toe te voegen.
  • Mogelijkheid om een levering toe te wijzen aan een specifieke vrijwilliger.
  • Live dashboard met statistieken: Hoeveel % van de pakketten is al bezorgd?

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Code Architectuur: Gebruik van een duidelijke mappenstructuur en header/footer includes.
• Veiligheid: Beveiliging tegen SQL-injectie en het valideren of een vrijwilliger alleen zijn eigen routes kan inzien.
• Data Integriteit: Een levering (delivery) is gekoppeld aan één vrijwilliger (user), maar een vrijwilliger kan meerdere leveringen hebben (1-op-N relatie).

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.
• Oplevering: Een werkend prototype (MVP) inclusief testdata.

---

BIJLAGE: Specifieke Design & Interface Wensen

De stichting wil een betrouwbare en rustige uitstraling: wit, lichtgrijs en 'hulpvaardig' oranje.

1. Status Badges:

   • In Magazijn: Grijze badge.
   • Onderweg: Oranje badge.
   • Afgeleverd: Groene badge.

2. De "Route-Tracker" Navigatie:

   • Top-navigatie met in het midden de tekst "Vuller - Logistiek Systeem".
   • Rechtsboven een duidelijke melding als er nog onbezorgde pakketten op de lijst staan.

3. Bezorging Detail View (2-Koloms):

   • Links (70%): Adresgegevens (groot) en de inhoud van het pakket (bijv. "Pakket A: Gezin 4 pers.").
   • Rechts (30%): "Klant-notities" box met informatie over de bewoner of de locatie van de voordeur.

4. Manager Filter:

   • Filteren op wijk (bijv. ?wijk=Centrum) en op vrijwilliger om snel te zien wie nog op pad is.

Project 10 - E-sports Arena

Projectbriefing

Projectnaam: E-sports Arena "Respawn & Conquer"

Datum: 8 januari 2026

Opdrachtgever: Gaming Community "The Final Boss"

Contactpersoon: Dhr. K. 'NoobSlayer' Visser (Toernooi Organisator)

Student: Joey

---

1. Achtergrond en Probleemstelling

Onze community organiseert maandelijks online 1v1 toernooien voor verschillende games. Momenteel communiceren we via Discord-chats over wie tegen wie moet spelen. Uitslagen worden handmatig in een Google Sheet geplakt, wat vaak leidt tot verwarring over de huidige 'bracket' en wie de volgende tegenstander is.

Spelers missen hun matches omdat ze niet weten wanneer hun lobby klaarstaat, en de admins worden overspoeld met vragen over de tussenstand. We hebben een eigen portaal nodig dat fungeert als de 'Single Source of Truth' voor onze spelers.

2. Doelstelling

Wij willen een toernooi-dashboard (Respawn) laten ontwikkelen.

Gamers moeten kunnen inloggen om hun aankomende matches en de 'Kill/Death' ratio of puntenstand te zien. De toernooi-leiding (Game Masters) moet lobby-codes kunnen delen, spelers aan matches kunnen koppelen en de winnaars kunnen bevestigen.

3. Doelgroepen

1. Players (Gebruikers): Willen direct zien in welke 'Lobby' ze worden verwacht en wat hun ranking is.

2. Game Masters (Admins): Willen matches aanmaken, scores valideren en valsspelers kunnen markeren/verwijderen.

4. Gewenste Functionaliteiten (Must-Haves)

Voor het MVP verwachten wij de volgende functies:

• Authenticatie:

  • Login met 'GamerTag' en wachtwoord.
  • Rollen: player en gamemaster.

• Voor Players:

  • Persoonlijke 'Quest Log' (Dashboard) met actieve en komende matches.
  • Zichtbare Lobby-code voor de match (bijv. "A1-B99").
  • Leaderboard van de huidige competitie gebaseerd op gewonnen rondes.

• Voor Game Masters (Admins):

  • Match-maker interface: Koppel twee spelers aan een nieuwe match.
  • Uitslagen invoeren (bijv. 16-12) en de winnaar aanwijzen.
  • Systeem om matches op "Pending Validation" te zetten bij geschillen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Sterke focus op rollen-beheer; spelers mogen nooit de score van een ander aanpassen.
• Front-end: Responsive design (spelers gebruiken vaak een tweede scherm of telefoon naast hun PC).
• Data Relatie: Een match-tabel die verwijst naar twee unieke ID's uit de player-tabel (Player 1 vs Player 2).

6. Budget en Planning

• Tijdsinvestering: Ontwikkelingstijd van circa 40-45 uur.
• Oplevering: Broncode via Git, inclusief een SQL-dump met test-gamers.

---

BIJLAGE: Specifieke Design & Interface Wensen

Het design moet een "Dark Mode" gamer-esthetiek hebben: donkergrijs/zwart, met neon-accenten in paars en cyaan.

1. Match Status Badges:

   • Waiting: Grijze gloed.
   • Warm-up: Cyaan (Ready to join).
   • In-Game: Paars (Live).
   • GG (Finished): Goud/Geel.

2. De "HUD" Navigatie:

   • Een sticky top-navigatie die lijkt op een 'Heads-Up Display' met de toernooinaam in een futuristisch font.

3. Match View (2-Koloms Split):

   • Links (75%): "Versus" scherm: Player 1 Avatar vs Player 2 Avatar, met daaronder de score-input.
   • Rechts (25%): "Server Info": Map-naam, Lobby-code en de naam van de Game Master die toezicht houdt.

4. GM Quick-Filter:

   • Knoppen om direct te filteren op "Matches zonder winnaar" of "Matches met conflict".

Project 11 - Sneaker Marketplace

Projectbriefing

Projectnaam: Sneaker Marketplace "SoleExchange"

Datum: 8 januari 2026

Opdrachtgever: Streetwear Boutique "The Kickz"

Contactpersoon: Dhr. M. Air (Eigenaar)

Student: Joey

---

1. Achtergrond en Probleemstelling

De markt voor exclusieve sneakers is enorm gegroeid. Onze klanten willen niet alleen schoenen kopen, maar hun eigen 'deadstock' (ongedragen schoenen) kunnen aanbieden aan andere verzamelaars. Momenteel gebeurt dit via onoverzichtelijke Marktplaats-advertenties waar veel fraude plaatsvindt.

We hebben een veilig, besloten platform nodig waar onze community leden hun sneakers kunnen aanbieden. De winkel (wij als organisatie) fungeert als tussenpersoon die de echtheid controleert voordat een deal wordt gesloten.

2. Doelstelling

Ontwikkel een Sneaker Trading Platform (SoleExchange).

Leden moeten hun sneakers kunnen uploaden (maat, merk, conditie). Andere gebruikers kunnen hierop een bod uitbrengen. Zodra een koper en verkoper akkoord zijn, moet het systeem de status bijwerken naar 'Verificatie' (waarbij de schoen naar de winkel wordt gestuurd).

3. Doelgroepen

1. Verzamelaars (Gebruikers): Willen hun collectie beheren, advertenties plaatsen en biedingen doen op andere schoenen.

2. Authenticators (Admins): Medewerkers van de winkel die de schoenen controleren op echtheid en de uiteindelijke verkoop goedkeuren.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen voor verzamelaars.
  • Rollen: collector en admin.

• Voor Verzamelaars:

  • "My Closet": Een overzicht van je eigen aangeboden sneakers.
  • Marktplaats-overzicht: Alle beschikbare sneakers van andere leden.
  • Biedings-systeem: Een bod kunnen uitbrengen op een item.

• Voor Admins (The Kickz Staff):

  • Dashboard met verkochte items die wachten op controle.
  • Knop om een item op 'Verified' (Echt) of 'Rejected' (Nep) te zetten.
  • Gebruikersbeheer om malafide verkopers te blokkeren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Voorkom dat gebruikers elkaars biedingen verwijderen of aanpassen via de URL (ID-manipulatie).
• UX: Gebruik van afbeeldings-URL's om de schoenen visueel aantrekkelijk te tonen.
• Data Relatie: Een tabel `bids` die gekoppeld is aan zowel een `user` (de bieder) als een `sneaker_id`.

---

BIJLAGE: Specifieke Design & Interface Wensen

De uitstraling moet 'Urban' en 'High-end' zijn: Veel witruimte, strakke zwarte letters en rode accenten (zoals het bekende merk 'Supreme').

1. Conditie Labels:

   • DS (Deadstock/Nieuw): Felrode badge.
   • VNDS (Zo goed als nieuw): Zwarte badge.
   • Used: Grijze badge.

2. De "Price-Ticker" Navigatie:

   • Een navigatiebalk waarin naast de links ook een kleine 'ticker' (looptekst) staat met de laatste verkopen.

3. Product Card Design:

   • In het overzicht moeten de schoenen in een 'grid' staan met een hover-effect waarbij het hoogste bod direct zichtbaar wordt.

Project 12 - Studie-Portaal

Projectbriefing

Projectnaam: Studie-Portaal "StudyBuddy"

Datum: 8 januari 2026

Opdrachtgever: Studentenraad "Beter Leren"

Contactpersoon: Dhr. L. De Boeck (Studentenvoorzitter)

Student: Joey

---

1. Achtergrond en Probleemstelling

Studenten hebben vaak moeite met het organiseren van hun studietijd. Informatie staat verspreid over verschillende systemen, PDF's raken kwijt in downloads en de voortgang van projecten is onduidelijk. Vooral bij groepsopdrachten is het lastig om te zien wie wat heeft gedaan.

Er is behoefte aan een centrale web-app waar studenten hun vakken kunnen beheren, bronnen (links/notities) kunnen opslaan en hun cijfers kunnen bijhouden om hun gemiddelde te berekenen.

2. Doelstelling

Wij willen een Persoonlijk Studie Dashboard (StudyBuddy) laten ontwikkelen.

Het platform moet studenten helpen bij het plannen. De kern van de app is het beheren van 'Vakken' (Courses) en de bijbehorende 'Taken' (Tasks) en 'Cijfers' (Grades).

3. Doelgroepen

1. Studenten (Gebruikers): Willen hun eigen vakken, deadlines en behaalde cijfers inzien.

2. Docenten/Beheerders (Admins): Willen vakken kunnen aanmaken en algemene aankondigingen of studiemateriaal kunnen pushen naar alle studenten.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met een studentnummer.
  • Rollen: student en admin (docent).

• Voor Studenten:

  • Overzicht van actieve vakken (bijv. PHP, Databases, Nederlands).
  • Deadline-lijst: Taken die gesorteerd zijn op datum.
  • Cijferlijst: Invoer van behaalde resultaten met automatische berekening van het gemiddelde.

• Voor Admins (Docenten):

  • Nieuwe vakken toevoegen aan het systeem.
  • Studiemateriaal (links naar documenten) koppelen aan een vak.
  • Overzicht van hoeveel studenten een vak volgen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: SQL-injectie preventie. Zorg dat een student alleen zijn *eigen* cijfers kan zien en bewerken.
• Wiskundige Logica: De backend moet het gemiddelde berekenen op basis van de ingevoerde cijfers uit de database.
• Data Relatie: Een vak (course) heeft meerdere taken (tasks) en meerdere cijfers (1-op-N relatie).

---

BIJLAGE: Specifieke Design & Interface Wensen

De look-and-feel moet rustgevend en productief zijn: Pastelkleuren (lichtblauw, zachtgroen) en een 'clean' wit dashboard.

1. Deadline Indicators:

   • Kritiek (binnen 2 dagen): Rode tekst + klok-icoon.
   • Gepland: Blauwe badge.
   • Voltooid: Doorgestreepte tekst met een groen vinkje.

2. De "Focus" Navigatie:

   • Minimale zijbalk (Sidebar) met iconen voor: Dashboard, Mijn Cijfers, Materialen en Instellingen.

3. Grade View (Tabel):

   • Een strakke tabel waar cijfers onder de 5.5 automatisch een rode achtergrond krijgen.

Project 13 - GoalGetter

Projectbriefing

Projectnaam: Teammanager App "GoalGetter"

Datum: 15 januari 2026

Opdrachtgever: Voetbalvereniging “SV KickOff”

Contactpersoon: Dhr. P. Vermeer (Teamcoach JO19-1)

Student: Milan

---

1. Achtergrond en Probleemstelling

Binnen de vereniging wordt veel tijd verloren aan het coördineren van trainingen, wedstrijden en aanwezigheid van spelers. Communicatie verloopt nu via verschillende WhatsApp-groepen en Excel-schema’s, wat leidt tot verwarring en gemiste wedstrijden.

De club wil één centraal platform waar trainers, spelers en ouders hun planning, statistieken en communicatie kunnen beheren.

2. Doelstelling

Wij willen een Teammanager App (GoalGetter) ontwikkelen die alle teamactiviteiten centraliseert.

De app moet helpen bij het plannen van trainingen, beheren van teamleden en inzicht geven in prestaties per speler en team.

3. Doelgroepen

1. Trainers (Admins): Willen snel zien wie aanwezig is, teams indelen en statistieken beheren.

2. Spelers (Gebruikers): Willen hun wedstrijden, statistieken en teamberichten bekijken.

3. Ouders: Willen meldingen ontvangen over wedstrijden en aanwezigheid van hun kind bevestigen.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met lidnummer of e-mail.
  • Rollen: trainer, speler, ouder.

• Voor Spelers:

  • Overzicht van komende trainingen en wedstrijden.
  • Eigen statistieken bekijken (doelpunten, assists, kaarten).
  • Aanwezigheid bevestigen of afmelden.

• Voor Trainers:

  • Teamselectie maken voor wedstrijden.
  • Statistieken invoeren per speler.
  • Berichten versturen naar spelers of ouders.

• Voor Ouders:

  • Meldingen ontvangen over aanvangstijden en locatie van wedstrijden.
  • Afwezigheid van hun kind melden.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Beveiliging: Rolgebaseerde toegang; alleen trainers mogen teamstatistieken bewerken.
• Data Relatie: Een team heeft meerdere spelers (1-op-N) en een speler heeft meerdere statistieken (1-op-N).
• Logica: De backend berekent automatisch het gemiddelde aantal doelpunten per wedstrijd en de teamvorm (W-D-L).

---

BIJLAGE: Specifieke Design & Interface Wensen

De look-and-feel moet sportief en energiek zijn: kleuren in clubstijl (groen/wit), duidelijke iconen en een mobielvriendelijke interface.

1. Status-Indicators:

   • Wedstrijd gewonnen: Groene badge met trofee-icoon.
   • Gelijkspel: Gele badge.
   • Verloren: Rode badge met kruis-icoon.

2. Navigatie:

   • Onderbalk met iconen voor: Home, Team, Wedstrijden, Statistieken en Berichten.

3. Statistiekenweergave:

   • Grafieken tonen prestaties per speler en teamtrend over de tijd.

--

Project 14 - CoachVision

Projectbriefing

Projectnaam: Voetbal Analyse Dashboard "CoachVision"

Datum: 15 januari 2026

Opdrachtgever: KNVB Innovatie-afdeling

Contactpersoon: Dhr. J. van den Berg (Technisch Analist)

Student: Daan

---

1. Achtergrond en Probleemstelling

Bij veel amateur- en semi-professionele voetbalclubs worden wedstrijdgegevens nog handmatig bijgehouden. Hierdoor ontbreekt inzicht in prestaties op team- en individueel niveau. Trainers baseren beslissingen vaak op gevoel in plaats van data.

De KNVB wil een digitaal dashboard ontwikkelen waarmee coaches eenvoudig data kunnen verzamelen, analyseren en visualiseren, zodat trainingen en tactische keuzes beter onderbouwd kunnen worden.

2. Doelstelling

Het doel is om een Voetbal Analyse Dashboard (CoachVision) te ontwikkelen dat inzicht biedt in spelersprestaties, teamontwikkeling en wedstrijdstatistieken.

De tool moet visueel sterk zijn, realtime data kunnen verwerken en trainers ondersteunen in hun tactische beslissingen.

3. Doelgroepen

1. Trainers: Willen inzicht in de prestaties van spelers en teams om trainingen te optimaliseren.

2. Data-analisten: Willen gegevens verzamelen, filteren en exporteren voor verdere analyse.

3. Teamleiders: Willen snel rapportages kunnen delen met bestuur of spelersgroep.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met clubaccount.
  • Rollen: trainer, analist, beheerder.

• Dashboard voor Trainers:

  • Overzicht van wedstrijdresultaten, doelpuntenmakers en conditiestatus.
  • Automatische berekening van teamvorm (laatste 5 wedstrijden).
  • Heatmaps en pass-statistieken per speler.

• Voor Analisten:

  • Data importeren vanuit CSV of tracking-sensoren.
  • Statistische filters toepassen (bijv. balbezit, afstand gelopen, succesratio passes).
  • Exporteren naar Excel of PDF voor rapportages.

• Voor Beheerders:

  • Gebruikersrechten beheren.
  • Teams, spelers en seizoenen aanmaken of archiveren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en gebruik van Chart.js voor visualisaties.
• Beveiliging: JWT-authenticatie en SSL-verbinding verplicht.
• API-koppelingen: Mogelijkheid om data te ontvangen van GPS-trackers of sport-API’s (zoals SportMonks).
• Data Relatie: Een speler kan meerdere statistieken per wedstrijd hebben (1-op-N-relatie).

---

BIJLAGE: Specifieke Design & Interface Wensen

Het dashboard moet professioneel en overzichtelijk zijn: donkere modus met clubaccentkleuren (donkerblauw, oranje) en duidelijke datavisualisaties.

1. Visualisaties:

   • Grafieken voor doelpunten, balbezit en afstand per speler.
   • Kaartweergave (heatmap) met looplijnen over het veld.

2. Navigatie:

   • Sidebar met secties voor: Dashboard, Spelers, Wedstrijden, Analyse en Instellingen.

3. Rapportageweergave:

   • Downloadbare rapporten in PDF met clublogo en prestatiegrafieken.

Project 15 - MatchUp

Projectbriefing

Projectnaam: Schooltoernooi Planner "MatchUp"

Datum: 15 januari 2026

Opdrachtgever: MBO College Stad – Sport & Beweging

Contactpersoon: Mevr. K. van Es (Docent Sport)

Student: Ruben

---

1. Achtergrond en Probleemstelling

Tijdens sportdagen en toernooien op school is het lastig om overzicht te houden over wedstrijden, uitslagen en standen. Schema’s worden vaak handmatig gemaakt in Excel of op papier, wat fouten en vertragingen oplevert.

De opleiding wil een eenvoudige webapp waarmee studenten en docenten een toernooi kunnen organiseren, teams kunnen indelen en automatisch een speelschema kunnen genereren.

2. Doelstelling

Het doel is een Schooltoernooi Planner (MatchUp) te ontwikkelen waarmee wedstrijden, teams en scores digitaal beheerd kunnen worden.

De app moet toegankelijk zijn voor studenten en docenten, overzichtelijk werken op mobiel, en automatisch de poulestanden bijhouden.

3. Doelgroepen

1. Studenten (Spelers): Willen hun team, wedstrijdtijden en uitslagen bekijken.

2. Docenten (Organisatoren): Willen teams aanmaken, het speelschema genereren en standen bijhouden.

3. Toeschouwers: Willen de actuele stand van het toernooi zien.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Inloggen met schoolaccount.
  • Rollen: student en docent.

• Voor Studenten:

  • Inzien van het eigen team, poule en wedstrijden.
  • Live tussenstanden en uitslagen volgen.
  • Teamfoto en teamnaam aanpassen.

• Voor Docenten:

  • Teams aanmaken en wedstrijden genereren (automatisch schema).
  • Uitslagen invoeren en standen automatisch laten berekenen.
  • Winnaar van het toernooi bepalen.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x) en MySQL.
• Logica: Automatische poule-indeling en puntentelling (3 punten winst, 1 punt gelijk, 0 verlies).
• Beveiliging: Alleen docenten kunnen uitslagen invoeren of wijzigen.
• Data Relatie: Een team speelt meerdere wedstrijden (1-op-N) en elke wedstrijd hoort bij één poule.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet sportief en helder zijn: veel witruimte met accenten in blauw en oranje (schoolkleuren), en duidelijke iconen voor teams en standen.

1. Poule-overzicht:

   • Tabel met teams, gespeelde wedstrijden, punten en doelsaldo.
   • Automatische kleur voor koploper (groen) en laatste plaats (rood).

2. Navigatie:

   • Tabs of knoppen voor: Poules, Wedstrijden, Uitslagen en Ranglijst.

3. Score-invoer:

   • Docentinterface met invoervelden voor thuis- en uitteam, plus scorevalidatie.

Project 16 - EuroMatch

Projectbriefing

Projectnaam: European School Cup Manager "EuroMatch"

Datum: 15 januari 2026

Opdrachtgever: European Schools Federation (ESF)

Contactpersoon: Mevr. L. Schneider (Projectcoördinator Sport en ICT)

Student: Elias

---

1. Achtergrond en Probleemstelling

De European Schools Federation organiseert jaarlijks een sporttoernooi met teams uit verschillende landen. De organisatie gebruikt momenteel losse Excel-bestanden en e-mails om wedstrijden en scores bij te houden. Dit leidt tot fouten, vertragingen en taalverwarring tussen teams uit verschillende landen.

Er is behoefte aan een centrale, meertalige webapplicatie waarmee het toernooi digitaal kan worden beheerd: teams registreren, wedstrijden plannen, scores bijhouden en statistieken tonen per land en team.

2. Doelstelling

Het doel is om een European School Cup Manager (EuroMatch) te ontwikkelen die alle landen, teams, wedstrijden en uitslagen samenbrengt in één overzichtelijk systeem.

De app moet ondersteuning bieden voor meerdere talen, automatische tijdzone-afstemming en uitgebreide statistieken per land.

3. Doelgroepen

1. Teamcoaches: Willen hun team inschrijven, spelers beheren en resultaten invoeren.

2. Organisatoren (Admins): Willen het volledige toernooi beheren, schema’s genereren en rapportages exporteren.

3. Internationale bezoekers: Willen live de standen en statistieken volgen in hun eigen taal.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie & Rollen:

  • Inloggen met e-mail of teamcode.
  • Rollen: coach, admin, viewer.
  • Tweetrapsverificatie voor beheerders.

• Meertalige Ondersteuning:

  • Taalkeuze: Engels, Nederlands, Frans, Duits en Spaans.
  • Automatische vertaling van teamnamen en landen via een taaltabel in de database.

• Voor Coaches:

  • Teams aanmaken met vlag, spelerslijst en schoolnaam.
  • Uitslagen invoeren of bevestigen.
  • Teamstatistieken bekijken (doelpunten, winstpercentage).

• Voor Organisatoren:

  • Automatisch wedstrijdschema genereren op basis van poules en tijdzones.
  • Resultaten valideren en standen automatisch laten berekenen.
  • Exporteren van rapporten naar PDF of Excel per land.

• Voor Bezoekers:

  • Live scorebord met vlaggen van deelnemende landen.
  • Filteren op land, poule of datum.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL, JavaScript (Chart.js voor grafieken).
• Beveiliging: SQL-prepared statements, CSRF-tokens en SSL.
• Internationalisatie: Gebruik van gettext() voor meertalige ondersteuning.
• Data Relatie: Elk land heeft meerdere teams (1-op-N), elk team meerdere wedstrijden (1-op-N).
• Tijdzones: Wedstrijdtijden automatisch converteren naar lokale tijd van gebruiker.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet een internationale uitstraling hebben met vlag-iconen, een moderne typografie en lichte achtergrond. Kleuren gebaseerd op het thema blauw (Europa) en goud (prestatie).

1. Dashboard:

   • Kaart van Europa met deelnemende landen gemarkeerd.
   • Top 5 landen zichtbaar op basis van behaalde punten.

2. Navigatie:

   • Bovennavigatie met vlag-iconen voor taalkeuze en dropdown voor landenfilter.

3. Statistiekenweergave:

   • Grafieken per land (doelpunten, winstpercentage, fair play-score).
   • Automatisch kleurenschema op basis van landvlag (bijv. rood-geel voor Spanje).

Project 17 - ReWear

Projectbriefing

Projectnaam: Tweedehands Kledingplatform "ReWear"

Datum: 15 januari 2026

Opdrachtgever: Stichting Duurzaam Jong

Contactpersoon: Mevr. F. Mulder (Projectleider Circulaire Economie)

Student: Noor

---

1. Achtergrond en Probleemstelling

Veel jongeren willen duurzamer leven, maar hebben moeite om betaalbare en milieuvriendelijke kleding te vinden. Tweedehands kleding wordt steeds populairder, maar online platforms zijn vaak onoverzichtelijk of gericht op winst in plaats van hergebruik.

Er is behoefte aan een gebruiksvriendelijk platform waar jongeren tweedehands kleding kunnen ruilen, verkopen of doneren — met aandacht voor duurzaamheid, hergebruik en eerlijke mode.

2. Doelstelling

Het doel is om een Tweedehands Kledingplatform (ReWear) te ontwikkelen dat het makkelijk maakt om kleding een tweede leven te geven.

De app moet gebruikers helpen om hun kleding te uploaden, ruilpartners te vinden en inzicht te krijgen in hun duurzame impact.

3. Doelgroepen

1. Jongeren (Hoofdgebruikers): Willen kleding verkopen, ruilen of doneren op een veilige en makkelijke manier.

2. Beheerders: Willen toezicht houden op advertenties, gebruikers en duurzaamheidsscore.

3. Duurzaamheidsorganisaties: Willen inzicht in hoeveel kleding via het platform wordt hergebruikt.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie:

  • Registratie met e-mail of Google-account.
  • Rollen: gebruiker en beheerder.

• Voor Gebruikers:

  • Kleding uploaden met foto, maat, merk en staat (nieuw, goed, gedragen).
  • Zoeken op categorie, maat of locatie.
  • Ruilfunctie: bied kleding aan in ruil voor andere items.
  • Berichten sturen via een intern chatsysteem.

• Voor Beheerders:

  • Advertenties goedkeuren of verwijderen bij misbruik.
  • Statistieken bekijken over aantal ruilen, verkopen en donaties.
  • Gebruikersaccounts beheren.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en een REST API voor mobiele koppeling.
• Beveiliging: Alleen ingelogde gebruikers kunnen kleding uploaden of berichten sturen.
• Afbeeldingen: Automatisch verkleinen bij upload om opslag te beperken.
• Data Relatie: Een gebruiker heeft meerdere advertenties (1-op-N) en berichten (1-op-N).
• Duurzaamheidslogica: De app berekent hoeveel CO₂ en water per ruil bespaard wordt.

---

BIJLAGE: Specifieke Design & Interface Wensen

De uitstraling moet fris, jong en duurzaam zijn: gebruik van pastelgroen, beige en wit met minimalistische iconen en zachte schaduwen.

1. Productoverzicht:

   • Rasterweergave van kledingstukken met foto, maat en prijs/ruiloptie.
   • Duidelijk label voor “Ruilbaar” of “Gratis”.

2. Navigatie:

   • Vaste onderbalk met iconen voor: Home, Upload, Ruilen, Chat en Profiel.

3. Duurzaamheidsweergave:

   • Kleine teller die toont hoeveel kledingstukken een gebruiker al heeft hergebruikt.
   • Groene animatie bij succesvolle ruil of donatie.

Project 18 - StyleCycle

Projectbriefing

Projectnaam: Tweedehands Verkoopplatform "StyleCycle"

Datum: 15 januari 2026

Opdrachtgever: Startup “EcoWear BV”

Contactpersoon: Dhr. T. van Aalst (Founder & CEO)

Student: Zoë

---

1. Achtergrond en Probleemstelling

De tweedehands kledingmarkt groeit snel, maar veel platforms zijn complex of vragen hoge commissies. Gebruikers zoeken een betrouwbaar en gebruiksvriendelijk platform waar ze eenvoudig hun kleding kunnen verkopen, kopen of ruilen — zonder verborgen kosten.

EcoWear BV wil een platform laten ontwikkelen dat zich richt op transparante handel, duurzaamheid en een lage drempel voor particuliere verkopers.

2. Doelstelling

Het doel is om een Tweedehands Verkoopplatform (StyleCycle) te realiseren waar gebruikers kleding kunnen aanbieden, verkopen en veilig afrekenen.

De applicatie moet betrouwbaar, mobielvriendelijk en financieel veilig zijn, met focus op een prettige gebruikerservaring en duurzaamheid.

3. Doelgroepen

1. Particuliere verkopers: Willen eenvoudig kleding uploaden, prijzen bepalen en contact met kopers onderhouden.

2. Kopers: Zoeken naar betaalbare tweedehands kleding en willen veilig kunnen betalen.

3. Beheerders: Zorgen voor controle op advertenties, betalingen en misbruik.

4. Gewenste Functionaliteiten (Must-Haves)

• Authenticatie & Profielen:

  • Registratie met e-mail of Google-account.
  • Profielpagina met beoordelingensysteem (sterren en feedback).
  • Verificatie via e-mail of telefoonnummer.

• Verkoop & Koopfunctionaliteit:

  • Kleding uploaden met titel, beschrijving, prijs, maat, categorie en foto’s.
  • Zoeken en filteren op maat, merk, prijs of staat (nieuw, gedragen, vintage).
  • Biedfunctie: gebruikers kunnen op items bieden of direct kopen (“Koop Nu”).

• Betaalsysteem:

  • Integratie met Mollie of Stripe voor iDEAL, PayPal en creditcard.
  • Geld wordt vastgehouden tot het pakket is ontvangen (“escrow”-systeem).
  • Automatische vergoeding van commissie aan het platform (5%).

• Berichten & Notificaties:

  • Chatfunctie tussen koper en verkoper met automatische vertaling (Nederlands/Engels).
  • Pushmeldingen bij biedingen, verkopen en verzending.

• Beheerfunctionaliteit:

  • Controle op verboden producten (AI-beeldherkenning op merk/logo’s).
  • Dashboard met statistieken over omzet, gebruikers en transacties.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en JavaScript voor dynamische elementen.
• Beveiliging: SSL, wachtwoordhashing (bcrypt), CSRF-bescherming en veilige betalings-API’s.
• Afbeeldingen: Compressie en automatische watermarking.
• Data Relatie: Een gebruiker heeft meerdere producten (1-op-N) en meerdere transacties (1-op-N).
• Betaallogica: Transactiestatussen: “in behandeling”, “betaald”, “verzonden”, “voltooid”.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet modern en commercieel ogen, vergelijkbaar met Vinted of Depop. Gebruik van witruimte, lichte pastelkleuren en afgeronde randen zorgt voor vertrouwen en gebruiksgemak.

1. Productoverzicht:

   • Tegelweergave met productfoto, prijs en verkoperscore.
   • Hover-effect toont snelle acties: “Bied”, “Chat”, “Favoriet”.

2. Navigatie:

   • Vaste bovenbalk met zoekveld, categorieën, verkoopknop en profielicoon.
   • Mobiel: onderbalk met iconen voor Home, Verkoop, Chat, Favorieten en Profiel.

3. Betalingsflow:

   • Stap-voor-stap checkout met adres, verzendmethode en betaling.
   • Bevestigingspagina met statusoverzicht en track-&-trace.

Project 19 - MediaMeter

Projectbriefing

Projectnaam: Kijk- en Luisteronderzoek Platform "MediaMeter"

Datum: 15 januari 2026

Opdrachtgever: Nationaal Onderzoeksbureau voor Media (NOM)

Contactpersoon: Dhr. R. Jacobs (Onderzoekscoördinator)

Student: Emma

---

1. Achtergrond en Probleemstelling

Omroeporganisaties en adverteerders willen weten hoeveel mensen naar bepaalde programma’s luisteren of kijken. Huidige methodes, zoals steekproeven en vragenlijsten, zijn onnauwkeurig en traag. Data uit streamingdiensten en podcasts worden bovendien niet goed gecombineerd met traditionele media-cijfers.

Er is behoefte aan een digitaal platform dat kijk- en luistergedrag betrouwbaar kan registreren, analyseren en visualiseren — zowel voor lineaire uitzendingen als online streams.

2. Doelstelling

Het doel is een Media Analyse Platform (MediaMeter) te ontwikkelen dat real-time inzicht geeft in kijk- en luistergedrag.

Het platform moet data verzamelen via verschillende bronnen (TV, radio, streaming, podcasts) en deze combineren in overzichtelijke rapportages.

3. Doelgroepen

1. Onderzoeksbureaus: Willen gedetailleerde data per programma, tijdstip en platform.

2. Omroepen: Willen snel zien welke programma’s goed scoren bij welke doelgroep.

3. Adverteerders: Willen weten op welke momenten hun reclames het meeste bereik hebben.

4. Gewenste Functionaliteiten (Must-Haves)

• Dataverzameling:

  • Automatisch importeren van kijk- en luisterdata via API’s van NPO, Spotify, YouTube en Nielsen.
  • Handmatige invoer mogelijk voor kleinere omroepen.
  • Dagelijkse synchronisatie en validatie van data.

• Dashboard & Visualisatie:

  • Grafieken en tabellen met bereik per zender, programma en tijdslot.
  • Vergelijkfunctie tussen radio, tv en online streams.
  • Export naar Excel, PDF of Power BI.

• Gebruikersrollen:

  • onderzoeker: data analyseren en rapportages maken.
  • beheerder: bronnen koppelen, gebruikers beheren.
  • gast: beperkte weergave van publieke trends.

• Analysetools:

  • Gemiddelde kijktijd per programma berekenen.
  • Top-10 uitzendingen per week automatisch genereren.
  • Demografische verdeling (leeftijd, regio) tonen via filters.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL, Chart.js voor grafieken.
• API-koppelingen: Integratie met NPO-Data, Spotify API en YouTube Analytics.
• Beveiliging: OAuth2-authenticatie en SSL-verbinding verplicht.
• Data Relatie: Eén uitzending kan meerdere datapunten hebben (1-op-N) per platform.
• Prestaties: Geoptimaliseerde queries en caching voor grote datasets.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet zakelijk en datagedreven zijn: donkere achtergrond, contrasterende accentkleuren (blauw/oranje) en duidelijke grafieken.

1. Dashboardweergave:

   • Line-charts voor trends per dag/week.
   • Pie-charts voor mediatype-verdeling (radio, tv, online).
   • Interactieve tijdlijn met filteropties.

2. Navigatie:

   • Sidebar met secties voor: Dashboard, Uitzendingen, Analyse, Rapportages, Instellingen.

3. Rapportages:

   • Automatische weekrapporten met top-programma’s en bereikscijfers.
   • Downloadknop voor PDF-versie met logo en datum.

Project 20 - TrendWatch

Projectbriefing

Projectnaam: Social Media Analyse Platform "TrendWatch"

Datum: 15 januari 2026

Opdrachtgever: Communicatiebureau “Insight Digital”

Contactpersoon: Mevr. J. van der Steen (Head of Strategy)

Student: Maxime

---

1. Achtergrond en Probleemstelling

Bedrijven besteden steeds meer aan online marketing, maar hebben weinig inzicht in wat er écht leeft op sociale media. Data zijn verspreid over platforms zoals Instagram, TikTok, X (Twitter) en LinkedIn. Zonder overzicht is het moeilijk om trends te herkennen of campagnes te evalueren.

Er is behoefte aan één centrale omgeving waar berichten, hashtags, volgersaantallen en reacties automatisch worden verzameld en geanalyseerd. Zo kunnen communicatieprofessionals beter inspelen op actuele thema’s.

2. Doelstelling

Het doel is om een Social Media Analyse Platform (TrendWatch) te ontwikkelen dat inzicht geeft in merkprestaties, trending onderwerpen en doelgroepgedrag.

Het platform moet automatisch data verzamelen via API’s en duidelijke grafieken tonen voor bereik, sentiment en engagement.

3. Doelgroepen

1. Marketingteams: Willen weten welke berichten goed scoren en wanneer hun publiek actief is.

2. Communicatieadviseurs: Willen trends en sentimenten in de publieke opinie volgen.

3. Bedrijfsleiding: Wil inzicht in het totale online imago van het merk.

4. Gewenste Functionaliteiten (Must-Haves)

• Dataverzameling:

  • Koppeling met social media-API’s (Instagram Graph API, X API, TikTok for Developers, LinkedIn Insights).
  • Automatische import van likes, reacties, shares, hashtags en volgersaantallen.
  • Dagelijkse synchronisatie met historische opslag (database logging).

• Analyse & Visualisatie:

  • Sentimentanalyse op basis van reacties (positief, neutraal, negatief).
  • Top 10 posts per kanaal (hoogste engagement).
  • Trendgrafieken met hashtagfrequentie per dag.
  • Heatmap met activiteit per uur van de dag.

• Gebruikersrollen:

  • analist: bekijkt en exporteert data.
  • beheerder: beheert accounts, API-sleutels en instellingen.
  • gast: alleen weergave van openbare trends.

• Rapportages:

  • Automatische maandrapporten met belangrijkste statistieken.
  • Export naar PDF of PowerPoint met grafieken en merklogo’s.

5. Technische Eisen & Randvoorwaarden

• Taal & Database: PHP (8.x), MySQL en Python voor dataverwerking (NLTK of TextBlob voor sentimentanalyse).
• API-koppelingen: OAuth 2.0 authenticatie met alle social media-platforms.
• Beveiliging: Beperk toegang via token-gebaseerde login en SSL-certificaat.
• Data Relatie: Eén merk heeft meerdere social accounts (1-op-N), en elk account heeft meerdere posts (1-op-N).
• Prestaties: Asynchrone verwerking via cronjobs voor API-updates.

---

BIJLAGE: Specifieke Design & Interface Wensen

De interface moet modern en datavisueel zijn, met een dashboardstijl vergelijkbaar met marketingtools als Hootsuite of Sprout Social.

1. Dashboard:

   • KPI-kaarten met aantal volgers, engagementrate en sentiment per kanaal.
   • Grafieken met groei over tijd per platform.
   • Donutchart voor verdeling positief/neutraal/negatief sentiment.

2. Navigatie:

   • Sidebar met secties: Dashboard, Posts, Hashtags, Analyse, Rapporten.
   • Filterbalk bovenaan met platform-selectie (Instagram, TikTok, etc.).

3. Rapportageweergave:

   • Automatische screenshotfunctie voor presentaties.
   • Kleurenthema per merk (instelbaar in instellingen).