Productvisie en scope

1.1 Doel

Dit hoofdstuk beschrijft de productvisie, doelgroep, functionele scope en expliciete scopegrenzen van OefenHub.

Het hoofdstuk is bedoeld als richtinggevend kader voor de rest van het Functioneel Ontwerp. De onderliggende FO-hoofdstukken werken de afzonderlijke domeinen verder uit.

Dit hoofdstuk legt daarom vooral vast:

• waarvoor OefenHub bedoeld is;
• voor wie OefenHub bedoeld is;
• welke functionele domeinen binnen de eerste productscope vallen;
• welke technische of organisatorische keuzes functioneel zichtbaar zijn;
• welke onderwerpen bewust buiten scope blijven;
• welke principes bij latere interpretatie van detailhoofdstukken leidend zijn.

Productvisie en scope vervangen geen usecases, schermdocumentatie, database-informatie of architectuurdocumentatie. Zij geven de functionele context waarin die bronnen gelezen moeten worden.

1.2 Bronpositie

Dit hoofdstuk gebruikt de volgende bronlagen.

Bronlaag	Betekenis voor dit hoofdstuk
FO-hoofdstukken	Domeinuitwerkingen die de productscope concretiseren per functioneel gebied.
Usecases	Procesbron voor wat gebruikers per rol daadwerkelijk kunnen doen.
Database-informatie	Bron voor domeinobjecten, readmodels, historiek, audit en opslaggrenzen.
Ontwerpbronnen	Bron voor business rules, statusmodellen, autorisatiematrix, commandregister, eventregister en popupregister.
Schermdocumentatie	Bron voor zichtbare schermcontext, acties, waarden, lege toestanden en schermgrenzen.
Architectuurdocumentatie	Contextbron voor systeemgrens, externe systemen, containers en functionele architectuurimplicaties.
Oefenmodule-documentatie	Bron voor modulespecifieke configuratie, payloads en de grens tussen generieke engine en modulelogica.
Mockups	Ondersteunende visuele bron, niet leidend voor definitieve datawaarden of autorisatieregels.

Wanneer bronnen elkaar lijken te overlappen, geldt de bronhiërarchie uit Bronnen en afbakening.

1.3 Productvisie

OefenHub is een Nederlandstalige webapplicatie waarin kinderen van circa 7 tot en met 15 jaar schoolgerelateerde oefeningen kunnen maken, herhalen, hervatten, terugkijken en waar toegestaan delen.

De applicatie ondersteunt oefenen en begeleiden in een gecontroleerde context:

• leerlingen oefenen binnen toegankelijke niveaus, categorieën en oefeningen;
• docenten richten oefenaanbod in, autoriseren leerlingen en volgen voortgang binnen hun docentcontext;
• ouders/voogden ondersteunen gekoppelde kinderen via read-only inzage, geschiedenis, resultaten en live meekijken;
• beheerders beheren centrale inhoud, accounts, modules, instellingen, meldingen en supportcontexten;
• TestDocenten kunnen testmodules en testgedrag gebruiken binnen een gecontroleerde context.

OefenHub is geen algemeen sociaal platform, geen vrij contentplatform en geen open leeromgeving waarin iedere gebruiker onbeperkt inhoud kan publiceren of raadplegen. De applicatie is ingericht rond gecontroleerde rolcontexten, relaties, niveauautorisaties, centrale categorieën, concrete oefeningconfiguraties en historische oefenruns.

1.4 Positionering

OefenHub positioneert zich functioneel als:

Aspect	Positionering
Primair product	Webapplicatie voor oefenen, voortgang, resultaten en begeleiding.
Primaire gebruiker	Leerling die oefeningen maakt binnen toegankelijke context.
Begeleidende gebruikers	Ouders/voogden en docenten met ieder eigen autorisatiegrenzen.
Beheerrol	Beheerder voor centrale inrichting, ondersteuning, meldingen en systeembeheer.
Inhoudsstructuur	Niveaus, centrale categorieën, concrete oefeningen en technische oefenmodules.
Resultaatbron	Historische oefenruns met uniforme runvelden en modulespecifieke payloads.
Communicatie	Systeemberichten, privéberichtthreads, meldingen en systeemnotificaties als gescheiden domeinen.
Technologiecontext	Nederlandstalige .NET / C# / Blazor webapplicatie met externe identity provider en relationele opslag.
Scopegrens	Geen native mobiele app, geen publieke API voor externe clients en geen vrije pagebuilder.

1.5 Doelgroepen

OefenHub ondersteunt meerdere doelgroepen. Iedere doelgroep heeft een eigen functioneel doel en eigen grenzen.

