Open punten en buiten scope

20.1 Doel

Dit hoofdstuk bewaakt de grens tussen het Functioneel Ontwerp, vervolguitwerking en onderwerpen die bewust buiten de huidige FO-scope vallen.

Het doel is niet om details uit andere hoofdstukken opnieuw te beschrijven. Dit hoofdstuk legt vooral vast:

• welke reviewbesluiten documentatiebreed zijn genomen;
• welke vervolguitwerking niet meer in het FO thuishoort, maar in TO, SRS, schermdocumentatie, ontwerpbronnen, registers of implementatie;
• welke onderwerpen alleen na een aparte scopebeslissing kunnen worden toegevoegd;
• welke onderwerpen bewust buiten het Functioneel Ontwerp vallen;
• welke interpretatieregels blijven gelden wanneer een vervolgonderwerp later wordt uitgewerkt.

Dit hoofdstuk bevat geen open FO-blokkers. Wanneer een punt in dit hoofdstuk als vervolgwerk wordt genoemd, betekent dit dat de functionele hoofdlijn in het FO is vastgesteld en dat detailuitwerking elders hoort.

20.2 Domeinafbakening

Onderdeel	Binnen dit hoofdstuk	Buiten dit hoofdstuk
Vastgelegde reviewbesluiten	Centrale vastlegging van besluiten die tijdens FO-review documentatiebreed relevant zijn geworden.	Volledige herhaling van de betrokken domeinhoofdstukken.
Vervolguitwerking	Benoemen welk vervolg naar TO, SRS, schermdocumentatie, ontwerpbronnen, registers of implementatie hoort.	De volledige technische of requirementmatige uitwerking zelf.
Buiten scope	Expliciet benoemen wat niet onder het FO valt of niet in de huidige functionele scope zit.	Roadmap-, sprint-, budget- of releaseplanning.
Scopebewaking	Voorkomen dat buiten-scopeonderwerpen impliciet als verplichting worden gelezen.	Besluiten nemen over nieuwe scope zonder aparte productkeuze.
Documentatieonderhoud	Benoemen welk onderhoud structureel nodig blijft na FO-wijzigingen.	Losse onderhoudstaken als open FO-punt presenteren.

20.3 Status van resterende punten

Categorie	Status in het FO	Betekenis
Open functionele FO-beslissingen	Geen	Er staat geen bekende functionele keuze open die FO-afronding blokkeert.
Vastgelegde reviewbesluiten	Aanwezig	Besluiten die meerdere hoofdstukken raken zijn hieronder centraal benoemd.
Detailuitwerking elders	Aanwezig	De FO-hoofdlijn is vastgesteld; detail hoort in SRS, TO, schermdocumentatie, ontwerpbronnen of implementatie.
Buiten scope	Aanwezig	Deze onderwerpen zijn geen huidige functionele verplichting.
Normaal documentatieonderhoud	Aanwezig	Linkcontrole, registercontrole en bronconsistentie blijven reguliere onderhoudstaken.

20.4 Interpretatieregels

Voor alle vervolgonderwerpen en buiten-scopegrenzen gelden de volgende regels.

• Een vervolgonderwerp verruimt geen autorisatie.
• Een vervolgonderwerp introduceert geen nieuwe bron van waarheid zonder expliciete FO-wijziging.
• Een buiten-scopeonderwerp is geen impliciete requirement.
• Server-side controles blijven leidend, ook wanneer detailuitwerking nog naar TO of SRS gaat.
• Historische context, audit en bron-van-waarheidregels uit de domeinhoofdstukken blijven gelden.
• Zichtbare UI, mockupwaarden, clientstate, filters, browsergeschiedenis en bookmarks zijn nooit autorisatiebewijs.
• Wanneer een vervolgonderwerp meerdere domeinen raakt, moet de uitwerking documentatiebreed consistent worden verwerkt.
• Wanneer een vervolgonderwerp alleen technische implementatie raakt, hoort de uitwerking in TO.
• Wanneer een vervolgonderwerp testbaar gedrag betreft, hoort de uitwerking in SRS.
• Wanneer een vervolgonderwerp zichtbare schermdetails betreft, hoort de uitwerking in schermdocumentatie.

20.5 Vastgelegde reviewbesluiten

20.5.1 Systeemcommunicatie voor gedeelde oefeningen

Voor systeemcommunicatie rond gedeelde oefeningen is de verwijzingsroute vastgesteld.

