5.0 KiB
Story Generation Plan — SlpModularCms.Api
Uitvoeringsplan
Stap 1: Persona's definiëren
- Eigenaar (Owner) persona aanmaken
- Beheerder (Administrator) persona aanmaken
- Gebruiker (User) persona aanmaken
Stap 2: User Stories genereren per domein
- Authenticatie stories (login, token refresh, logout)
- Gebruikersbeheer stories (aanmaken, bewerken, verwijderen gebruikers)
- Autorisatie stories (rolbeheer, bevoegdheidsgrenzen)
- Module stories (module laden, module uitschakelen)
- Beschikbaarheidscontrole stories (placeholder/stub interactie)
Stap 3: Acceptatiecriteria toevoegen
- Acceptatiecriteria per story definiëren (INVEST-compliant)
Stap 4: Feature-story mapping
- Elke story koppelen aan het relevante feature-domein (Authenticatie, Gebruikersbeheer, Autorisatie, Setup, Modules, Beschikbaarheidscontrole)
Stap 5: Persona-story mapping
- Elke story koppelen aan relevante persona('s) (Eigenaar, Beheerder, Gebruiker)
Stap 6: Artifacts opslaan
aidlc-docs/inception/user-stories/stories.mdaanmakenaidlc-docs/inception/user-stories/personas.mdaanmaken
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)
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)
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)
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)
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)
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)