-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Overgenomen uit hoofdstuk 3 van het document 20220701.MVP.Huwelijksplanner.2022_v0.96 (zie bijlage).
Dit hoofdstuk gaat in op de scope en de minimale eisen die aan de functionaliteit van het zgn. Minimum Viable Product van de huwelijksplanner worden gesteld. Het MVP is een huwelijksplanner met genoeg functionaliteit om voldoende waarde te hebben om vroeg aansluitende gebruikers aan te kunnen sluiten en een werkend product in handen te hebben.
We richten ons in het MVP op:
- Gratis Huwelijk/partnerschap
- Eenvoudig huwelijk/partnerschap
- Flits- en baliehuwelijk/partnerschap, variant op eenvoudig
Trouwstellen kunnen een huwelijk digitaal plannen / reserveren. Tijdens het plannen van het huwelijk, wordt meteen de melding voorgenomen huwelijk gedaan.
De voor het trouwstel benodigde functionaliteit is zichtbaar in een prototype: https://huwelijk.utrecht.eend.nl/docs/site/huwelijksplanner-uitgebreid/
Met als toelichting:
- Kies voor eenvoudig trouwen op 14 april 2021, anders kom je bij de datum/tijd stap niet verder.
- Je kijkt hier naar een prototype dat gebouwd is om een idee weer te geven, dus…
- er worden geen ingevulde gegevens opgeslagen. Als je bijvoorbeeld een getuige invult, zal dit niet onthouden worden.
- niet alle klikpaden zijn helemaal uitgewerkt. De ‘extra’s’ pagina is er bijvoorbeeld wel, maar je zal met de hand even terug moeten klikken.
- de teksten die er staan zijn niet de laatste versie van de teksten.
- de look & feel zal nog veranderen en meer richting de huisstijl van de gemeente Utrecht gaan.
De backend moet minimaal de in het prototype zichtbare functionaliteit ondersteunen. Met als uitzondering de geautomatiseerde checks, die nog vervangen moeten worden door een handmatige actie in het prototype.
In de volgende paragrafen wordt de benodigde functionaliteit verder toegelicht.
- De inwoner heeft de mogelijkheid om een reservering voor een flits, eenvoudig of gratis huwelijk/partnerschap te maken die aan de minimale indieningsvereisten voldoet
- De inwoner kan zelf een datum, tijd en type ceremonie kiezen obv beschikbaarheid.
- Reservering alleen met DigiD. Op de webpagina wordt aangegeven dat zonder DigiD alleen aan de balie kan
- Melding voorgenomen huwelijk geïntegreerd in huwelijksplanner. Inclusief bericht naar burger over status van de melding.
- Afleggen van de verklaringen (leeftijd, curatele, bloedverwantschap 2e graads en reeds getrouwd.)
- Getuigen kunnen doorgeven en uitnodigen
- Extra's kunnen kiezen en betalen.
- Dubbele inlog faciliteren voor partner, naast mogelijkheid via instemmingsverzoek
- Bevestigingen van reservering, betaling en instemmingen versturen. Alle notificaties gaan per e-mail.
- Betaalproces via Ideal. Inclusief bijbetalen als de reservering wijzigt. (Terugstorten buiten Huwelijksplanner om)
- Duidelijke informatie en navigatie in de huwelijksplanner
- Wijzigen van contactgegevens, wijzigen of toevoegen van getuigen en toevoegen van extra's
- Annuleren van reservering
- Instemming kunnen geven door getuigen en partners. Alleen met Digid
- Een huwelijk mag niet eerder dan een jaar van te voren gepland worden.
- Een (tijdelijk) gereserveerde locatie/tijd moet na een op te geven termijn weer vrijgegeven worden indien de reservering niet afgemaakt wordt (dat betekent niet definitief ingediend -> trouwstel is niet op de samenvattingspagina gekomen).
- Er moet een maximale termijn ingesteld zijn waarop getuigen toegevoegd of gewijzigd kunnen worden.
- Er moet een maximale termijn ingesteld zijn waarop extra’s toegevoegd of gewijzigd kunnen worden.
- Er moet een minimale termijn ingesteld zijn tussen de reservering en huwelijksdatum. Rationale: je wilt niet dat een trouwstel een huwelijk voor morgen reserveert. Wettelijke termijn is 14 dagen, laten we die aanhouden voor de MVP.
Wat we zoeken? We zoeken een partij die voor ons het front end kan ontwikkelen voor de huwelijkplanner.
- Kennis van het vak
- Innovatieve kijk
- Goed kunnen samenwerken
- Kennis kunnen delen en overdragen “jezelf misbaar en overbodig maken”
- Achtervang bij uitval geregeld
- Nederlandse taal machtig
- Eenvoudig en toegankelijk kunnen bouwen
- Kennis Common Ground
- Kennis van NL Design Systems
- Aantoonbare werkervaring en referenties
- Ervaring met Gemeenten of overheid
- Beschikbaarheid, termijn/tijd
- Verhouding tussen prijs en kwaliteit
- Front End bouwen voor Eenvoudig, Gratis en Flits huwelijk/geregistreerd partnerschap
- Front End bouwen op basis van prototype (https://huwelijk.utrecht.eend.nl/docs/site/huwelijksplanner/index.html - kies bij de datumprikker voor Eenvoudig trouwen, 14 april, 10:00 om verder te kunnen)
- Front End koppelen met NL DesignSystem - Utrecht
- Goed gedocumenteerde open source code maken
- Front End koppelen via API calls aan back end
- Een Front End opleveren die makkelijk over te dragen is aan beheer
- Open source software gebruiken en opleveren
- Herbruikbaar en schaalbaar door opbouw in componenten/services/API’s.
- Herbruikbaar voor meerdere doeleinden, niet alleen voor de huwelijksplanner.
- Inrichting geschikt om te ontsluiten als mobiele variant.
- Geschikt om nieuwe tools voor de digitaal identificeren te toetsen.
- Persoonlijke eigenschappen
- Enthousiast en creatief zijn
- Ervaring met gemeente/overheid
- Ervaring ontwikkelen containers in Kubernetes
- Aantoonbare werk ervaring:
- Toegankelijk apps kunnen bouwen
- Werken aan en met Design System
- Werken aan en met API's
- Ervaring met Common Ground projecten
- Weet wanner hij/zij sober of saai moet ontwerpen, en wanneer niet
- Ervaring met progressive webapp maken
- javascript
- React / Angular / Vue
- JSON
- HTML
- CSS/SCSS
- CSS variabelen
- BEM
- Stencil js
- Storybook
- Componenten kunnen opleveren/beheren in het een NL Design system
- WCAG 2.1
- GitHub
En zeker ook
- Kunnen omgaan met feedback
- Kunnen denken vanuit toegevoegde waarde
- Zich in kunnen leven in de gebruiker
Ons aanbod aan Utrecht: Hierbij onze grove planning, inclusief de plekken waar de frontend (mogelijk) even op de anderen moet wachten. Op basis van deze planning hebben we ook een offerte gemaakt. Deze bestaat wat ons betreft uit twee delen: frontend op resultaatbasis en coördinatie api en deployment op prestatiebasis.
week 1: (40u frontend, ~4 tot 8 uur samenwerking api en ci/cd):
- Wireframe niveau frontend implementatie
- Dockerfile opleveren
- Login gegevens testomgeving aanvragen
week 2: (~40u nacalculatie basis samenwerking api en ci/cd):
- aansluiten op API van testomgeving
- terugkoppeling naar API ontwikkelaars bij problemen en wensen
Pauze voor frontend totdat de API ver genoeg is
week 3: (40u frontend, eventueel in overleg ~4 tot 8u samenwerking api team om api helder te krijgen):
- bestaande componenten inzetten
- componenten Utrecht Design System uitwerken
week 4: (40u frontend, eventueel in overleg ~4 tot 8u samenwerking api team om api helder te krijgen):
- componenten Utrecht Design System uitwerken
- redactie betrekken bij verbeteren teksten en foutmeldingen
Mogelijk pauze voor frontend totdat de API er klaar voor is
week 5: (40u nacalculatie basis samenwerking api en ci/cd):
- deployment verder uitwerken
- aansluiten op productieomgeving
- iteratie op aansluiting API
- op problemen stuiten
week 6: (geen frontend, samenwerking in overleg):
- accessibility audit door gemeente Utrecht
- gebruikerstest door gemeente Utrecht
Mogelijk pauze voor frontend totdat de API en teksten er klaar voor zijn
week 7: (40u frontend, ~8 tot 10u samenwerking api en ci/cd):
- iteratie op UI
- iteratie op teksten
- iteratie op API problemen
- responsive verbeteringen
Voor ons heeft dit project twee kanten, de kant van de frontend werkzaamheden en de werkzaamheden die nodig zijn om koppelen aan de API mogelijk te maken en de applicatie te publiceren.
Voor de werkzaamheden die nodig zijn voor de samenwerking om de API te koppelen en de app te publiceren hebben wij een afhankelijkheid van de andere partijen die hier verantwoordelijk voor zijn. Afhankelijk van hoeveel samenwerking er nodig en gewenst is, hoeveel wij moeten meehelpen/vergaderen over de nodige verbeteringen zijn we veel of weinig tijd kwijt.
Voor dat deel van de werkzaamheden willen we dus graag goede afspraken maken en voor 100 euro per uur deze werkzaamheden op prestatie basis doen. We verwachten voor het koppelen van de api en klaarzetten van de deployment 2 weken fulltime bezig te zijn. Daarnaast reserveren we 8u per week voor coördinatie en overleg. Voor de offerte van de api en ci/cd samenwerking komen we op een schatting van 112 uur, maar dit zou meer of minder kunnen zijn afhankelijk van de samenwerking met de andere partijen.
Voor de frontend werkzaamheden hebben wij alle controle, gebaseerd op onze planning stellen we voor om dat deel van het project resultaat gericht te offreren. Wij denken voor de pure frontend 4 weken 40u per week nodig te hebben.