Onderdeel	Besluit
SystemMessages.EntityType	SharedExercise
SystemMessages.EntityId	Verwijst naar SharedExercises.Id.
Doel	Het systeembericht is een ingang naar de gedeelde-oefeningcontext.
Geen automatische actie	Lezen of openen van het bericht start geen oefening, maakt geen ontvangerrun aan en wijzigt geen resultaatdata.
Autorisatie	De vervolgroute controleert server-side of de ontvanger toegang heeft tot het gedeelde record.

Dit besluit hoort consistent terug te komen in gedeelde oefeningen, berichten/communicatie, database-informatie en berichtroutering.

Raakvlakken:

• Gedeelde oefeningen
• Berichten, communicatie en notificaties
• Database-informatie — communicatie en notificaties
• Database-informatie — oefenruns, delen en voortgang

20.5.2 Tijdelijke basis- en extractiedocumenten zijn geen duurzame FO-bron

Tijdelijke ruwe basisdocumenten, conversiebestanden, zipnamen, tussenextracties en overdrachtsnotities hebben geen blijvende bronstatus binnen het FO.

De duurzame bronpositie ligt bij:

• usecases;
• database-informatie;
• ontwerpbronnen;
• schermdocumentatie;
• oefenmodule-documentatie;
• architectuurdocumentatie;
• mockups als visuele referentie;
• FO-hoofdstukken en registers.

Bronbeleid en bronhiërarchie blijven centraal beschreven in Bronnen en afbakening, Bronnenoverzicht en Extractie-notities.

20.5.3 Versie-informatie blijft centraal

Het FO-versienummer wordt niet door losse hoofdstukken herhaald. De centrale status en versie-identificatie staan alleen in Intro.

Andere FO-hoofdstukken mogen verwijzen naar actuele bronposities, scopegrenzen of vervolguitwerking, maar moeten geen eigen versie-uitleg of releasepad bevatten.

20.6 Afgedichte vervolguitwerking en doorlopend onderhoud buiten het FO

De onderstaande onderwerpen zijn geen open FO-blokkers. Een deel is inmiddels afgedicht in Software Requirements Specification, Technisch Ontwerp, schermdocumentatie, ontwerpbronnen of oefenmoduledossiers. Wat overblijft is regulier onderhoud: bij nieuwe functies, nieuwe modules of gewijzigde schermen moet opnieuw worden gecontroleerd of de juiste bronlaag geraakt wordt.

20.6.1 Tellerdefinities en readmodeldetails

Frontpages, overzichten, badges en beheersamenvattingen tonen op meerdere plaatsen tellers of compacte aantallen.

De functionele hoofdregel blijft dat een teller nooit impliciet of op basis van mockupwaarden wordt geïmplementeerd. De SRS bevat de centrale readmodel-NFR's en tellergrenzen; het Technisch Ontwerp bevat de technische vertaling naar queryvorm, cache, materialisatie, fallback en performance. Nieuwe of gewijzigde tellers moeten langs dezelfde aspecten worden gecontroleerd.

Aspect	Onderhoudscontrole
Bronobject	Welk recordtype of readmodel wordt geteld.
Context	Welke rol-, relatie-, niveau-, categorie-, oefening- of beheercontext begrenst de telling.
Statusfilter	Welke statussen meetellen en welke worden uitgesloten.
Activiteitsfilter	Of inactieve, verlopen, soft-deleted of historische records meetellen.
Tijdvenster	Of een periode geldt, zoals vandaag, afgelopen week, afgelopen 31 dagen of alles.
Testdata	Of testmodules, testzichtbare modules of docenttestruns meetellen.
Distinct-logica	Of dubbele koppelingen worden samengenomen of afzonderlijk geteld.
Autorisatie	Of uitsluitend data wordt geteld die de gebruiker binnen de actuele context mag zien.

Raakvlakken:

• Frontpages en overzichtsschermen
• Applicatieschil, header, footer en navigatie
• Berichten, communicatie en notificaties
• Meldingen en ticketafhandeling
• Beheerderfunctionaliteit
• Technisch Ontwerp — readmodels, tellers, badges, caching en materialisatie

20.6.2 Popupkeys en popupregisterconsistentie

Usecases, schermdocumentatie en FO-hoofdstukken verwijzen naar popupkeys. Volledige popupteksten, knoplabels, inputlabels en themakeuzes horen niet herhaald te worden in FO-hoofdstukken.

De beheerbare seeddata- en keystrategie is technisch afgebakend. Regulier documentatie- en registeronderhoud blijft controleren:

• of genoemde popupkeys in het popupregister bestaan;
• of domeinen geen afwijkende sleutelspelling gebruiken;
• of popupteksten niet onnodig in FO-hoofdstukken worden gedupliceerd;
• of fout- en autorisatiepopups geen gevoelige data, tokens, payloads of interne identifiers lekken;
• of ouder-/voogd-, live-, geschiedenis-, meldingen- en beheerpopups naar de juiste keyfamilies verwijzen.

Raakvlakken:

• Popups, templates, features en systeemnotificaties
• Schermlaag en UX-specificaties
• Ontwerpbron — popup-register
• Ontwerpbron — popup-themes
• Technisch Ontwerp — databaseontwerp, migraties, seeddata en constraints

20.6.3 Placeholderlijsten voor systeemberichttemplates

Systeemberichttemplates gebruiken codegedreven placeholders. De FO-hoofdlijn is dat placeholdergebruik niet vrij beheerbaar is en dat beheer alleen ondersteunde placeholders mag gebruiken.

De technische seed- en templatebaseline is vastgelegd; per nieuwe of gewijzigde templatefamilie blijft onderhoud nodig op toegestane placeholders, zichtbaarheid en privacy.

Onderwerp	Onderhoudscontrole
Relatie-uitnodigingen	Namen, rollen, relatietypen en deadlines die renderbaar zijn.
Ontkoppelingen	Partij, rolcontext en reden die zichtbaar mag zijn.
Niveauautorisaties	Niveau-, docent- en contextinformatie die mag worden genoemd.
Collaboratorwijzigingen	Niveau- en docentgegevens die zichtbaar mogen zijn.
Gedeelde oefeningen	Snapshotvelden en actiecontext die in communicatie mogen verschijnen.
Meldingen/tickets	Meldingreferentie, status, deadline en actiecontext die zichtbaar mag zijn.
Beheerterugkoppelingen	Beheeractie of supportcontext zonder interne auditdetails te lekken.

Raakvlakken:

• Berichten, communicatie en notificaties
• Popups, templates, features en systeemnotificaties
• Relatiebeheer
• Meldingen en ticketafhandeling
• Technisch Ontwerp — berichten, systeemberichten, notificaties en privéberichten

20.6.4 Module-specifieke render- en exporthulpen

De generieke opslag, voortgang, resultaatpresentatie en PDF-export blijven leidend. Per technische oefenmodule kan aanvullend modulespecifieke presentatiehulp nodig zijn, bijvoorbeeld bij breuken, machten, wortels, tabellen of meerstapsnotatie.

De eerste modulecategorie en eerste concrete oefenmodule zijn vastgelegd. Nieuwe technische oefenmodules volgen het moduledossier-template onder oefen_modules en leggen modulespecifiek vast:

• welke vraagrepresentatie nodig is voor schermweergave;
• welke antwoordrepresentatie nodig is voor schermweergave;
• welke exportrepresentatie nodig is voor PDF;
• of de module een veilige renderhulp of DTO levert;
• hoe historische runs met oudere schemaVersion worden weergegeven;
• hoe fallbackweergave werkt wanneer de module niet langer actief of beschikbaar is;
• welke velden nooit in export of gewone UI getoond mogen worden.

Raakvlakken:

• Oefenmodules en modulepayloads
• PDF-export en resultaatpresentatie
• Leerling: oefenen, voortgang en resultaten
• Oefenmodules — template en minimale verwachtingen
• Oefenmodule — Optellen en aftrekken simpel

20.6.5 Schermdocumentatieconsistentie

Schermdocumentatie blijft leidend voor concrete zichtbare schermonderdelen, waarden, acties, lege toestanden en fouttoestanden. De traceability- en baselineopschoning van schermdocumentatie is uitgevoerd; na nieuwe FO- of schermwijzigingen blijft reguliere controle nodig.

Te controleren bij onderhoud:

• knoppen die niet meer passen bij de FO-scope;
• schermlabels die afwijken van domeintermen;
• tabellen die andere statuslabels tonen dan het FO;
• ontbrekende lege toestanden;
• fouttoestanden die te technisch zijn;
• zichtbare acties die server-side niet toegestaan mogen zijn;
• mockupwaarden die niet als echte tellerdefinities mogen worden gelezen.

Raakvlakken:

• Schermlaag en UX-specificaties
• Schermdocumentatie — intro
• FO-scherm-index

20.6.6 Event- en command-registers

De FO-hoofdstukken beschrijven functionele acties, mutaties en lifecyclegrenzen. Command- en event-registers blijven de plek om command- en eventnamen documentatiebreed te controleren.

Te controleren bij registeronderhoud:

• relatie-events;
• oefenrun-events;
• shared-exercise-events;
• ticket-events;
• module- en categoriemigratie-events;
• beheerlog- en audit-events;
• commando's voor beheer, docent, leerling en ouder/voogd;
• eventnamen die mogelijk nog oude domeintermen gebruiken.

