Initial commit with inital CMS
This commit is contained in:
@@ -0,0 +1,131 @@
|
||||
# Story Generation Plan — SlpModularCms.Api
|
||||
|
||||
## Uitvoeringsplan
|
||||
|
||||
### Stap 1: Persona's definiëren
|
||||
- [x] Eigenaar (Owner) persona aanmaken
|
||||
- [x] Beheerder (Administrator) persona aanmaken
|
||||
- [x] Gebruiker (User) persona aanmaken
|
||||
|
||||
### Stap 2: User Stories genereren per domein
|
||||
- [x] Authenticatie stories (login, token refresh, logout)
|
||||
- [x] Gebruikersbeheer stories (aanmaken, bewerken, verwijderen gebruikers)
|
||||
- [x] Autorisatie stories (rolbeheer, bevoegdheidsgrenzen)
|
||||
- [x] Module stories (module laden, module uitschakelen)
|
||||
- [x] Beschikbaarheidscontrole stories (placeholder/stub interactie)
|
||||
|
||||
### Stap 3: Acceptatiecriteria toevoegen
|
||||
- [x] Acceptatiecriteria per story definiëren (INVEST-compliant)
|
||||
|
||||
### Stap 4: Feature-story mapping
|
||||
- [x] Elke story koppelen aan het relevante feature-domein (Authenticatie, Gebruikersbeheer, Autorisatie, Setup, Modules, Beschikbaarheidscontrole)
|
||||
|
||||
### Stap 5: Persona-story mapping
|
||||
- [x] Elke story koppelen aan relevante persona('s) (Eigenaar, Beheerder, Gebruiker)
|
||||
|
||||
### Stap 6: Artifacts opslaan
|
||||
- [x] `aidlc-docs/inception/user-stories/stories.md` aanmaken
|
||||
- [x] `aidlc-docs/inception/user-stories/personas.md` aanmaken
|
||||
|
||||
---
|
||||
|
||||
## Vragen voor Story Planning
|
||||
|
||||
Beantwoord elke vraag door de letter van jouw keuze in te vullen na de `[Answer]:` tag.
|
||||
|
||||
---
|
||||
|
||||
### Vraag 1: Story breakdown aanpak
|
||||
Hoe moeten de user stories worden georganiseerd?
|
||||
|
||||
A) Feature-gebaseerd — stories gegroepeerd per systeemfunctionaliteit (authenticatie, gebruikersbeheer, modules)
|
||||
B) Persona-gebaseerd — stories gegroepeerd per gebruikerstype (Eigenaar, Beheerder, Gebruiker)
|
||||
C) User Journey-gebaseerd — stories volgen de workflow van een gebruiker van begin tot eind
|
||||
D) Epic-gebaseerd — hiërarchische structuur met epics en sub-stories
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
---
|
||||
|
||||
### Vraag 2: Story granulariteit
|
||||
Hoe gedetailleerd moeten de user stories zijn?
|
||||
|
||||
A) Hoog niveau — epics met globale beschrijvingen, details komen later
|
||||
B) Standaard — "Als [rol] wil ik [actie] zodat [doel]" met basisacceptatiecriteria
|
||||
C) Gedetailleerd — uitgebreide acceptatiecriteria met edge cases en foutscenario's
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: B
|
||||
|
||||
---
|
||||
|
||||
### Vraag 3: Gebruiker (User) rol — specifieke rechten
|
||||
De requirements vermelden dat Gebruikers "configureerbare rechten per klant" hebben. Welke standaard rechten moet een Gebruiker hebben in de MVP (voordat een Beheerder iets aanpast)?
|
||||
|
||||
A) Alleen lezen — Gebruiker kan alleen content bekijken, niets aanpassen
|
||||
B) Beperkt bewerken — Gebruiker kan eigen profiel en toegewezen content bewerken
|
||||
C) Geen rechten — Gebruiker heeft standaard geen rechten totdat een Beheerder ze instelt
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: X, Alleen lezen en eigen profiel bewerken.
|
||||
|
||||
---
|
||||
|
||||
### Vraag 4: Eigenaarschap overdracht
|
||||
Hoe moet eigenaarschap overdracht werken?
|
||||
|
||||
A) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar wordt automatisch Beheerder
|
||||
B) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar behoudt ook de Eigenaar rol (meerdere eigenaars mogelijk)
|
||||
C) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar kiest zelf welke rol hij behoudt
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: B
|
||||
|
||||
---
|
||||
|
||||
### Vraag 5: Wachtwoord reset / initieel wachtwoord
|
||||
Hoe wordt het initiële wachtwoord van een nieuwe gebruiker ingesteld?
|
||||
|
||||
A) Beheerder/Eigenaar stelt een tijdelijk wachtwoord in — gebruiker moet dit wijzigen bij eerste login
|
||||
B) Beheerder/Eigenaar stelt een permanent wachtwoord in — geen verplichte wijziging
|
||||
C) Systeem stuurt een uitnodigingslink per e-mail — gebruiker stelt zelf wachtwoord in
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
---
|
||||
|
||||
### Vraag 6: Refresh token gedrag
|
||||
Hoe moeten refresh tokens werken?
|
||||
|
||||
A) Refresh token is eenmalig bruikbaar — na gebruik wordt een nieuw refresh token uitgegeven (rotation)
|
||||
B) Refresh token is herbruikbaar tot vervaldatum — geen rotation
|
||||
C) Refresh token vervalt bij uitloggen en bij inactiviteit na een configureerbare periode
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
---
|
||||
|
||||
### Vraag 7: Eerste Eigenaar aanmaken
|
||||
Hoe wordt de eerste Eigenaar van een nieuwe installatie aangemaakt? (Er is geen andere Eigenaar/Beheerder om dit te doen)
|
||||
|
||||
A) Via een seed/migratie script dat bij eerste deployment wordt uitgevoerd
|
||||
B) Via een speciaal setup-endpoint dat alleen beschikbaar is als er nog geen Eigenaar bestaat
|
||||
C) Via configuratie in appsettings (e-mail + wachtwoord bij eerste start)
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: X, Optie A of B, wat is het handigste? Optie A zou ook kunnen als directe aanpassing in database en dan een Wachtwoord vergeten optie
|
||||
|
||||
---
|
||||
|
||||
### Vraag 8: Module rechten voor Gebruikers
|
||||
Kunnen Gebruikers rechten krijgen die specifiek zijn per module?
|
||||
|
||||
A) Ja — modules kunnen eigen rechten definiëren die een Beheerder/Eigenaar aan Gebruikers kan toekennen
|
||||
B) Nee — rechten zijn globaal voor de hele API, niet per module
|
||||
C) Nog niet in MVP — architectuur moet het later mogelijk maken
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
Reference in New Issue
Block a user