Requirementconventies
2.1 Requirement-ID
Functionele requirement-ID's volgen dit patroon:
SRS-<DOMEIN>-<VOLGNUMMER>
Niet-functionele requirement-ID's volgen dit patroon:
SRS-NFR-<THEMA>-<VOLGNUMMER>
Voorbeelden:
| Prefix | Domein |
|---|---|
| SRS-AUTH | Rollen, context en autorisatie |
| SRS-ACC | Account, profiel en voorkeuren |
| SRS-REL | Relatiebeheer |
| SRS-CAT | Oefencatalogus, niveaus, categorieën en oefeningen |
| SRS-LRN | Leerling oefenen, voortgang en resultaten |
| SRS-SHR | Gedeelde oefeningen |
| SRS-TCH | Docentfunctionaliteit |
| SRS-GUA | Ouder-/voogdfunctionaliteit |
| SRS-ADM | Beheerderfunctionaliteit |
| SRS-MSG | Berichten, communicatie en notificaties |
| SRS-TIC | Meldingen en ticketafhandeling |
| SRS-LIVE | Live meekijken |
| SRS-CNT | Contentbeheer |
| SRS-POP | Popups, templates, features en systeemnotificaties |
| SRS-PDF | PDF-export en resultaatpresentatie |
| SRS-MOD | Oefenmodules en modulepayloads |
| SRS-RDM | Readmodels, tellers en afgeleide schermwaarden |
| SRS-ARCH | Functionele architectuurcontext |
| SRS-NFR | Niet-functionele requirements |
2.2 Requirementtype
| Type | Betekenis |
|---|---|
| Functioneel | Zichtbaar of domeingericht systeemgedrag. |
| Functioneel/Security | Functioneel gedrag met expliciete autorisatie- of securitygrens. |
| Functioneel/Privacy | Functioneel gedrag rond persoonsgegevens, anonimisering, retentie of zichtbaarheid. |
| Functioneel/Data | Gedrag rond bron-van-waarheid, historische context of datamutatie. |
| Functioneel/Audit | Functioneel gedrag waarbij auditregistratie expliciet vereist is. |
| Functioneel/UX | Functioneel zichtbaar gedrag, presentatievolgorde of gebruikersrust zonder pixel-perfect UI-specificatie. |
| Functioneel/Architectuur | Functionele systeem- of containergrens zonder technische implementatiedetail. |
| Niet-functioneel/Security | Security-eis die toetsbaar moet worden gemaakt. |
| Niet-functioneel/Privacy | Privacy-, dataminimalisatie- of anonimiseringseis. |
| Niet-functioneel/Audit | Logging-, audit- of herleidbaarheidseis. |
| Niet-functioneel/Performance | Prestatie-, schaalbaarheids- of efficiëntie-eis. |
| Niet-functioneel/Beschikbaarheid | Eis rond beschikbaarheid, foutafhandeling bij externe afhankelijkheden of herstelbaarheid. |
| Niet-functioneel/Betrouwbaarheid | Eis rond consistentie, bron-van-waarheid of fallback bij gemiste transportevents. |
| Niet-functioneel/Toegankelijkheid | Toegankelijkheids- of bedienbaarheidseis. |
| Niet-functioneel/Logging | Eis rond technische logging, logtoegang of payloadbeperking. |
Een requirement krijgt één primair type. Wanneer een eis meerdere aspecten raakt, wordt het meest bepalende aspect gekozen en wordt de rest in bron, opmerking of acceptatiecriterium benoemd.
2.3 Prioriteit
| Prioriteit | Betekenis |
|---|---|
| Must | Vereist voor de eerste acceptabele SRS-baseline of voor veilige werking. |
| Should | Belangrijk voor de beoogde eerste productervaring, maar kan onder productbesluit gefaseerd worden. |
| Could | Optioneel of latere uitbreiding. |
| Won't | Bewust niet in huidige scope; alleen gebruiken met bron of besluit. |
2.4 Status
| Status | Betekenis |
|---|---|
| Vastgesteld | Opgenomen in de actuele SRS-baseline en bruikbaar voor ontwerp, implementatie, testvoorbereiding en acceptatie. |
| Open | Inhoudelijk nog niet voldoende beslist voor baseline-opname. |
| Uitgesteld | Bewust buiten de actuele SRS-baseline geplaatst, bijvoorbeeld richting Technisch Ontwerp, beleid of latere scope. |
| Vervallen | Niet langer van toepassing, met reden in wijzigingshistorie of reviewbesluit. |
2.5 Acceptatiecriterium
Acceptatiecriteria worden bij voorkeur geschreven in Given/When/Then-vorm:
Gegeven ...
Wanneer ...
Dan ...
En ...
Een requirement is pas reviewbaar wanneer minimaal één toetsbaar acceptatiecriterium bestaat.
2.6 Schermrequirements (REQ-SCH-*)
De SRS is de enige normatieve bron voor centrale requirementtekst, prioriteit en acceptatiecriteria. REQ-SCH-*-items in de schermdocumentatie zijn schermspecifieke verwijzingen en ankers. Zij zijn niet leidend voor centrale requirementtekst, prioriteit of acceptatie.
Iedere REQ-SCH-* wordt via het schermrequirements-trace-register gekoppeld aan een centrale SRS-requirement, als schermspecifiek geclassificeerd of als vervallen/dubbel gemarkeerd. Wanneer een schermrequirement een domeinbrede regel, autorisatiegrens, lifecycle, datamutatie, statusregel, privacyregel, auditverplichting of bron-van-waarheid introduceert die nog niet centraal bestaat, wordt deze als promotiekandidaat gemarkeerd en pas na review als centrale SRS-requirement opgenomen. De eerste promotieronde is verwerkt in SRS-RDM-* voor readmodels, tellers en afgeleide schermwaarden.
In de schermdocumentatie zelf wordt een REQ-SCH-* daarom vastgelegd als traceanker met de kolommen Schermrequirement, Dekt en Schermcontext. De kolom Dekt verwijst naar centrale SRS-*- en AC-*-items; de kolom Schermcontext beschrijft alleen waar het scherm de centrale eis toepast, toont of toetst.
| Classificatie | Gebruik |
|---|---|
| Gedekt door SRS | De schermrequirement is traceerbaar naar een bestaande centrale SRS-requirement of bestaand acceptatiecriterium. |
| Promoveren naar SRS | De schermrequirement bevat mogelijk een ontbrekende centrale eis en vraagt SRS-aanvulling na review. |
| Schermspecifiek | De regel blijft in de schermdocumentatie als UI-, label-, veld-, kolom-, tooltip-, schermvalidatie- of layoutcontextanker. |
| Vervallen/dubbel | De regel is dubbel, verouderd of verkeerd geformuleerd en wordt niet centraal overgenomen. |
2.7 Oefenmodule-eisen (REQ-SCH-MOD-*)
Oefenmodule-eisen vormen een bijzondere requirementslaag voor technische oefenmodules. Zij zijn belangrijker en normatiever dan gewone schermankers, omdat nieuwe oefenmodules na de eerste productversie naar verwachting vaker worden toegevoegd dan dat de generieke applicatie ingrijpend wijzigt. Tegelijk zijn zij niet hetzelfde als centrale SRS-*-requirements: centrale requirements, prioriteiten en acceptatiecriteria blijven in de SRS-tabellen staan.
REQ-SCH-MOD-*-items worden vastgelegd en geclassificeerd in het oefenmodule-eisenregister. Een module-eis kan twee soorten waarde hebben:
| Classificatie | Gebruik |
|---|---|
| Moduleplatform-eis | Generieke eis aan het OefenHub-moduleplatform, zoals registratie, selectie, opslag, voortgang, autorisatie of historische beschikbaarheid. |
| Modulecontract-eis | Eis waaraan iedere technische module moet voldoen om veilig door de generieke engine gebruikt te kunnen worden. |
| Moduleplatform-toepassing | Toepassing van het generieke platformcontract binnen één concrete module. |
| Concrete module-eis | Modulespecifieke configuratie-, generatie-, validatie- of renderingeis voor één benoemde module. |
Wanneer een module-eis een generieke regel introduceert die voor alle modules of de engine geldt en nog niet door SRS-MOD-*, SRS-CAT-*, SRS-LRN-*, SRS-LIVE-*, SRS-PDF-* of relevante NFR's is gedekt, moet deze als kandidaat voor centrale SRS-promotie worden beoordeeld. Concrete module-eisen blijven in de moduledocumentatie en het module-eisenregister, zodat nieuwe modules later zelfstandig kunnen worden gespecificeerd zonder de centrale SRS-index onnodig te laten groeien.
2.8 Usecase-afleidingen (REQ-UC-* en UC-*-REQ-*)
Usecase-afleidingen zijn procesgerichte traceankers. Zij mogen niet uitgroeien tot een tweede normatieve requirementlaag naast de SRS. De centrale requirementtekst, prioriteit en acceptatiecriteria staan uitsluitend in de SRS.
Iedere usecase-afleiding wordt via het usecase-requirements traceability-register gekoppeld aan centrale SRS-*- en AC-*-items, als usecase-specifiek geclassificeerd of als vervallen/dubbel gemarkeerd. Wanneer een usecase-afleiding een domeinbrede regel, autorisatiegrens, lifecycle, datamutatie, statusregel, privacyregel, auditverplichting of bron-van-waarheid introduceert die nog niet centraal bestaat, wordt deze als promotiekandidaat gemarkeerd en pas na review als centrale SRS-requirement opgenomen.
In usecases zelf wordt hoofdstuk 19 daarom vastgelegd als SRS-trace met de kolommen Usecase-afleiding, Dekt en Usecasecontext. De kolom Dekt verwijst naar centrale SRS-*- en AC-*-items; de kolom Usecasecontext beschrijft alleen waar het proces de centrale eis toepast, controleert of muteert.
| Classificatie | Gebruik |
|---|---|
| Gedekt door SRS | De usecase-afleiding is traceerbaar naar een bestaande centrale SRS-requirement of bestaand acceptatiecriterium. |
| Promoveren naar SRS | De usecase-afleiding bevat mogelijk een ontbrekende centrale eis en vraagt SRS-aanvulling na review. |
| Usecase-specifiek | De regel blijft procescontext, afbakening of flowinformatie en wordt niet als centrale SRS-eis opgenomen. |
| Vervallen/dubbel | De regel is dubbel, verouderd of verkeerd geformuleerd en wordt niet centraal overgenomen. |
2.9 Readmodel- en tellerdefinities (RDM-*)
Concrete teller- en readmodeldefinities worden vastgelegd in het readmodel- en tellerdefinitieregister.
RDM-*-ID's zijn geen nieuwe centrale requirements en krijgen daarom geen eigen prioriteit of acceptatie-ID. Zij zijn functionele uitwerkingen van bestaande SRS-RDM-* requirements en bijbehorende domeinrequirements. De SRS blijft leidend voor de betekenis van de teller; het Technisch Ontwerp bepaalt de queryvorm, indexering, caching, materialisatie en performance-aanpak.
Een RDM-*-definitie moet minimaal vastleggen:
| Aspect | Regel |
|---|---|
| Waarde | Welke zichtbare teller, badge, samenvatting of lijstwaarde wordt bedoeld. |
| Context | Binnen welke rol-, relatie-, niveau-, object- of schermcontext de waarde geldt. |
| Meetellogica | Welke records, statussen en tijdvensters meetellen. |
| Uitsluiting | Welke records niet meetellen, zoals testdata, soft-deleted records, verlopen contexten of ongeautoriseerde objecten. |
| Trace | Welke centrale SRS-*- en waar relevant AC-*-items de definitie dekken. |
Meetbare gedragsgrenzen voor readmodels en tellers staan niet per RDM-*-rij herhaald, maar centraal in SRS-NFR-RDM-* en de bijbehorende acceptatiecriteria. Die grenzen bepalen onder meer actualiteit na mutaties, consistentie met detailoverzichten, veilige fallback en gebruikersgerichte responstijd. Het Technisch Ontwerp mag zelf bepalen of dit via directe queries, caching, materialized readmodels, events of jobs wordt gerealiseerd, zolang de functionele betekenis en meetbare SRS-grenzen behouden blijven.
2.10 NFR-meetwaarden
Het NFR-meetwaardenregister bundelt toetsbare grenzen voor bestaande niet-functionele requirements. Dit register introduceert geen nieuwe requirement-ID’s en vervangt geen acceptatiecriteria. Het maakt expliciet welke grens in de SRS thuishoort en welke technische invulling, monitoring, loadtestopzet, retrystrategie of infrastructuur-SLO in het Technisch Ontwerp of beheerbeleid thuishoort.
2.11 Requirementkwaliteit
| Controlepunt | Regel |
|---|---|
| Eenduidigheid | Een requirement beschrijft één toetsbare verwachting. |
| Bron | Iedere requirement verwijst minimaal naar FO of een duurzame bron. |
| Autoriseerbaarheid | Requirements mogen FO-autorisatiegrenzen niet verruimen. |
| Testbaarheid | Een reviewer moet kunnen bepalen of het systeem aan de eis voldoet. |
| Geen implementatiedetail | Services, tabellen, codeklassen en infrastructuur worden alleen genoemd wanneer zij functioneel bron-van-waarheid of context bepalen. |