Raakvlakken:

• Ontwerpbron — command-register
• Ontwerpbron — event-register
• Audit, historie en technische uitgangspunten
• Technisch Ontwerp — relatiebeheer, uitnodigingen en gedeelde oefeningen

20.6.7 Featuretoggle-sleutelset

Featuretoggles zijn sitebrede schakelaars voor expliciet togglebare functies. De FO-hoofdlijn is dat featuretoggles beschikbaarheid wijzigen, maar bestaande domeindata niet verwijderen of herschrijven.

De technische seeddata- en beheerstrategie is vastgelegd. De sleutelset blijft bij ontwerpbron- en beheeronderhoud consistent voor onder meer:

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

Raakvlakken:

• Popups, templates, features en systeemnotificaties
• Beheerderfunctionaliteit
• Database-informatie — configuratie en contentbeheer
• Technisch Ontwerp — databaseontwerp, migraties, seeddata en constraints

20.6.8 Retentie, bewaartermijnen en anonimisering

Het FO legt functionele retentie- en anonimiseringhoofdlijnen vast wanneer deze invloed hebben op zichtbaarheid, autorisatie, historie, audit of gebruikersgedrag.

Binnen FO-scope vallen minimaal:

Onderwerp	Functionele FO-vastlegging
Privéberichten	Privéberichten hebben een bewaartermijn van drie maanden, tenzij documentatiebreed anders besloten wordt. Verwijderen door een gebruiker blijft participantgebonden zichtbaarheid en is geen hard delete voor andere deelnemers.
Systeemberichten	Systeemberichten volgen niet automatisch de privéberichtretentie. Zij blijven beschikbaar als systeemcommunicatie en lichte logging, tenzij een expliciete retentieregel anders bepaalt.
Accountverwijdering	Een definitief verwijderverzoek beëindigt reguliere toegang en start de interne anonimiseer- en opruimflow volgens de accountregels.
Accountanonimisering	Anonimisering beëindigt actieve toegang, rollen, relaties, open uitnodigingen en afhankelijke contexten, maar verwijdert historische domeinrecords niet blind.
Oefenruns en resultaten	Historische runs, resultaten, PDF-brondata en gedeelde-oefeningcontext blijven functioneel reconstructeerbaar waar dat nodig is, zonder actuele persoonsgegevens van een geanonimiseerd account zichtbaar te maken.
Meldingen en tickets	Tickets, discussie, sluitingen, heropenverzoeken, technische snapshots en history blijven waar nodig raadpleegbaar voor bevoegde beheerders, maar tonen geen actuele persoonsgegevens van geanonimiseerde accounts.
Audit en beheerlogs	Audit- en historyregels blijven functioneel herleidbaar binnen de toegestane beheercontext, maar mogen geen onnodige actuele persoonsgegevens blijven tonen na anonimisering.
Technische snapshots, backups en securitylogs	Technische cleanup-, backup-, restore- en logretentiegrenzen volgen het Technisch Ontwerp en beheerbeleid, maar mogen functionele privacy- en auditgrenzen uit het FO niet doorbreken.

Buiten FO-scope vallen:

• exacte juridische bewaartermijnen per wettelijke grondslag;
• technische cleanupjobs en database-implementatie;
• fysieke verwijderstrategie, archivering en backupretentie;
• loggingretentie op infrastructuurniveau;
• formele juridische akkoord- of DPIA-processen.

Retentie mag nooit bestaande autorisatiegrenzen verruimen of historische reconstructie onbedoeld onmogelijk maken waar die functioneel vereist blijft.

20.6.9 SRS-afleiding en traceabilityonderhoud

De Software Requirements Specification is voor de huidige baseline uitgewerkt: centrale requirements, acceptatiecriteria, niet-functionele meetwaarden en traceability zijn vastgelegd. Het FO hoeft daarom geen resterende SRS-afleiding meer als open punt te dragen.

Bij toekomstige FO-wijzigingen geldt wel een impactcontrole:

• leidt de wijziging tot nieuw testbaar gebruikersgedrag;
• wijzigt de wijziging een bestaande requirement of prioriteit;
• vraagt de wijziging een nieuw acceptatiecriterium;
• raakt de wijziging foutscenario's, autorisatie of privacy;
• moeten SRS-registers of traceabilitytabellen worden bijgewerkt.

Raakvlakken:

• Software Requirements Specification — intro
• SRS — open punten
• SRS — NFR-meetwaarden

20.6.10 Technisch Ontwerp-afstemming en technische impactanalyse

