Extractie-notities

Doel van deze pagina

Deze pagina beschrijft de duurzame extractieregels die worden gebruikt bij het opstellen, herzien en onderhouden van het Functioneel Ontwerp van OefenHub.

De extractie-notities leggen niet vast welke tijdelijke ruwe documenten ooit als werkinvoer zijn gebruikt. Zij beschrijven hoe structurele bronsets worden geïnterpreteerd en hoe informatie uit die bronsets naar het FO wordt vertaald zonder onnodige duplicatie.

De pagina ondersteunt vooral:

• consistente FO-herziening per domein;
• herleidbare bronkeuzes;
• duidelijke bronhiërarchie;
• DRY-documentatie;
• klikbare relatieve bronverwijzingen;
• scheiding tussen FO, TO en SRS;
• herhaalbare review- en extractieaanpak.

Status van deze pagina

Deze pagina is een werk- en onderhoudsrichtlijn binnen het FO.

Zij is geen:

• versiehistorie van het FO;
• lijst van alle ooit aangeleverde ruwe bestanden;
• vervanging van het bronnenoverzicht;
• inhoudelijke samenvatting van alle bronbestanden;
• technisch ontwerp;
• SRS-requirementmatrix;
• implementatieplan.

Versie-informatie van het FO hoort centraal in Functioneel Ontwerp OefenHub. Deze pagina noemt daarom geen FO-versienummer.

Duurzame bronpositie

Het FO wordt opgebouwd vanuit duurzame documentatiebronnen.

Brondomein	Gebruik in extractie
Usecases	Procesflows, actoren, alternatieve flows, precondities, postcondities en functionele autorisatiegrenzen.
Database-informatie	Domeinobjecten, relaties, statusvelden, readmodels, auditobjecten, opslaggrenzen en historische reconstructie.
Ontwerpbronnen	Business rules, autorisatiematrix, statusmodellen, command-register, event-register, popupregister en themasets.
Schermdocumentatie	Schermdoelen, schermcontext, zichtbare velden, acties, lege toestanden, fouttoestanden en dynamische waarden.
Mockupdocumentatie	Visuele interpretatie, layoutintentie en schermvoorbeeldgedrag waar tekstuele bronnen onvoldoende concreet zijn.
Oefenmodule-documentatie	Modulespecifieke configuratie, payloadstructuur, modulegedrag en grens tussen generieke engine en modulelogica.
Architectuurdocumentatie	Functionele systeemgrens, externe systemen, containers en interne bouwblokken op C4-niveau.
FO-registers	Traceerbaarheid, indexering en controle op brondekking.

Het FO zelf is de functionele consolidatielaag. Het legt de samenhang vast tussen deze bronnen, maar vervangt bronhoudende details niet overal door kopieën.

Tijdelijke werkbronnen

Tijdelijke ruwe werkdocumenten, conversiebestanden, extracties, overdrachtsnotities, zipnamen, tussenversies en andere niet-duurzame documenten worden niet als blijvende FO-bron opgenomen.

Zij mogen tijdens een reviewronde helpen om context te begrijpen, maar zij horen niet thuis als duurzame bronverwijzing in FO-hoofdstukken.

Voorbeelden van niet-duurzame verwijzingen die vermeden moeten worden:

• tijdelijke ruwe consolidatiedocumenten die ophouden te bestaan zodra de duurzame documentatiebronnen zijn uitgewerkt;
• zipbestanden als formele bronnaam;
• eenmalige conversie- of reconstructiebundels;
• losse chat- of overdrachtsnotities als blijvende bron;
• bestandsnamen die alleen iets zeggen over een importmoment;
• versienummers van tijdelijke consolidatiedocumenten.

Wanneer informatie uit zo’n werkbron in het FO wordt verwerkt, moet de duurzame bronpositie daarna in de reguliere documentatie liggen: usecases, database-informatie, ontwerpbronnen, schermdocumentatie, oefenmodules, architectuur, registers of het FO-hoofdstuk zelf.

Relatie tot het bronnenoverzicht

Het bronnenoverzicht beschrijft de hoofdgroepen van gebruikte bronnen en biedt directe ingangen naar brondomeinen.

Deze extractie-notities beschrijven hoe die bronnen worden geïnterpreteerd.

Document	Rol
Bronnenoverzicht	Overzicht van duurzame bronsets en directe ingangen.
Extractie-notities	Werkwijze, interpretatieregels en extractieprincipes.
Bronnen en afbakening	FO-brede bronhiërarchie, afbakening en normatieve interpretatie.
Open punten en buiten scope	Centrale plek voor resterende keuzes, documentatiehygiëne en buiten-scopegrenzen.

Wanneer het bronnenoverzicht en deze extractie-notities elkaar tegenspreken, moet de documentatie worden gecorrigeerd. De duurzame bronhiërarchie hoort in beide documenten consistent te zijn.

Extractiedoel per FO-hoofdstuk

Een FO-hoofdstuk beschrijft de functionele samenhang binnen één domein of aandachtsgebied.

Per hoofdstuk moet de extractie minimaal beantwoorden:

Vraag	Betekenis
Wat is het domein?	De functionele verantwoordelijkheid van het hoofdstuk.
Wat valt binnen scope?	Gebruikersacties, rollen, objecten en processen die in dit domein thuishoren.
Wat valt buiten scope?	Aangrenzende domeinen die niet in dit hoofdstuk bronhoudend worden uitgewerkt.
Wat is bron van waarheid?	Welke data of bronlaag leidend is voor gedrag, status, autorisatie of reconstructie.
Welke rollen zijn betrokken?	Actoren en contexten die het domein mogen raadplegen of wijzigen.
Welke acties zijn toegestaan?	Functionele acties, read-only grenzen en mutatiegrenzen.
Welke lifecycle geldt?	Statussen, transitions, begin- en eindmomenten of afgeleide toestanden.
Welke lege toestanden zijn normaal?	Situaties waarin geen data bestaat maar geen fout optreedt.
Welke fouttoestanden zijn relevant?	Veilige afhandeling van ongeldige context, ontbrekende objecten of geweigerde toegang.
Welke bronnen blijven leidend?	Relatieve links naar de brondocumenten die details blijven dragen.

Domeincontractstijl

Gereviewde FO-hoofdstukken worden bij voorkeur opgezet als domeincontract.

Een domeincontract beschrijft niet alleen losse requirements, maar ook de functionele grenzen van het domein.

Een hoofdstuk in domeincontractstijl bevat waar relevant:

• doel;
• domeinafbakening;
• bronpositie;
• betrokken rollen en contexten;
• bron-van-waarheidregels;
• hoofdobjecten of readmodels;
• lifecycle of statusmodel;
• toegestane acties;
• read-only versus mutatiegedrag;
• autorisatie- en veiligheidsregels;
• relatie tot aanpalende domeinen;
• lege toestanden;
• fouttoestanden;
• gerelateerde bronverwijzingen.

Niet ieder hoofdstuk hoeft even lang te zijn. De inhoudelijke complexiteit van het domein bepaalt de diepte.

Bronhiërarchie per vraagtype

Niet elke bron is voor elk soort vraag even leidend.

Vraagtype	Primair leidend	Ondersteunend
Procesflow	Usecases	Schermdocumentatie, FO-hoofdstukken
Domeinobjecten en relaties	Database-informatie	Ontwerpbronnen, usecases
Autorisatiegrenzen	Autorisatiematrix, usecases, FO-autorisatiehoofdstukken	Schermdocumentatie, database-informatie
Statusmodel	Ontwerpbronnen en database-informatie	Usecases, schermdocumentatie
Popupfeedback	Popupregister en popup-themes	Usecases, schermdocumentatie
Schermvelden en zichtbare acties	Schermdocumentatie	Mockups, usecases
Layoutintentie	Schermdocumentatie en mockups	FO-schermlaaghoofdstuk
Oefenmodulegedrag	Oefenmodule-documentatie	FO-22, database-informatie
Modulepayloads	Oefenmodule-documentatie en database-informatie	FO-22, docentusecases
Realtime gedrag	Usecases, database-informatie, FO-live/communicatiehoofdstukken	Architectuurdocumentatie
PDF-export	Usecases, FO-18, schermdocumentatie	Database-informatie, module-documentatie
Architectuurcontext	C4-documentatie	FO-23, database-informatie
Buiten scope	FO-20	FO-00 en relevante domeinhoofdstukken

Wanneer een bron op een bepaald punt specifieker is dan een andere bron, krijgt de specifiekere bron meestal voorrang, tenzij dat strijd oplevert met een hogere functionele grens zoals autorisatie, privacy of historische reconstructie.

Conflictregels

