Ontwerpbronnen
De ontwerpbronnen vormen de brug tussen usecases, schermdocumentatie, database-informatie, Functioneel Ontwerp, Technisch Ontwerp en Software Requirements Specification. Ze leggen gedeelde conclusies centraal vast zodat dezelfde regels niet per usecase opnieuw geïnterpreteerd hoeven te worden.
Documenten
| Document | Doel |
|---|---|
| Business rules | Domeinbrede regels die in meerdere usecases terugkomen. |
| Autorisatiematrix | Overzicht van acties, contextcontroles en overgang van rolkolommen naar permissions. |
| RBAC-permissieregister | Canonieke permission-codes, naamgevingsconventie, seedbundels en cache-/validatieregels voor permission-based RBAC. |
| Domeinobjecten | Mapping tussen functionele begrippen en database-entiteiten/readmodels. |
| Statusmodellen | Statuswaarden en statusovergangen voor domeinobjecten. |
| Command-register | Gebruikersacties en systeemacties gekoppeld aan technische commands/API-acties. |
| Event-register | Functionele en technische gebeurtenissen voor audit, notificaties en verwerking. |
| Popup-register | Centrale bron voor dynamische popups, popupkeys, teksten, knoppen en inputvelden. |
| Popup-themes | Herbruikbare theme-, variant- en importdefaults voor dynamische popups. |
| Header, footer en responsieve navigatie | Overkoepelende regels voor applicatieschil, responsieve menugroepering, begroeting, badges tijdens oefenen en footerresponsiviteit. |
Relatie met usecases
Na iedere volledig uitgewerkte usecase wordt een impactronde uitgevoerd. Alleen ontwerpbronnen die door de usecase geraakt worden, worden aangepast.
De impactronde controleert minimaal:
| Ontwerpbron | Wanneer bijwerken |
|---|---|
| Business rules | Nieuwe of aangescherpte domeinregel. |
| Autorisatiematrix | Nieuwe actie, command of contextcontrole. |
| RBAC-permissieregister | Nieuwe permission-code, gewijzigde permission-betekenis, seedbundel of cache-/validatieregel. |
| Domeinobjecten | Nieuw functioneel begrip, nieuwe mapping of aangescherpte entiteitbetekenis. |
| Statusmodellen | Nieuwe status, overgang of functionele state. |
| Command-register | Nieuwe gebruikersactie, systeemactie of API-command. |
| Event-register | Nieuw domeinevent, audit-event, notificatie-event of geplande verwerking. |
| Popup-register | Nieuwe popupkey of aangepaste popupdefinitie. |
| Popup-themes | Nieuwe popupvariant of nieuw theme/default. |
| Usecase-matrices | Nieuwe koppeling tussen usecase, schermen, popups of requirements. |
to-change.md | Iedere wijziging die later nog in database-informatie, Functioneel Ontwerp, Technisch Ontwerp en Software Requirements Specification of architectuur verwerkt moet worden. |
To-change
Niet alle conclusies uit usecases worden direct verwerkt in database-informatie, Functioneel Ontwerp, Technisch Ontwerp en Software Requirements Specification of architectuur. Zulke openstaande afgeleide wijzigingen worden vastgelegd in:
usecases/registers/to-change.md
Dit bestand is de centrale werkvoorraad voor vervolgverwerking buiten de usecase- en ontwerpbronnenlaag.
Popup-uitgangspunt
Voor niet-custom popups geldt:
PopupDetails-importrecord = PopupRegisterRow + PopupThemeDefaults + VariantDefaults
De popup-registerregel is de enige inhoudelijke bron voor titel, tekst, knoptekst, knopactie en inputvelden. Detailtabellen zijn alleen toegestaan voor Variant=Custom.
Ouder-/voogdresultaten en live meekijken
- Ouder-/voogdresultaten zijn read-only readmodels boven bestaande
ExerciseRunsenExerciseRunProgress. - Live meekijken door ouder/voogd gebruikt
LiveViewAudituitsluitend bij daadwerkelijke live-start; online-overzichten en beschikbaarheidschecks blijven read-only. - Popupverwijzingen voor ouder-/voogd-resultaten en live zijn genormaliseerd naar
POP-OVG-*en horen uitsluitend in het popupregister en de usecase-popup-matrix thuis. - De usecase-requirement-matrix bevat nu ook
UC-OVG-RES-*enUC-OVG-LIVE-*.