Traceability
6.1 Doel
Dit hoofdstuk koppelt SRS-domeinen aan FO-hoofdstukken en bronlagen.
6.2 Schermrequirement-traceability
Schermrequirements worden niet één-op-één gedupliceerd als centrale SRS-requirements. De schermdocumentatie behoudt REQ-SCH-*-ankers voor schermspecifieke UI-, veld-, label-, waardelaag- en contextinformatie. De SRS blijft de canonieke bron voor centrale requirementtekst, prioriteit en acceptatiecriteria; de schermdocumentatie verwijst via compacte tracetabellen naar centrale SRS-*- en AC-*-items.
Het schermrequirements-trace-register legt per REQ-SCH-* vast of de regel:
- al is gedekt door een bestaande centrale requirement of acceptatiecriterium;
- als schermspecifiek anker in de schermdocumentatie blijft;
- als promotiekandidaat naar de SRS moet worden beoordeeld of inmiddels via
SRS-RDM-*is verwerkt; - later als vervallen of dubbel in de schermdocumentatie moet worden opgeschoond.
Promotie naar de SRS gebeurt alleen wanneer een schermrequirement een domeinregel, autorisatiegrens, lifecycle, datamutatie, statusregel, privacyregel, auditverplichting of bron-van-waarheid introduceert die schermoverstijgend of acceptatiekritisch is. Schermspecifieke labels, velden, kolommen, tooltips, layoutcontexten en waardelaagnotities blijven in de schermdocumentatie en worden waar relevant alleen aan bestaande SRS/AC-items gekoppeld.
6.3 Usecase-requirement-traceability
Usecase-afleidingen worden niet één-op-één gedupliceerd als centrale SRS-requirements. De usecases behouden processtappen, pre- en postcondities, alternatieve flows, validatie en datamutaties als procescontext. De SRS blijft de canonieke bron voor centrale requirementtekst, prioriteit en acceptatiecriteria; usecases verwijzen via compacte tracetabellen naar centrale SRS-*- en AC-*-items.
Het usecase-requirements traceability-register legt per usecase-afleiding vast of de regel:
- al is gedekt door een bestaande centrale requirement of acceptatiecriterium;
- als usecase-specifieke procescontext in de usecase blijft;
- als promotiekandidaat naar de SRS moet worden beoordeeld;
- later als vervallen of dubbel in de usecase of matrix moet worden opgeschoond.
Promotie naar de SRS gebeurt alleen wanneer een usecase-afleiding een domeinregel, autorisatiegrens, lifecycle, datamutatie, statusregel, privacyregel, auditverplichting of bron-van-waarheid introduceert die procesoverstijgend of acceptatiekritisch is. Processtappen, schermroutes, lokale uitzonderingspaden, afbakeningszinnen en herhalingen van bestaande SRS-eisen blijven in de usecase en worden waar relevant alleen aan bestaande SRS/AC-items gekoppeld.
6.4 Oefenmodule-requirement-traceability
Oefenmodule-eisen worden niet één-op-één toegevoegd aan de centrale requirementindex. De centrale SRS blijft leidend voor generieke producteisen, prioriteiten en acceptatiecriteria. Module-eisen krijgen wel een eigen traceerbare plek, omdat zij het contract vormen voor uitbreidbare technische oefenmodules en voor concrete module-implementaties.
Het oefenmodule-eisenregister legt per REQ-SCH-MOD-* vast of de eis een generieke moduleplatform-eis, modulecontract-eis, toepassing van het platformcontract of concrete module-eis is. Het register koppelt deze eisen aan bestaande centrale SRS-*- en AC-*-items en maakt zichtbaar welke onderdelen bij nieuwe moduleontwikkeling opnieuw gevolgd moeten worden.
Promotie naar een nieuwe centrale SRS-requirement is alleen nodig wanneer een module-eis een generieke regel introduceert die voor alle modules, de engine, autorisatie, opslag, resultaten, PDF-export of live meekijken geldt en nog niet door bestaande centrale SRS/AC-items wordt gedekt. Concrete module-eisen blijven in de moduledocumentatie en het module-eisenregister.
6.5 Domeintraceability
| SRS-prefix | Primair FO-hoofdstuk | Aanvullende bronnen | Vervolg voor traceability |
|---|---|---|---|
| SRS-AUTH | Rollen, context en autorisatie | FO-19, autorisatiematrix, usecase-trace | Usecase-afleidingen zijn gekoppeld aan bestaande SRS/AC-items. |
| SRS-ACC | Account, profiel en voorkeuren | Generieke accountusecases, database-identiteit | Koppel profiel- en provisioningusecases expliciet. |
| SRS-REL | Relatiebeheer | FO-usecase-index, database-relatiebeheer | Controleer uitnodiging-, acceptatie- en ontkoppelcriteria. |
| SRS-CAT | Oefencatalogus | Docentusecases, database-docentstructuur | Werk teller/readmodelcriteria later uit. |
| SRS-LRN | Leerling oefenen | Leerlingusecases, module-documentatie | Foutscenario’s per run-lifecycle aanvullen. |
| SRS-SHR | Gedeelde oefeningen | Berichten, database-oefenruns | SharedExercise-routering is verwerkt. |
| SRS-TCH | Docentfunctionaliteit | Docentusecases, schermdocumentatie | Scherm-ID’s later koppelen waar acties zichtbaar zijn. |
| SRS-GUA | Ouder-/voogdfunctionaliteit | Ouder-/voogdusecases, live meekijken | Read-only-criteria behouden. |
| SRS-ADM | Beheerderfunctionaliteit | Beheerderusecases, audit, beheerlogs | Audit- en supportacties verder specificeren. |
| SRS-MSG | Berichten, communicatie en notificaties | Database-communicatie, popup/templates | Retentie en participantzichtbaarheid blijven leidend. |
| SRS-TIC | Meldingen en ticketafhandeling | Ticketusecases, database-ticketbeheer | Alternatieve flows rond sluiten/heropenen aanvullen. |
| SRS-LIVE | Live meekijken | live-meekijken-usecases, SignalR-context | Reconnect/stale-state is meetbaar in de Software Requirements Specification; technische uitwerking staat in Technisch Ontwerp: realtime live meekijken. |
| SRS-CNT | Contentbeheer | Contentbeheerusecases, schermdocumentatie | Contactformulier blijft scopebesluit. |
| SRS-POP | Popups, templates, features en systeemnotificaties | Popupregister, popup-themes | Placeholder- en popupkeycontrole later uitvoeren. |
| SRS-PDF | PDF-export | Resultaatusecases, QuestPDF-context | Renderfouten en moduleweergave later concreter testen. |
| SRS-MOD | Oefenmodules | Oefenmodule-documentatie | SchemaVersion- en fallbackcriteria per module aanvullen. |
| SRS-RDM | Frontpages en overzichtsschermen | Schermlaag en UX-specificaties, Functionele beslisregels, schermrequirements-trace-register, readmodel- en tellerdefinities | Concrete functionele tellerdefinities en meetbare NFR-grenzen zijn verwerkt; technische query-, cache- en materialisatieaanpak staat in Technisch Ontwerp: readmodels, tellers, badges, caching en materialisatie. |
| SRS-ARCH | Functionele architectuurcontext | C4-architectuurdocumentatie | Technische afstemming staat in Technisch Ontwerp: architectuuroverzicht en solution-opbouw en Technisch Ontwerp: applicatielagen, projectstructuur en dependency-richting. |
| SRS-NFR | Functionele beslisregels | FO-20, readmodel- en tellerdefinities, NFR-meetwaarden, Technisch Ontwerp, SRS-review | Readmodelmeetwaarden en aanvullende SRS-grenzen voor toegankelijkheid, PDF, realtime herstel, logging, auditinzage en dependency-fallback zijn toegevoegd; infrastructuur-SLO’s en technische meetinrichting blijven Technisch Ontwerp of beleid. |
6.6 Requirementdekking
| Aspect | Regel |
|---|---|
| FO-bron | Iedere requirement heeft minimaal één FO-bron. |
| Usecasebron | Requirementachtige usecase-afleidingen zijn verwerkt in het usecase-requirements traceability-register. |
| Schermbron | Requirements met zichtbaar gedrag krijgen waar nodig een scherm-ID of schermdocumentverwijzing. |
| Acceptatiecriterium | Iedere Must-requirement heeft minimaal één acceptatiecriterium om als vastgesteld onderdeel van de baseline te gelden. |
| NFR-meetwaarde | Niet-functionele eisen verwijzen waar mogelijk naar het NFR-meetwaardenregister; technische meetinrichting blijft Technisch Ontwerp of beheerbeleid. |
6.7 Dekkingsoverzicht
| Categorie | Aantal |
|---|---|
| Functionele requirements | 124 |
| Niet-functionele requirements | 26 |
| Must | 116 |
| Should | 34 |
| Could | 0 |
| Won't | 0 |
6.8 Verdieping van lifecycle-, privacy- en realtimegrenzen
De traceability maakt lifecycle-, fout-, privacy-, beheer- en realtimegrenzen expliciet als centrale requirements. De bronverwijzingen blijven gekoppeld aan het actuele Functioneel Ontwerp, usecases en schermdocumentatie zonder documentversies in de inhoud te dupliceren.
6.9 Readmodelverdieping
Schermrequirement-promotiekandidaten die tellers, samenvattingswaarden, badges en readmodels betreffen zijn gebundeld in SRS-RDM-*. Daardoor bevat de centrale SRS de normatieve regels en behoudt de schermdocumentatie alleen schermspecifieke ankers en context.
6.10 Schermdocumentatie-trace
De schermdocumentatie gebruikt tracetabellen met Schermrequirement, Dekt en Schermcontext. De normatieve eis en acceptatiecriteria blijven centraal in de SRS staan.
6.11 Usecase-trace
Usecase-afleidingen worden gekoppeld via SRS/AC-trace en vormen geen tweede normatieve requirementlaag. Het usecase-requirements traceability-register legt de volledige koppeling vast.
6.12 Readmodel- en tellerdefinities
Het readmodel- en tellerdefinitieregister concretiseert de SRS-RDM-* requirements. Per zichtbare teller, badge, samenvatting of readmodel ligt vast wat functioneel meetelt, wat wordt uitgesloten en welke context de waarde begrenst. Het register verdiept bestaande SRS/AC-items en laat technische queryvorm, indexering, caching en materialisatie aan Technisch Ontwerp: readmodels, tellers, badges, caching en materialisatie.
6.13 Readmodel-NFR-grenzen
SRS-NFR-RDM-* legt readmodelactualiteit, autorisatiegrenzen, tellerconsistentie, veilige fallback en gebruikersgerichte responstijd vast. De SRS bepaalt wat een waarde betekent en hoe betrouwbaar deze zich voor gebruikers moet gedragen; het Technisch Ontwerp bepaalt hoe die grens technisch wordt gerealiseerd.
6.14 NFR-meetwaarden
Het NFR-meetwaardenregister bundelt meetbare grenzen voor bestaande niet-functionele requirements en acceptatiecriteria. Er worden geen extra SRS- of AC-ID’s geïntroduceerd; de trace blijft gekoppeld aan de bestaande NFR-set en aan de bestaande requirementindex.