GEMMA Online

Gemeentelijke Applicatiearchitectuur Omgevingswet

Requirements Omgevingsbeleidscomponenten

Introductie

Op deze bladzijde bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de planvormingssoftware per 2021. Requirements geven inzicht in de wensen en eisen die we stellen aan software. Het betreft hier de software die nodig is voor het maken en wijzigen van omgevingsvisie, programma en omgevingsplan. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor planvorming dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. plan juristen) , medewerkers van ICT (functioneelbeheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software. Binnen de Gemeentelijke Model Architectuur (GEMMA) wordt deze groep componenten (applicaties) ook wel omgevingsbeleidcomponenten genoemd, of te wel de applicaties die het maken van beleid voor de Omgevingswet ondersteunen.


Iteratief: Nu een 1.0 versie, straks een 1.1

De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.0 versie. Dit is een voorlopig stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor planvorming. Het betreft hier nadrukkelijk niet de definitieve versie van de requirements. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de ontwikkeling van STOP-TPOD of de samenwerkingsruimte. Beide onderwerpen zijn nog in beweging en gaan zorgen voor aanpassingen in de requirements.

Let op: halverwege november 2019 zal een geüpdate versie (1.1) van de requirements verschijnen.

Requirements en aanbesteding

Wil een gemeente in de zomer van 2019 starten met een aanbesteding, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? VNG komt deze zomer met zowel een masterclass aanbesteden van Omgevingswet software als met een Handreiking Aanbesteden.

Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking ook vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: Op welke manier zal de leverancier de workflow voor het opstellen van een omgevingsplan ondersteunen? Of op welke manier gaat de leverancier ondersteuning bieden aan het koppelen van juridische en toepasbare regels?

Uniforme manier van uitvragen

Met de requirements en de nog te verschijnen leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de plansoftware. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers op gebied van planvorming staan al onder druk om op 1 januari 2021 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.

Wettelijkverplicht, basis en plus

Wat is nu echt softwarefunctionaliteit die een gemeente per 1 januari 2021 nodig heeft? Welke is nodig, maar kan ook eventueel na 1 januari? En welke functionaliteit is niet essentieel en kan iedere gemeente voor zich zelf besluiten of ze deze functionaliteit wil gebruiken. Hiervoor hanteren we de onderstaande driedeling. Per component is aangeven in welke categorie deze bij benadering valt. Daarnaast worden op korte termijn de categorieën ook gekoppeld aan de individuele requirements.

  • Wettelijk verplicht: requirements op basis van de wet
  • Basis: requirements die nodig zijn om Omgevingswet goed te ondersteunen en dienstverlening op zelfde niveau te houden
  • Plus: functionaliteit bovenop de basis, bijvoorbeeld ten behoeve van innovatie

Doorontwikkeling applicaties: Na 1 januari 2021 zal de software voor planvorming zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software. Komende periode zal deze doorontwikkeling verder in beeld worden gebracht.

Overzicht Omgevingsbeleidcomponenten

De Omgevingsbeleidcomponenten vormen gezamenlijk de software die benodigd is voor het opstellen van beleid voor de Omgevingswet. Denk hierbij aan het wijzigen van het omgevingsplan of het maken van een omgevingsvisie. Onder de Omgevingsbeleidcomponent vallen een aantal subcomponenten.

Toekomstige component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingsdocumenten welke is ondergebracht in vier sub-componenten: * Regelingencomponent: wijzigen van tekst en kaart (voor omgevingsvisie, programma en omgevingsplan) * Werkprocescomponent: ondersteunen van werkproces voor wijzigen tekst en kaart * Publicatiecomponent: publiceren en archiveren van omgevingsbeleid * Viewercomponent: tonen van regelingen (tekst en kaart) onder andere voor besluitvorming (ApplicationComponent) Omgevingsbeleidcomponent Component voor het ondersteunen van het werkproces voor het opstellen van omgevingsbeleid (visie, programma en plan). Deze component is onderdeel van Omgevingsbeleidcomponent. (ApplicationComponent) Werkprocescomponent Component voor het publiceren en archiveren van regelingen (Omgevingsvisie, programma en omgevingsplan). Deze component is onderdeel van de omgevingsbeleidcomponent. (ApplicationComponent) Publicatiecomponent Component voor het weergeven van omgevingsbeleid (omgevingsplan, omgevingsvisie en programma) in tekst en kaart onder andere bedoeld voor het ondersteunen van besluitvorming. Deze component is onderdeel van omgevingsbeleidcomponent. (ApplicationComponent) Viewercomponent Component voor het opstellen van regelingen met tekst en werkingsgebied. Onderdeel van Omgevingsbeleidcomponent (ApplicationComponent) Regelingcomponent Component voor het tekenen en wijzigen van geometrieen van omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent.. (ApplicationComponent) Geometriecomponent Component voor het opstellen en wijzigen van tekst in een regeling. Bedoeld voor wijzigen van omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent.. (ApplicationComponent) Tekstcomponent Deze svg is op 21-07-2019 01:23:13 CEST gegenereerd door ArchiMedes © 2016-2018 XL&Knowledge. ArchiMedes 21-07-2019 01:23:13 CEST

Overzicht Omgevingsbeleidcomponenten (uit model: Omgevingswet) - Toon SVG


Modulaire opzet: De omgevingsbeleidcomponent is modulair opgezet. Iedere subcomponent is of een module binnen een grotere softwaresuite of een apart aan te schaffen applicatie. Het is aan de gemeente om te kiezen op welke manier zij de applicaties willen aanschaffen. Kiest de gemeente voor één pakket van één leverancier of gaat ze voor een "best of breeds" aanpak waarbij verschillende applicaties van verschillende leveranciers samenwerken. Een gemeente kan dan bijvoorbeeld kiezen voor de tekstcomponent van leverancier X en de geometriecomponent van leverancier Y terwijl de viewercomponent weer afgenomen wordt bij leverancier Z. Het geheel van componenten kan in de Common Ground gedachte worden ondersteund met een omgevingsbeleidregistratiecomponent, of te wel een aparte component waarin de gegevens uit de andere componenten worden opgeslagen en kunnen worden ontsloten.

Onderstaande geeft een overzicht van de component met sub-componenten. Van iedere component kunnen de requirements als CSV worden gedownload.

Omgevingsbeleidcomponent (download als CSV) waarbinnen vallen de:

Omgevingsbeleidcomponent

Omschrijving: Toekomstige component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingsdocumenten welke is ondergebracht in vier sub-componenten:

  • Regelingencomponent: wijzigen van tekst en kaart (voor omgevingsvisie, programma en omgevingsplan)
  • Werkprocescomponent: ondersteunen van werkproces voor wijzigen tekst en kaart
  • Publicatiecomponent: publiceren en archiveren van omgevingsbeleid
  • Viewercomponent: tonen van regelingen (tekst en kaart) onder andere voor besluitvorming

Hieronder staan de generieke requirements die voor alle omgevingsbeleidcomponenten (visie, programma en plan) gelden. De drie componenten zijn specialisaties van de Omgevingsbeleid- en regelbeheercomponent en overerven daarmee dus de generieke functies.

De procesondersteunende systemen zullen na publicatie (van de visie, programma of plan) voor hun opslag aangewezen zijn op de landelijke voorzieningen (LVBB, DSO-LV Register Toepasbare Regels etc). Echter, voor de wijzigingsfase binnen de gemeenten is er wel een eigen registratie nodig. Evenals in de conceptfase waarin wordt samengewerkt met ketenpartners, waarbij tevens een koppeling nodig is met de DSO-LV samenwerkingsruimte die in deze fase gebruikt kan worden.

Dat leveranciers na publicatie voor een optimalisatie kiezen om kopie-gegevens te hebben in hun oplossingen is een keuze, zolang ze maar de brongegevens tijdig van de juiste voorziening halen.

Functionele requirements
Aantal: 2
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OB00 Voldoet aan STOP-TPOD Kunnen voldoen aan nieuwste versie van STOP-TPOD. Voor eisen verwijzen we in algemene zin naar de documentatie bij de standaard. Een aantal specifieke eisen zijn opgenomen in de requirements.


Must
OB01Kunnen synchroniseren met landelijke voorziening Kunnen ophalen van regelingen (omgevingsvisie, programma, omgevingsplan) uit LVBB dan wel DSO-LV OZON conform STOP-TPOD


Must
  • Download als CSV


Regelingcomponent

Omschrijving: Component voor het opstellen van regelingen met tekst en werkingsgebied. Onderdeel van Omgevingsbeleidcomponent

Functionele requirements
Aantal: 10
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBR00 Kunnen aanbeiden van tekst en geometrie als eenheid Kunnen combineren van tekst en geometrie als eenheid volgens STOP-TPOD


OBR01 Kunnen leggen van de relatie juridische regels en toepasbare regels
  • Kunnen leggen van een relatie tussen juridische en toepasbare regels.
  • Requirement wordt in volgende versie verder gespecificeerd.


 Could
OBR02 Kunnen tijdreizen in regelingen
  • Kunnen inzien van oude, huidige en nieuwe regelingen.
  • Kunnen zien van verschillen (wijzigingen) in regelingen.


 Could
OBR03 Kunnen ondersteunen van samenwerking !! Requirement in onderzoek!! Wordt aangevuld in volgende versie van requirements.

Onder kunnen ondersteunen van samenwerking verstaan we:

  • Kunnen gebruiken van DSO-LV upload/download API voor documenten
  • Kunnen gebruiken van DSO-LV upload/download API voor regelingen (in STOP-TPOD)
  • Kunnen ontvangen van notificatie als nieuwe documentatie da wel regeling beschikbaar is
  • Kunnen viewen van regelingen (inclusief regelingen in wording)
  • Kunnen aangeven dat (ander) bevoegd gezag in bepaald gebied een regeling aan het aanpassen is in geval van meervoudig bronhouderschap (zaakgericht)
  • Samenwerking voor initiatiefnemers en stedebouwkundige bureau's.


 Could
OBR04 Kunnen ondersteunen van tegelijk werken aan plan binnen organisatie
  • Kunnen ondersteunen van voorkomen van fouten door wijzigen van zelfde artikel door verschillende medewerkers.
  • Kunnen bieden van inzicht aan gebruiker van elkaars werkzaamheden
  • Kunnen samenvoegen van wijzigingen


 Must
OBR05 Kunnen ondersteunen bij samenloop
  • Onder samenloop wordt de situatie verstaan waarin een tekstuele afhankelijkheid tussen twee (of meer) wetsvoorstellen (of met betrekking tot een wet die nog niet in werking is getreden) bestaat terwijl de procedures van totstandkoming in de tijd onafhankelijk van elkaar verlopen.
  • * Requirement wordt in volgende versie verder gespecificeerd.


 Must
OBR06 Kunnen bieden van kwaliteitsbewaking Hieronder wordt verstaan:
  • Tijdens het opstellen de tekst en geometerie valideren op zaken als: verplichte velden ingevuld, gesloten zijn van geometrie, eventuele verplichte annotaties etc.


 Could
OBR07 Kunnen bieden van inzicht in inhoud van regeling Kunnen bevragen van de dataset behorende bij de regeling. Hierbij valt te denken aan:
  • kunnen tonen van locatie in combinatie met annotatie
  • kunnen tonen van annotatie in combinatie met andere annotatie.

Hierbij valt te denken aan een vraag als: geef me inzicht in waar ik tot 10 meter hoogte mag bouwen.


Could
OBR08Kunnen vergelijken van (onderdelen van) regelingen Kunnen vergelijken van regelingen (oud, huidig en toekomstig) met als doel het detecteren van de verschillen tussen de regelingen.


Must
OBR09 Kunnen leggen van relatie tussen eigen omgevingsdocument en ander omgevingsdocument Kunnen vastleggen van de relatie tussen de regels die vastgesteld worden in de diverse onderdelen (visie, programma, plan en toepasbare regels).

Doel: Intern toetsen van de impact van de samenhang van de regels tussen deze onderdelen (visie, programma, plan en toepasbare regels).


Could
  • Download als CSV


Tekstcomponent (categorie: wettelijk verplicht)

Omschrijving: Component voor het opstellen en wijzigen van tekst in een regeling. Bedoeld voor wijzigen van omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent..

Functionele requirements
Aantal: 7
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBT01 Kunnen wijzigen en intrekken van juridische regels en waarden Kunnen wijzigen (incl. toevoegen) en intrekken (verwijderen) van regels:

In de systematiek van de toepassingsprofielen voor OW-besluiten bestaan regels uit de volgende onderdelen:

  • de juridische regeltekst
  • informatie-objecten, waaronder: de coördinaten die de werkingsgebieden van regels begrenzen en de waarden die de normen uit de juridische regeltekst ter plaatse van de verschillende werkingsgebieden hebben;
  • de annotaties: elementen waarmee betekenis aan regeltekst en informatie-objecten wordt toegevoegd en die het OW-besluit machine-leesbaar maken en het mogelijk maken om regeltekst, werkingsgebieden en waarden betekenisvol en leesbaar weer te geven, waar nodig op een kaart.


 Must
OBT02 Kunnen annoteren van juridische regels, en waarden (juridisch spoor) Kunnen annoteren van juridische- en beleidsregels, waarden en werkingsgebied. (In LVBB het juridisch spoor genoemd.)
  • Onder annoteren verstaan we het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen die tekst machine-leesbaar maken en/of het mogelijk maken dat bepaalde gegevens op een kaart weergegeven worden.


 Must
OBT03 Kunnen annoteren ten behoeve van het servicespoor
  • Kunnen annoteren ten behoeve van het servicespoor. Dit heeft betrekking op alle onderdelen van de regeling.
  • Dit service spoor bevat additionele informatie die machineleesbaarheid en slimme bevraging verbeteren maar de juridische informatie niet verandert.
  • Hieronder valt ook: Kunnen annoteren van individuele woorden in een regeling. Bijvoorbeeld: kunnen aangeven dat de tekst een omgevingswaarde betreft.


 Must
OBT04 Kunnen toevoegen van metadata aan een regeling Kunnen toevoegen van metadata aan regeling zoals gedefinieerd in STOP (IMOP). Waaronder: Concept, Ontwerp, Vastgesteld, Inwerkingtreding, Onherroepelijk en ook naam


Must
OBT05 Kunnen leggen van een relatie met geometrie Kunnen uitwisselen van gegevens met geometriecomponent en daarmee leggen van relatie tussen tekst en geometrie.


Must
OBT06 Kunnen ondersteunen van waardelijsten
  • Kunnen ondersteunen van waardelijsten zoals gedefinieerd binnen STOP-TPOD en voor het omgevingsplan uitgewerkt in document 17 van de standaard.
  • Kunnen aanpassen van de waardelijst.
  • Kunnen importeren van waardelijst.


 Must
OBT07 Kunnen interacteren met de DSO stelselcatalogus Kunnen interacteren met de DSO stelselcatalogus, hieronder vallen sub-requirements:
  • Gebruiken van begrippen uit Stelselcatalogus
  • Begrippen toevoegen aan Stelselcatalogus
  • Requirement wordt in volgende versie verder gespecificeerd.
  • Wordt verder gespecificeerd in volgende versie van de requirements.


 Could
  • Download als CSV


Geometriecomponent (categorie: basis)

Omschrijving: Component voor het tekenen en wijzigen van geometrieen van omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent..

Functionele requirements
Aantal: 5
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBG01 Kunnen tekenen en wijzigen van geometrie Kunnen tekenen en wijzigen van een geometrie.


Must
OBG02 Kunnen overnemen van geometrie Hieronder wordt verstaan:
  • Kunnen importeren van geometrie middels extern bestand (GIS / CAD applicatie)
  • Kunnen overnemen van geometrie via applicatie service


 Must
OBG03 Kunnen leggen van een relatie met tekst Kunnen leggen van een relatie met (onderdelen) van tekst uit de tekstcomponent.


Must
OBG04 Kunnen ophalen en overnemen van geometrie en ID uit (basis)registraties Hieronder wordt verstaan:
  • Het kunnen ophalen van objecten en gegevens uit de Basisregistratie Grootschalige Topografie (BGT), Basisregistratie Adressen en Gebouwen (BAG) en Basisregistratie Kadaster (BRK) en gemeentelijke Kernregistraties.
  • Het kunnen relateren van het werkingsgebied van een omgevingsregel aan een object uit de basis- of kernregistraties.
  • Kunnen ophalen van ambtsgebied.


 Could
OBG05 Kunnen ondersteunen van 3D Kunnen ondersteunen van 3D.


Could
  • Download als CSV


Werkprocescomponent (categorie: plus)

Omschrijving: Component voor het ondersteunen van het werkproces voor het opstellen van omgevingsbeleid (visie, programma en plan). Deze component is onderdeel van Omgevingsbeleidcomponent.

Functionele requirements
Aantal: 4
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBWP01 Kunnen besturen van gehele werkproces (generiek voor omgevingsbeleid) Kunnen besturen van werkproces voor het opstellen van omgevingsdocumenten (visie, progamma, plan). Hieronder vallen een aantal sub-requirements.


Could
OBWP 01.1 Kunnen monitoren van statussen
OBWP 01.2 Kunnen instellen en bijhouden van doorlooptijden gedurende het wijzigingsproces
OBWP 01.3 Kunnen doen van termijnbewaking zoals gedefinieerd volgens de wet
OBWP 01.4 Kunnen doen van termijnbewaking conform eigen service termijn
OBWP02 Kunnen ondersteunen van werkproces opstellen of wijzigen omgevingsvisie Kunnen ondersteunen van het werkproces voor het opstellen dan wel wijzigen van een omgevingsvisie zoals gedefineerd op GEMMAonline.


Could
OBWP03 Kunnen ondersteunen van werkproces opstellen of wijzigen programma Kunnen ondersteunen van het werkproces voor het opstellen dan wel wijzigen van een programma zoals gedefineerd op GEMMAonline.


Could
OBWP04 Kunnen ondersteunen van werkproces opstellen of wijzigen omgevingsplan Kunnen ondersteunen van het werkproces voor het opstellen dan wel wijzigen van een omgevingsplan zoals gedefineerd op GEMMAonline.


Could
  • Download als CSV


Publicatiecomponent (categorie: wettelijk verplicht)

Omschrijving: Component voor het publiceren en archiveren van regelingen (Omgevingsvisie, programma en omgevingsplan). Deze component is onderdeel van de omgevingsbeleidcomponent.

Functionele requirements
Aantal: 7
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBP01 Kunnen genereren van was/wordt instructies Hieronder wordt verstaan:
  • Kunnen detecteren van de verschillen (op basis van de STOP) tussen oude en nieuwe versies van de regeling (tekst, annotaties en datacollecties waaronder geometrie ) (was-wordt).
  • Kunnen genereren van een was-wordt instructie welke aan het (wijzigings)besluit wordt toegevoegd.
OBP02 Kunnen consolideren van de regeling Hieronder wordt verstaan:
  • het over elkaar heen leggen van (eerder gemaakte) was-wordt-mutaties uit wijzigingsbesluiten tot een geconsolideerde regeling (omgevingsplan, omgevingsvisie of programma)


 Could
OBP03 Kunnen doorgeven van relevante procedure gevens
  • Denk hierbij aan kunnen aangeven van af en tot wanneer een besluit in werking treed.


 Must
OBP04 Kunnen publiceren van initiele versie van regeling Kunnen publiceren van eerste versie van de regeling (bijvoorbeeld omgevingsplan van rechtswege) waarna volgende publicaties wijzigingsbesluiten zijn.
  • in onderzoek: wat is exact de eerste versie


 Must
OBP05 Kunnen valideren van besluiten via LVBB Kunnen valideren van besluit via LVBB validatie service.


Must
OBP06 Kunnen aanleveren van besluiten aan LVBB Hieronder wordt verstaan:
  • Kunnen aanleveren van initieel- of wijzigingsbesluit naar de LVBB volgens STOP-TPOD om besluit beschikbaar te stellen en bekend te maken.
  • Kunnen gebruiken van digikoppeling voor aanlevering aan LVBB


 Must
OBP08 Kunnen archiveren van besluiten Hieronder wordt verstaan:
  • Kunnen archiveren van besluiten in STOP/TPOD
  • Kunnen aanleveren van besluiten aan archiefregistratiecomponent

Let op: De gemeente is zelf verantwoordelijk voor het conform wettelijke normen archiveren van haar besluiten. De LVBB vervult deze functie niet.


Must
  • Download als CSV


Viewercomponent (categorie: basis)

Omschrijving: Component voor het weergeven van omgevingsbeleid (omgevingsplan, omgevingsvisie en programma) in tekst en kaart onder andere bedoeld voor het ondersteunen van besluitvorming. Deze component is onderdeel van omgevingsbeleidcomponent.

Functionele requirements
Aantal: 4
Requirement Toelichting MoSCoW
MoSCoW-methode


De MoSCoW-methode is een wijze van prioriteiten stellen in onder meer de software engineering. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor:

  • M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
  • S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
  • C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
  • W - would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "won't haves".
OBV01 Kunnen tonen van omgevingsbeleid op een kaart
  • Kunnen tonen van omgevingsbeleid (omgevingsvisie, omgevingsplan, programma) op een kaart op basis van STOP-TPOD presentatieweergave
  • Kunnen tonen van wijzigingen in regeling op een kaart op basis van STOP-TPOD presentatieweergave


 Must
OBV02 Kunnen tonen van omgevingsbeleid als tekst
  • Kunnen tonen van omgevingsbeleid (omgevingsvisie, omgevingsplan, programma) als tekst op basis van STOP-TPOD presentatieweergave
  • Kunnen tonen van wijzigingen in regeling als tekst op basis van STOP-TPOD presentatieweergave


 Must
OBV03 Kunnen tonen van verschillen tussen regelingen


Must
OBV04 Kunnen plaatsen van opmerkingen bij tekst dan wel kaart Mogelijkheid om opmerkingen te plaatsen bij tekst of kaart welke door andere gebruikers kan worden gezien.


Could
  • Download als CSV




Overgenomen van "https://www.gemmaonline.nl/index.php?title=GAO_-_Omgevingsbeleidscomponenten&oldid=703097"