Usecases
Deze sectie bevat de procesgerichte usecasebeschrijvingen van OefenHub. Usecases beschrijven functioneel gedrag, autorisatie, server-side controles, beslismomenten, datamutaties, events, readmodels, audit en de samenhang tussen schermen en domeinobjecten.
Usecases zijn bewust niet primair per scherm geordend. Eén proces kan meerdere schermen gebruiken en één scherm kan in meerdere processen voorkomen. De koppeling tussen usecases, schermen, popups en requirements wordt vastgelegd in de centrale matrices en registers.
Domeinen
| Domein | Omschrijving |
|---|---|
| Generiek | Roloverschrijdende en applicatiebrede processen, zoals accounttoegang, profiel, relaties, berichten, meldingen en systeemnotificaties. |
| Leerling | Leerlingprocessen rond oefenaanbod, niveaucontext, oefenen, voortgang, resultaten, geschiedenis en gedeelde oefeningen. |
| Ouder/voogd | Ouder-/voogdprocessen rond gekoppelde kinderen, resultaten, geschiedenis en live meekijken. |
| Docent | Docentprocessen rond frontpage, oefenaanbod, niveaus, categorieën, oefeningen, leerlingen, autorisaties, resultaten en live meekijken. |
| Beheerder | Beheerprocessen rond site-instellingen, content, templates, systeemnotificaties, modules, categorieën, accountbeheer, docentondersteuning en beheerlogging. |
Opbouw van usecases
Iedere uitgewerkte usecase gebruikt dezelfde 19-hoofdstukkenstructuur:
- Kerngegevens
- Omschrijving
- Scope
- Pre-condities
- Post-condities
- Trigger
- Normale processtroom
- Alternatieve en exceptionele processtromen
- Business rules
- Datavalidatie
- Datamutaties en events
- Geen datamutaties
- State diagram
- Decision flow
- Data lifecycle diagram
- Sequence diagrammen
- Popupverwijzingen
- Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
- SRS-trace
Acceptatiecriteria worden niet in usecases opgenomen. Hoofdstuk 19 bevat voortaan alleen SRS-trace: de usecase verwijst naar centrale SRS-*- en AC-*-items en bevat geen tweede normatieve requirementtekst.
Documentatieregels
| Onderwerp | Regel |
|---|---|
| Schermen | Usecases verwijzen naar officiële scherm-ID’s en schermdocumentatie, maar beschrijven geen volledige schermopbouw opnieuw. |
| Popups | Usecases verwijzen uitsluitend naar PopupKey; popupteksten, knopteksten, inputlabels, acties en thema’s blijven centraal in popupregister en popup-themes. |
| Autorisatie | Server-side autorisatie is leidend; clientstate, routeparameters of browsercontext mogen toegang nooit verruimen. |
| Datamutaties | Muterende flows benoemen expliciet welke records wijzigen en welke events of historyregels ontstaan. |
| Read-only flows | Read-only flows benoemen expliciet dat zij geen domeinmutaties uitvoeren. |
| Diagrammen | Mermaid-diagrammen worden functioneel gebruikt en afgestemd op de concrete usecase; generieke of decoratieve diagrammen worden vermeden. |
| Afbakening | Usecases verwijzen naar andere domeinen wanneer die bronhoudend zijn en dupliceren die flows niet. |
| SRS-trace | Usecase-afleidingen zijn traceankers naar centrale SRS/AC-items; normatieve requirements en acceptatiecriteria staan uitsluitend in de SRS. |
Registers en matrices
- Usecase-scherm-matrix
- Usecase-popup-matrix
- Usecase-requirement-matrix — verwijst naar de verwerkte SRS-trace
Ontwerpbronnen
- Ontwerpbronnen
- Business rules
- Autorisatiematrix
- Domeinobjecten
- Statusmodellen
- Command-register
- Event-register
- Popup-register
- Popup-themes
Template
Nieuwe usecases worden opgezet volgens het centrale template: