30 — Product Requirements Documents
PRDs beschrijven wat een proces of feature moet doen vanuit het perspectief van de gebruiker. Ze zijn product-gericht: ze zeggen wat er voor de gebruiker verandert, niet hoe het wordt geïmplementeerd.
Elke PRD koppelt aan een of meer TDS documenten (het technische doel) en een implementatieplan (de stappen).
Reikwijdte in Documentatie
PRDs hier gaan over cross-repo veranderingen — features die meerdere apps tegelijk raken, gedeelde contracten, of portfolio-brede toevoegingen. PRDs binnen één app blijven in die product-repo.
Wanneer wel
- Een nieuwe cross-app feature wordt geïntroduceerd
- Een bestaande cross-repo flow verandert op een gebruiker-zichtbare manier
- Stakeholders moeten het eens worden over uitkomsten voordat ontwerp begint
Wanneer niet
- Pure refactors of tech-debt — die gaan direct naar een TDS
- Bug fixes — die zijn GitHub Issues
- Kleine UX-wijzigingen — die staan in de PR-omschrijving
Statuswaarden
| Status | Betekenis |
|---|---|
| Concept | Wordt geschreven |
| In beoordeling | Wacht op akkoord van stakeholders |
| Goedgekeurd | Klaar om een TDS van te maken |
| Opgeleverd | Het werk is af en live |
| Gearchiveerd | Vervangen of gestaakt |
Bestandspatroon
<slug>-prd.md — bijv. cross-repo-woordenlijst-prd.md.
Sjabloon
# <Titel> PRD
**Datum:** YYYY-MM-DD
**Status:** Concept | In beoordeling | Goedgekeurd | Opgeleverd | Gearchiveerd
**Eigenaar:** <persoon of team>
## Probleem
(Wat is er nu kapot of mist. Maak het concreet.)
## Doel
(Eén zin. Wat ziet succes eruit.)
## Niet-doelen
(Wat deze PRD expliciet *niet* op zich neemt.)
## Productprincipes
(Optioneel — de waarden die het ontwerp leiden.)
## Gewenste gebruikerservaring
(Loop de 2–3 hoofdflows door vanuit het gebruikersperspectief. Geen implementatiedetail.)
## Vereisten
### Must have
-
### Should have
-
### Nice to have
-
## Openstaande vragen
-
## Gerelateerd
- TDS: [[TDS-NAAM]]
- ADRs: [[ADR-NAAM]]
- Plan: [[plan-naam]]