Doelgroep	Functioneel doel	Belangrijkste scopegrenzen
Leerling	Oefeningen maken, voortgang bewaren, resultaten bekijken, geschiedenis raadplegen en afgeronde oefeningen delen waar toegestaan.	Kan geen docent-, ouder-/voogd- of beheerderrol combineren; kan eigen oefenresultaten niet verwijderen; ziet alleen toegankelijke oefencontext.
Ouder/voogd	Gekoppelde kinderen ondersteunen, resultaten en geschiedenis raadplegen, PDF downloaden en live meekijken.	Read-only; kan geen oefening namens een kind starten, beantwoorden, corrigeren, afronden, opnieuw maken of delen.
Docent	Niveaus, categorieën en oefeningen beheren, leerlingen autoriseren, resultaten binnen eigen docentcontext bekijken en live meekijken.	Ziet alleen leerlingen en resultaten binnen geldige docentcontext; testresultaten worden niet als leerlinggeschiedenis behandeld.
Beheerder	Accounts, rollen, centrale categorieën, modules, content, instellingen, meldingen, templates en supportcontexten beheren.	Beheerdercontext is geen vrije bypass op eindgebruikersfunctionaliteit; beheerder kan niet live meekijken tijdens actieve leerlingruns.
TestDocent	Testmodules en modulegedrag gebruiken binnen gecontroleerde docent-/testcontext.	Niet-publieke rol; testgebruik veroorzaakt geen reguliere leerlinggeschiedenis of permanente resultaatstatistiek.

1.6 Primaire gebruiksdoelen

De productscope wordt functioneel gedreven door een aantal primaire gebruiksdoelen.

Gebruikdoel	Betekenis
Oefenen	Leerlingen kunnen een toegankelijke oefening starten, beantwoorden, onderbreken, hervatten en afronden.
Voortgang bewaren	Oefenvoortgang wordt server-side opgeslagen zodat onderbreken, hervatten en live meekijken mogelijk zijn.
Resultaten tonen	Afgeronde runs leveren samenvatting, vraagdetails, statistieken, geschiedenis en PDF-export op.
Begeleiden	Ouders/voogden en docenten kunnen voortgang en resultaten binnen hun eigen context raadplegen.
Oefenaanbod beheren	Docenten beheren niveaus, categorieën, oefeningen en modulespecifieke configuratie binnen hun docentcontext.
Toegang sturen	Docenten autoriseren leerlingen voor niveaus en oefeningen; relaties bepalen aanvullende contexten.
Samenwerken	Docenten kunnen via collaborators samenwerken aan niveau-inhoud zonder automatisch leerlingresultaten te delen.
Communiceren	Systeemberichten, privéberichten, meldingen en systeemnotificaties ondersteunen functionele communicatie.
Ondersteunen	Beheerders behandelen meldingen, ondersteunen docenten, beheren centrale inhoud en corrigeren instellingen.
Historie behouden	Resultaten, gedeelde oefeningen, audit en history blijven reconstrueerbaar bij latere wijzigingen.

1.7 Functionele hoofdscope

De eerste functionele hoofdscope bestaat uit de volgende domeinen.

Domein	Binnen scope
Account, profiel en voorkeuren	Interne applicatiecontext, profielgegevens, avatar uit vaste set, toegankelijkheid en voorkeuren.
Rollen, context en autorisatie	Roltoekenning, actieve context, combinatierollen, niet-publieke rollen en server-side autorisatie.
Applicatieschil	Header, footer, navigatie, profielmenu, badges en anti-afleidingsgedrag tijdens oefenen.
Frontpages	Read-only oriëntatieschermen per context met contentblokken, tellers en systeemnotificaties na load.
Relatiebeheer	Vriendschappen, docent-leerlingrelaties, ouder-/voogdrelaties, docent-docentrelaties en AdminAdmin-context.
Oefencatalogus	Niveaus, centrale categorieën, niveau-categorie-koppelingen, concrete oefeningen en moduleconfiguratie.
Oefenruns	Starten, hervatten, beantwoorden, voortgang, afronden, resultaten, geschiedenis en opnieuw maken.
Gedeelde oefeningen	Delen van afgeronde runs met vrienden, ontvangen shared-records en zelfstandige ontvangersruns.
Docentfunctionaliteit	Oefenaanbod, leerlingen, niveauautorisaties, resultaten, testen, collaborators en eigenaarschap.
Ouder-/voogdfunctionaliteit	Kinderenoverzicht, kindinformatie, resultaten, geschiedenis, PDF en live meekijken read-only.
Beheerderfunctionaliteit	Accounts, rollen, categorieën, modules, content, meldingen, templates, features, instellingen en support.
Berichten en communicatie	Systeemberichten, privéberichtthreads, readstates, badges en SignalR-signalen.
Meldingen	Indienen, opvolgen, behandelen, oplossen, sluiten, heropenen en doorzetten naar docent.
Live meekijken	Read-only realtime volgen van actieve oefenvoortgang door bevoegde docent of ouder/voogd.
PDF-export	Tijdelijke resultaat-PDF vanuit historische runcontext.
Contentbeheer	Beheerbare tekst binnen vaste contentblokken, vaste publieke pagina’s en footercontexten.
Popups/templates/features/notificaties	Beheerbare feedback, systeemberichttemplates, featuretoggles en systeemnotificaties binnen vaste grenzen.
Oefenmodules	Technische modulekoppeling, configuratiepayloads, runpayloads, testzichtbaarheid en migraties.

1.8 Niet-doelen van het product

OefenHub is in deze scope nadrukkelijk niet bedoeld als:

Niet-doel	Afbakening
Vrij sociaal netwerk	Vriendschappen ondersteunen gedeelde oefeningen en beperkte communicatie, maar geen algemene social-feed of profielnetwerk.
Vrij contentplatform	Docenten configureren oefeningen binnen ondersteunde modules; gebruikers kunnen geen willekeurige contentvormen publiceren.
Pagebuilder	Beheerders beheren tekst en links binnen vaste structuren, niet de volledige layout of componentstructuur.
Volwaardig LMS	OefenHub richt zich op oefenen, voortgang en begeleiding; planning, roosters, cijfersystemen of formele curriculumadministratie vallen buiten scope.
Open API-platform	Er worden geen publieke API-endpoints voor externe clients of native apps ontworpen.
Identity-provider	Keycloak of een gelijkwaardige externe identity provider blijft bronhouder voor authenticatie en credentials.
Documentmanagementsysteem	PDF’s worden tijdelijk gegenereerd vanuit historische runcontext; OefenHub beheert geen generieke documentbibliotheek.
Juridisch workflowplatform	Privacy- en contactteksten kunnen beheerbaar zijn, maar juridische acceptatieflows vallen niet automatisch binnen contentbeheer.

1.9 Platformscope

OefenHub is primair bedoeld voor tablet en desktop via een responsive webinterface. Smartphonegebruik is geen ondersteund primair gebruiksscenario. Wanneer schermgrootte of apparaatcontext onvoldoende geschikt is voor normaal leerling-, ouder/voogd-, docent- of beheerdergebruik, mag de applicatie een duidelijke Nederlandstalige melding tonen en verwijzen naar gebruik op tablet of desktop.

Binnen scope:

• Nederlandstalige webapplicatie;
• tablet- en desktopgebruik;
• responsive layout;
• browsergebaseerde interactie;
• server-side context- en autorisatiecontrole;
• realtime UI-updates waar functioneel nodig;
• tijdelijke PDF-downloads;
• externe identity-providerflow;
• mailafhandeling via externe mailvoorziening.

Buiten scope:

• native mobiele app;
• publieke API voor externe clients;
• offline-first gebruik;
• aparte mobiele backend;
• app-store distributie;
• meertalige gebruikersinterface;
• pixel-perfect beschrijving van alle responsive breekpunten in het FO.

Responsive gedrag wordt functioneel beschreven waar het zichtbaar relevant is, maar pixelperfecte CSS-uitwerking hoort niet in dit FO.

1.10 Taal- en naamgevingsscope

De gebruikersinterface van OefenHub is Nederlandstalig.

Voor de functionele scope betekent dit:

• zichtbare labels, meldingen, pagina’s en toelichtingen zijn Nederlandstalig;
• functionele rollen hebben Nederlandstalige gebruikerslabels;
• technische sleutelwaarden, databasevelden, classes, enums en backendnamen mogen Engelstalig zijn;
• het FO gebruikt waar nodig technische Engelstalige termen wanneer die als bronnaam of modelnaam fungeren.

Meertaligheid valt buiten de huidige scope. Nieuwe taalkeuzes, vertaalbeheer, localization-resources of meertalige contentvarianten zijn dus geen impliciet onderdeel van contentbeheer.

1.11 Architectuurscope

OefenHub wordt functioneel gezien als één centraal softwaresysteem met een webapplicatie en eigen database.

Architectuuronderdeel	Functionele betekenis
OefenHub Webapp	Primaire gebruikersinterface en applicatielaag voor businesslogica, autorisatie, realtime gedrag, jobs en PDF-generatie.
OefenHub Database	Opslag voor domeindata, configuratie, historie, auditrecords, operationele voortgang en readmodelbronnen.
Keycloak	Externe identity provider voor authenticatie, registratie, sessies en credential-lifecycle.
Mailvoorziening	Externe afhandeling voor verificaties, uitnodigingen en notificatiegerelateerde e-mailprocessen.
SignalR of gelijkwaardige realtime techniek	Transport voor live updates, badges en live meekijken; geen bron van waarheid.
TickerQ of gelijkwaardige scheduler	Periodieke verwerking voor cleanup, testruns, verlopen heropentermijnen en vergelijkbare taken.
QuestPDF of gelijkwaardige PDF-generator	Tijdelijke PDF-generatie vanuit historische resultaatcontext.

De functionele architectuurcontext staat verder uitgewerkt in Functionele architectuurcontext.

1.12 Externe identity-providergrens

Authenticatie, registratie, wachtwoorden, credentialstatus, sessies en credential lifecycle zijn geen OefenHub-domeinfunctionaliteit.

Voor OefenHub geldt:

• OefenHub valideert geen wachtwoorden;
• OefenHub slaat geen wachtwoorden, tokens, secrets of identity-providerinterne sessiedata op als domeindata;
• OefenHub gebruikt de identity-provideruitkomst alleen als startpunt voor interne accountcontext;
• een geslaagde externe login geeft pas OefenHub-toegang na interne account-, status-, rol- en contextcontrole;
• e-mailadres als authenticatiegegeven blijft aan de identity-providergrens gebonden;
• OefenHub beheert aanvullend applicatieprofiel, rollen, instellingen en domeintoegang.

Wanneer interne provisioning of contextbepaling na een geslaagde externe login faalt, ontstaat geen reguliere OefenHub-sessie.

1.13 Rol- en contextscope

Rollen bepalen niet alleen zichtbare navigatie, maar ook de functionele context waarin acties worden uitgevoerd.

Belangrijke scopeprincipes:

• de rol Leerling is niet combineerbaar met ouder/voogd, docent, beheerder of TestDocent;
• ouder/voogd, docent en beheerder mogen gecombineerd voorkomen;
• TestDocent is een niet-publieke rol;
• beheerder en TestDocent worden niet via publieke selfservice toegekend;
• actieve context wordt server-side bepaald;
• zichtbare UI is nooit autorisatiebewijs;
• iedere route, mutatie, detailweergave, export en liveactie voert opnieuw contextcontrole uit.

De gedetailleerde rol- en contextregels staan in Rollen, context en autorisatie.

1.14 Leerlinggerichte scope

Voor leerlingen ligt de kernscope bij oefenen.

Binnen scope voor leerlingen:

• toegankelijke categorieën en oefeningen bekijken;
• oefeningstartpagina openen;
• nieuwe run starten;
• niet-afgeronde run hervatten;
• vragen beantwoorden;
• waar toegestaan Geen idee gebruiken;
• resultaat na afronding bekijken;
• geschiedenis raadplegen;
• resultaat-PDF downloaden;
• afgeronde oefening opnieuw maken;
• oefening delen met vrienden wanneer toegestaan;
• ontvangen gedeelde oefeningen starten of verwijderen uit eigen overzicht;
• eigen berichten, systeemberichten en meldingen gebruiken.

Buiten scope voor leerlingen:

• eigen oefengeschiedenis verwijderen;
• docent- of ouder-/voogdcontext combineren;
• oefeningen namens anderen maken;
• oefeningconfiguratie wijzigen;
• centrale categorieën beheren;
• live meekijkers inhoudelijk sturen;
• beheer- of supportdata raadplegen.

Tijdens actieve oefening heeft anti-afleidingsgedrag prioriteit: badges, meldingsterugkoppelingen en systeemnotificatie-overlays worden visueel uitgesteld zonder dat onderliggende data verloren gaat.

1.15 Ouder-/voogdgerichte scope

Voor ouders/voogden ligt de kernscope bij read-only ondersteuning.

Binnen scope:

• gekoppelde kinderen bekijken;
• kindinformatie raadplegen;
• resultaten en geschiedenis van gekoppelde kinderen bekijken;
• filters toepassen binnen toegestane kinddataset;
• resultaatdetails raadplegen;
• PDF downloaden vanuit geautoriseerde historische runcontext;
• online status en livebeschikbaarheid bekijken;
• live meekijken read-only;
• eigen ouder-/voogdrelatie beëindigen waar toegestaan.

Buiten scope:

• oefening namens kind starten;
• oefening namens kind beantwoorden;
• oefening namens kind hervatten of afronden;
• antwoorden corrigeren;
• resultaten verwijderen of herschrijven;
• docentautorisaties aanpassen;
• docentcontext impliciet gebruiken binnen ouder-/voogdroutes.

De actieve ouder-/voogdrelatie is een voortdurende autorisatievoorwaarde voor alle ouder-/voogdacties.

1.16 Docentgerichte scope

Voor docenten ligt de kernscope bij oefenaanbod, leerlingtoegang en begeleiding.

Binnen scope:

• docent-frontpage bekijken;
• oefenaanbod openen;
• niveaus beheren binnen eigen eigenaar- of collaboratorcontext;
• centrale categorieën koppelen aan niveaus;
• nieuwe centrale categorie voorstellen of aanmaken via ondersteunde flow;
• concrete oefeningen aanmaken, configureren, bewerken en activeren;
• technische module selecteren voor een oefening;
• oefeningen testen zonder reguliere leerlinggeschiedenis;
• leerlingen binnen docentcontext bekijken;
• niveauautorisaties toekennen of intrekken;
• resultaten binnen eigen docentcontext bekijken;
• resultaat-PDF downloaden binnen eigen docentcontext;
• online leerlingen bekijken;
• live meekijken read-only;
• collaborators beheren waar toegestaan;
• eigenaarschap overdragen volgens domeinregels.

Buiten scope:

• resultaten van leerlingen buiten eigen docentcontext raadplegen;
• ouder-/voogdinzage impliciet gebruiken;
• centrale categorie-identiteit vrij wijzigen zodra gedeeld gebruik bestaat;
• technische modulecode wijzigen;
• testresultaten als gewone leerlingresultaten opslaan;
• live meekijken buiten geldige relatie- en autorisatiecontext.

1.17 Beheerdersscope

Voor beheerders ligt de kernscope bij centrale inrichting, ondersteuning, audit en correctie.

Binnen scope:

• beheerder-frontpage raadplegen;
• accounts en rollen beheren;
• niet-publieke rollen toekennen of intrekken;
• accounts uitschakelen, heractiveren of anonimiseren;
• centrale categorieën beheren en migreren;
• modules beheren, testzichtbaarheid wijzigen en modulemigraties uitvoeren;
• contentblokken, vaste pagina’s en footerinhoud beheren;
• popups, templates, features, systeemnotificaties en instellingen beheren;
• meldingen behandelen;
• docentondersteuning uitvoeren binnen expliciete supportcontext;
• beheerlogging en history raadplegen.

Buiten scope:

• beheerdercontext gebruiken als vrije bypass op eindgebruikersfunctionaliteit;
• live meekijken tijdens actieve leerlingruns;
• wachtwoorden of credentials beheren;
• identity-providerinterne sessies beheren;
• willekeurig eindgebruikersresultaten wijzigen;
• historische runs herschrijven door categorie- of modulebeheer;
• vrije pagina-layouts, componenten of routes bouwen via beheer.