Het Technisch Ontwerp is voor de huidige baseline uitgewerkt tot technische implementatie- en besluitlaag. Eerdere FO-vervolgpunten rond autorisatie, database, jobs, SignalR, QuestPDF, Keycloak, caching, logging, monitoring, securityheaders, testaanpak, componentenstrategie, oefenmodules en transaction boundaries zijn in het Technisch Ontwerp of de bijbehorende registers geborgd.

Bij toekomstige FO-wijzigingen geldt wel een technische impactcontrole:

• raakt de wijziging een project-, module- of DbContextgrens;
• vraagt de wijziging nieuwe persistentie, migratie of seeddata;
• verandert de wijziging readmodels, caching, badges of tellers;
• raakt de wijziging SignalR, jobs, PDF-export, maildelivery of externe identity provider;
• vraagt de wijziging logging-, privacy-, security- of rate-limit-aanpassing;
• raakt de wijziging frontendcomponenten, routing, state of mockupconversie;
• moet een bestaand TO-besluit worden aangepast of een nieuw besluit worden toegevoegd.

Het FO blijft hiervoor functioneel kader, geen technische implementatiespecificatie.

Raakvlakken:

• Technisch Ontwerp — intro
• Technisch Ontwerp — open punten, ontwerpbesluiten en besluitenregister
• Functionele architectuurcontext

20.7 Onderwerpen die alleen na aparte scopebeslissing kunnen worden toegevoegd

Sommige onderwerpen zijn niet definitief uitgesloten, maar vallen niet onder de huidige scope zonder aparte beslissing.

Onderwerp	Nodige nieuwe uitwerking
Contactformulier	Functionele flow, validatie, verwerking, retentie en security.
Bijlagen	Uploadbeleid, scanning, opslag, retentie, autorisatie en UI.
Groepsberichten	Threadmodel, deelnemersbeheer, readstate, relatiecontext en retentie.
Native app	Platformscope, API, notificaties, offlinegedrag en distributie.
Publieke API	Authenticatie, autorisatie, rate limits, versioning en datacontracten.
Beheerder-subrollen	Autorisatiematrix, UI, audit en beheerflows.
Juridische acceptatieflow	Versioning, consentregistratie, gebruikeractie en audit.
Uitgebreide analytics	Datamodel, privacy, UI, aggregatie en interpretatie.

20.7.1 Oefenconfiguraties herstellen na verwijderen of deactiveren

Een prullenbak- of herstelmechanisme voor verwijderde of gedeactiveerde oefenconfiguraties is geen onderdeel van de huidige functionele baseline.

Een latere uitbreiding kan waardevol zijn voor docenten en beheerders wanneer een oefeningconfiguratie onbedoeld is verwijderd, gedeactiveerd of verkeerd gewijzigd. Zo'n uitbreiding vraagt een apart besluit over:

Aspect	Later te bepalen
Bewaartermijn	Hoe lang een configuratie herstelbaar blijft.
Autorisatie	Welke docent-, collaborator- of beheercontext herstel mag uitvoeren.
Audit	Welke herstel-, verwijder- en deactiveeracties historisch worden vastgelegd.
UI-weergave	Waar verwijderde of herstelbare configuraties zichtbaar zijn.
Geschiedenis	Wat herstel betekent voor bestaande exercise runs, resultaten en PDF-export.

Zonder expliciete latere scopewijziging betekent de huidige FO-baseline dus niet dat oefenconfiguraties via een generieke prullenbak herstelbaar moeten zijn.

20.7.2 Beheer van iconen en media

Categorieën, oefeningen en profielafbeeldingen gebruiken iconen of vooraf gedefinieerde afbeeldingen, maar een generiek media- of iconenbeheerdomein is nog geen vastgesteld onderdeel van de huidige functionele baseline.

De huidige baseline gaat uit van gecontroleerde keuzes binnen de bestaande domeinen:

• categorieën hebben centrale naam, kleur en icoon;
• oefeningen hebben een naam en icoon binnen de concrete oefenconfiguratie;
• profielafbeeldingen komen uit een vooraf gedefinieerde goedgekeurde set;
• vrije uploads door reguliere gebruikers zijn niet toegestaan voor profielafbeeldingen.

Een later generiek beheergebied voor iconensets, mediabestanden, uploadvalidatie, hergebruik, retentie of moderatie moet als afzonderlijke scope worden uitgewerkt. Tot die tijd blijft iconen- en mediagebruik domeingebonden en beperkt.

20.8 Buiten scope van het Functioneel Ontwerp

20.8.1 Technisch ontwerp

Buiten het FO vallen:

• database-DDL;
• migratiescripts;
• volledige class-, interface- en servicearchitectuur;
• repository- en projectstructuur;
• hostingtopologie;
• deploymentstrategie;
• infrastructuur-as-code;
• packagekeuzes;
• technische performance-optimalisaties;
• technische cachingstrategie;
• low-level SignalR-implementatie;
• low-level QuestPDF-implementatie;
• Keycloak-configuratie op protocolniveau;
• mailserverconfiguratie;
• secretsbeheer;
• monitoring- en alertingconfiguratie.

Deze onderwerpen horen in het Technisch Ontwerp of implementatieplan.

20.8.2 Software Requirements Specification

Het FO bevat geen volledige SRS-detailmatrix.

Buiten het FO vallen:

• requirements per uniek ID;
• formele acceptatiecriteria per requirement;
• testcases per requirement;
• traceabilitymatrix op requirementniveau;
• prioriteit, release, sprint of planning per requirement;
• formele non-functional requirements op meetbaar niveau;
• volledige teststrategie.

Het FO is wel input voor de SRS.

20.8.3 Pixel-perfect UI-specificatie

Het FO beschrijft functionele schermsamenhang en bronposities, maar geen pixel-perfect ontwerp.

Buiten scope van het FO vallen:

• exacte CSS;
• kleurwaarden buiten centrale ontwerpregels;
• exacte marges, padding en breakpoints;
• componentimplementatie;
• animatiedetails;
• browser-specifieke layoutfixes;
• visuele regressietests;
• definitieve iconbestanden.

Schermdocumentatie en mockups ondersteunen interpretatie, maar mockupdata is geen definitieve functionele bron.

20.8.4 Native mobiele app

Een native mobiele app valt buiten de huidige scope.

Dit betekent:

• geen iOS-app;
• geen Android-app;
• geen app-storepublicatie;
• geen offline-first mobiele functionaliteit;
• geen pushnotificatie-infrastructuur voor native apps;
• geen aparte mobiele API-scope.

De webapplicatie blijft responsive voor tablet en desktop, met mobiele bruikbaarheid voor zover de webinterface dat ondersteunt.

20.8.5 Publieke API voor externe clients

Een publieke API voor externe clients valt buiten de huidige scope.

Buiten scope vallen:

• publieke REST- of GraphQL-API voor derden;
• externe mobiele-app-API;
• partnerintegraties;
• publieke OAuth-clientregistratie voor derden;
• externe data-export-API;
• bulkimport-API voor externe onderwijsplatformen.

Interne applicatie-API’s of servercalls binnen de webapp vallen onder implementatie, niet onder publieke API-scope.

20.8.6 Vrije pagebuilder

OefenHub bevat contentbeheer, maar geen vrije pagebuilder.

Buiten scope vallen:

• vrije pagina-aanmaak via GUI;
• vrije componentplaatsing;
• custom layouts via beheer;
• drag-and-drop pagebuilder;
• vrije route-aanmaak;
• vrije formulierbuilder;
• CSS- of templatebewerking door beheerders;
• willekeurige HTML-invoer als paginaopbouw.

Contentbeheer beperkt zich tot tekstuele inhoud, linktoewijzingen en vaste beheerbare velden binnen codegedreven structuren.

20.8.7 Vrije bericht- of chatfunctionaliteit

OefenHub ondersteunt privéberichten binnen toegestane relatiecontexten, maar geen volledig vrij chatplatform.

Buiten scope vallen:

• openbare chatrooms;
• groepsgesprekken zonder aparte uitwerking;
• vrije bijlagen in privéberichten;
• audio- of videoberichten;
• doorsturen als generieke eindgebruikersfunctie;
• conceptopslag voor berichten;
• realtime typindicatoren;
• leesbevestigingen buiten bestaande readstate;
• onbeperkt berichten buiten relatiecontext.

Uitbreidingen op privéberichten moeten later apart worden gespecificeerd.

20.8.8 Bijlagen in meldingen en berichten

Bijlagen zijn binnen de initiële scope buiten scope, tenzij later expliciet toegevoegd.

Dit geldt voor:

• bijlagen bij privéberichten;
• bijlagen bij meldingen;
• screenshots uploaden bij meldingen;
• bestanden toevoegen aan tickets;
• downloadbare bestanden in privéthreads;
• virus- en malware-scanning;
• opslagquota voor bijlagen.

Wanneer bijlagen later worden toegevoegd, vraagt dit aparte functionele, technische en securityspecificatie.

20.8.9 Juridische workflow en privacybeleid

Privacy- en contactteksten kunnen via vaste contentpagina’s beheerbaar zijn, maar het FO beschrijft geen volledige juridische workflow.

