Skip to main content

Open punten voor SRS

7.1 Doel​

Dit hoofdstuk verzamelt de resterende review-, onderhouds- en beleidsaandachtspunten voor de Software Requirements Specification. Deze punten blokkeren de huidige SRS-baseline niet. Nieuwe functionele eisen worden alleen toegevoegd wanneer zij als centrale requirement thuishoren in de Software Requirements Specification; technische uitwerking blijft in het Technisch Ontwerp, beleidsdetails blijven in beleid of beheerafspraken.

7.2 Afgeronde reviewpunten voor SRS 1.0​

PuntUitkomstBorging
AcceptatiecriteriadekkingAlle vastgestelde SRS-requirements hebben een gekoppeld acceptatiecriterium. De criteria voor realtime gedrag, relatie-uitnodigingen, leerlingfeedback, afleidingsvrije oefenruns, docentautorisatie en kindgerichte foutmeldingen zijn toetsbaar geformuleerd.Acceptatiecriteria + requirement-index
PrioriteitsreviewDe bestaande Must/Should/Could-indeling blijft behouden. Must markeert baseline- of veiligheidskritische eisen; Should blijft bewust faseerbaar onder productbesluit zonder de functionele betekenis van de eis te verlagen.Requirementconventies + requirement-index

7.3 Afgedichte opvolgpunten na Technisch Ontwerp- en documentatieafstemming​

PuntUitkomstBorging
Readmodel- en Technisch Ontwerp-queryafstemmingAfgedicht voor de SRS-baseline. De functionele tellerdefinities en SRS-NFR-RDM-*-grenzen zijn technisch doorvertaald naar query-, caching-, materialisatie-, fallback- en performanceafspraken. De Software Requirements Specification blijft bron voor functionele betekenis en autorisatiescope; het Technisch Ontwerp bepaalt de technische realisatie.Readmodel- en tellerdefinities + Technisch Ontwerp: readmodels, tellers, badges, caching en materialisatie + Technisch Ontwerp: performance
Foutscenario's per usecaseAfgedicht voor de huidige usecaseset. De kernusecases bevatten alternatieve en exceptionele processtromen voor verlopen context, gewijzigde autorisatie, validatiefouten, race conditions, ontbrekende data en veilige fallback. Nieuwe usecases moeten dezelfde structuur blijven volgen.Usecases + usecase-trace-register
Niet-functionele meetwaardenAfgedicht voor de SRS-baseline. De SRS bevat toetsbare NFR-grenzen en het Technisch Ontwerp heeft de technische baselines uitgewerkt voor performance, PDF-export, realtime reconnect, logging/retentie, CSP, rate limiting, backup/restore, testaanpak en readmodelmaterialisatie. Formele WCAG-audit en operationele uitvoering blijven test-/beheeractiviteiten en leveren alleen nieuwe SRS-wijzigingen op wanneer zij een centrale requirement veranderen.Niet-functionele requirements + NFR-meetwaardenregister + Technisch Ontwerp
Retentie detailtermijnenAfgedicht waar de huidige baseline concrete technische termijnen nodig heeft. PDF-tempopslag, logretentie, backup-/restoredoelen en relevante privacy-/anonimiseringsregels zijn technisch vastgelegd. Juridische bewaarplichten of beleidskeuzes buiten de bekende productscope worden niet als SRS-detail opgenomen zonder apart beleidsbesluit.Technisch Ontwerp: logging + Technisch Ontwerp: operatie + Technisch Ontwerp: privacy en retentie
Technisch Ontwerp-afstemmingAfgedicht voor de recente baseline. De relevante technische keuzes rond modulaire monoliet, MudBlazor/componentenstrategie, architecture tests, PDF-regressie, materialized readmodels, seeddata, RPO/RTO, performance, EF Core migrations, tijdelijke PDF-opslag, Blazor/E2E-tests, SignalR reconnect, Serilog/Seq, securityevents, CSP, rate limits, oefenmodulecategorieën en cross-module transaction boundaries zijn in het Technisch Ontwerp verwerkt. Nieuwe technische besluiten worden voortaan via normale impactanalyse op Software Requirements Specification, Functioneel Ontwerp, database-informatie, usecases en schermdocumentatie beoordeeld.Technisch Ontwerp: open punten en besluitenregister

7.4 Resterende onderhouds- en beleidsaandachtspunten​

PuntVervolgactieBeoogde bronlaag
Schermtraceability onderhoudHoud nieuwe of gewijzigde REQ-SCH-*-ankers in schermdocumentatie gekoppeld aan centrale SRS/AC-items zonder normatieve tekst te dupliceren. Dit is doorlopend onderhoud, geen open blocker voor de huidige baseline.SRS trace-register + schermdocumentatie
Usecase-traceability onderhoudHoud nieuwe of gewijzigde usecase-afleidingen gekoppeld aan centrale SRS/AC-items zonder normatieve requirementtekst te dupliceren. Dit is doorlopend onderhoud, geen open blocker voor de huidige baseline.Usecase-trace-register + usecases
Toegankelijkheidsaudit en uitzonderingenVoer formele toegankelijkheidscontrole uit tijdens test/acceptatie. Alleen bevindingen die de functionele toegankelijkheidsbaseline wijzigen leiden tot een SRS-wijziging.Niet-functionele requirements + teststrategie
Juridische of beleidsmatige retentie buiten productbaselineVoeg alleen aanvullende bewaartermijnen toe wanneer juridisch beleid, privacybeleid of beheerbesluit concrete eisen stelt die verder gaan dan de huidige technische baseline.SRS/beleid/beheer

7.5 Niet opnemen als SRS-detail zonder apart besluit​

  • technische implementatieklassen;
  • database-DDL;
  • sprintplanning;
  • juridische beleidsprocedures;
  • volledige CSS- of pixel-perfect specificaties;
  • vrije pagebuilder- of native-appscope.

7.6 Afrondingscriteria voor SRS-review​

CriteriumBetekenis
RequirementdekkingAlle primaire usecasegroepen zijn via SRS/AC-trace gekoppeld of expliciet usecase-specifiek geclassificeerd.
AcceptatiedekkingAlle Must-requirements hebben minimaal één toetsbaar acceptatiecriterium.
PrioriteitsbesluitMust/Should/Could is inhoudelijk gevalideerd.
NFR-meetbaarheidReadmodel-NFR's en overige NFR's hebben toetsbare grenzen in de Software Requirements Specification of een expliciete technische baseline in het Technisch Ontwerp.
TraceabilityElke requirement verwijst naar Functioneel Ontwerp en waar nodig usecase- of schermdocumentatie.