Beheerderacties blijven server-side geautoriseerd, gescopeerd en auditbaar.

1.18 Oefeninhoud en catalogusscope

Oefeninhoud is hiërarchisch en functioneel opgebouwd.

Laag	Betekenis
Niveau	Onderwijscontext zoals groep, klas, leerjaar of vergelijkbare oefencontext, met eigenaar en eventueel collaborators.
Centrale categorie	Gedeelde semantische categorie met centrale naam, kleur en icoon.
Niveau-categorie-koppeling	Koppeling tussen niveau en centrale categorie, inclusief volgorde en afgeleide zichtbaarheid.
Concrete oefening	Door docent ingerichte oefening binnen niveau en categorie, gekoppeld aan precies één technische module.
Technische module	Codecomponent die configuratie, generatie, antwoordcontrole en moduleweergave levert.
Oefenrun	Unieke uitvoering van een concrete oefening door een gebruiker.

Binnen scope:

• centrale categorie-identiteit;
• docentniveaus;
• open en privé niveaucontext;
• concrete oefeningconfiguratie;
• modulepayloads;
• docenttesten;
• historische runcontext;
• categorie- en modulemigratie met audit.

Buiten scope:

• onbeperkte vrije oefentypen zonder module;
• docentbeheer van technische modulecode;
• automatische inhoudelijke proof van backwards compatibility;
• herschrijven van historische runs bij actuele hernoeming of migratie.

1.19 Resultaat-, geschiedenis- en exportscope

Resultaten en geschiedenis zijn gebaseerd op historische oefenruns.

Binnen scope:

• resultaat na afronding;
• geschiedenis per oefening en brede geschiedenis;
• resultaatdetail met vraag- en antwoordinformatie;
• uniforme statistieken;
• duplicaat- en opnieuw-maakcontext;
• PDF-export vanuit historische runcontext;
• docent- en ouder-/voogdinzage binnen eigen autorisatiegrens.

Belangrijke grenzen:

• niet-afgeronde runs zijn geen afgeronde geschiedenisregels;
• test runs van docenten tellen niet als gewone leerlingresultaten;
• PDF-download maakt geen permanent PDF-domeinrecord aan;
• resultaatweergave en export wijzigen geen run;
• actuele naamgeving of latere configuratiewijzigingen herschrijven historische resultaatcontext niet.

1.20 Communicatie- en notificatiescope

OefenHub ondersteunt meerdere communicatievormen die gescheiden blijven.

Communicatievorm	Scope
Systeemberichten	Gebruikergebonden systeemcommunicatie met eventuele domeinverwijzing.
Privéberichtthreads	Relatie- of systeemcontextgebonden privécommunicatie.
Thread-events	Systeemachtige gebeurtenissen binnen een privéthread.
Meldingen	Ticketdomein voor problemen, fouten, wijzigingsverzoeken en opvolging.
Systeemnotificaties	Planbare overlays na frontpageload voor doelgroepgerichte mededelingen.
Popupfeedback	Actie-, fout- en bevestigingsfeedback via popupkeys.
Realtime signalen	Transport voor badges, mailboxupdates en live meekijken.

Deze communicatievormen mogen in de UI samen zichtbaar zijn, maar blijven verschillende domeinen met eigen brondata, lifecycle en autorisatie.

Buiten scope:

• vrije chat met beheerders buiten meldingcontext;
• vrije HTML of actieve inhoud in berichten;
• generieke bijlagen voor privéberichten binnen de initiële scope;
• systeemnotificaties gebruiken als vervanging voor verplichte mailbox-systeemberichten;
• popupteksten dupliceren in usecases of FO-hoofdstukken waar popupregister leidend is.

1.21 Content- en vaste-paginascope

Contentbeheer maakt tekstuele inhoud beheerbaar zonder de applicatie in een pagebuilder te veranderen.

Binnen scope:

• frontpagecontent binnen vaste blokken;
• vaste publieke pagina’s zoals Over OefenHub, Privacybeleid en Contact;
• footerinhoud;
• URL-records;
• footersecties;
• footerlinktoewijzingen;
• wijzigingsgeschiedenis;
• cacheverversing na opslaan.

Buiten scope:

• nieuwe routes via contentbeheer;
• vrije componentplaatsing;
• layout- of CSS-beheer;
• nieuwe vaste pagina’s via GUI;
• formulierlogica aanpassen;
• systeemnotificaties, popups, templates of featuregedrag nabootsen met contentblokken.

1.22 Meldingen- en supportscope

Het meldingenproces ondersteunt eindgebruikers en beheerders bij problemen, inhoudelijke fouten, wijzigingsverzoeken en overige situaties.

Binnen scope:

• melding indienen;
• eigen meldingen bekijken;
• reageren;
• eigen melding sluiten;
• oplossing accepteren;
• melding heropenen binnen termijn;
• beheerderoverzicht;
• interne en externe discussie;
• oplossen en sluiten;
• heropenen door beheer;
• doorzetten naar docent;
• technische snapshot;
• compacte history.

Buiten scope:

• automatische samenvoeging van dubbele meldingen;
• vrij helpdeskchatkanaal buiten meldingcontext;
• bijlagen binnen de initiële scope;
• zoeken in compacte history als eerste zoekscope;
• generieke doorstuurfunctie voor gewone eindgebruikers.

1.23 Beheerbare versus codegedreven onderdelen

OefenHub maakt expliciet onderscheid tussen beheerbare inhoud en codegedreven structuur.

Onderdeel	Beheerbaar	Codegedreven / buiten gewone beheeractie
Contentblokken	Titel, tekst, label waar ondersteund.	Layout, componenttype, volgorde, renderlocatie.
Vaste pagina’s	Tekstuele blokinhoud.	Routes, formulierlogica, nieuwe pagina’s.
Footer	Tekst, secties, linktoewijzingen binnen toegestane context.	Kolomstructuur, responsive volgorde, nieuwe contexten.
Popups	Bestaande beheerbare tekstvelden.	Popupkeys, technische acties, custom renderers.
Systeemberichttemplates	Onderwerp en tekst van bestaande templates.	Nieuwe technische referenties of routering.
Features	Bestaande togglewaarden.	Nieuwe featurekeys zonder code/migratie.
Systeeminstellingen	Waarde van bestaande instellingen.	Nieuwe sleutelsets of vrije runtimevariabelen.
Systeemnotificaties	Doelgroep, tekst, planning en weergaveregel.	Mailboxberichten of popupregistergedrag.
Oefenmodules	Metadata, actiefstatus, testzichtbaarheid en migratieacties.	Modulecode en modulespecifieke interne logica.

1.24 Gegevens- en bron-van-waarheidprincipes

De productscope rust op enkele vaste gegevensprincipes.

Principe	Betekenis
Server-side autorisatie	Clientstate, zichtbare UI, routeparameters en browsergeschiedenis verruimen toegang nooit.
Historische reconstructie	Resultaten, PDF’s, gedeelde oefeningen en audit gebruiken historische context waar relevant.
Readmodels zijn afgeleid	Tellers, badges, frontpageblokken en overzichten vervangen de brondata niet.
Runs zijn bron voor resultaten	ExerciseRuns en voortgangspayloads blijven leidend voor resultaat, geschiedenis, PDF en live meekijken.
Relaties begrenzen toegang	Vriendschap, docentrelatie en ouder-/voogdrelatie bepalen toegestane communicatie, resultaatinzage en livecontext.
Audit voor beheerimpact	Beheeracties met domeinimpact worden herleidbaar vastgelegd.
Geen dataverlies door UI-uitstel	Anti-afleiding of realtime-uitstel mag onderliggende berichten, readstates of voortgang niet verliezen.
Geen onnodige nieuwe kolommen	FO-aanscherping introduceert geen extra databasevelden wanneer bestaande payloadvelden of brondata volstaan.

1.25 Privacy- en veiligheidsprincipes

OefenHub verwerkt leerling-, ouder-/voogd-, docent- en beheercontexten. Privacy- en veiligheidsgrenzen zijn daarom productscope, niet alleen technische randvoorwaarde.

Voor de productscope geldt:

• toegang wordt per actie server-side gecontroleerd;
• foutmeldingen lekken geen technische payloads, tokens, stacktraces of gevoelige inhoud;
• resultaatdetails worden alleen getoond binnen geldige rol-, relatie- en objectcontext;
• ouder-/voogdinzage is read-only;
• docentinzage is beperkt tot eigen docentcontext;
• beheerderinzage is functioneel begrensd en auditbaar;
• accountanonimisering behoudt noodzakelijke historische reconstructie zonder actuele persoonsgegevens zichtbaar te houden;
• vrije upload van profielfoto’s of leerlingbestanden valt buiten scope;
• gebruikersafbeeldingen komen uit een vooraf gedefinieerde set.

1.26 Featuretoggles en beschikbaarheid

Sommige functionaliteit kan sitebreed of contextueel beschikbaar of niet beschikbaar zijn.

Featuretoggles kunnen de beschikbaarheid beïnvloeden van onder meer:

• registratie;
• inloggen;
• vriendschappen;
• privéberichten;
• live meekijken;
• oefeningen delen;
• testoefeningen;
• meldingen;
• toegankelijkheid.

Featuretoggles verwijderen geen bestaande domeindata. Zij bepalen alleen of nieuwe acties of zichtbare functies beschikbaar zijn binnen de geldende context.

Voorbeelden:

• uitschakelen van privéberichten verwijdert geen bestaande threads;
• uitschakelen van meldingen verwijdert geen bestaande tickets;
• uitschakelen van delen verwijdert geen bestaande gedeelde oefeningen;
• uitschakelen van live meekijken verwijdert geen auditrecords;
• uitschakelen van toegankelijkheid verwijdert geen opgeslagen voorkeuren.

1.27 Initiële scope-afbakening

De initiële scope richt zich op een brede maar begrensde webapplicatie.

Binnen de initiële scope vallen de kernflows rond:

• accountcontext;
• rollen en autorisatie;
• oefencatalogus;
• oefenruns;
• resultaten;
• geschiedenis;
• PDF-export;
• delen;
• relaties;
• berichten;
• meldingen;
• live meekijken;
• contentbeheer;
• beheerderondersteuning;
• modulebeheer.