Bronnen kunnen elkaar tegenspreken of op verschillende detailniveaus spreken.

Bij conflicten gelden de volgende regels.

Situatie	Extractieregel
Usecase en schermdocumentatie verschillen over procesvolgorde	Usecase is primair voor procesflow; schermdocumentatie kan zichtbare presentatie verduidelijken.
Schermdocumentatie toont een actie die autorisatieregels niet toestaan	Autorisatieregels zijn leidend; zichtbare UI is geen autorisatiebewijs.
Mockup toont voorbeelddata die niet in database- of usecasebron staat	Mockupwaarde is voorbeelddata en wordt niet als functionele waarheid overgenomen.
Databasebron bevat technisch detail dat niet functioneel relevant is	FO benoemt alleen functionele betekenis of grens, niet de volledige implementatie.
FO-hoofdstuk en bronbestand verschillen	Het FO moet worden aangepast of het conflict wordt als open punt geregistreerd.
Twee bronbestanden zijn inhoudelijk even specifiek maar spreken elkaar tegen	Niet zelf stilzwijgend kiezen wanneer dit product- of scopegevoelig is; registreer een open punt.
Oude tijdelijke bron wijkt af van duurzame bron	Duurzame bron is leidend; tijdelijke bron wordt niet als blijvende referentie gebruikt.

Alle conflictcorrecties moeten traceerbaar blijven via het gewijzigde FO-hoofdstuk of via Open punten en buiten scope.

DRY-principe

Het FO moet DRY blijven: informatie wordt niet onnodig gekopieerd uit bronbestanden.

Het FO mag wel samenvatten:

• welke functionele regels gelden;
• welke domeingrenzen bestaan;
• welke bron leidend is;
• welke acties en rollen relevant zijn;
• welke lifecycle of statusbetekenis functioneel belangrijk is;
• welke open punten nog bestaan.

Het FO hoort niet volledig te dupliceren:

• volledige usecaseflows;
• complete schermspecificaties;
• alle databasevelden;
• alle popupteksten;
• alle template-inhoud;
• alle mockupdetails;
• alle SRS-acceptatiecriteria;
• volledige technische implementatiekeuzes.

Wanneer detailinformatie elders leidend blijft, verwijst het FO met een relatieve link naar die bron.

Linkbeleid

Bronverwijzingen in FO-bestanden moeten klikbaar zijn.

Voor Docusaurus-bronnen gelden relatieve markdownlinks.

Voorbeelden vanuit een FO-hoofdstuk in docs/functioneel_ontwerp:

Doel	Voorbeeldlink
Ander FO-hoofdstuk	./06-relatiebeheer
Usecase-intro	../usecases/intro
Database-informatie	../database_informatie/intro
Ontwerpbron	../ontwerpbronnen/business-rules
Schermdocumentatie	../schermdocumentatie/intro
Oefenmodule	../oefen_modules/rekenen/optellen_en_aftrekken_simpel/intro

Vanuit deze bronnenmap (docs/functioneel_ontwerp/bronnen) moet één niveau extra worden teruggegaan voor bronnen buiten functioneel_ontwerp.

Voorbeelden vanuit deze pagina:

Doel	Voorbeeldlink
FO-hoofdstuk	[Bronnen en afbakening](../00-bronnen-en-afbakening)
FO-register	[Usecase-index](../registers/fo-usecase-index)
Usecases	[Usecases](../../usecases/intro)
Database-informatie	[Database-informatie](../../database_informatie/intro)
Schermdocumentatie	[Schermdocumentatie](../../schermdocumentatie/intro)

Tekstuele verwijzingen zoals “zie de usecases” zonder link zijn onvoldoende wanneer de bronlocatie bekend is.

Markdownbeleid

FO-bestanden worden geschreven in onderhoudbare markdown.

Daarvoor gelden de volgende regels:

• tabellen zijn echte markdown-tabellen;
• geen platte tekst gebruiken om kolommen na te bootsen;
• relatieve links gebruiken voor interne Docusaurus-bronnen;
• geen FO-versienummers opnemen buiten de centrale intro;
• geen tijdelijke bestandsnamen als duurzame bronverwijzing gebruiken;
• code- of veldnamen alleen gebruiken wanneer ze functionele betekenis hebben;
• lange bronlijsten in tabellen plaatsen wanneer dat de scanbaarheid verbetert;
• niet onnodig enorme usecaseblokken kopiëren;
• open punten expliciet markeren en centraliseren waar nodig.

