Als gemeente wil ik dat registratiecomponenten onafhankelijk van elkaar en onafhankelijk van de ZTC kunnen worden gebruikt

[Hugo-ter-Doest]

zodat ik mijn applicatielandschap flexibel(er) kan inrichten en registratiecomponenten zowel voor ZGW als voor niet-ZGW kan gebruiken.

Dit geldt i.i.g. voor DRC en BRC die ook buiten ZGW een rol zullen gaan spelen.

Bepaling prioriteit door PO

• [ ] verbreding of verdieping API's
• [ ] stimuleert gebruik door gemeenten
• [ ] stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• [ ] Iedereen in het team begrijpt de user story
• [ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• [ ] Is klein genoeg (maximaal 1/5 van sprint)
• [ ] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [ ] Userstory is voorzien van een analyse (met daarin architectuur, IM, technische beslissingen afgestemd met team)
• [ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] Er is een OAS 3.0 specificatie
• [ ] Er is een referentieimplementatie
• [ ] Er zijn tests aanwezig die de wijziging aantonen
• [ ] De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

• [ ] De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• [ ] Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• [ ] Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• [ ] Implementeren in referentie-implementatie [verantwoordelijke]
• [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

[Hugo-ter-Doest]

@joeribekker helder zo?