Buiten scope vallen:

• juridisch akkoordensysteem;
• versiebeheer van privacyverklaringen met gebruikeracceptaties;
• toestemmingsbeheer buiten bestaande functionele context;
• juridische reviewflow;
• automatische dataverwerkingsregisters;
• formele DPIA-procedure.

Binnen FO-scope blijven wel:

• functionele accountverwijdering en accountanonimisering;
• functionele gevolgen van anonimisering voor rollen, relaties, sessies, berichten, meldingen, resultaten, audit en historie;
• functionele bewaartermijnen of retentiehoofdlijnen waar deze gebruikersgedrag, zichtbaarheid, audit of historische reconstructie beïnvloeden;
• de regel dat privacy- en securityprincipes bestaande autorisatie- en bron-van-waarheidregels nooit mogen verruimen.

20.8.10 Automatisch bewijs van backwards compatibility

Het FO schrijft voor dat historische runs leesbaar moeten blijven en dat modulepayloads via moduleKey en schemaVersion interpreteerbaar moeten zijn.

Buiten scope van het FO valt:

• automatisch formeel bewijs van backwards compatibility;
• generieke migratievalidatie voor alle toekomstige modules;
• volledig automatisch schema-diffmechanisme;
• automatische correctie van oude payloads zonder modulecode.

Technische validatie en teststrategie horen in TO/SRS.

20.8.11 Volledige beheerder-subrollen

Binnen de huidige FO-lijn zijn beheerders functioneel gelijkwaardig, tenzij een specifiek hoofdstuk anders bepaalt.

Buiten scope vallen:

• beheerder-subrollen;
• fijnmazige beheerrechten per beheergebied;
• escalatieniveaus;
• vierogenprincipe;
• goedkeuringsflows voor beheeracties;
• maker-checker-processen.

Als deze later nodig zijn, raakt dat autorisatiematrix, beheerderfunctionaliteit, audit, schermdocumentatie en SRS.

20.8.12 Onderwijsinhoudelijke curriculumstandaarden

OefenHub gebruikt niveaus, categorieën en oefeningen, maar legt geen volledige externe curriculumstandaard vast.

Buiten scope vallen:

• formele koppeling aan landelijke onderwijsstandaarden;
• automatische curriculumdekking;
• leerlijnanalyse op curriculumdoelen;
• adaptief leersysteem op basis van leerdoelen;
• automatische adviesroutes voor leerlingen;
• beoordeling of oefeningen pedagogisch correct zijn.

Docenten beheren concrete oefeningen binnen de functionele grenzen van OefenHub.

20.8.13 Geavanceerde analyse en rapportage

OefenHub toont resultaten, geschiedenis, statistieken en beheer-/frontpagesamenvattingen.

Buiten scope vallen:

• uitgebreide BI-dashboards;
• cohortanalyse;
• voorspellende analyses;
• automatische adviezen;
• learning analytics buiten de beschreven resultaten en geschiedenis;
• export naar externe analysetools;
• datamarts of aparte rapportagedatabases.

20.8.14 Meertaligheid

De applicatie is Nederlandstalig.

Buiten scope vallen:

• meertalige gebruikersinterface;
• taalkeuze per gebruiker;
• vertaalbeheer;
• meertalige contentblokken;
• meertalige foutmeldingen;
• meertalige PDF-export.

Technische namen in backend, database en code kunnen Engelstalig zijn, maar de gebruikersinterface is Nederlandstalig.

20.9 Afhandeling van vervolgonderwerpen

Voor verdere verwerking gelden de volgende regels.

1. Vervolgonderwerpen worden niet opgelost door losse tekst in één willekeurig hoofdstuk toe te voegen wanneer meerdere domeinen geraakt worden.
2. Een vervolgonderwerp wordt gesloten wanneer de keuze of uitwerking in de juiste bronlaag is verwerkt.
3. Als een vervolgonderwerp leidt tot een nieuwe functionele regel, moet het betrokken FO-hoofdstuk worden bijgewerkt.
4. Als een vervolgonderwerp leidt tot een technische keuze, hoort die uitwerking in TO.
5. Als een vervolgonderwerp leidt tot testbare requirements, hoort die uitwerking in SRS.
6. Als een vervolgonderwerp alleen schermgedrag betreft, hoort de detailuitwerking in schermdocumentatie.
7. Als een vervolgonderwerp register- of sleutelsetconsistentie raakt, moeten ontwerpbronnen en registers worden bijgewerkt.
8. Als een onderwerp buiten scope blijft, moet het in dit hoofdstuk of in productscope duidelijk als buiten scope blijven staan.