Versiebeleid

Het FO-versienummer staat uitsluitend centraal in Functioneel Ontwerp OefenHub.

Andere FO-bestanden noemen geen v0.x-versies.

Wanneer een hoofdstuk wordt herzien, wordt de inhoud aangepast zonder lokaal versienummer in het hoofdstuk.

Commitberichten, pull requests of changelogmechanismen kunnen wijzigingscontext bevatten, maar het FO-document zelf houdt versie-informatie centraal.

Functionele versus technische extractie

Het FO beschrijft functionele betekenis, geen volledige technische implementatie.

Onderwerp	Wel in FO	Niet volledig in FO
Database	Functionele brondata, relaties, statusbetekenis en opslaggrenzen.	Volledige DDL, indices, constraints en migratiescripts.
Backend	Functionele acties, autorisatie, lifecycle en verwerking.	C#-classes, services, namespaces en methodesignatures.
Frontend	Schermdoel, zichtbaarheid, acties, lege toestanden en UX-grenzen.	Pixelperfect CSS, componentnamen en responsive breakpoints tenzij functioneel relevant.
Realtime	Welke updates functioneel nodig zijn en welke bron leidend blijft.	Technische hubimplementatie of transportdetails.
PDF	Functionele inhoud, historische bron, bestandsnaam en exportgrenzen.	Volledige QuestPDF-code.
Modules	Modulecontract, payloadgrenzen en configuratiegedrag.	Volledige module-implementatiecode.

Wanneer technische informatie een functionele beslissing draagt, mag het FO die functionele grens wel expliciet benoemen.

Autorisatie als extractiegrondregel

Autorisatie is een overkoepelende interpretatieregel.

Voor alle FO-hoofdstukken geldt:

• zichtbare UI is nooit autorisatiebewijs;
• routes zijn nooit autorisatiebewijs;
• clientstate is nooit autorisatiebewijs;
• browsergeschiedenis is nooit autorisatiebewijs;
• querystrings en filters mogen toegang niet verruimen;
• exportacties controleren opnieuw server-side;
• liveacties controleren opnieuw server-side;
• detailweergaven controleren opnieuw server-side;
• mutaties controleren opnieuw server-side.

Wanneer een schermdocumentatiebron een actie toont, moet het FO controleren of de relevante autorisatie- en contextbron die actie toestaat.

Privacy en dataminimalisatie

Bij extractie geldt dat het FO geen onnodige persoonsgegevens, gevoelige payloads of interne technische details zichtbaar maakt.

Functionele regels moeten duidelijk maken:

• welke rol welke gegevens mag zien;
• welke gegevens alleen beheer- of auditcontext zijn;
• wanneer namen geanonimiseerd of generiek weergegeven worden;
• wanneer technische snapshots niet aan eindgebruikers worden getoond;
• wanneer foutmeldingen geen payload, tokens, stacktrace of interne identifiers mogen lekken;
• wanneer historische reconstructie persoonsgegevens moet beperken na anonimisering.

Historische reconstructie

Veel OefenHub-domeinen gebruiken historische context.

Voorbeelden:

• afgeronde oefenruns;
• resultaten;
• PDF-export;
• gedeelde oefeningen;
• categorie- en modulemigratie;
• accountanonimisering;
• relatiehistorie;
• ticketgeschiedenis;
• content- en beheerhistory.

Extractieregel:

Historische reconstructie gaat vóór actuele naamgeving wanneer het domein gaat over resultaten, PDF’s, gedeelde oefeningen, audit of eerdere context.

Een latere wijziging aan categorie, module, niveau, gebruiker, relatie of content mag historische bronrecords niet stilzwijgend herschrijven, tenzij een bron expliciet een gecontroleerde migratie of correctieflow beschrijft.

Readmodels, tellers en badges

Tellers, badges, samenvattingen en overzichten zijn meestal afgeleide readmodels.

Bij extractie moet per teller of samenvatting duidelijk zijn:

• welke objecten meetellen;
• welke statussen meetellen;
• welke rollen en contexten begrenzen;
• welk tijdvenster geldt;
• of testdata meetelt;
• of soft-deleted of inactieve records meetellen;
• of lege toestanden normaal zijn;
• of realtime updates alleen presentatie zijn of ook brondata wijzigen.

Een teller is nooit zelfstandig autorisatiebewijs.

Featuretoggles en systeeminstellingen

Featuretoggles en systeeminstellingen worden niet door elkaar gebruikt.

Mechanisme	Extractieregel
Featuretoggle	Schakelt expliciet togglebare functionaliteit aan of uit. Verwijdert geen bestaande domeindata.
Systeeminstelling	Bevat een configureerbare waarde met datatype en invoervorm.
Contentblok	Beheert tekstuele inhoud op vaste plekken.
Popup	Geeft actiegerichte feedback via popupkey.
Systeemnotificatie	Toont tijdelijke of geplande overlay na frontpageload.
Systeemberichttemplate	Levert inhoudsbasis voor concrete mailbox-systeemberichten.

Extractie moet deze mechanismen gescheiden houden, ook wanneer ze in de UI op elkaar lijken.

Modulepayloads en hybride opslag

Oefenmodules gebruiken modulespecifieke payloads binnen generieke OefenHub-opslag.

Voor extractie gelden de volgende regels:

• het FO benoemt functioneel het verschil tussen configuratiepayload, runpayload en voortgangspayload;
• module-specifieke vraag- en antwoorddetails worden niet relationeel uitgesplitst in het FO;
• uniforme runvelden blijven leidend voor geschiedenis, resultaatweergave, PDF en live meekijken;
• moduleKey en schemaVersion binnen bestaande payloads zijn voldoende voor module- en schemaherleidbaarheid;
• er wordt geen extra generieke databasekolom geïntroduceerd wanneer bestaande payloadvelden de herleidbaarheid al functioneel dragen;
• historische runs worden niet herschreven door modulewijzigingen of modulemigraties.

Popups, templates en teksten

Popupteksten, template-inhoud en systeemcommunicatieteksten worden niet per usecase of FO-hoofdstuk gedupliceerd.

Extractieregels:

• FO-hoofdstukken verwijzen naar popupkeys of popupregister waar mogelijk;
• popupteksten blijven in popupregister of PopupDetails;
• systeemberichttemplates blijven in het templatebeheer;
• FO beschrijft functionele intentie, niet alle exacte teksten;
• foutfeedback mag geen gevoelige informatie lekken;
• ontbrekende of nog niet vastgestelde popupkeys worden als open punt geregistreerd.

Schermdocumentatie en mockups

Schermdocumentatie is leidend voor schermspecifieke zichtbaarheid en acties.

Mockups ondersteunen visuele interpretatie.

Extractieregels:

• mockupdata is voorbeelddata;
• mockupnamen, aantallen, tijden en statussen worden niet automatisch als functionele waarheid overgenomen;
• schermdocumentatie bepaalt zichtbare velden, lege toestanden en schermacties;
• FO beschrijft de functionele samenhang, niet iedere UI-pixel;
• visuele elementen met functionele betekenis mogen wel worden benoemd, bijvoorbeeld badges, waarschuwingen, disabled acties of read-only indicatoren.

Usecases

Usecases beschrijven procesgedrag.

Bij extractie uit usecases geldt:

• neem de functionele flow samen, maar kopieer niet de volledige usecase;
• benoem belangrijke precondities en postcondities wanneer ze domeinbreed relevant zijn;
• neem alternatieve flows op als ze de domeinregel wijzigen;
• neem uitzonderingen op als ze een autorisatie-, status- of foutregel bepalen;
• verwijs naar de usecases voor detailstappen;
• centraliseer open vragen in FO-20 wanneer een keuze documentatiebreed is.

Database-informatie

Database-informatie wordt functioneel geïnterpreteerd.

Bij extractie geldt:

• objecten worden benoemd wanneer ze functionele brondata, readmodels, audit of lifecycle dragen;
• veldnamen worden genoemd wanneer ze functionele betekenis hebben;
• technische opslagdetails worden alleen genoemd wanneer ze een functionele grens bepalen;
• history- en auditobjecten worden benoemd wanneer ze reconstructie of beheertransparantie dragen;
• soft delete, statusvelden en timestamps worden functioneel uitgelegd wanneer ze zichtbaar gedrag bepalen.

Ontwerpbronnen

Ontwerpbronnen zijn leidend voor generieke regels.

Bij extractie geldt:

• business rules worden niet per hoofdstuk volledig herhaald;
• autorisatiematrixregels worden functioneel samengevat waar relevant;
• statusmodellen worden gebruikt om lifecycle en labels consistent te houden;
• command-register en event-register worden gebruikt om mutaties en gebeurtenissen te duiden;
• popupregister en popup-themes blijven leidend voor feedbackmechanismen;
• afwijkingen of ontbrekende keys worden als open punt geregistreerd.

Architectuurdocumentatie

Architectuurdocumentatie wordt functioneel gebruikt, niet als TO-kopie.

Extractieregels:

• C4 niveau 1 duidt systeemgrens en externe actoren/systemen;
• C4 niveau 2 duidt containers en functionele verantwoordelijkheden;
• C4 niveau 3 en 4 duiden interne bouwblokken op hoofdlijnen;
• FO-23 vertaalt dit naar functionele architectuurcontext;
• technische implementatiekeuzes blijven voor TO, tenzij ze functioneel begrenzend zijn.

Oefenmodule-documentatie

Oefenmodule-documentatie is leidend voor modulespecifieke configuratie en gedrag.

Bij extractie geldt:

• de generieke engine blijft verantwoordelijk voor autorisatie, run-lifecycle, opslag, resultaten, geschiedenis en export;
• de module levert modulespecifieke configuratie, generatie, validatie, antwoordinterpretatie en renderhulp waar nodig;
• payloadvoorbeelden worden niet onnodig volledig gekopieerd;
• belangrijke payloadvelden zoals moduleKey en schemaVersion worden functioneel benoemd;
• module-specifieke uitzonderingen worden naar FO-22 of modulebronnen verwezen.

Open punten

Open punten worden niet verspreid als losse waarschuwingen in elk hoofdstuk zonder centrale vindbaarheid.

Een open punt hoort in Open punten en buiten scope wanneer:

• een documentatiebrede keuze nodig is;
• bronnen elkaar tegenspreken;
• een productkeuze openstaat;
• een technische keuze later in TO moet worden uitgewerkt;
• een SRS-uitwerking nodig is;
• een register of bronverwijzing nog opgeschoond moet worden;
• een bron ontbreekt of nog niet eenduidig genoeg is.

Een hoofdstuk mag het open punt kort noemen wanneer het voor dat domein essentieel is, maar FO-20 blijft de centrale plek voor opvolging.

Buiten scope

Wanneer iets buiten FO-scope valt, moet het niet alsnog half worden uitgewerkt in het FO.

Veelvoorkomende buiten-scopecategorieën:

• technische implementatie in C# of Blazor;
• database-DDL;
• volledige API-contracten;
• deploymentdetails;
• pixelperfect UI;
• volledige SRS-requirementmatrix;
• teststrategie;
• analytics en rapportage buiten huidige scope;
• mobiele native app;
• publieke API voor externe clients;
• vrije pagebuilder;
• bijlagenbeleid wanneer nog niet uitgewerkt;
• juridische workflow buiten beheerbare privacytekst.

Buiten-scopepunten worden centraal bewaakt in FO-20.

Reviewaanpak per hoofdstuk

Een hoofdstukreview volgt bij voorkeur deze werkwijze:

1. Lees het bestaande FO-hoofdstuk.
2. Bepaal het domein en de grenzen.
3. Raadpleeg de relevante duurzame bronnen.
4. Vergelijk procesflow, brondata, schermgedrag en autorisatiegrenzen.
5. Los eenduidige inconsistenties zelf op in de voorgestelde tekst.
6. Stel alleen vragen wanneer sprake is van bronconflict, productkeuze, scopegevoeligheid of ontbrekende bron.
7. Houd het FO DRY.
8. Voeg relatieve bronlinks toe.
9. Gebruik echte markdown-tabellen.
10. Benoem open punten centraal.
11. Voeg een kort Engels commitbericht toe.
12. Vraag om akkoord en stel een logisch volgend hoofdstuk voor.

Kwaliteitscheck vóór oplevering

Voor ieder gereviewd FO-bestand geldt de volgende checklist.

