UC-XXX-000 — Naam van de usecase
Gebruik dit template voor elke nieuwe usecasebeschrijving. Vul alleen velden in die functioneel bekend zijn en verwijs naar registers voor centrale definities.
Usecases zijn procesgericht. Zij beschrijven gedrag, beslissingen, datamutaties, events, foutstromen en requirements-afleiding. Schermdocumentatie blijft de bron voor UI-details.
1. Kerngegevens
| Veld | Waarde |
|---|
| Usecase-ID | UC-XXX-000 |
| Naam | |
| Domein | |
| Primaire actor | |
| Secundaire actor(en) | |
| Rolcontext | |
| Betrokken schermen | |
| Gerelateerde usecases | |
| Primaire entiteiten | |
| Secundaire entiteiten / events | |
| Gerelateerde popups | |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | |
2. Omschrijving
Beschrijf de functionele bedoeling van de usecase in enkele alinea’s.
3. Scope
Deze usecase beschrijft:
Deze usecase beschrijft niet:
4. Pre-condities
5. Post-condities
6. Trigger
Beschrijf welke gebruikersactie, systeemgebeurtenis of vervolgflow de usecase start.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|
| 1 | | | | | |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|
| ALT-001 | | | | | |
9. Business rules
Gebruik waar mogelijk ook verwijzingen naar centrale business rules in ontwerpbronnen/business-rules.md.
10. Autorisatie en server-side controles
| Controle | Regel |
|---|
| Rolcontext | |
| Relatiecontext | |
| Objectcontext | |
| Server-side controle | Frontend-zichtbaarheid is nooit voldoende beveiliging. |
11. Datavalidatie
12. Datamutaties en events
| Stap | Type | Entiteit / event | Mutatie |
|---|
| Database | | |
13. Geen datamutaties
Gebruik deze sectie wanneer expliciet moet worden vastgelegd dat een usecase iets niet aanmaakt of wijzigt.
14. Diagrammen
Gebruik diagrammen selectief. Niet iedere usecase hoeft elk diagramtype te bevatten.
| Diagramtype | Wanneer gebruiken? |
|---|
| Sequence diagram | Bij interactie tussen gebruiker, frontend, backend, database, notificatie of externe service. |
| State diagram | Bij domeinobjecten met statussen, zoals uitnodigingen, tickets of oefenruns. |
| Decision flow | Bij veel business rules, blokkades of alternatieve routes. |
| Data lifecycle | Bij belangrijke datamutaties of expliciet “wel/niet aangemaakte” entiteiten. |
| UI-flowdiagram | Alleen als meerdere schermen of modals lastig te volgen zijn. |
| ERD | Niet in usecase; centraal in database-informatie of domeinobjecten. |
14.1 Sequence diagram
14.2 State diagram
14.3 Decision flow
14.4 Data lifecycle
De usecase legt alleen popupverwijzingen vast. Titel, tekst, knoppen, thema, inputvelden en importeerbare PopupDetails-waarden worden centraal beheerd in het popupregister.
| PopupKey | Moment | Variant | Doel |
|---|
| | | |
16. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Doeldocument | Afleiding |
|---|
| Functioneel Ontwerp | |
| Technisch Ontwerp | |
| Software Requirements Specification | |
17. SRS-trace
Usecases bevatten geen normatieve requirementtekst. Gebruik dit hoofdstuk alleen om usecase-afleidingen te koppelen aan centrale SRS- en AC-items.
| Usecase-afleiding | Dekt | Usecasecontext |
|---|
| REQ-UC-XXX-000-001 | SRS-XXX-001, AC-XXX-001 | Korte proces- of schermcontext, geen eisformulering. |
18. Ontwerpbron-impact
Bij het opstellen of wijzigen van de usecase moet worden bepaald welke centrale documenten of registers moeten worden bijgewerkt.
| Ontwerpbron | Impact | Actie |
|---|
| Business rules | | |
| Autorisatiematrix | | |
| Domeinobjecten | | |
| Statusmodellen | | |
| Command-register | | |
| Event-register | | |
| Popup-register | | |
| Popup-themes | | |
| Usecase-scherm-matrix | | |
| Usecase-popup-matrix | | |
| Usecase-requirement-matrix | SRS-trace bijwerken zonder normatieve requirementtekst te dupliceren. | |
| Functioneel Ontwerp | Functionele regels bijwerken wanneer de usecase een functionele ontwerpregel wijzigt of verduidelijkt. | |
| Technisch Ontwerp | Technische ontwerpregels bijwerken wanneer de usecase technische implementatie-impact heeft. | |
| Software Requirements Specification | Alleen bijwerken wanneer centrale requirements, acceptatiecriteria of traceability wijzigen. | |
| Database-informatie | Bijwerken wanneer de usecase tabellen, kolommen, relaties, enumwaarden, readmodels of soft links raakt. | |
| Architectuur | Bijwerken wanneer de usecase architectuurkeuzes, modulegrenzen of integratieprincipes raakt. | |
Wanneer een centrale bron geraakt wordt, wordt de wijziging direct in die bron verwerkt of als concreet aandachtspunt vastgelegd in het relevante register of besluitenoverzicht van die bron.
19. Open punten / aandachtspunten