Als medewerker van de gemeente wil ik dat informatie over zaken van andere afdelingen voor mij begrijpelijk is

[ArjanKloosterboer]

...zodat ik een goed beeld heb van de afhandeling van voor mijn werk relevante zaken buiten mijn directe werkomgeving.

Het gaat dan bijvoorbeeld om een KCC-medewerker die op hoofdlijnen de informatie over een zaak wil kunnen begrijpen en juist interpreteren. Of een BAG-beheerder voor wie een vergunningzaak relevant is. Of een belastingenmedewerker voor wie een bouwtoezichtzaak relevant is. Of ...

Een zaak is ingericht o.b.v. een van toepassing zijnd zaaktype. Die zaaktypen kunnen wezenlijk van elkaar verchillen tussen taakvelden. Dit kan terecht zo zijn gezien inhoudelijke verschillen tussen die taakvelden. Toch is het soms nodig dat een medewerker van een taakveld de zaken van een ander taakveld juist kan interpreteren. De zaaktype-catalogus heeft hier voorzieningen voor: attributen waarvan de naam eindigt op 'generiek'. Wenselijk is dat we voor deze attributen voorzien in een landelijke waardentabel. Zaken worden dan ook over organisaties heen eenduidiger interpreteerbaar. En ook naar burger en bedrijf.

Er moet hiertoe functionaliteit komen om deze ZTC-attributen te kunnen onderhouden en bevragen. En er moeten API's komen voor de desbetreffende waardentabellen. En er moet iets geregeld worden dat er ergens een (landelijke) voorziening is waar deze tabellen 'draaien'. En het beheer van deze tabellen moet geregeld worden.

Het betreft de volgende attributen en bijbehorende waardetabellen (in RGBZ-termen: Referentielijsten):

• n.t.b.

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 Eelco)
• [ ] Voorzien van acceptatiecriteria (duidelijk en testbaar)
• [ ] Voorzien van Definition of Done (duidelijk en testbaar)
• [ ] Voorzien van taken
• [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [ ] Userstory is ingevuld op template architectuurschets
• [ ] Userstory is voorzien van veldmapping naar RGBZ2 (mag alleen afgevinkt worden door Arjan)
• [ ] Userstory past op wenselijk gebruik ZGW volgens GEMMA 2 (mag alleen afgevinkt worden door Jeffrey)
• [ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] er is een OAS 3.0 specificatie
• [ ] de functionele specificatie is gepubliceerd leesbaar
• [ ] de technische specificatie is gepubliceerd leesbaar
• [ ] er is een referentieimplementatie
• [ ] de DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• [ ] eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• [ ] er zijn geen (nieuwe) conflicten met ontwerp keuzes in BIP
• [ ] review heeft plaatsgevonden (dus reviewers hebben voldoende en vindbare info om te kunnen reviewen (dus duidelijke verwijzing in issue/user story naar deze documentatie)
• [ ] wijzigigen als gevolg van user story zijn vindbaar en gedocumenteerd
• [ ] functionele documentatie is gereviewd door developers (lees is techniek in overeenstemming met functionele documentatie)

Acceptatiecriteria Uit de algemene uitgangspunten:

• [ ] Voldoet aan RGBZ 2.0
• [ ] Voldoet aan GEMMA 2.0

Taken

• [ ] Opstellen welke velden bij een melding horen [verantwoordelijke]
• [ ] Aanleveren testdata [verantwoordelijke]
• [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• [ ] Implementeren in referentie-implementatie [verantwoordelijke]
• [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• [ ] Functionele documentatie [verantwoordelijke]
• [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

[TCIMEddy]

@ehotting graag prioriteit en visie

[ehotting]

Begrijp de ontstaansgeschiedenis maar zou liever energie steken in echte standaardisatie, waarbij we proberen het totaal aantal mogelijke waarden voor dergelijke attributen wat te beperken. Dit kan vervolgens ook aan consumer-kant worden opgelost, aangezien niet in iedere gemeente dit een issue zal zijn. Afdelingen die een centrale rol hebben (zoals KCC) worden juist geacht wél het domeinspecifieke jargon te kennen. De constructie met domeinespecifieke attributen en generieke attributen waartussen een mapping nodig is vind ik niet fraai en zouden we moeten voorkomen.

[ehotting]

@TCIMEddy staat op twee borden nu