Controle	Vraag
Domein	Is duidelijk wat het hoofdstuk wel en niet behandelt?
Bronnen	Zijn de relevante bronlagen geraadpleegd en klikbaar gelinkt?
DRY	Is detailinformatie niet onnodig gekopieerd?
Autorisatie	Is server-side contextcontrole voldoende expliciet?
Rollen	Zijn rolgrenzen en combinatierollen juist verwerkt?
Bron van waarheid	Is duidelijk welke data of bron leidend is?
Lifecycle	Zijn status, start, einde en historische context duidelijk?
Readmodels	Zijn tellers, badges en samenvattingen als afgeleid benoemd?
Lege toestanden	Zijn normale lege situaties benoemd?
Fouttoestanden	Zijn veilige foutafhandeling en dataminimalisatie benoemd?
Links	Zijn bronverwijzingen relatieve markdownlinks?
Tabellen	Zijn tabellen echte markdown-tabellen?
Versiebeleid	Staat er geen lokaal FO-versienummer?
Open punten	Zijn resterende keuzes centraal traceerbaar?
Commit	Is een kort Engels commitbericht beschikbaar?

Relatie tot TO en SRS

Het FO is niet het eindpunt van alle specificatie.

De extractie moet rekening houden met vervolgdocumenten.

Document	Rol
FO	Functionele samenhang, rollen, gedrag, grenzen, brondata en schermbetekenis.
TO	Technische implementatie, componenten, services, API’s, database-DDL, deployment en technische ontwerpkeuzes.
SRS	Atomair toetsbare requirements, acceptatiecriteria en traceerbaarheid naar FO/usecases.

Wanneer een detail thuishoort in TO of SRS, moet het FO hoogstens de functionele grens benoemen en niet de volledige uitwerking overnemen.

Relatie tot registers

Registers ondersteunen traceerbaarheid.

Register	Gebruik
FO-usecase-index	Controle of usecases door FO-hoofdstukken worden geraakt.
FO-scherm-index	Controle of schermdocumentatie aan FO-hoofdstukken gekoppeld is.
FO-broninventaris overige markdown	Controle op overige bronbestanden zoals mockups, architectuur en modules.

Registers zijn geen vervanging van inhoudelijke bronanalyse. Zij helpen vooral om dekking en linkbaarheid te bewaken.

Omgaan met ontbrekende bronnen

Wanneer een bron ontbreekt of niet toegankelijk is:

• benoem welke bron niet geraadpleegd kon worden;
• gebruik geen vage verwijzing zoals “zoek zelf in de docs”;
• werk met de beschikbare duurzame bronnen;
• registreer een open punt als de ontbrekende bron een inhoudelijke beslissing blokkeert;
• vraag alleen om bronaanvulling wanneer het punt niet veilig op basis van bestaande bronnen kan worden opgelost.

Omgaan met bronupdates

Wanneer bronbestanden later wijzigen, moet het FO niet automatisch stilzwijgend als achterhaald blijven staan.

Bij relevante bronupdates:

• bepaal welke FO-hoofdstukken geraakt worden;
• update de domeincontractregels;
• pas bronverwijzingen aan;
• controleer registers;
• controleer open punten;
• wijzig geen historische context zonder expliciete bronregel;
• voeg een passend commitbericht toe.

Commitbericht bij hoofdstukwijzigingen

Bij iedere voorgestelde FO-wijziging hoort een kort Engels commitbericht.

Richtlijn:

• eerste regel begint met docs:;
• maximaal enkele zinnen;
• benoem het domein;
• benoem de belangrijkste inhoudelijke aanscherping;
• geen lange changelog;
• geen Nederlandse implementatiediscussie in het commitbericht.

Voorbeeld:

docs: refine functional design source extraction notes

Clarify durable source hierarchy, extraction rules, DRY policy and conflict handling.
Remove lasting references to temporary consolidation documents.
Document review, link, markdown, authorization and open-point handling rules.

Gerelateerde bronverwijzingen

Bron	Link
FO — Bronnen en afbakening	Bronnen en afbakening
FO — Productvisie en scope	Productvisie en scope
FO — Open punten en buiten scope	Open punten en buiten scope
FO — Schermlaag en UX-specificaties	Schermlaag en UX-specificaties
FO — Functionele architectuurcontext	Functionele architectuurcontext
Bronnenoverzicht	Bronnenoverzicht
Usecase-index	FO-usecase-index
Schermindex	FO-scherm-index
Broninventaris overige markdown	FO-broninventaris overige markdown
Usecases	Usecases
Database-informatie	Database-informatie
Ontwerpbronnen	Ontwerpbronnen
Schermdocumentatie	Schermdocumentatie
Mockupdocumentatie	Mockupdocumentatie
Oefenmodules	Oefenmodules
Architectuur	Architectuur