20.10 Relatie tot andere FO-hoofdstukken

Hoofdstuk	Relatie
Bronnen en afbakening	Bepaalt bronhiërarchie, DRY-regels, linkbeleid en duurzame bronpositie.
Productvisie en scope	Bepaalt productniveau-scope, doelgroepen, platformgrenzen en niet-doelen.
Rollen, context en autorisatie	Bepaalt autorisatieprincipes die ook bij vervolgonderwerpen blijven gelden.
Frontpages en overzichtsschermen	Raakt tellerdefinities, readmodels en lege toestanden.
Gedeelde oefeningen	Beschrijft gedeelde records, ontvangersruns en de SharedExercise-systeemcommunicatieroute.
Berichten, communicatie en notificaties	Beschrijft systeemcommunicatie, badges, retentie en EntityType-keuzes.
Meldingen en ticketafhandeling	Raakt contactformulier, retentie, systeemberichten en ticketcommunicatie.
Contentbeheer, vaste pagina’s en footer	Raakt contactpagina, pagebuildergrens en contentscope.
Popups, templates, features en systeemnotificaties	Raakt popupkeys, placeholders, featuretoggles en notificaties.
PDF-export en resultaatpresentatie	Raakt module-specifieke exportrepresentatie.
Functionele beslisregels en uitgangspunten	Beschrijft domeinbrede regels voor autorisatie, context, readmodels, mutaties en foutafhandeling.
Schermlaag en UX-specificaties	Raakt schermdocumentatie, lege toestanden, fouttoestanden en UX-regels.
Oefenmodules en modulepayloads	Raakt module-renderhulpen, schemaVersion en backwards compatibility.
Functionele architectuurcontext	Raakt TO-afbakening, systeemgrenzen, readmodels, realtime en jobs.

20.11 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — besluitenregister	Open punten, ontwerpbesluiten en besluitenregister
Technisch Ontwerp — teststrategie	Teststrategie, acceptatieherleidbaarheid en kwaliteitsgrenzen
FO — bronnen en afbakening	Bronnen en afbakening
FO — productvisie en scope	Productvisie en scope
FO — gedeelde oefeningen	Gedeelde oefeningen
FO — berichten, communicatie en notificaties	Berichten, communicatie en notificaties
FO — meldingen en ticketafhandeling	Meldingen en ticketafhandeling
FO — contentbeheer, vaste pagina’s en footer	Contentbeheer, vaste pagina’s en footer
FO — popups, templates, features en systeemnotificaties	Popups, templates, features en systeemnotificaties
FO — PDF-export en resultaatpresentatie	PDF-export en resultaatpresentatie
FO — functionele beslisregels en uitgangspunten	Functionele beslisregels en uitgangspunten
FO — schermlaag en UX-specificaties	Schermlaag en UX-specificaties
FO — oefenmodules en modulepayloads	Oefenmodules en modulepayloads
FO — functionele architectuurcontext	Functionele architectuurcontext
Bronnenoverzicht	Bronnenoverzicht
Extractie-notities	Extractie-notities
FO-usecase-index	FO-usecase-index
FO-scherm-index	FO-scherm-index
FO-broninventaris overige markdown	FO-broninventaris overige markdown
Database-informatie — communicatie en notificaties	Communicatie en notificaties
Database-informatie — configuratie en contentbeheer	Configuratie en contentbeheer
Database-informatie — oefenruns, delen en voortgang	Oefenruns, delen en voortgang
Ontwerpbron — popup-register	Popup-register
Ontwerpbron — command-register	Command-register
Ontwerpbron — event-register	Event-register
Ontwerpbron — statusmodellen	Statusmodellen
Schermdocumentatie — intro	Schermdocumentatie
Oefenmodules — intro	Oefenmodules

20.12 Bewust buiten V1.0-scope gehouden

De volgende beoordeelde restpunten worden niet als V1.0-baseline toegevoegd:

• Generiek doorsturen van privéberichten: gewone eindgebruikers krijgen geen algemene forwardfunctie. Doorzetten of namens iemand versturen blijft beperkt tot expliciet ondersteunde beheer- of meldingenprocessen.
• Notificatievoorkeuren voor e-mail of push: berichten, badges en systeemnotificaties blijven binnen de bestaande OefenHub-communicatielaag; opt-in e-mail- of pushvoorkeuren horen niet bij V1.0.
• Beschikbaarheidsdoel 75% uit Word: dit oude cijfer wordt niet overgenomen. De actuele beschikbaarheids-, backup-, restore- en performancegrenzen staan in het Technisch Ontwerp.