Onderwerpen die niet automatisch binnen de initiële scope vallen:

• native mobiele app;
• publieke externe API;
• meertaligheid;
• vrije bestandsbijlagen;
• vrije contentupload;
• uitgebreide LMS-functionaliteit;
• automatische module-backwards-compatibilitybewijzen;
• formele juridische akkoordworkflow;
• volledige SRS-traceability per requirementregel;
• technische implementatieplanning.

1.28 Scopegrenzen per aangrenzend documenttype

Documenttype	Wat hoort daar primair thuis
FO	Functionele samenhang, domeingrenzen, rolgedrag, bron-van-waarheid, scope en gebruikersgedrag.
Usecases	Procesverloop, actoractie, alternatieve flows, foutflows en acceptatiecriteria per handeling.
Schermdocumentatie	Zichtbare schermonderdelen, acties, lege toestanden, labels, waardelagen en schermspecifiek gedrag.
Database-informatie	Domeinobjecten, tabellen, relaties, opslaggrenzen, readmodels, history en auditobjecten.
Ontwerpbronnen	Business rules, autorisatiematrix, commandregister, eventregister, popupregister en statusmodellen.
Architectuur	Systeemgrens, containers, componenten, technische context en interne bouwblokken.
SRS	Testbare requirements en traceerbaarheid op requirementniveau.
Mockups	Visuele interpretatie en layoutondersteuning, niet de definitieve functionele waarheid.

1.29 Binnen scope versus buiten scope

Onderwerp	Binnen scope	Buiten scope
Webapplicatie	Nederlandstalige responsive webapp.	Native mobiele app.
API	Interne servercommunicatie voor webappgedrag waar functioneel zichtbaar.	Publieke API voor externe clients.
Authenticatie	Externe identity-providerflow en interne applicatiecontext.	Eigen wachtwoordvalidatie of credentialbeheer.
Rollen	Leerling, ouder/voogd, docent, beheerder en TestDocent.	Vrije rolcreatie door eindgebruikers.
Oefenen	Starten, hervatten, antwoorden, afronden en resultaat.	Oefenen namens een andere gebruiker.
Oefenmodules	Modulekoppeling, configuratiepayloads, testbaarheid en beheermetadata.	Modulecodebeheer via GUI.
Resultaten	Historische runcontext, statistieken, geschiedenis en PDF.	Resultaten herschrijven via resultaatweergave.
Delen	Afgeronde oefeningen delen met vrienden waar toegestaan.	Publiek publiceren van oefenruns.
Berichten	Systeemberichten en privéthreads binnen relatiecontext.	Vrije open chat of social feed.
Meldingen	Ticketflow voor opvolging en beheerbehandeling.	Helpdeskchat buiten meldingcontext.
Content	Vaste contentblokken en footerlinks.	Pagebuilder of routebeheer.
Beheer	Centrale inrichting, support en audit.	Vrije bypass op eindgebruikersdata.
PDF	Tijdelijke resultaatdownload.	Permanent documentarchief.
Realtime	Badges, live meekijken en readmodelupdates.	Realtime als bron van waarheid.

1.30 Open scope-aandachtspunten

Dit hoofdstuk introduceert geen nieuwe open punten, maar verwijst naar het centrale hoofdstuk Open punten en buiten scope.

Voor de productvisie en scope zijn met name de volgende bestaande aandachtspunten relevant:

Onderwerp	Scopebetekenis
Tellerdefinities	Tellers moeten per frontpage en overzicht definitief blijven aansluiten op brondata, statusfilters en contextfilters.
Contactformulier	Tekstuele contactpagina valt onder contentbeheer; formuliergedrag vraagt aparte functionele specificatie wanneer verder uitgewerkt.
Module-renderhulpen	Complexe notatie kan per module een export- of renderrepresentatie vragen.
Popupteksten	Popupkeys zijn leidend; definitieve teksten en knoplabels horen in popupregister/beheer.
Placeholderlijsten	Template- en popupplaceholders moeten per domein consistent blijven.
Gedeelde-oefening-systeemberichtlink	De definitieve verwijzingsroute voor gedeelde oefeningen in systeemberichten moet documentatiebreed consistent zijn.

1.31 Lege toestanden binnen productscope

Lege toestanden zijn normaal en vormen niet automatisch een fout.

Voorbeelden:

• gebruiker heeft nog geen rolcontext;
• leerling heeft geen toegankelijke oefeningen;
• leerling heeft geen geschiedenis;
• leerling heeft geen vrienden om mee te delen;
• docent heeft nog geen leerlingen;
• docent heeft nog geen niveaus;
• ouder/voogd heeft nog geen gekoppelde kinderen;
• beheerder heeft geen recente beheerwijzigingen;
• mailbox bevat geen berichten;
• meldingenoverzicht bevat geen meldingen;
• systeemnotificatiebeheer bevat geen actieve notificaties;
• contentbeheer bevat nog geen ingevulde optionele contentblokken.

Een lege toestand mag uitleg en veilige vervolgactie bieden, maar mag geen autorisatie- of technische details lekken.

1.32 Fouttoestanden binnen productscope

Fouttoestanden moeten veilig worden afgehandeld.

Voorbeelden:

• interne accountcontext kan na identity-providerlogin niet worden opgebouwd;
• rolcontext ontbreekt of is ongeldig;
• routeparameter verwijst naar niet-toegankelijk object;
• relatiecontext is beëindigd;
• niveauautorisatie is ingetrokken;
• oefening is in onderhoud gezet;
• module is niet meer beschikbaar;
• run is niet afgerond terwijl resultaatdetail wordt gevraagd;
• PDF-export faalt;
• realtime verbinding valt weg;
• feature is uitgeschakeld;
• content- of templatevalidatie faalt;
• beheeractie mist geldige beheercontext.

Bij fouttoestanden geldt:

• geen gedeeltelijke data buiten autorisatie tonen;
• geen technische stacktraces, tokens of secrets tonen;
• geen clientstate vertrouwen;
• geen stille datamutatie uitvoeren;
• veilige terugkeer naar een toegankelijke context waar mogelijk;
• audit of securitylogging toepassen waar relevant.

1.33 Relatie tot andere FO-hoofdstukken

Hoofdstuk	Relatie
Bronnen en afbakening	Bepaalt bronhiërarchie, interpretatieregels en wat het FO wel/niet beschrijft.
Rollen, context en autorisatie	Werkt rolcombinaties, contextbepaling en autorisatiegrenzen uit.
Applicatieschil, header, footer en navigatie	Werkt de webapplicatieschil en responsive navigatie uit.
Frontpages en overzichtsschermen	Werkt de read-only oriëntatieschermen, tellers en contextfrontpages uit.
Account, profiel en voorkeuren	Werkt interne accountcontext, profiel, voorkeuren, toegankelijkheid en anonimisering uit.
Relatiebeheer	Werkt vriendschappen, ouder-/voogdrelaties, docentrelaties en docent-docentrelaties uit.
Oefencatalogus, niveaus, categorieën en oefeningen	Werkt de inhoudsstructuur en catalogusgrenzen uit.
Leerling: oefenen, voortgang en resultaten	Werkt de kern van leerlingruns en resultaatgedrag uit.
Gedeelde oefeningen	Werkt delen, ontvangen, shared-records en ontvangersruns uit.
Docentfunctionaliteit	Werkt oefenaanbod, leerlingen, autorisaties, resultaten en samenwerking uit.
Ouder-/voogdfunctionaliteit	Werkt read-only ouder-/voogdinzage, kinderen, resultaten en live meekijken uit.
Beheerderfunctionaliteit	Werkt centrale beheer- en supportscope uit.
Berichten, communicatie en notificaties	Werkt mailbox, privéberichten, readstates, badges en systeemnotificaties uit.
Meldingen en ticketafhandeling	Werkt ticket- en meldingenscope uit.
Live meekijken	Werkt read-only realtime meekijken uit.
Contentbeheer, vaste pagina’s en footer	Werkt contentbeheer zonder pagebuilder uit.
Popups, templates, features en systeemnotificaties	Werkt beheerbare feedback, toggles, templates en notificaties uit.
PDF-export en resultaatpresentatie	Werkt resultaatweergave en PDF-export uit.
Functionele beslisregels en uitgangspunten	Bundelt domeinoverstijgende regels en beslisprincipes.
Open punten en buiten scope	Houdt resterende open punten en expliciete buiten-scopeonderwerpen bij.
Schermlaag en UX-specificaties	Werkt schermlaagprincipes, UX-regels en bronpositie uit.
Oefenmodules en modulepayloads	Werkt modulecontract, payloadlagen en schema-evolutie uit.
Functionele architectuurcontext	Verbindt functionele scope met systeemgrens, containers en architectuurimplicaties.

1.34 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — scope en uitgangspunten	Intro, scope en uitgangspunten
Technisch Ontwerp — architectuuroverzicht	Architectuuroverzicht en solution-opbouw
Technisch Ontwerp — rolflows	Rollenflows technisch
FO — bronnen en afbakening	Bronnen en afbakening
FO — rollen, context en autorisatie	Rollen, context en autorisatie
FO — frontpages en overzichtsschermen	Frontpages en overzichtsschermen
FO — oefencatalogus	Oefencatalogus, niveaus, categorieën en oefeningen
FO — leerling oefenen, voortgang en resultaten	Leerling: oefenen, voortgang en resultaten
FO — docentfunctionaliteit	Docentfunctionaliteit
FO — ouder-/voogdfunctionaliteit	Ouder-/voogdfunctionaliteit
FO — beheerderfunctionaliteit	Beheerderfunctionaliteit
FO — open punten en buiten scope	Open punten en buiten scope
FO — functionele architectuurcontext	Functionele architectuurcontext
Usecases — startpunt	Usecases
Database-informatie — intro	Database-informatie
Ontwerpbron — business rules	Business rules
Ontwerpbron — autorisatiematrix	Autorisatiematrix
Ontwerpbron — statusmodellen	Statusmodellen
Ontwerpbron — command-register	Command-register
Ontwerpbron — event-register	Event-register
Ontwerpbron — popup-register	Popup-register
Architectuur — system context	C4 niveau 1 — system context
Architectuur — container diagram	C4 niveau 2 — container diagram
Architectuur — component diagram	C4 niveau 3 — component diagram
Oefenmodules — intro	Oefenmodules
Schermdocumentatie — intro	Schermdocumentatie